KhronosGroup / OpenGL-API

OpenGL and OpenGL ES API Issue Tracker
34 stars 5 forks source link

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

Open null77 opened 5 years ago

null77 commented 5 years ago

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 commented 5 years ago

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

nvpbrown commented 5 years ago

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 commented 5 years ago

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.