… 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
- 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.
