Official feedback on OpenGL 3.2 thread

[Jon Leech (oddhack)]

So in the GLSL 1.50 spec the precision predeclaration for the float type should have been highlighted in magenta.

To speak somewhat in our own defense, the GL and GLSL specs are huge, complex documents that go through many, many revisions during the process of creating a new version. John and I try to keep the change markings sensible but it's not going to be a 100% error free process; they're mostly just a guideline to finding changed stuff, to accompany the new feature summaries. We don't mark the places where a lot of text is removed with strikethroughs, for example. Our focus is on getting the new spec out on schedule, so some stuff like this is always going to fall through the cracks.

[kRogue]

I see the use/reason of having forward compatible and profile selection (i.e. core vs compatibility) separate as they address 2 different issues, but those issues over lap (at this point a great, great deal)... and can you imagine the mess that occurs when trying to teach this stuff to people new to GL? They will scream that one is splitting hairs.

But I am really surprised that a bindless edit buffer object, I figured that it would have been a kind of no brainer to specify and for driver writers to deal with, something simple as for each buffer object type function glSomeBufferFunction, a new function glSomeBufferFunctionNamed which had one extra parameter, a GLuint of the buffer object; ditto for texture stuff too.

One point of irony for me right now is the deprecating (or saying only in compatible profiles) is the naming of interpolators in shaders, I prefer, in the language of GL_EXT_separate_shader_objects, "rendezvous by resource" instead of the current "rendezvous by name". The argument of removing an interpolator at link time to optimize I have always found to be kind of thin (especially since for each tuple (vertex,fragment) or (vertex,geometry,fragment) shader one had to have a different program).... does anyone have some reasonable real world examples where one leaves an interpolator present if it would get optimized out?


Just out of curiosity, is there active movement on:
1) direct state access
2) separation of texture data from filtering method
?

I am starting to think, given that 2) is quite hairy to do well, we won't see anything like that till GL 4.0...

Also, I am really, really overjoyed that the GL API is now getting updated more regularly, is that pace expected to remain? (I suspect that the pace of so many updates will slow once GL core exposes all features that D3D of that time exposes, and then once there only big updates at new GFX card generations and minor updates handling making things "cleaner")

[Jon Leech (oddhack)]

I see the use/reason of having forward compatible and profile selection (i.e. core vs compatibility) separate as they address 2 different issues, but those issues over lap (at this point a great, great deal)... and can you imagine the mess that occurs when trying to teach this stuff to people new to GL? They will scream that one is splitting hairs.

They overlap but the use cases are very different. The FC context is really only intended as a futureproofing aid for developers, along the lines of the (otherwise so-far mythical) "debug context". Personally I wouldn't even tell someone new to GL about it for quite a while.

Separation of filters and samplers is on the agenda for a future release, yes. DSA has been brought up as well, though it is perhaps less far along in terms of being seen as desirable by everyone.

[Eosie]

glTexImage being async comes at a cost - it will most likely create a copy of your image data right away. And this is what I want to avoid.

You can't avoid the copy with glBufferData. The data MUST be stored in page-locked system memory (to make sure your operating system won't move it) before it can be asynchronously transfered to the GPU. There is only one way to access this memory directly and so to avoid the copy - glMapBuffer{Range}. The same applies for textures: use PBO. The buffer object represents both a GPU buffer and a corresponding buffer in page-locked system memory.

If I understand correctly, you want to have a fine-grained control over PCIe transfers. In CUDA it's easy, you can use cudaMemcpyAsync and place a fence (called "event" in CUDA) after that, and then ask whether all preceding commands have ended. Because you have no such control in OpenGL, it's hard to give advice. ARB_copy_buffer might help here but I am not sure. As someone already said, "only driver guys can tell".

[kRogue]

... Personally I wouldn't even tell someone new to GL about it for quite a while.

That is my point, someone new to GL would say "What the?" But it is quite awkward if you look at what effective practice was:

GL3.0: request forward compatible context to make sure one was not using naughty deprecated stuff, mostly fixed function pipeline.

GL3.1: ditto, but if you did not request a forward compatible context then expect ARB_compatibility to be present, chances are then code to check if it there; often the context creation code is buried in some platform dependent monster that nobody likes to read, worse for cross platform code.

GL3.2: now be aware of difference between deprecated features and compatibility features, in theory a twisted one could request a forward compatible context and request a compatible profile (shudders).

hopefully, no more new context creation attributes will be added.

