Support for 64 bit indices

OpenGL OpenGL: Basic Coding
1

Hi everyone,

I am wondering if there is any chance there will be support for 64 bit indices in element array buffers in the near future. GLSL has been extended recently to support all kinds of data types based on 64 bit types, as well as 64 bit vertex attributes. However, it appears that indices can still only be provided as 32 bit unsigned data types. glDrawElements and friends only accept GL_UNSIGNED_BYTE, GL_UNSIGNED_SHORT, or GL_UNSIGNED_INT as type, not the recently added GL_UNSIGNED_INT64_ARB.

“Why would you possibly need this?” - If you have large grid-based data from simulation, e.g. a velocity field or a height field, that you want to render cell by cell, you will need 6 indices by cell for GL_TRIANGLES (*). That means that in the range of unsigned int, you can address indices for floor(2^32 / 6) cells, which is approximately 26754x26754. This is not a very huge grid in a lot of applications and we ourselves are slowly approaching this limit (laser scans with 1x1 meter cell size). Of course, the data would not fit into current cards’ memory anyway, but since GL_ARB_sparse_buffer, it is possible to have an “arbitrarily” large address space and only allocate it sparsely where actual data is stored, so that you only need to commit the data of the stuff you are currently rendering. So it is possible right now already to have way more than 2^32 indices in total, only they are not rendered at the same time by selecting the range if elements.

(*) This is an example to illustrate the problem. No need to provide optimization ideas for this specific application.

I have now two choices to adjust our renderer to the growing data size:

  1. Chop all data into parts of at most 2^32 elements (meaning indices as well as the corrseponding vertex attributes such as velocity and elevation) and render with multiple draw calls
  2. Find a way to render everything in one go with GL_UNSIGNED_INT64_ARB indices or wait for an extension that provides this functionality

Is 2) worth waiting for? Support for 64 bit indices appears to be a logical next step given the previous extensions, but I might be wrong. Of course it would be possible to process and maintain all data in a way that works with the traditional 32 bit indices as it has been done all the years before, but it would be so awfully convenient to simply change the data type in the existing code.