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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