On a related note to my post (but not to GL 3.2) reading GL_EXT_separate_shader_objects, I found something that I thought was just plain *bad*

16. Can you use glBindFragDataLocation to direct varying output
variables from a fragment shader program created by
glCreateShaderProgramEXT to specific color buffers?

UNRESOLVED:

Tenative resolution: NO for much the same reason you can't do
this with attributes as described in issue 15. But you could
create the program with the standard GLSL creation process where
you attach your own shaders and relink.

For fragment shader programs created with
glCreateShaderProgramEXT, there is already the gl_FragData[]
builtin to output to numbered color buffers. For integer
framebuffers, we would need to add:

varying out ivec4 gl_IntFragData[];

User-defined output fragment shader varyings can still be used
as long as the application is happy with the linker-assigned
locations.

my thoughts on that are *ick*... since if one is doing MRT, then you would possibly need to call glDrawBuffers on every shader switheroo... ick... would be better if they just added a pragma like interface to fragment shaders:

pragma(out vec4 toFrag0, 0)
pragma(out ivec4 toFrag1, 1)

or extend the layout() deal in fragment shaders:

layout(fragment_output, 0) out vec4 toFrag0;
layout(fragment_output, 1) out ivec4 toFrag1;

and along those lines one could then use that kind of mentality on interpolators, i.e in vertex shaders:

layout(vertex_output, 0) out vec4 myValue;
layout(vertex_output, 1) out flat myFlatValue;

and in geometry shaders:

layout(geometry_input, 0) in vec4 myValue;
layout(geometry_input, 1) in vec4 myFlatValue;
 
layout(geometry_output, 0) out vec4 myValueForFragging;

and then even in fragment shaders:

layout(fragment_input, 0) in vec4 myValueForFragging;

but on closer inspection since out/in qualifier is already there, it can all be collapsed to:

layout(location, N) in/out [flat, centroid, etc] type variable_name;

The sweet part of this being that one can then dictates where attributes and interpolators are, the lazy could even skip calling glAttrbuteLocation...

This comment probably would be best in suggestion for next release or some kind of GL_EXT_separate_shader_objects thread.

[Jon Leech (oddhack)]

GL3.2: now be aware of difference between deprecated features and compatibility features, in theory a twisted one could request a forward compatible context and request a compatible profile (shudders).

You can do that, but as previously noted, nothing is deprecated from the compatibility profile, so a forward-compatible compatibility profile is exactly the same thing as a non-FC CP :-)

I would be a little surprised if any of the remaining deprecated-but-not-removed features in the core profile are actually removed from core anytime in the near future. It's challenging enough dealing with the number of options we have today.

[AlexN]

[quote=kRogue]

...
On a related note to my post (but not to GL 3.2) reading GL_EXT_separate_shader_objects, I found something that I thought was just plain *bad*

16. Can you use glBindFragDataLocation to direct varying output
variables from a fragment shader program created by
glCreateShaderProgramEXT to specific color buffers?

UNRESOLVED:

Tenative resolution: NO for much the same reason you can't do
this with attributes as described in issue 15. But you could
create the program with the standard GLSL creation process where
you attach your own shaders and relink.

For fragment shader programs created with
glCreateShaderProgramEXT, there is already the gl_FragData[]
builtin to output to numbered color buffers. For integer
framebuffers, we would need to add:

varying out ivec4 gl_IntFragData[];

User-defined output fragment shader varyings can still be used
as long as the application is happy with the linker-assigned
locations.

my thoughts on that are *ick*... since if one is doing MRT, then you would possibly need to call glDrawBuffers on every shader switheroo...

...

This comment probably would be best in suggestion for next release or some kind of GL_EXT_separate_shader_objects thread.

I don't like this, either. The previous issue, about vertex input attribute binding locations, has the same problem. I'm used to binding my vertex attributes to known locations when I load a shader, to avoid both excessive vertex array rebinding and to remove the need to query and store the locations of every attribute, for every shader...

[Brolingstanz]

A big sloppy kiss for the quick ref cards!

[Alfonse Reinheart]

I don't like this, either.

Which is why this is an nVidia extension (despite the EXT name) and not the eventual solution to this problem. It tries to solve the problem by making OpenGL pretend to do things the D3D way, but without realizing that OpenGL has issues with doing things that way.

[Scribe]

By the way, does anyone know if glu.h is ok with the gl3.h header file? I know some of glu is no longer relevant to openGl 3.2, is it compatible at all with a forward context?

Many thanks