This very nice desktop OpenGL has been ratified as a OpenGL ES extension recently.
I would like to request support for this extension since it will improve performance of my application by a very large margin on Mali hardware.
It's at the Khronos registry here. https://www.khronos.org/registry/gles/extensions/EXT/EXT_draw_elements_base_vertex.txt
We can raise it with our product management team, but based on typical release cycles even if we implemented it immediately it's unlikely to see devices for ~12 months.
In the interests of solving your application issues before then, if it actually makes that much difference to performance you could just upload multiple index buffers, or if you only render a consistent sub-ranges pre-offset the indices and then calculate the pointer offsets as part of attribute setting (as outlined in the extension doc). The extension is "nice to have" but it doesn't do anything the application can't to already - it just moves the effort for supporting it into the drivers, but it isn't necessarily "free" or any cheaper than just having the applications do it (and by not relying on extensions, is then also portable).
Pete
The problem is that due to the nature of my application I can't do things by "best practices" so when I'm stuck with base OpenGL ES 3.0 I am /very/ limited in performance, especially on any form of hardware that does deferred rendering.
In a perfect world I would have both this extension and GL_ARB_buffer_storage, which at that point my performance problems would be gone.
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.
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
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.