On 08/02/2013 07:52 PM, Paul Berry wrote:
1. Is it ok to declare an unsized array in an interface block? In other
words, is this ok?
out blk {
vec4 foo[];
};
The nVidia Linux driver allows this, but Mesa currently doesn't. AFAICT
the spec says it's ok. In fact, the spec defines the built-in interface
block gl_PerVertex this way:
out gl_PerVertex {
vec4 gl_Position;
float gl_PointSize;
float gl_ClipDistance[];
};
So it seems like it ought to be allowed for user-defined interface
blocks too.
2. If you declare an unsized array in an interface block, is it legal to
redeclare that interface block later and specify an array size? E.g.:
out blk {
vec4 foo[];
};
out blk {
vec4 foo[2];
};
I can't find any text in the spec saying whether this is allowed, but it
seems reasonable that if the answer to question 1 is yes, then this
should be allowed too, since it's parallel to what's allowed outside of
interface blocks.
3. How about redeclaring a named interface block and specifying a size?
out blk {
vec4 foo[];
} ifc_name;
out blk {
vec4 foo[2];
} ifc_name;
It seems to me that this should have the same answer as question 2, but
nVidia disallows this (it gives a compile error: declaration of
"ifc_name" conflicts with previous declaration at ...).
4. How about if you redeclare an interface block that has some arrays
and some non-arrays? E.g.:
out blk {
vec4 foo[];
vec4 bar;
};
out blk {
vec4 foo[2];
vec4 bar;
};
It seems to me that this should also have the same answer as question 2,
but nVidia rejects this with a compile error too (declaration of "bar"
conflicts with previous declaration at ...).
5. How about if you redeclare an interface block and give it different
members? E.g.:
out blk {
vec4 foo[];
vec4 bar;
};
out blk {
vec3 baz;
};
This seems like it should definitely give an error, since the spec says
"Matched block names within an interface ... must match in terms of
having the same number of declarations with the same sequence of types
and the same sequence of member names, as well as having the same
member-wise layout qualification ...".
But the nVidia driver allows this.
I'm baffled as to what behaviour I should implement in Mesa. At the
very least I'm pretty sure I have to allow gl_PerVertex to be
redeclared, since (a) that's the only way to give the gl_ClipDistance
input a size in a geometry shader, and (b) redeclaring gl_PerVertex is
explicitly permitted by GLSL 4.10 section 7.1.1 (and I'm pretty sure the
text there is meant as a clarification, rather than a new rule).
But for anything beyond that, the spec seems open to interpretation.
And I don't feel like I can use nVidia's implementation for guidance,
because of the inconsistencies and non-compliant behaviour I noted above.
I definitely think NVIDIA has some bugs. :)
I spent most of the train ride home last night digging through the GLSL
specs and trying to remember any relevant Khronos discussions. I could
only find one bit of text that even hinted at anything. The bottom of
page 50 (page 56 of the PDF) of the GLSL 4.40 spec says:
"A block name is allowed to have different definitions in
different interfaces within the same shader, allowing, for
example, an input block and output block to have the same
name."
That /suggests/ that you can't redeclare a block for the same interface,
but I don't feel very comfortable relying on that. I'll submit a bug.
Any thoughts?
_______________________________________________
mesa-dev mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
