sso-user-varying: Remove probes for undefined values.

If it's undefined, you can't expect it to (not) be any particular
value.
glx-multithread-makecurrent-*: Write the expected value for alpha

The tests would previously write 0.0 to the alpha and expect to read 1.0
back.  If the test got a visual without alpha (and it doesn't request
alpha), this would happen to work.  However, drivers are not required to
expose visuals without alpha, so the test might get an RGBA visual
afterall.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59738
Reviewed-by: Brian Paul <brianp@vmware.com>
Accept array uniform names with or without [0] from glGetActiveUniform

This is required by OpenGL ES 3.0 and desktop OpenGL 4.2.  Previous
version were ambiguous.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Cc: Frank Henigman <fjhenigman@google.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59688
Reviewed-by: Carl Worth <cworth@cworth.org>
GL_ARB_ubo/getintegeri_v: Respect implementation value of GL_UNIFORM_BUFFER_OFFSET_ALIGNMENT

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Cc: Vinson Lee <vlee@freedesktop.org>
Cc: Fredrik Höglund <fredrik@kde.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59331
ARB_shading_language_packing: fix exact tests

Commit 78435fe (ARB_shading_language_packing: Allow some imprecision
in unpackUnorm4x8) inadvertently introduced a regression to the
unpackHalf2x16 tests.  In those tests, the "exact" uniform wasn't
being initialized, resulting in the tests being run in inexact
fashion.

Surprisingly, this actually produced a failure, because inexact
testing uses "distance(actual, expect) < 0.00001" as the pass/fail
criterion, and this doesn't work when actual == expect == Infinity
(because distance(Inf, Inf) == NaN).

We always intended to test unpackHalf2x16 in exact fashion anyhow, so
the fix is to go ahead and initialize the "exact" uniform to 1 for
this case.
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.
Use asprintf to concatenate strings.