-
-
Save tilkinsc/e9ecf0e1653df40afdb9d62ff6d7b5cc to your computer and use it in GitHub Desktop.
See https://gist.github.com/tilkinsc/7f383faccf3722622f5d0cc9bd45e7e6 |
I didn't realize you had moved past this gist, I apologize. However this gist is what shows up on Google when you search "WGL" which explains the level of engagement this particular gist gets.
You are right that using multiple threads is fighting against the design of OpenGL but it DOES net you a significant performance boost, it just doesn't come entirely from the GPU (only the async DMA part). OpenGL draw commands can only be sent by one thread and that can't be changed because that's how GPUs work in general but if you generate commands from threads and get them to execute on the render thread you are utilizing much more of your CPU, without mentioning the async DMA you get from a shared context in a separate thread. In fact this is what Vulkan does. While OpenGL hides the "command queues" behind context objects, Vulkan gives you access to command buffers you can use. You mention drivers breaking but actually they have evolved to accept this kind of process (and OpenGL's API has too) since developers are using OpenGL more and more like this which even helps towards making an abstraction layer of OpenGL, Vulkan and DirectX 12.
If you want I can provide an example of OpenGL threading with software command queues and an async DMA thread.
If you want I can provide an example of OpenGL threading with software command queues and an async DMA thread.
I would be interested in seeing this myself!
Check it out I did a huge update.
I also came to the conclusion that having multiple render threads is more work than is needed, creates race conditions, breaks opengl/drivers ability to optimize, and has no point because nearly everything is async. I think the only time you want multiple threads and contexts would be when you have multiple windows.