very cool project. i wonder if the libraries used in this project also offer the guarantee of static allocations only / dyn allocations only at startup. i’ve been using the JUCE toolkit for a project the past 10 years and it has allocations all over the place. need 16 bytes? malloc. need to concat that string? a few mallocs for handfuls of bytes. i am stuck with it, so i have had to override malloc and friends and build my own fixed block size allocator. very annoying to find out you are only doing static allocations but then all the libs you use together amount to 3000 malloc calls per second. 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.
> 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?
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.
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
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...
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.
