The most confusing part to me is that the 'fast paths' in the API are not obvious, especially if you need to support older GL versions (GL2, GLES2). For instance:
- Using Vertex Array Objects should be fast since it's only a single call to change the vertex data binding. But in many GL implementations they are slower then using the old way calling VertexAttribPointer and EnableVertexAttribArray
- What's the fastest way to update dynamic vertex data? Buffer orphaning? Doing double buffering yourself? BufferData or BufferSubData? It's likely that the answer is different dependent on driver or GPU
Resource binding can introduce subtle errors by screwing up the GL state (for instance to create and initialize a resource you need to 'make it current', should the creation function restore the previous binding, or keep the GL state 'dirty'?)
Some call parameters are overloaded with completely different meaning depending on GL state. For instance the 'const void* pointer' argument in VertexAttribPointer is actually an integer offset and not a pointer if an array buffer is bound.
The most important problem which the OpenGL NG initiative tries to solve is validation overhead. In current OpenGL, an app can change every state at every time in the frame, and after each change (or rather before each draw call) the entire GL state must be validated. Most games (or 3D apps in general) only create a relatively small set of 'pre-compiled' state at startup and then just switch between these state presets. With this pattern, all expensive validation can happen once at startup, and not during the render loop.
- Using Vertex Array Objects should be fast since it's only a single call to change the vertex data binding. But in many GL implementations they are slower then using the old way calling VertexAttribPointer and EnableVertexAttribArray
- What's the fastest way to update dynamic vertex data? Buffer orphaning? Doing double buffering yourself? BufferData or BufferSubData? It's likely that the answer is different dependent on driver or GPU
Resource binding can introduce subtle errors by screwing up the GL state (for instance to create and initialize a resource you need to 'make it current', should the creation function restore the previous binding, or keep the GL state 'dirty'?)
Some call parameters are overloaded with completely different meaning depending on GL state. For instance the 'const void* pointer' argument in VertexAttribPointer is actually an integer offset and not a pointer if an array buffer is bound.
The most important problem which the OpenGL NG initiative tries to solve is validation overhead. In current OpenGL, an app can change every state at every time in the frame, and after each change (or rather before each draw call) the entire GL state must be validated. Most games (or 3D apps in general) only create a relatively small set of 'pre-compiled' state at startup and then just switch between these state presets. With this pattern, all expensive validation can happen once at startup, and not during the render loop.