Ian Romanick <i...@freedesktop.org> writes: > On 07/16/2018 02:46 PM, Eric Anholt wrote: >> This fixes dEQP case: >> >> dEQP-GLES2.functional.shaders.scoping.valid.local_variable_hides_function_parameter_fragment > > Are we sure that test is correct? I'm sure I already know the answer, > but does the test contain any justification or spec references? I just > re-read section 4.2 (Scoping) of the ESSL 1.00 spec, and I don't see > anything to support this. Did I miss something? > > In fact, the grammar says: > > function_definition: > function_prototype compound_statement_no_new_scope > > So... I think this test is just wrong.
OK, so I'm confused why this test still exists, if people have managed to get conformance on Mesa. I'm on master of VK-GL-CTS, and it's still in the mustpass file: external/openglcts/data/mustpass/gles/aosp_mustpass/master/gles2-master.txt:dEQP-GLES2.functional.shaders.scoping.valid.local_variable_hides_function_parameter_fragment I don't see anything that would exclude the test -- there's gles2-driver-issues.txt, but that appears to only be used to exclude tests from AOSP DEQP usage. Could whoever on the Intel side submitted a conformance package for Mesa send me a copy? I haven't been able to find it on the Khronos site, and I suspect it would help me understand how to achieve conformance with Mesa. dEQP-GLES3.functional.shaders.preprocessor.predefined_macros.line_2_vertex is another one that fails on Mesa with i965, and seems to have been in the testsuite forever.
signature.asc
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
