Official feedback on OpenGL 3.1 thread

[Chris Lux]

If you read the presentation from when 3.0 was released, you'll see that the indended "retirement plan" for features were "Core -> Deprecated -> Extension -> Gone/Vendor specific extension"

So they're just following their plan.

but an extension means you opt-in the features. with the ARB_compatibility the features are just there...

[skynet]

Why not just prepare your data in some user-defined buffer and then just tell gl "copy this to that", why the extra READ/WRITE buffer semantic?

Because GL has ugly bind points instead of an "object oriented" API. One buffer object can be bound to several bind points at the same time. So instead of specifying that you have to re-use existing bind points (which already have their own semantic), they decided to introduce two new bind points with a clearly defined semantic. I think, this is ok, because it allows you to copy data between two buffers without disturbing their original current binding.

[Rob Barris]

The copy-buffer extension looks nice and very useful. However, i have a few questions: The main reason for this is obviously loading data in parallel directly into a gl buffer.

The central value is in being able to transfer chunks of data between buffers on the GPU efficiently, not necessarily using it as a tool for streamlining upload. Though you may have hit on an interesting idea here that should be tried.

[ScottManDeath]

In D3D10, a common pattern is to create a resource with CPU write access, copy data from the CPU (either via mapping or resourcesubdata) and then copy it to a GPU-access-only resource.

So with the extension, one could have two textures (e.g. with the same size and the same number of bytes per texel), each backed by a pixel buffer object and then we could copy the PBOs into each other? So it would be possible to access a 32-bit float single channel texture as a 4 channel 8 bit fixed point texture to gain access to the individual bytes?

[Chris Lux]

is there an ETA for the new glext.h and GL3/gl.h header files?

[_SMK_]

Why exactly are geometry shaders expected to be depreciated soon?

[ZbuffeR]

OpenCL ?

[Ilian Dinev]

is there an ETA for the new glext.h and GL3/gl.h header files?

Uhm, glext.h version 48 is up there for grabs in the repository. It's just not a clean slate.

[Eosie]

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.

Concerning this ARB_compatibility extension, I don't think removing it will have a great impact on the stability of drivers since all important IHVs have implemented it anyway. What OpenGL really needs is extensive unit testing and official certification based on that by an independent authority. Everytime a new bug is found, a new test should be added to make sure the bug will never appear again in any implementation. Using OpenGL games and applications for driver testing is obviously not enough.

[RickA]

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.