Repository navigation
Clarification regarding binding on non-consecutive fragment output array locations #50
Description
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.
@pdaniell-nv FYI
Activity
pdaniell-nv commentedon May 8, 2019
Each element of the array is identified separately and so it is okay that they are bound to non-consecutive locations.
nvpbrown commentedon Jun 25, 2019
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".
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:
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.
pdaniell-nv commentedon Jul 9, 2019
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.