Current workaround assumes that glMapBuffer and glMapBufferRange
'access' bitfield uses the same values, when it is not.
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>

Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>

Test leaks a memory allocated by malloc: fixed

CC: Paul Berry <stereotype441@gmail.com>
Signed-off-by: Sergii Romantsov <sergii.romantsov@globallogic.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>

There's a limitation on VC4 where it can only handle 65536 verts at a
time in a glDrawArrays(), so the driver needs to split up the calls.
This tests that path for all the primitive types.

v2: handle error from glMapBuffer().
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

Test verifies correct work of alpha-to-coverage with every variation of
sample mask, all levels of MSAA and different number of render targets.
Signed-off-by: Andrii Kryvytskyi <andrii.o.kryvytskyi@globallogic.com>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>

Usage of shader program disables most of fixed functions
functionality, at least projection and glColor.

This fixes the test for Gallium drivers.  It also makes it pass on
NVIDIA 418.56 (GP107M).
Signed-off-by: Danylo Piliaiev <danylo.piliaiev@globallogic.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

Cc: Veluri Mithun <velurimithun38@gmail.com>
Cc: Emil Velikov <emil.l.velikov@gmail.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Nicolai Hähnle <nicolai.haehnle@amd.com>
Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>

Signed-off-by: Tapani Pälli <tapani.palli@intel.com>

v2: test glGetIntegerv after every every change of the thread count
    spaces -> tabs

Besides code removal, this fixes behavior if test_format was to return
PIGLIT_WARN on some tests but not others.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

Reviewed-by: Tapani Pälli <tapani.palli@intel.com>

I wanted to fix up some type-punning warnings and was surprised to see
we didn't have this yet.
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>

The shared one is a more complete implementation of half-float
packing.

Untested, since Mesa doesn't support the extension.
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>

From the GL_ARB_program_interface_query spec v.20:

  " When a program is linked, the GL builds a list of /active
    resources/ for each interface.  Examples of active resources
    include variables, interface blocks, and subroutines used by
    shader code.  Resources referenced in shader code are considered
    /active/ unless the compiler and linker can conclusively determine
    that they have no observable effect on the results produced by the
    executable code of the program.  For example, variables might be
    considered inactive if they are declared but not used in
    executable code, used only in a clause of an "if" statement that
    would never be executed, used only in functions that are never
    called, or used only in computations of temporary variables having
    no effect on any shader output.  In cases where the compiler or
    linker cannot make a conclusive determination, any resource
    referenced by shader code will be considered active.  The set of
    active resources on for any interface is implementation-dependent
    because it depends on various analysis and optimizations performed
    by the compiler and linker."

Therefore, although the determination of the active resources is
implementation dependent, it is clear that not making any kind of use
in the shader code will, most probably, make the compiler/linker
determine that the resource is inactive.
Signed-off-by: Andres Gomez <agomez@igalia.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Martin Peres <martin.peres@linux.intel.com>

And also redefined built-ins that are not used.

From Section 7.4.1 (Shader Interface Matching) of the OpenGL 4.60
spec:

  " To use any built-in input or output in the gl_PerVertex block in
    separable program objects, shader code must redeclare that block
    prior to use. A separable program will fail to link if:

      * it contains multiple shaders of a single type with different
         redeclarations of this built-in block; or

      * any shader uses a built-in block member not found in the
        redeclaration of that block.

    There is one exception to this rule described below.

    As described above, an exact interface match requires matching
    built-in input and output blocks. At an interface between two
    non-fragment shader stages, the gl_PerVertex input and output
    blocks are considered to match if and only if the block members
    match exactly in name, type, qualification, and declaration order.
    At an interface involving the fragment shader stage, the presence
    or absence of any built-in output does not affect interface
    matching."
Signed-off-by: Andres Gomez <agomez@igalia.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Martin Peres <martin.peres@linux.intel.com>

From Section 7.4.1 (Shader Interface Matching) of the OpenGL 4.60
spec:

  " To use any built-in input or output in the gl_PerVertex block in
    separable program objects, shader code must redeclare that block
    prior to use. A separable program will fail to link if:

      * it contains multiple shaders of a single type with different
        redeclarations of this built-in block; or

      * any shader uses a built-in block member not found in the
        redeclaration of that block.

    There is one exception to this rule described below.

    As described above, an exact interface match requires matching
    built-in input and output blocks. At an interface between two
    non-fragment shader stages, the gl_PerVertex input and output
    blocks are considered to match if and only if the block members
    match exactly in name, type, qualification, and declaration order.
    At an interface involving the fragment shader stage, the presence
    or absence of any built-in output does not affect interface
    matching."
Signed-off-by: Andres Gomez <agomez@igalia.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Martin Peres <martin.peres@linux.intel.com>

no-error.c: In function ‘check_no_error’:
no-error.c:37:3: error: ‘GLX_CONTEXT_OPENGL_NO_ERROR_ARB’ undeclared (first use in this function)
   GLX_CONTEXT_OPENGL_NO_ERROR_ARB, 1,
   ^

