GL_EXT_draw_elements_base_vertex support?

All this extension really changes is some semantics of setting up the attribute pointers, allowing multiple drawcalls to use the same attribute buffers with different offsets (i.e. you avoid the CPU load of the repeated attribute binding calls). It shouldn't change the actual rendering workload at all - can you explain why you think this helps performance? I'm probably missing something obvious .

EDIT To add a few more details behind my question - on most deferred architectures there is a minimum static cost per drawcall and per render target in terms of dispatch overhead to the hardware. State setting, such as attribute pointers, is generally really inexpensive - so I'd be really surprised if it was a problem unless you also have a lot of drawcalls (and hence a lot of rebinding calls). If this is the case then I doubt that the attribute setting is actually the cause of the slow performance - it's more likely down to the general drawcall cost - so I'm not entirely sure this extension will actually solve your problem.

Cheers,
Pete

All this extension really changes is some semantics of setting up the attribute pointers, allowing multiple drawcalls to use the same attribute buffers with different offsets (i.e. you avoid the CPU load of the repeated attribute binding calls). It shouldn't change the actual rendering workload at all - can you explain why you think this helps performance? I'm probably missing something obvious .

EDIT To add a few more details behind my question - on most deferred architectures there is a minimum static cost per drawcall and per render target in terms of dispatch overhead to the hardware. State setting, such as attribute pointers, is generally really inexpensive - so I'd be really surprised if it was a problem unless you also have a lot of drawcalls (and hence a lot of rebinding calls). If this is the case then I doubt that the attribute setting is actually the cause of the slow performance - it's more likely down to the general drawcall cost - so I'm not entirely sure this extension will actually solve your problem.

Cheers,
Pete

With this extension we are able to use the elements buffer as a ring buffer, updating portions of it as we go making sure to never trample GPU state as we go along.

Due to the nature of our application, we have many many updates that we have to push through the elements buffer, and without this extension it is the most inefficient for us.

Do you know what your "inefficiency" actually is? It's still not clear to me what the specific bottleneck your application is hitting (CPU load for binding, attribute setting, memory upload of index buffer data, etc).

If the overhead is index upload for new indices via glBufferSubData, what is stopping you using an existing "in memory" index buffer, and providing appropriately modified data offsets into glVertexAttribPointer per drawcall?

All this extension really provides is a cleaner interface to avoid the need for blatant "hacky" offset mangling in the application, but the ability to set an arbitrary offset in to a VBO already there today, and shouldn't actually be that expensive.