Jordan Justen <[email protected]> writes: > On Thu, Feb 28, 2013 at 4:41 PM, Eric Anholt <[email protected]> wrote: >> Jordan Justen <[email protected]> writes: >> >>> Signed-off-by: Jordan Justen <[email protected]> >>> --- >>> ...terface-blocks-member-type-mismatch.shader_test | 39 >>> ++++++++++++++++++++ >>> 1 file changed, 39 insertions(+) >>> create mode 100644 >>> tests/spec/glsl-es-3.00/linker/interface-blocks-member-type-mismatch.shader_test >>> >>> diff --git >>> a/tests/spec/glsl-es-3.00/linker/interface-blocks-member-type-mismatch.shader_test >>> >>> b/tests/spec/glsl-es-3.00/linker/interface-blocks-member-type-mismatch.shader_test >>> new file mode 100644 >>> index 0000000..d586867 >>> --- /dev/null >>> +++ >>> b/tests/spec/glsl-es-3.00/linker/interface-blocks-member-type-mismatch.shader_test >>> @@ -0,0 +1,39 @@ >>> +# Tests that a link error occurs when an interface block member's type >>> +# differs between the vertex and fragment shaders. >>> +# >>> +# GLSL_ES_Specification_3.00.3, 4.3.7 Interface Blocks: >>> +# "Matched block names within an interface (as defined above) must match >>> +# in terms of having the same number of declarations with the same >>> +# sequence of types, precisions and the same sequence of member names, >>> +# as well as having the same member-wise layout qualification (see next >>> +# section)." >>> +[require] >>> +GL ES >= 3.0 >>> +GLSL ES >= 3.00 >>> + >>> +[vertex shader] >>> +#version 300 es >> >> This looks like a single case of what's tested in link-mismatch-blocks. >> I don't know whether it's important to have ES-specific version of that >> test, but we might want to test the same things on both sides if we >> decide to. > > This test fails for us currently. The differing instance name seems to > be significant in masking the linker failure. > > I guess ARB_uniform_buffer_object doesn't support instance names, so > this test can't be added to link-mismatch-blocks.
Ah, I see. I'm still confused by the spec about what should happen with the same block name and uniforms within differently-named interfaces, and I'll leave that interpretation up to others :)
pgpAjPVevwmAf.pgp
Description: PGP signature
_______________________________________________ Piglit mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/piglit
