As CPUs with more and more cores arrive, it will become increasingly important for rendering code to be multithreaded, which conflicts with the (very nice) single-threaded state management approach of OpenGL.
So I propose that the display list functionality be extended to support quick recording from other threads, being committed to the main GPU rendering queue only from the main thread, this concept works well with the existing OpenGL state machine.
Some consideration must be given to the rapid creation and deletion of dynamic lists, as well as rapid insertion of both dynamic and compiled lists into new dynamic lists.
For example a light source may possess two lists (shadow volumes and lit meshes) created by the main thread, to which the secondary threads append their temporary lists, finally being called by the main thread at the appropriate stage of rendering.
A game wants optimal efficiency, so it is likely to invoke threads on ALL renderable objects in the scene at once, including multiple light sources and other objects, as well as off-screen rendering tasks like reflection textures, updating physics data using the GPU, mixing sound data, etc.
The insertion order is mostly random due to the multithreading nature of such a system, but the lists are appended to lists that will be drawn in the correct rendering stage, so the order does not significantly matter.
This seems to me like the best approach to multithreading functionality in OpenGL, without rearchitecting the existing functionality.
As they say, if it ain’t broke, don’t fix it
You should perhaps read all the forum threads and GDC presentations about GL Long Peaks, and the two OpenGL pipeline newsletters, and then reconsider your suggestion
Basically, display lists as we have them now won’t exist in the next OpenGL version. What we have now is just a command macro, recording this in parallel would not speed anything up, as the playback would have to be serialized anyway.
There will be a geometry only replacement for display lists. Constructing them in another thread could be interesting, but I don’t think it’s really needed.
Better just prepare some sort of “high level” rendering queue in multiple threads, and play them back manually in the rendering thread. This should only be a single call per drawn object in the new API, so the CPU overhead is minimal (and the GPU work won’t be parallel).
You can also use memory mapped VBOs, they can be filled from other threads. Then just issue the drawing calls in the rendering threads. Drawing calls in other threads don’t make sense because it has to be serialized for the GPU.
I know nothing about “GL Long Peaks” and have never heard of it. Nor have I heard of “OpenGL pipeline newsletters”. I do not know where to find these things, I followed the link to opengl.org from khronos.org and found this section of this forum and figured it would be a good place to suggest a means of multithreaded OpenGL, to compete with multithreaded Direct3D9.
The purpose of such lists is not to improve rendering performance in a single threaded case but to improve performance in a multithreaded case, where the OpenGL command validation and other chores can be threaded, migrating such overhead away from the main thread.
Regarding memory mapped VBOs, that is only useful for CPU-calculated geometry, which is already disasterous for performance, and is not what I was referring to, such geometry generation has nothing to do with the multithreaded OpenGL functionality I was suggesting, although I can see where you may have gotten that idea.
I know nothing about “GL Long Peaks” and have never heard of it. Nor have I heard of “OpenGL pipeline newsletters”. I do not know where to find these things,
You didn’t bother to even Google “GL Long Peaks”. In 2 seconds, the top two searches would tell you 50% of what you needed to know. And from there, you would find links to the rest.
Since you didn’t bother to use the most basic tool on the Internet, you have no right to actual information until you’ve made some good-faith effort to find out for yourself.
Forest hale, multithreaded rendering makes absolutely no sense. In respect to this, the single-threaded model of OpenGL is very reasonable. What makes sense is multithreaded data loading, which you can have with VBOs.
I did google for OpenGL Longs Peak and read all about it, I just didn’t choose to make another post explaining that I had done so as it seemed redundant.
Since OpenGL Longs Peak is lowering overhead and getting rid of display lists the point is moot.
As I said this is the first time I’ve seen any mention anywhere about new OpenGL developments beyond the usual extension and integration process, none of my fellow engine developers had heard about any progress either, it seems to be little known outside opengl.org.
To be clear, I opened this thread specifically because I thought I had something to contribute to the discussion of the slow evolution of OpenGL (which Longs Peak and Mt Evans development seem to be making not so slow), I am saddened that after Overmind’s informative reply to my suggestion, the thread has devolved into bitterness, in what was completely intended as a technical discussion.
There are a few things that could be said, or perhaps you already know this :
- Multithreading is not important for GL’s spec because those are implmentation details
- If you are writing drivers, go ahead and spawn 2 or more threads
- Seems as if nVidia does this for people with dual core but who knows what they do within those threads
- The GL layer will still support good old GL 2.1 so display lists will be around for decades to come.
Longs Peak and Mt Evans :
Things like this get announced at GDC, forums like gamedev.net, nehe, …
Obviously this site and khronos are the best sources.