[tsherif]

> i even found out that a call like glBufferSubData will call malloc or related functions. so doing that on each frame seems to be a bad idea as well.

That's interesting and not what I'd expect at all! Is there documentation you could point me to or did you find that out with some tooling? And is there a better way to update attribute buffers for instanced draw calls?

[b20000]

I did not look up any documentation to verify this but since I did override all allocation functions I could keep statistics of how many calls I was getting for each function, and when I commented out the glBufferSubData calls I could see my stats drop. The contribution was somewhere around 300 calls/s I think... this is with the panfrost driver with gallium/mesa on an ARM platform. My plan is to use persistent buffers which are memory mapped once. Hopefully that will get rid of these allocation calls.

[Impossible]

This is one of the main advantages of using a lower level library like Vulkan or DX12. Higher level APIs like OpenGL and DX11 do a lot of work for you, but that work can result in extra allocations that you can't control, starting driver threads, extra resource transitions, etc

[tsherif]

Thanks for the tip! I'll try to figure out if something similar is happening on either of the machines I'm using. That's a bummer that an in-place update function would be allocating behind the scenes...

[kaetemi]

I'm guessing the data is copied to a temporary buffer. The target GL buffer can still be in flight for previous operations. If I remember correctly, that safety can be disabled with the right incantation of flags on the buffer.

[b20000]

in that case you probably need a barrier? which is what you need with persistent mapping too?