Official feedback on OpenGL 3.1 thread

[Jan]

I'd like to see the direct state access in the next version, but the question is whether it is performance-wise. I was told that glBind* calls do a hash table lookup, which sort of defends the idea of bind-once-use-many-times.

Direct-state access should not need to do hash-lookups anymore, because GL3 introduced, that you are forced to generate objects using glGen* calls. It is an error to generate a handle by simply using it. Therefore hash-tables are not necessary anymore.


In practice that doesn't mean it isn't done anymore. It is hilarious how fast nVidia claims to support GL3+ simply by adding a "compatibility"-extension to their list. It should be called NV_we_dont_need_to_change_anything.

Jan.

[Chris Lux]

[quote=Jan]

In practice that doesn't mean it isn't done anymore. It is hilarious how fast nVidia claims to support GL3+ simply by adding a "compatibility"-extension to their list. It should be called NV_we_dont_need_to_change_anything.

their forward compatible context seems to expose the extension but is missing the functionality, so i think/hope that they are taking advantage of the cleaner interface.

[Rob Barris]

I think there's a small error in the glspec31.20090324.pdf document regarding the Uniform Buffer Objects. On page 50, near the bottom it says:

Uniform buffer objects provide the storage for named uniform
blocks, so the values of active uniforms in named uniform blocks may be changed
by modifying the contents of the buffer object using commands such as Buffer-
Data, BufferSubData, MapBuffer, and UnmapBuffer. Uniforms in a named
uniform block are not assigned a location and may <u>be</u> be modified using the Uni-
form* commands. The offsets and strides of all active uniforms belonging to
named uniform blocks of a program object are invalidated and new ones assigned
after each successful re-link.

I imagine this is supposed to be

Uniform buffer objects provide the storage for named uniform
blocks, so the values of active uniforms in named uniform blocks may be changed
by modifying the contents of the buffer object using commands such as Buffer-
Data, BufferSubData, MapBuffer, and UnmapBuffer. Uniforms in a named
uniform block are not assigned a location and may <u>NOT</u> be modified using the Uni-
form* commands. The offsets and strides of all active uniforms belonging to
named uniform blocks of a program object are invalidated and new ones assigned
after each successful re-link.

Your assessment of the typo is correct. Uniforms in a UBO may not be accessed with the old API.

[Bruce Merry]

By the way, are those gl3.h headers available somewhere? And yes, why <GL3/gl3.h> not <GL/gl3.h> like <GL/glaux.h>, <GL/glu.h>

The name for the header file is largely an arbitrary choice. <GL3/gl3.h> matches OpenGL ES conventions (the header file for OpenGL ES 2.0 is <GLES2/gl2.h>).

[ScottManDeath]

Your assessment of the typo is correct. Uniforms in a UBO may not be accessed with the old API.

Is there a specific reason for this? In D3D10, it is possible to use both buffer access api and the effect framework to update uniforms which are in constant buffer blocks in the shader.

[Auto]

The spec suggest to use the <GL3/gl3.h> header instead of classic gl.h header. But nobody seem to know when it will be available

Ok that sounds a bit more like it - though I'm still a bit unclear about it; as if for example I set up my code to be including the gl stuff from GL3/gl3.h, but then I am including glext.h for some other extensions, wouldn't that mean that I'd implicitly be including the ARB_compatibility extension and therefore the compiler would just accept all my old code?

Is that right - or does anyone know whether there's going to be something within gl3.h that we can #define like a GL_DISABLE_COMPATIBILITY?

Thanks

[Chris Lux]

a header alone will not do it. for example in GL3.1 you can not call glGetString with GL_EXTENSIONS, but the GL_EXTENSIONS token is still in the gl3.h header file because you can use it with another function. so including the gl3.h header does not ensure that your code is GL3.1 compliant.

[ZbuffeR]

The spec refers to both gl3.h and gl3ext.h

[Auto]

The spec refers to both gl3.h and gl3ext.h

Ah great - thanks

[glfreak]

OpenGL doomed itself to be honest. With its current direction it will be neither a CAD preferable nor a good competitor to Direct3D 10/11 or even 9 which are already established in the game industry and video card standards.

OpenGL should at least stick to its playground where it rules, the CAD application arena!

Now GL is put face to face to D3D, and either game creators start adopting it sooner, or CAD companies start porting their stuff to D3D.