| Age | Commit message (Collapse) | Author |
|---|
|
Not actually necessary. rgbTriStrip test used it but it was just a proof
of concept, never part of any test list.
This greatly simplifies building piglit for Windows.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
|
|
This directory contained a single test, gles2_shader_runner, that was
never used. It was a failed artifact from the time when we were scrambling
to discover how to support GLES2 in piglit. Instead, GLES functionality
has been added to the real shader runner, tests/shaders/shader_runner.c.
In the future, any tests specific to GLES2 should go into the directory
tests/spec/gles-2.0, just as we do for all other GL versions.
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
|
|
Some cmake options and features macros had form USE_${feature}, others
BUILD_${category}_TESTS. This patch consistently prefixes all such options
and macros with PIGLIT.
Piglit, be a good code citizen. Namespace your variables.
This patch was created with
find . -type f | xargs sed -i \
-e 's/\(^\|[^_]\)\(USE_\(GLX\|GLUT\|WAFFLE\|OPENGL\|OPENGL_ES1\|OPENGL_ES2\)\)\($\|[^_]\)/\1PIGLIT_\2\4/g' \
-e 's/\(^\|[^_]\)\(BUILD_\(CL\|GLX\|GLES1\|GLES2\)_TESTS\)\($\|[^_]\)/\1PIGLIT_\2\4/g' \
Reviewed-and-tested-by: Jordan Justen <jordan.l.justen@intel.com>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Tested-by: Paul Berry <stereotype441@gmail.com>
Acked-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
|
|
The texline test did not probe any pixels and was not listed in all.tests.
It was not a test at all.
This patch also removes directory tests/mesa, because the utility
functions defined there were only used by texline.
CC: Eric Anholt <eric@anholt.net>
Reviewed-by: Brian Paul <brianp@vmware.com>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
|
|
Build OpenCL tests to binaries with 'cl-' prefix. Each test type adds
another prefix to it, for example Custom test has a 'cl-custom-' prefix.
Signed-off-by: Blaž Tomažič <blaz.tomazic@gmail.com>
|
|
This is the first of a new category of piglit tests that exercise
things related to security.
The first test, initialized-texmemory, creates a texture image with
unspecified contents (pixels=NULL). We draw a polygon with the texture
and see what we get. Ideally, we'd get a constant/black image and not
some random VRAM data from another application or another user (like a
window image). The OpenGL spec doesn't say that texture memory should
be initialized in this situation so if the test fails we return "WARN"
rather than "FAIL".
Reviewed-by: José Fonseca <jfonseca@vmware.com>
|
|
It was impossible to have the source directory read-only.
Also add the include_directories() directive for tests/util
in just one place, under tests/, so that all subdirectories
inherit it. A bunch of CMakeLists.txt files duplicate it,
so delete those redundant include flags:
sed -i -e "/^\t\${piglit_SOURCE_DIR}\/tests\/util/ d" \
`grep piglit_SOURCE_DIR -rl tests/ | grep "CMakeLists\.gl"`
|
|
This is the first GLESv1 tests. GL_OES_draw_texture is a GLESv1
specific extension.
The tests are added to the newly created all_es1.tests.
Changes since v1:
- rename the file name to oes_draw_texture.c
- rename the static variable glDrawTexiOES to piglit_glDrawTexiOES
- add all_es1.tests for this (and future) GLESv1 tests
Changes since v2:
- Put the test in tests/spec/oes_draw_texture instead of tests/gles1.
- Minor fixes to all_es1.tests
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
|
|
This commit adds the infrastructure for writing GLES1 specific tests.
Reviewed-by: Ian Romanick <ian.d.romanick at intel.com>
|
|
It's only used by glean, so no need to force linking against it everywhere.
|
|
Eventually there will be over a dozen HiZ tests, so placing common
functionality in a library will reduce a good hunk of code.
Reviewed-By: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Chad Versace <chad.versace@intel.com>
|
|
Apply fixes to gles2_shader_runner.c to get it to build.
Then enable build in CMake files.
Signed-off-by: Chad Versace <chad.versace@intel.com>
|
|
A convenience header that includes the actual OpenGL headers, which are
chosen according to the macro definitions USE_OPENGL and USE_OPENGL_ES2.
Note: This belongs to a series that adds GLES2 support to Piglit.
Signed-off-by: Chad Versace <chad.versace@intel.com>
|
|
In order to add proper GLES2 support to the build system, the CMake files
must undergo significant change. Disabling GLES2 targets is necessary in
order to prevent breaking the build during that CMake upheaval.
Note: This belongs to a series that adds GLES2 support to Piglit.
Signed-off-by: Chad Versace <chad.versace@intel.com>
|
|
|
|
|
|
This in an updated version of the test I posted, now split into 8 tests
sharing a common header file.
It now features testing of multiple render targets and fog.
Test output logs and results on GeForce 8xxx, GTX 2xx or ideally GTX 4xx
with the proprietary drivers would be really welcome.
The files are put in "spec/arb_color_buffer_float" with the idea of
starting a convention of writing testsuites for each new extension
to be implemented in Mesa, putting it in "spec/<extension_name>".
The tests now fail on any bugs in the default mode.
If "-xfail" is passed, then known bugs on ATI and nVidia will be ignored,
and all tests will then succeed.
The driver bugs don't seem due (solely) to hardware limitations, but may
be due to software fallbacks being improperly implemented.
There are two areas where the specification seems unclear, as far as I
understand it.
I'm not sure what the process to ask for clarification is, and suggestions
would be welcome here.
This first issue is whether, when fragment clamping is set to FIXED_ONLY
and the FBO has some fixed-point and some floating-point buffers attached,
gl_FragData[n] is never clamped, or is clamped only for the fixed point
buffers.
Note that while blending on fixed-point clamps the color anyway, alpha
test and polygon smoothing happen before blending, and should be affected
by whether gl_FragData[n] is clamped or not.
From the OpenGL 4.1 spec, it seems that the intent is that fragment
clamping does not depend on the target, especially because it can be
bound dynamically due to user-defined varyings.
None of the hardware I have access to supports such dishomogeneous FBOs,
so I have no idea what the proprietary drivers do.
Current nVidia cards might shed light on this.
The second issue is whether disabling fragment clamping disables the
clamping done before fog application in fragment shaders with ARB_fog_*
options (or whether this is undefined)
This happens in the fixed pipeline, but making it happen for shaders too
would contradict the rationale of adding ARB_fog_* to shaders, which
is to avoid recompilation.
All the hardware I have access to has fixed function fog (all existing
Radeons seem to have it), and here the disabling applies to fragment
programs too, as a "naive" implementation would result in.
Again, current nVidia cards might shed light on this.
|
|
If EGL is not found, don't run the tests.
|
|
|
|
|
|
The mesa tests currently do not build under MSVC or on Mac OS.
|
|
|
|
|
|
|
|
|
|
This test has seen only limited testing. The GM945 driver fails in the
expected way from code inspection. More concerning is that Mesa software
appears to select a mipmap one level smaller than it should.
|
|
|
|
|
