6 ms·
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
by b20000 5y ago
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.
- tsherif 5y agoThanks 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 5y agoI'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 5y agoin that case you probably need a barrier? which is what you need with persistent mapping too?
- Impossible 5y agoThis 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
- deleted 5y ago[deleted]