Updating buffers more than once per frame

[floooh]

Updating buffers more than once per frame

[floooh]

Yes, the restriction exists to prevent lock-stalls where the CPU would be blocked until a buffer is no longer in use by the GPU. Some APIs provide internal buffer renaming (e.g. D3D's LockDiscard and LockNoOverwrite), but on OpenGL and especially WebGL it's more complicated (in OpenGL there are tricks like buffer orphaning, but none of this works in WebGL). Metal is yet another issue. So sokol-gfx does its own double-buffering (except on D3D11 where LOCK_DISCARD is used, so that D3D switches buffer under the hood itself). Each dynamic buffer is allocated twice, and while the CPU copies data to one buffer, the GPU uses the other one for rendering, and in the next frame roles are switched.

Removing the above check might work on OpenGL, but depending on the driver and OpenGL variant (GLES2, WebGL etc...) a CPU lock-stall will happen, and on Metal you'll most likely get rendering artefacts.

[floooh]

PS: there's a few ways to solve the issue, in your code you could have a buffer pool, which you initialize with different size buckets, for instance 16 buffer with room for 1024 vertices, 8 buffers room for 2048, etc... in spritebatch_end() you grab a buffer which is closest to the required size, and copy the data over. If there's no free buffer, create a new one. At the end of the frame, move all used buffers back into the free buckets.

The other option is to create one buffer with the max number of indexable vertices (64k for 16-bit indices), and a second memory buffer of the same size. Fill the memory buffer up during the frame, and keep a record where each sprite batch starts in the vertex/index buffer and the number of elements to render in that batch (don't render them yet in spritebatch_end(). At the end of the frame, have a spritebatches_draw(), which does one big buffer update copy, and renders all sprite batches in a loop. This is probably the most efficient way.