Open null77 opened 5 years ago
Each element of the array is identified separately and so it is okay that they are bound to non-consecutive locations.
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