With geometry display lists the hardware has the opportunity to perform both frustum and occlusion culling.
Actually, no.
Geometry display lists imply that all that is being stored is the pre-T&L geometry itself. That is, it could be usable with any vertex shader that accepts the inputs that the pre-T&L geometry provides.
Frustum culling requires the implementation to know how the vertex shader with transform the vertices, which by GL 3.0 standards is now entirely arbitrary. Thus, no frustum culling is possible.
By “occlusion culling,” I assume that you mean performing occlusion queries on some bounding region and then checking later to see if that object was visible before rendering the actual geometry. The problem there, once again, is the arbitrary T&L. The implementation cannot even tell what the input positional data is, let alone build a bounding volume that is guaranteed to encompass the post-T&L region.
No, the advantage of geometry display lists is in giving the driver the opportunity to rearrange your vertex data into a form most appropriate for rendering. For example, Humus mentioned in a previous thread the idea of making some vertex attributes accessible from a texture rather than a buffer object, to more effectively use parallelism. Well, the driver knows best when to do this, and the only information it needs to know is covered by the GL 3.0 Vertex Array Object (the shader can be patched to get its vertex data from a different place. It’s a quick patch). Thus, a geometry display list from well-built drivers will be able to parse your vertex data and split it into textures and so forth and more optimally use the hardware for maximum vertex throughput.
The only way for geometry display lists to be able to perform any kind of culling would require the reinstatement of fixed-function T&L.
I thought the point of OpenGL 3 was to reduce the complexity of the drivers.
Does nobody read the thread? How many times has it been mentioned how stupidly simple it is to implement geometry display lists? Let me make it abundantly clear for you all:
Driver complexity is not a valid issue here!
Why couldn’t display lists be implemented in something like GLU?
Because the purpose of geometry display lists is to get optimal performance for a particular piece of hardware. You cannot achieve that without hardware-independent code. And GL implementations cannot alter GLU.