shader_runner and glslparsertest: choose GL version more accurately.

Previously, both shader_runner and glslparsertest contained switch
statements that attempted to choose a GL version for testing based on
a GLSL version requirement, and those switch statements didn't choose
a GL version very accurately (for example, they converted GLSL version
1.50 to GL version 3.1, which doesn't work).

This patch replaces the switch statements with a single common
function (in piglit-util-gl-common) that does the right thing.

Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
shader_runner: Remove unimplemented geometry_program vestiges.

Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
shader_runner: Add support for testing geometry shaders.

Note that there are two slightly different variants of geometry
shaders: those supported by GLSL 1.50 and those supported by
ARB_geometry_shader4.  A principal difference between these two
variants is in how geometry shader layout parameters are specified
(i.e. input and output primitive types, max number of output
vertices).  When using GLSL 1.50 style geometry shaders, these layout
parameters are specified in the shader source.  When using
ARB_geometry_shader4 style geometry shaders, these layout parameters
are specified by calling glProgramParameteriARB() prior to linking.

In order to support both variants, this patch allows an optional
"[geometry layout]" section to shader_runner test files.  For example
the following [geometry layout] section:

    [geometry layout]
    input type GL_POINTS
    output type GL_LINE_STRIP
    vertices out 3

Causes shader_runner to make these calls prior to linking:

    glProgramParameteriARB(prog, GL_GEOMETRY_INPUT_TYPE_ARB,
                           GL_POINTS);
    glProgramParameteriARB(prog, GL_GEOMETRY_OUTPUT_TYPE_ARB,
                           GL_LINE_STRIP);
    glProgramParameteriARB(prog, GL_GEOMETRY_VERTICES_OUT_ARB, 3);

Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
glslparsertest: Add support for testing geometry shaders.

Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Basic geometry shader sanity tests.

Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Add geometry testing to code-generated tests.

This patch adds geometry shader variants to the code-generated
built-in function tests produced by gen_builtin_uniform_tests.py and
gen_constant_array_size_tests.py.

Note that there are two ways in which an implementation may expose
geometry shader support: via GLSL 1.50 or via ARB_geometry_shader4.
After some discussion on IRC, I've provisionally decided to write most
of the geometry shader tests using ARB_geometry_shader4, and then only
supply GLSL-1.50-based tests for basic santy testing and to cover the
cases where GLSL 1.50 and ARB_geometry_shader4 differ.

Rationale: (a) Mesa is likely to implement ARB_geometry_shader4
support before GLSL 1.50 support (since Bryan Cain already has some
work-in-progress geometry shader patches that use
ARB_geometry_shader4).  (b) there are likely to be some
implementations that support geometry shaders but not GLSL 1.50
(e.g. Mesa softpipe, or i965 Gen5); writing most of the tests for
ARB_geometry_shader4 ensures that those implementations are
well-covered.

Accordingly, these code-generated tests are written entirely using
ARB_geometry_shader4.

Reviewed-by: Eric Anholt <eric@anholt.net>
GLSL ES: Verify that fragment shaders have no default float precision.

Tested on the nVidia proprietary driver for Linux.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=60737

Reviewed-by: Eric Anholt <eric@anholt.net>
glslparsertest: Fix parsing of GL_SHADING_LANGUAGE_VERSION in GLES.

In desktop GL, glGetString(GL_SHADING_LANGUAGE_VERSION) returns a
string that begins with the supported version number.  But in GLES,
the version number is preceded by the text "OpenGL ES GLSL ES ".  This
was causing glslparsertest to fail to parse the implementation's
supported GLSL version, and that in turn caused parse_glsl_version()
function to access uninitialized memory.

This patch splits parse_glsl_version() into two functions:
parse_glsl_version_number(), which parses the bare version number, and
parse_glsl_version_string(), which expects the prefix "OpenGL ES GLSL
ES " when compiled for GLES testing.
glslparsertest: Don't require ES compatibility extensions when testing GLES.

glslparsertest should only check for the presence of
GL_ARB_ES{2,3}_compatibility when the test is running under desktop
GL.  GLES never exposes these extensions.
glslparsertest: Avoid uninitialized vars in parse_glsl_version_number.

Previously, if the user specified an ill-formed GLSL version number
(or the implementation supplied an ill-formed number in its response
to glGetString(GL_SHADING_LANGUAGE_VERSION)), glslparsertest would
access uninitialized variables, resulting in unpredictable (and often
confusing) behaviour.

With this patch, glslparser test accepts version numbers either of the
form "<int>" or "<int>.<int>".  Ill-formed version numbers lead to a
test failure.
Test transform feedback of varying structs.

The test may be run either against GLSL ES 3.00 or against desktop
GLSL 1.50.  When desktop GLSL is tested, the test verifies proper
functioning both with and without the use of interface blocks.

This test is slightly meaner than what's currently necessary to verify
proper functionality in Mesa (in particular, it tests a variety of
different nestings of structs and arrays, even though no extra
implementation effort was necessary to make these tests pass).  I have
two reasons for wanting to write such a mean test:

- Varying structs in Mesa are currently implemented using a naive
  layout that packs structure and array contents in order with no gaps
  (in much the same way that structs are laid out in memory in C).
  It's likely that in the future we will need to replace this with a
  more sophisticated mechanism that "flattens" varying structs to
  their constituent fields.  Such an implementation will have
  important corner cases involving complex nesting of structs and
  arrays.

- During my implementation of this feature in Mesa (and my development
  of this test), I cross-checked against a competing implementation
  and found several bugs, particularly in cases involving complex
  nesting of structs and arrays.  It seemed worthwhile to write a test
  capable of detecting these bugs.