[Piglit] [PATCH] Add a test of isinf() and isnan() functionality.

[Ian Romanick]

On 10/07/2011 01:26 PM, Paul Berry wrote:
> On 7 October 2011 12:28, Ian Romanick <idr at freedesktop.org
> <mailto:idr at freedesktop.org>> wrote:
>
>     On 10/06/2011 08:45 AM, Paul Berry wrote:
>
>         +static const char vs_boilerplate[] =
>         + "flat out vec4 data;\n"
>         + "void do_common_shader_operations()\__n"
>         + "{\n"
>         + "  gl_Position = gl_Vertex;\n"
>         + "}\n"
>         + "void output_result(vec4 result)\n"
>         + "{\n"
>         + "  data = result;\n"
>         + "}\n";
>         +
>         +static const char fs_boilerplate[] =
>         + "void do_common_shader_operations()\__n"
>         + "{\n"
>         + "}\n"
>         + "void output_result(vec4 result)\n"
>         + "{\n"
>         + "  gl_FragColor = result;\n"
>         + "}\n";
>
>
>     Also yuck.  Since this test will require GLSL 1.30 and OpenGL 3.0,
>     you can just make a fragment shader output called result.
>
>     out vec4 result;
>
>     Mesa doesn't have glBindFragDataLocation yet, but you can use
>     explicit attribute locations.  Something like:
>
>     #version 130
>     #extension GL_ARB_explicit_attrib___location: enable
>
>     #if defined GL_ARB_explicit_attrib___location
>     layout(location = 0)
>     #endif
>         out vec4 result;
>
>     In the application, you'll have to call glBindFragDataLocation if
>     GL_ARB_explicit_attrib___location isn't supported.
>
>
> Ok, I think I see why you had a "yuck" reaction to the output_result()
> function above, but I'm having a "yuck" reaction of my own to the
> preprocessor stuff above, and to having a run-time decision of whether
> to call glBindFragDataLocation based on whether
> GL_ARB_explicit_attrib_location is supported.  I think I can make the

That's probably fair.  I'm not really in love with it either.  All of 
the GL_ARB_explicit_attrib_location business is just a hack until we get 
glBindFragDataLocation working in Mesa.

> gl_FragColor approach look a lot cleaner when I rework the test to use
> multiple compilation units.  Let's revisit this question after I've done
> the rework and see if it's still objectionable to you.

Okay.

>     The other alternative, if we really care about GLSL 1.30 without
>     OpenGL 3.0, is
>
>     #define result gl_FragColor