• State Accepted Answer
  • Locked Locked
  • Replies 8 replies
  • Subscribers 136 subscribers
  • Views 6905 views
  • Users 0 members are here
Options
Related
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

GL_EXT_draw_elements_base_vertex support?

Ryan Houdek

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

Parents
  • 0 Arm Employee Badge in reply to Ryan Houdek

    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.

Reply
  • 0 Arm Employee Badge in reply to Ryan Houdek

    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.

Children
No data