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.
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.
View all questions in Graphics and Gaming forum