[Mesa-dev] GLSL spec bug?

[Ian Romanick]

On 01/12/2015 11:09 PM, Iago Toral wrote:
> Hi,
> 
> Mesa fails the following dEQP tests:
> 
> dEQP-GLES3.functional.shaders.linkage.varying.rules.invalid_type_struct_array
> dEQP-GLES3.functional.shaders.linkage.varying.rules.invalid_type_struct_struct
> dEQP-GLES3.functional.shaders.linkage.varying.rules.invalid_type_array_struct
> 
> they are about defining a struct with an array field, a struct inside a
> struct and an array of structs respectively. dEQP considers these types
> invalid but Mesa allows them. I thought this was a bit odd but then I
> read this in the GLSL ES spec, chapter 4.3.4. Input variables (and
> similar text exists for the desktop version):
> 
> "Fragment inputs can only be signed and unsigned integers and integer
> vectors, float, floating-point vectors, matrices, or arrays or
> structures of these."
> 
> That text suggests that the tests are correct and these types are
> invalid (at least as inputs of a fragment shader).
> 
> I think that is an odd restriction, and then is the fact that not only
> Mesa, but also nVidia and AMD proprietary drivers support this. I also
> tested these types using Khronos' glslangvalidator tool and it does not
> complain, so it looks a lot like a spec bug to me... Should we file a
> bug report against the spec? Ian, what do you think?

This is an intentional divergence of ES... that the desktop vendors
didn't notice when the spec was approved.  There was quite some debate
about this after specs were approved and the divergence was noted.  The
mobile vendors thought this restriction would make their compilers
simpler, and the desktop vendors though the non-orthogonal restriction
was silly.

I would really prefer to not add more complexity to the compiler or
linker to support a spurious restriction.

> Iago