Official feedback on OpenGL 3.2 thread

[Heiko]

Noticed the following whilst reading the GLSL 1.50 specs with changes (GLSLangSpec.1.50.09.withchanges.pfd).

On page 45:
The fragment language has the following predeclared globally scoped default precision statements:
precision mediump int;
precision highp float;

The float precision predeclaration is new in GLSL 1.50 and is not marked in magenta.

Are you sure? I already used that in GLSL 1.30.

[Demirug]

Based on the fact that GL 3.2 is now competent with D3D 10 or 11 and evolving rapidly, but providing there will be reliable drivers soon. D3D will not be abandoned in a day. Will never. But supporting two rendering paths is now possible.

It was always possible. I could not see why 3.2 should motivate more game developers going this way than before. If you don’t target the Mac or even more unlikely Linux there is simply no good reason to write an additional OpenGL rendering path. While the pure API Spec is getting better there are still so many holes when it comes to the infrastructure.

[GeLeTo]

Are there plans to use ARB_sync with VBOs?

For instance after calling glBufferData - the data will not be copied immediately, and it can be safely changed or deleted only after the sync object is signaled. Calling ClientWaitSync will copy the data immediately (as is the current behavior of glBufferData ).

Is there a way to do this with the current API or an extension?

[Jon Leech (oddhack)]

Are there plans to use ARB_sync with VBOs?

For instance after calling glBufferData - the data will not be copied immediately, and it can be safely changed or deleted only after the sync object is signaled. Calling ClientWaitSync will copy the data immediately (as is the current behavior of glBufferData ).

Is there a way to do this with the current API or an extension?

I'm not certain what you're asking, but if it is whether we would make sync objects affect the behavior of previously existing API calls, there are no plans to do that. BufferData in GL 3.2 does just what BufferData always did before. Placing a fence after a GL command and waiting on the corresponding fence sync object in another context simply provides a (potentially) more efficient way to know that the command has completed from the point of view of the other context.

[Dan Bartlett]

Are ARB extensions #74 + #75 (at http://www.opengl.org/registry/) meant to be labelled as "WGL_ARB_create_context" and "GLX_ARB_create_context", or "WGL_ARB_create_context_profile" and "GLX_ARB_create_context_profile", or are they a special case because they modify existing extensions?

Also just noticed that with wglGetExtensionsStringARB, NVidia beta drivers 190.56 display the extension string "WGL_ARB_create_context_profile", but not "WGL_ARB_create_context".

[GeLeTo]

I'm not certain what you're asking, but if it is whether we would make sync objects affect the behavior of previously existing API calls, there are no plans to do that....

Ok, then lets call it glBufferDataRetained / glBufferSubDataRetained.

Currently sending data to VBO (or any other buffer data object) works like this:
1. Allocate and fill the data
2. Give it to glBufferData
3. glBufferData immediately makes a copy of the data (or sends it directly to the card which is unlikely)
4. When glBufferData returns the data is no longer needed and I can delete or modify it

What I want is to skip #3 to avoid the extra copy done by glBufferData. When using glBufferDataRetained the data will not be immediately copied and it cannot be changed/deleted till OpenGL signals that this data is no longer needed.

The ARB_Sync API is probably not designed for this case but something similar can be very useful. Using the ARB_Sync semantics this functionality will work like this:

1. Allocate and fill the data
2. Give the data and a sync object to glBufferDataRetained
3. glBufferDataRetained returns immediately without copying anything
4. The next time I need to change or delete the data I check if the sync object is signaled - and if so I can use it right away. If the object is not signaled - I can either call ClientWaitSync (or whatever) to ensure the data is copied right away or I can allocate the changed data in a new place.

Currently the only way (that I know of) to avoid the extra copying is to use glMapBuffer. And this is another can of worms...

[Executor]

Where anisotropy in core?

Rob explained this here.

Waiting OGL4 for features ten years ago? So stupid...

[Heiko]

Where anisotropy in core?

Rob explained this here.

Waiting OGL4 for features ten years ago? So stupid...

There is no need to wait. The functionality is available for any vendor anyway. Just use the extension, why would that be a problem?

[Executor]

There is no need to wait. The functionality is available for any vendor anyway. Just use the extension, why would that be a problem?

I want use core functionality only, but i forced use extension too, because core not have needed functionality. This is sad.

[Jon Leech (oddhack)]

Are ARB extensions #74 + #75 (at http://www.opengl.org/registry/) meant to be labelled as "WGL_ARB_create_context" and "GLX_ARB_create_context", or "WGL_ARB_create_context_profile" and "GLX_ARB_create_context_profile", or are they a special case because they modify existing extensions?

We folded the profile extension into the same documents as the original create_context extensions, largely because it was necessary to get them out on time for SIGGRAPH, for arcane reasons involving the Khronos spec approval process. So they are two extensions, in one file.