4 ms·
It's an interesting idea, but you still have single threaded rendering in the end with OpenGL. However, you are able to keep that thread constantly busy which i
by warmwaffles 7y ago
It's an interesting idea, but you still have single threaded rendering in the end with OpenGL. However, you are able to keep that thread constantly busy which is a big plus.
- monocasa 7y agoThis fits really well with the single submission queue model, particularly if you're careful to use AZDO style OpenGL. You merge sort the lists once you're done with the frame, and then you have a pretty good approximation of the minimum state changes needed as you iterate through the sorted list on your submission thread. Now, the better implementations I've seen use per thread lists during queueing so you don't need any of the barriers or atomics here at all, but this is a good first pass.
- warmwaffles 7y agoAgreed, this is actually a fun exercise to think about
- tuxalin 7y agoIndeed, that's a limitation of OpenGL which is addressed with Vulkan, however you can still use this with Vulkan and make use of the other features like: command sorting, less verbose API or command keys. However, in most cases you wouldn't need the lock-free aspect of it (i.e. should be configurable), since in the end you would dispatch commands from their own threads, as monocasa well-pointed, that is something I do plan to do at some point (a solution better suited for Vulkan/D3D12), but sadly didn't had the free time.