[Mesa-dev] [PATCH] glsl: Allow ES2 function parameters to be hidden by variable declarations.

[Eric Anholt]

Ian Romanick <idr at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20180718/49675262/attachment.sig>