[Mesa-dev] Questions about arrays in GLSL 1.50 interface blocks
Ian Romanick
idr at freedesktop.org
Tue Aug 6 10:19:55 PDT 2013
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
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
More information about the mesa-dev
mailing list