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