<p>Nvidia has an <a href="http://developer.download.nvidia.com/opengl/specs/GL_NV_command_list.txt" rel="nofollow noreferrer">extension for creating command buffers in modern GL</a>.</p>

<p>The reason for the lack of similar functionality is that there is a lot of state involved regarding how to render and the display list be affected by a lot of different state. For example changing the blend state requires patching the fragment shader on some hardware.</p>

<p>NVidia solved it by capturing <em>all</em> state and reseting to the state after a dispatch:</p>

<blockquote>
  <p>1) What motivates the design?</p>
  
  <p>The primary goal is to be able to reuse pre-validated command buffers.
  Other APIs and proposals have addressed this with various incarnations
  of command  lists or state objects, but a recurring problem is that
  interactions between various stages of the pipeline prevent this
  prevalidation and reuse. These  interactions are often
  hardware-specific (and differ from vendor to vendor  or even
  generation to generation) and new interactions are introduced by  new
  features that were not imagined when the prevalidation scheme was 
  proposed.</p>
  
  <p>We attempt to address this by having a monolithic state object that 
  encompasses (almost) the entire state of the pipeline. This should
  provide enough information for all implementations to do any needed
  cross- validation. We try to create these in a way that minimizes the
  new API  footprint - since we want ALL state (including any added in
  the future), we just capture it from the current state of the context.</p>
  
  <p>[...]</p>
  
  <p>23) In what condition is the state left, that is modified by tokens,
  after the dispatch call?</p>
  
  <p>RESOLVED: state is reset.  </p>
</blockquote>

<p>(from the extension text linked above)</p>

<p>However the true successor is the command buffer functionality in DX12 and vulkan. Those will also capture all render state into a single object to use when creating and filling the command buffer. The NVidia extension is based on that architecture as a result of NVidia's involvement in the Vulkan design.</p>

CC BY-SA 3.0
2015-10-05T09:30:15.083Z
2016-11-07T09:59:51.000Z
2016-11-07T09:59:51.000Z
ratchet freak
<p>Display lists were an OpenGL feature that could, in theory, accelerate any part of the API by storing a group of commands for later use. In my understanding, this makes a lot of sense with regards to the current effort to reduce the driver overhead.</p>

<p>Display lists were deprecated in version 3.1 though. What is the modern API equivalent and does DirectX expose a similar feature? If there is no such functionality anymore, what is the rationale?</p>

<opengl><display-lists>
What is the modern equivalent of display lists?
Julien Guertault
# What is the modern equivalent of display lists?

(Asked by: username_0 on 2015-10-05)

Display lists were an OpenGL feature that could, in theory, accelerate any part of the API by storing a group of commands for later use. In my understanding, this makes a lot of sense with regards to the current effort to reduce the driver overhead.

Display lists were deprecated in version 3.1 though. What is the modern API equivalent and does DirectX expose a similar feature? If there is no such functionality anymore, what is the rationale?

**Tags:** opengl, display-lists


---

## 1 answers

### Answer by username_1 on 2015-10-05. Score: 12 | Accepted answer

Nvidia has an [extension for creating command buffers in modern GL](http://developer.download.nvidia.com/opengl/specs/GL_NV_command_list.txt).

The reason for the lack of similar functionality is that there is a lot of state involved regarding how to render and the display list be affected by a lot of different state. For example changing the blend state requires patching the fragment shader on some hardware.

NVidia solved it by capturing *all* state and reseting to the state after a dispatch:

> 1) What motivates the design?
>
> The primary goal is to be able to reuse pre-validated command buffers.
> Other APIs and proposals have addressed this with various incarnations
> of command lists or state objects, but a recurring problem is that
> interactions between various stages of the pipeline prevent this
> prevalidation and reuse. These interactions are often
> hardware-specific (and differ from vendor to vendor or even
> generation to generation) and new interactions are introduced by new
> features that were not imagined when the prevalidation scheme was
> proposed.
>
> We attempt to address this by having a monolithic state object that
> encompasses (almost) the entire state of the pipeline. This should
> provide enough information for all implementations to do any needed
> cross- validation. We try to create these in a way that minimizes the
> new API footprint - since we want ALL state (including any added in
> the future), we just capture it from the current state of the context.
>
> [...]
>
> 23) In what condition is the state left, that is modified by tokens,
> after the dispatch call?
>
> RESOLVED: state is reset.

(from the extension text linked above)

However the true successor is the command buffer functionality in DX12 and vulkan. Those will also capture all render state into a single object to use when creating and filling the command buffer. The NVidia extension is based on that architecture as a result of NVidia's involvement in the Vulkan design.


---

