You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This mostly pertains to the ES specs. I haven't looked at desktop as closely.
EXT_blend_func_extended adds new entry points glBindFragDataLocation* for associating a fragment output with a particular output location. Is it expected for a program to link with non-consecutive locations for array elements? Or to fail link? Or is either result OK?
For example:
GLuint program = glCreateProgram();
// snip init program
glBindFragDataLocationEXT(program, 5, "arrayOutput[0]");
glBindFragDataLocationEXT(program, 3, "arrayOutput[1]");
glBindFragDataLocationEXT(program, 1, "arrayOutput[2]");
glLinkProgram(program); // should this succeed?
Shannon Woods looked into it in detail and concluded there may be spec ambiguity. I can perhaps share some of her digging if warranted. Also this is in context of Lee Salzman needing this functionality in ANGLE. Kimmo Kinnunnen from Nvidia has also added tests requiring this functionality to Chromium.
I personally don't think this example should be legal and that array elements should not be addressable via BindFragDataLocation and similar APIs.
If this example is legal, shader code like:
arrayOutput[dynamically_computed_index] = value;
would have to turn into
switch (dynamically_computed_index) {
case 0: generic_output_5 = value; break;
case 1: generic_output_3 = value; break;
case 2: generic_output_1 = value; break;
default: do_whatever_you_want_for_out_of_bounds_indexing(); break;
};
Section 15.2.3 of the OpenGL 4.6 spec seems to talk about assigning locations to variables and I wouldn't call an array element a "variable".
When a program is linked, each active user-defined fragment shader output
variable will have a binding consisting of a fragment color number, a fragment
color index, and a component index.
Similarly, there is explicit language on what happens to array variables that assumes locations are assigned to the array and not the individual elements, and are effectively doled out in consecutive order:
For an output variable declared as an array bound to fragment color number
i, individual active array elements are written to consecutive fragment color
numbers beginning with i, with the components written determined from the array
element’s data type and the array variable’s component index binding.
There doesn't seem to be any explicit language on what strings can be passed to name. Perhaps this should be connected with Section 7.3.1.1, "Naming Active Resources", which attempts to standardize naming conventions for strings identifying active shader resources.
Discussed in the 2019-06-26 OpenGL/ES meeting and we agreed the spec needs to be clarified to state that the whole array is bound and you can't bind each element. SW has an AI to investigate the OpenGL ES spec and extensions and propose a fix.
This mostly pertains to the ES specs. I haven't looked at desktop as closely.
EXT_blend_func_extended adds new entry points glBindFragDataLocation* for associating a fragment output with a particular output location. Is it expected for a program to link with non-consecutive locations for array elements? Or to fail link? Or is either result OK?
For example:
Shannon Woods looked into it in detail and concluded there may be spec ambiguity. I can perhaps share some of her digging if warranted. Also this is in context of Lee Salzman needing this functionality in ANGLE. Kimmo Kinnunnen from Nvidia has also added tests requiring this functionality to Chromium.
@pdaniell-nv FYI
The text was updated successfully, but these errors were encountered: