[Piglit] [PATCH 4/4] glsl-1.30: Verify that gl_Frag{Color, Data} and a function out can be written

[Ian Romanick]

On 12/14/2011 11:24 AM, Chad Versace wrote:
> On 11/16/2011 01:50 PM, Ian Romanick wrote:
>> From: Ian Romanick<ian.d.romanick at intel.com>
>>
>> These tests try to trick the GLSL compiler by writing a built-in
>> fragment shader output and a function "out" variable.  The compiler is
>> supposed to generate an error if a built-in output and a user-defined
>> shader "out" variable are written.  Writing to a built-in and a
>> funciton "out" should be allowed.
>>
>> Signed-off-by: Ian Romanick<ian.d.romanick at intel.com>
>> ---
>>   .../write-gl_FragColor-and-function-output.frag    |   29 ++++++++++++++++++++
>>   .../write-gl_FragData-and-function-output.frag     |   29 ++++++++++++++++++++
>>   2 files changed, 58 insertions(+), 0 deletions(-)
>>   create mode 100644 tests/spec/glsl-1.30/compiler/fragment-outputs/write-gl_FragColor-and-function-output.frag
>>   create mode 100644 tests/spec/glsl-1.30/compiler/fragment-outputs/write-gl_FragData-and-function-output.frag
>
> These tests look correct to me.
> Reviewed-by: Chad Versace<chad.versace at linux.intel.com>
>
> I'm having difficulty seeing the motivation for them, though. Unless the motivation
> was a weakness in the compiler implementation that you identified while working on
> this test series.

Right now, these tests fail on Mesa.  This particular test case hits a 
weakness in a fix that I had though of.

> To wrap up this series, I think we also need tests that write to the out variables
> as function out params. Like this:
>     // expect_result: fail
>     out vec4 frag_color;
>     void f(out vec4 x) {
>          x = vec4(1.0);
>     }
>     void main() {
>         f(gl_FragColor);
>         frag_color = vec4(1.0);
>     }
> You're more familiar with the linker than I. Do you also think we need these tests?

That's a good idea.