Fixes: 4991384f ("glx: add test for GLX_ARB_create_context_no_error")
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Adam Jackson <ajax@redhat.com>

Fixes: db98d3a7 ("arb_enhanced_layouts: corrected multiple comments")
Suggested-by: Timothy Arceri <tarceri@itsqueeze.com>
Signed-off-by: Andres Gomez <agomez@igalia.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>

This test for a crash in Mesa seen in an Assasins Creed Odyssey shader.
Reviewed-by: Andres Gomez <agomez@igalia.com>

From the GL_ARB_enhanced_layouts spec:

  " No aliasing in output buffers is allowed: It is a compile-time or
    link-time error to specify variables with overlapping transform
    feedback offsets."

v2: added forgotten check_link.

Cc: Timothy Arceri <tarceri@itsqueeze.com>
Signed-off-by: Andres Gomez <agomez@igalia.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>

Additional check to address a bug in mesa in which a stride which
is a divisor of the declared offset for an overflowing varying
won't fail.

From the GL_ARB_enhanced_layouts spec:

  " It is a compile-time or link-time error to have any *xfb_offset*
    that overflows *xfb_stride*, whether stated on declarations before
    or after the *xfb_stride*, or in different compilation units."

Cc: Timothy Arceri <tarceri@itsqueeze.com>
Signed-off-by: Andres Gomez <agomez@igalia.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>

New tests for component aliasing with duplicated inputs which match
the same output variable in the previous stage.

From Section 4.4.1 (Input Layout Qualifiers) of the GLSL 4.60 spec:

  " Location aliasing is causing two variables or block members to
    have the same location number. Component aliasing is assigning the
    same (or overlapping) component numbers for two location
    aliases. (Recall if component is not used, components are assigned
    starting with 0.) With one exception, location aliasing is allowed
    only if it does not cause component aliasing; it is a compile-time
    or link-time error to cause component aliasing."

From Section 7.4.1 (Shader Interface Matching) of the OpenGL 4.60 spec:

  "   * An output variable is considered to match an input variable in
        the subsequent shader if:

        – the two variables match in name, type, and qualification,
          and neither has a location qualifier, or

        – the two variables are declared with the same location and
          component layout qualifiers and match in type and
          qualification."

Cc: Timothy Arceri <tarceri@itsqueeze.com>
Cc: Iago Toral Quiroga <itoral@igalia.com>
Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Andres Gomez <agomez@igalia.com>
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>

There was a pre-existing test using "component = 0" with dvec3 which
was not failing as it should. This was because the other tests
checking for the usage of the component keyword with dvec3 and dvec4
were failing due to a different restriction: the component sequence
was overflowing 3 and/or a double based type was using component 1 o
3.

Now we fix them by using "component = 0" when need to fail and
removing the keyword when need to succeed.

From Section 4.4.1 (Input Layout Qualifiers) of the GLSL 4.50 spec:

  " It is a compile-time error if this sequence of components gets
    larger than 3. A scalar double will consume two of these
    components, and a dvec2 will consume all four components available
    within a location. A dvec3 or dvec4 can only be declared without
    specifying a component."

...

  " It is a compile-time error to use component 1 or 3 as the
    beginning of a double or dvec2."

Cc: Timothy Arceri <tarceri@itsqueeze.com>
Cc: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Andres Gomez <agomez@igalia.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>

Added tests which check component aliasing between types that have
different bit widths.

From Section 4.4.1 (Input Layout Qualifiers) of the GLSL 4.60 spec:

    "Further, when location aliasing, the aliases sharing the location
     must have the same underlying numerical type and bit
     width (floating-point or integer, 32-bit versus 64-bit, etc.)
     and the same auxiliary storage and interpolation
     qualification. The one exception where component aliasing is
     permitted is for two input variables (not block members) to a
     vertex shader, which are allowed to have component aliasing. This
     vertex-variable component aliasing is intended only to support
     vertex shaders where each execution path accesses at most one
     input per each aliased component. Implementations are permitted,
     but not required, to generate link-time errors if they detect
     that every path through the vertex shader executable accesses
     multiple inputs aliased to any single component."

Cc: Timothy Arceri <tarceri@itsqueeze.com>
Cc: Iago Toral Quiroga <itoral@igalia.com>
Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Andres Gomez <agomez@igalia.com>
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>

Corrected several component aliasing tests which shouldn't be failing
or were failing due to a different reason than the tested one:
interpolation qualifiers mismatch.

From Section 4.4.1 (Input Layout Qualifiers) of the GLSL 4.50 spec:

  " Further, when location aliasing, the aliases sharing the location
    must have the same underlying numerical type (floating-point or
    integer) and the same auxiliary storage and interpolation
    qualification."

Cc: Timothy Arceri <tarceri@itsqueeze.com>
Signed-off-by: Andres Gomez <agomez@igalia.com>
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>

Cc: Timothy Arceri <tarceri@itsqueeze.com>
Signed-off-by: Andres Gomez <agomez@igalia.com>
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>

