OpenGL state redundancy elimination Tree, render state priorities

Question

I am working on a Automatic OpenGL batching method in my Game Engine, to reduce draw calls and redundant calls.

My batch tree design begins with the most expensive states and adds leafs down for each less expensive state.

Example: Tree Root: Shaders / Programs Siblings: Blend states ... a.s.o.

So my question is what are most likely the most expensive calls, in this list:

• binding program
• binding textures
• binding buffers
• buffering texture, vertex data
• binding render targets
• glEnable / glDisable
• blend state equation, color, functions, colorWriteMask
• depth stencil state depthFunc, stencilOperations, stencilFunction, writeMasks

Also wondering which method will be faster:
- Collect all batchable draw commands to single vertex buffer and call only 1 draw call (this method would also force to update matrix transforms per vertex on cpu side)
- Do not batch at all and render many small draw calls, only batch particle system ...

PS: Render Targets will always Pre or Post changed, depending on usage.

Progress so far:

• Andon M. Coleman: Cheapest Uniform & Vertex Array Binding, Expensive FBO, Texture Bindings
• datenwolf: Programs invalidate State Cache

1: Framebuffer states
2: Program
3: Texture Binding
...
N: Vertex Array binding, Uniform binding

Current execution Tree in WebGL:

• Program
• Attribute Pointers
• Texture
• Blend State
• Depth State
• Stencil Front / Back State
• Rasterizer State
• Sampler State
• Bind Buffer
• Draw Arrays

Each step is a sibling hash tree, to avoid checking agains state cache inside of main render queue

Loading Textures / Programs / Shaders / Buffers happens before rendering in an extra queue, for future multi threading and also to be sure that the context is initialized before doing anything with it.

The biggest problem of self rendering objects is that you cannot control when something happens, for example if a developer calls these methods before gl is initialized, he wouldn't know why but he would have some bugs or problems...

Answer 1

The relative costs of such operations will of course depend on the usage pattern and your general scenario. But you might find Nvidia's "Beoynd Porting" presentation slides as a useful guide. Let me reproduce especially slide 48 here:

Relative Cost of state changes

• In decreasing cost...
• Render Target ~60K/s
• Program ~300K/s
• ROP
• Texture Bindings ~1.5M/s
• Vertex Format
• UBO Bindings
• Uniform Updates ~10M/s

This does not directly match all of the bullet points of your list. E.g. glEnable/glDisable might affect anything. Also GL's buffer bindings are nothing the GPU directly sees. Buffer bindings are mainly a client side state, depending on the target, of course. Change of blending state would be a ROP state change, and so on.

Answer 2

This tends to be highly platform/vendor dependent. Any numbers you may find apply to a specific GPU, platform and driver version. And there are a lot of myths floating around on the internet about this topic. If you really want to know, you need to write some benchmarks, and run them across a range of platforms.

With all these caveats:

• Render target (FBO) switching tends to be quite expensive. Highly platform and architecture dependent, though. For example if you have some form of tile based architecture, pending rendering that would ideally be deferred until the end of the frame may have to be completed and flushed out. Or on more "classic" architectures, there might be compressed color buffers or buffers used for early depth testing that need consideration when render targets are switched.

• Updating texture or buffer data is impossible to evaluate in general terms. It obviously depends heavily on how much data is being updated. Contrary to some claims on the internet, calls like glBufferSubData() and glTexSubImage2D() do not typically cause a synchronization. But they involve data copies.

• Binding programs should not be terribly expensive, but is typically still more heavyweight than the state changes below.

• Texture binding is mostly relatively cheap. But it really depends on the circumstances. For example, if you use a GPU that has VRAM, and the texture is not in VRAM at the moment, it might trigger a copy of the texture data from system memory to VRAM.

• Uniform updates. This is supposedly very fast on some platforms. But it's actually moderately expensive on others. So there's a lot of variability here.

• Vertex state setup (including VBO and VAO binding) is typically fast. It has to be, because it's done so frequently by most apps that it can very quickly become a bottleneck. But there are similar consideration as for textures, where buffer memory may have to be copied/mapped if it was not used recently.

• General state updates, like blend states, stencil state, or write masks, are generally very fast. But there can be very substantial exceptions.

Just a typical example of why characteristics can be so different between architectures: If you change blend state, that might be sending a couple of command words on one architecture, with minimal overhead. On other architectures, blending is done as part of the fragment shader. So if you change blend state, the shader program has to be modified to patch in the code for the new blending calculation.