On 15.05.2017 16:57, Erik Faye-Lund wrote:
On Mon, May 15, 2017 at 11:27 AM, Nicolai Hähnle <nhaeh...@gmail.com> wrote:
Hi all,
This series aims to simplify how we handle unnamed struct types and fix some
bugs on the way. Some of the patches should be uncontroversial, and all of
them align with my understanding of the GLSL spec, but the spec isn't
exactly explicit, so...
At a high level, the series changes two things:
1) Unnamed structs can never match named structs during linking.
2) Unnamed structs are considered the same type if they have the same
content. They will literally use the same glsl_type instance.
The second point causes a deviation from the behavior of C/C++, in that the
following code snippet now compiles (and does the reasonable thing):
struct { float a; } s1;
struct { float a; } s2;
s2 = s1;
The justification is basically that the GLSL spec says (when it comes to
linking, in Section 4.2) that
"Structures must have the same name, sequence of type names, and
type definitions, and member names to be considered the same type."
And since people generally seem to read that as mandating that globals of
unnamed struct types should match if they're structurally the same, and the
GLSL spec otherwise says nothing (as far as I can tell) about when struct
types are equal, the cleanest thing is to just say that _in general_ (not
just for linking) struct types are the same if and only if they have the
same name and the same fields; where "same name" can mean that they both
have no name.
It might also be reasonable to say that having the same name requires
having a name in the first place. But I'm not sure if such an
interpretation is useful.
I agree. But it seems the ship has sailed on that one at least when it
comes to cross-stage validation.
So, I think it would be useful to look at what other implementations
do. From a quick test, it seems like both glslangValidator, the Apple
GLSL compiler (as reported by OpenGL Shader Builder, on Intel HD
Graphics 5000) as well as the NVIDIA Windows driver allows your
example (and all of them forbids it if I add another member to one of
them, or rename the member). Those are the only implementations I have
at hand right now, but it seems to me like this behavior is at least
not too controversial.
Thank you for testing, that's indeed good to know!
Cheers,
Nicolai
--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