Cc: Timothy Arceri <tarceri@itsqueeze.com>
Signed-off-by: Andres Gomez <agomez@igalia.com>
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>

New tests to check that an unused input varying, which would be
matched based on its explicit location, won't cause a link failure if
there is no matching output variable.

From the ARB_separate_shader_objects spec v.25:

  "   * An output variable is considered to match an input variable in
        the subequent shader if:

        * the two variables match in name, type, and qualification; or

        * the two variables are declared with the same location layout
          qualifier and match in type and qualification."

  ...

  " For program objects containing multiple shaders, LinkProgram will
    check for mismatches on interfaces between shader stages in the
    program being linked and generate a link error if a mismatch is
    detected.  A link error will be generated if any statically
    referenced input variable or block does not have a matching
    output."

Cc: Timothy Arceri <tarceri@itsqueeze.com>
Cc: Iago Toral Quiroga <itoral@igalia.com>
Cc: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Cc: Tapani Pälli <tapani.palli@intel.com>
Cc: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Andres Gomez <agomez@igalia.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>

New tests for location overlap with scalars, doubles and for
duplicated inputs which match the same output variable in the previous
stage.

From the ARB_separate_shader_objects spec v.25:

  "   * An output variable is considered to match an input variable in
        the subequent shader if:

        * the two variables match in name, type, and qualification; or

        * the two variables are declared with the same location layout
          qualifier and match in type and qualification."

...

  " A program will fail to link if any two non-vertex shader input
    variables are assigned to the same location."

Cc: Timothy Arceri <tarceri@itsqueeze.com>
Cc: Iago Toral Quiroga <itoral@igalia.com>
Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Andres Gomez <agomez@igalia.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>

New tests to check that, with separable program objects, interface
matching by name or location are still checked at link time between
the inner interfaces existing inside the program.

From the ARB_separate_shader_objects spec v.25:

  " With separable program objects, interfaces between shader stages
    may involve the outputs from one program object and the inputs
    from a second program object.  For such interfaces, it is not
    possible to detect mismatches at link time, because the programs
    are linked separately.  When each such program is linked, all
    inputs or outputs interfacing with another program stage are
    treated as active.  The linker will generate an executable that
    assumes the presence of a compatible program on the other side of
    the interface.  If a mismatch between programs occurs, no GL error
    will be generated, but some or all of the inputs on the interface
    will be undefined."

Cc: Timothy Arceri <tarceri@itsqueeze.com>
Cc: Iago Toral Quiroga <itoral@igalia.com>
Cc: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Cc: Tapani Pälli <tapani.palli@intel.com>
Cc: Ian Romanick <ian.d.romanick@intel.com>
Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Andres Gomez <agomez@igalia.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>

Previuosly, this was overlooked asuming that, since they were SSOs, no
inner interface matching check was needed.

From the ARB_separate_shader_objects spec v.25:

  " With separable program objects, interfaces between shader stages
    may involve the outputs from one program object and the inputs
    from a second program object.  For such interfaces, it is not
    possible to detect mismatches at link time, because the programs
    are linked separately.  When each such program is linked, all
    inputs or outputs interfacing with another program stage are
    treated as active.  The linker will generate an executable that
    assumes the presence of a compatible program on the other side of
    the interface.  If a mismatch between programs occurs, no GL error
    will be generated, but some or all of the inputs on the interface
    will be undefined."

Cc: Timothy Arceri <tarceri@itsqueeze.com>
Cc: Tapani Pälli <tapani.palli@intel.com>
Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: Martin Peres <martin.peres@linux.intel.com>
Signed-off-by: Andres Gomez <agomez@igalia.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>

Cc: Timothy Arceri <tarceri@itsqueeze.com>
Cc: Martin Peres <martin.peres@linux.intel.com>
Signed-off-by: Andres Gomez <agomez@igalia.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>

In OpenGL 4.6 (Table 23.57: Implementation Dependent Vertex Shader Limits)
specification  said, that minimum value of MAX_VERTEX_ATOMIC_COUNTERS is 0.
Therefore if we use them we have to check available count.
Signed-off-by: Illia Iorin <illia.iorin@globallogic.com>
Reviewed-by: Eric Anholt <eric@anholt.net>

Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>

With GitLab is now much easier to setup.
Reviewed-by: Brian Paul <brianp@vmware.com>

Newer CMake versions (in particular 3.13.3 currently used by default
Appveyor machine) expects GLUT_glut_LIBRARY_RELEASE variable, instead of
GLUT_glut_LIBRARY.
Reviewed-by: Brian Paul <brianp@vmware.com>

We made some wrong assumptions about the format layout, this fixes
input given to formats, input can be identical.

v2: clear out 6 lsb from P010 and 4 lsb from P012

Fixes: 3ce4e483 "EGL_EXT_image_dma_buf_import: add P12, P16 format support"
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

Same as the EGL test, but without testing GLES contexts.
Reviewed-by: Eric Anholt <eric@anholt.net>