Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarification regarding binding on non-consecutive fragment output array locations #50

Open
null77 opened this issue May 8, 2019 · 3 comments

Comments

@null77
Copy link

null77 commented May 8, 2019

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

@pdaniell-nv
Copy link

Each element of the array is identified separately and so it is okay that they are bound to non-consecutive locations.

@pdaniell-nv pdaniell-nv self-assigned this May 28, 2019
@pdaniell-nv pdaniell-nv added this to the Needs Triage milestone Jun 25, 2019
@nvpbrown
Copy link

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.

@pdaniell-nv
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants