Opaque types inplace of GLuint

OpenGL
1

This request initially looks like just better type support to make it so the compiler helps you; here goes: right now all GL objects (textures, buffer objects, framebuffer objects, shaders, programs) are referenced by an GLuint with 0 be reserved for “nothing/default”. I would much, much rather have this:


typedef struct 
{
void *opaque
} GLtexture_object;

typedef struct 
{
void *opaque
} GLbuffer_object;

etc,...

and naturally kill the bind to use/edit that we hae all over the place, i.e. for example rather then binding a buffer object, the functions take a GLbuffer_object as an argument, and glVertexAttribPointer gets replaced by something with an additional argument: a GLbuffer_object as well.

On the surface, it only looks like syntax candy, but doing void *opaque, allows the driver to have a “raw pointer” to the data structure reducing some of the hassles of name look up and such.

The role of zero would be replaced by a the opaque field being NULL.

comments?

2

I believe tex object fbos are all opaque in the sense that we can not directly refer them, but use some helper functions. Eg: sampler*d() are all opaque.you can not do sampler1D.x etc…

for Fbo too, it is opaque as it has no image but images attached to it.

as far as binding is concerned, it is required too provide them integer names for identification.

The GLuint is chosen as it is a natural candidate that specifies indirectly address associated with a particular instant of class FBO ( assuming).

IMO binding is kept separate because there is only one main frame buffer per card and when something is to be rendered off-screen , that FBO must act as a frame buffer to the pipeline.

In short only one frame buffer can be active either main buffer or user buffer. Among user buffers , only one of them can be active hence a separate binding make sense.

The role of zero would be replaced by a the opaque field being NULL.

0 means default and literally means the same here.
When we do glBindFrameBufferEXT(GL_FRAMEBUFFER_EX , 0) ;

here ‘0’ => NULL that is no user FBO, at which the compiler assumes that everything will be directed to on-screen buffer.

…just thoughts.

3

That the GLuint is opaque is not the issue the GLuint provides an opaque like interface but:

  1. it is not a pointer, so the driver underneath needs to get the structure/object it maintains from the GLuint, for 32-bit targets, one could just do a cast, but for 64bits, that is not possible (uness GLuint is a 64bit int which it is not on x64 platforms). Worse, in GL 1.x/2.x one did not need to call glGenWhatever to get such integer values, if an application passed an unused value then the driver had to use that and added an internal book keeping hassle to the driver, atleast GL 3.1 requires all names uses to be first allocated with glGenWhatever prior to use. This look up, by the way, can be a significant source of cache misses.
  2. the addition of types adds strict types to GL usage, right now by using GLuint to access all GL objects, there is no type safety, the programmer must keep track themselves, by making it a separate type, it adds a little bit more compile time checking.
4

This should definitely be part of direct_state_access.

Too bad that ARB is so obsessed with backward compatibility and “ease of changing existing implementations”. To be honest, I wouldn’t expect something like that to appear in the spec.