A new direction for i965

I think display lists were mainly useful for specifying vertex data efficiently, compared to doing thousands of glVertex3f() calls per frame. But then OpenGL added vertex buffer objects, where the vertex data is stored directly in VRAM and you only need a handful of API calls to reference it, which is much simpler and more efficient than display lists. That largely eliminated the value of display lists and it was no longer worth the effort of supporting them in the API specification and in drivers.

Now GPUs have gotten really fast at drawing vertexes and pixels, so the bottleneck has moved back towards the API overhead and pipeline state changes, and we need a solution to that. Display lists are sort of the right idea, but aren't a good solution for modern hardware or applications.

Display lists are monolithic - they can affect the entire pipeline state at once, while hardware probably splits the pipeline into several independent chunks that could be changed relatively cheaply. They're incomplete - if any part of the state isn't specified, it gets inherited from the global state at call time (so is unknown when compiling the display list). They're immutable, while applications probably want to draw a lot of objects with identical state except for a few parameters that change frequently. They make the API complicated and inefficient, since pretty much every other API call changes behaviour if you're currently recording a display list. They put more complexity into the driver, which makes it harder for application programmers to understand how to optimise their use of the API.

Vulkan explicitly splits the pipeline state into about a dozen chunks that roughly map to modern hardware pipelines; you can reuse most of the state across all your draw calls and maybe change only a few chunks. It associates every draw call with a complete pipeline state object, so the complete state can be compiled and optimised ahead of time. It lets applications choose to make some state mutable(/dynamic). The API is reasonably orthogonal and doesn't depend on global state and can be used by multiple threads. It lets applications control allocation and caching so they don't have to second-guess the driver. Probably the most important design principle is that the Vulkan API tries to force applications to work in hardware-friendly ways (even if that's tricky for the application), whereas OpenGL tries to let applications work in application-friendly ways and then the driver has to scramble to map it onto the hardware.