| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
|
|
|
|
|
|
This test initially provides API test for EXT_transform_feedback,
checking for new functions, tokens, and the support for new tokens
in existent GL entry points..
|
|
Not really a FBO test, but it may help uncover some bugs.
|
|
|
|
This is a clone of the general draw-vertices test but adapted to test
the ARB_vertex_type_2_10_10_10_rev VBO api.
|
|
All of these tests follow a similar form. An array of matrices is set
to some values that have one incorrect element. A non-constant index
write is used to fix that incorrect element. The result is verified.
The tests vary on:
- Storage qualifier of the array/matrix (uniform, temporary, varying).
- Array / not an array.
- Matrix size (mat2, mat3, mat4).
- Whether or not the array index is a non-constant.
- Whether or not the matrix column is a non-constant.
- Whether or not the matrix row is a non-constant.
Since the base type is always a matrix, attributes and fragment shader
outputs are not tested.
|
|
All of these tests follow a similar form. A simple shader that reads
a particular array element, matrix column, and vector element (matrix
row) and compares it to some expected value. The tests vary on:
- Storage qualifier of the array/matrix (uniform, temporary, varying).
- Array / not an array.
- Matrix size (mat2, mat3, mat4).
- Whether or not the array index is a non-constant.
- Whether or not the matrix column is a non-constant.
- Whether or not the matrix row is a non-constant.
Since the base type is always a matrix, attributes and fragment shader
outputs are not tested.
|
|
Setting the rlimit should prevent the tests from completely exhausting
system memory and swap. Since the tests are more system friendly,
they are removed from the blacklist.
Acked-by: José Fonseca <jfonseca@vmware.com>
|
|
Acked-by: José Fonseca <jfonseca@vmware.com>
|
|
This test is made redundant by the spec/glsl-1.20/recursion tests. As
is, this test may not have been valid. It expected the error to be
generated at compile time, but many implementations generate this
error at link time.
Acked-by: José Fonseca <jfonseca@vmware.com>
|
|
These aren't done as shader_runner tests because there is no way to
expect linking or compilation to fail in shader_runner.
All of these tests pass on NVIDIA's closed-source driver except
'unreachable' and 'unreachable-constant-folding'.
All of these tests fail on AMD's closed-source driver, and 'simple',
'unreachable', and 'unreachable-constant-folding' crash inside the
driver. It looks like the compiler tries to recursively inline the
functions until the stack overflows.
Mesa currently produces pretty much the same results as AMD, but Mesa
can occasionally OOM instead of running out of stack.
I have not tested Apple's driver or Intel's Windows driver.
Reviewed-by: Chad Versace <chad@chad-versace.us>
Acked-by: José Fonseca <jfonseca@vmware.com>
|
|
Acked-by: José Fonseca <jfonseca@vmware.com>
|
|
This function sets the maximum amount of memory that a process can
have in its address space. This is useful for tests that use
"infinite" memory on failing implementations. Setting this low can
prevent the test from exhausting system memory and adversely affecting
other tests.
Acked-by: José Fonseca <jfonseca@vmware.com>
|
|
GLSL 1.30 added support for the following new built-in functions:
sinh, cosh, tanh, asinh, acosh, atanh, round, roundEven, trunc, modf,
isnan, and isinf.
This patch adds tests for all of the new built-in functions except
modf, isnan, and isinf. modf will need to be tested separately
because it has an out parameter; isnan and isinf will need to be
tested separately because producing infinite and NaN values will
require extra work in the shader.
Reviewed-by: Chad Versace <chad@chad-versace.us>
|
|
GLSL 1.30 adds support for the following operators: %, ~, <<, >>, &,
^, and |. This patch adds autogenerated tests for testing the
functionality of all these operators.
Reviewed-by: Chad Versace <chad@chad-versace.us>
|
|
GLSL 1.30 allows int and ivecN types to be passed to the functions
abs, sign, min, max, and clamp. In addition, it adds new unsigned
integer types uint and uvecN, which may be passed to min, max, clamp,
lessThan, lessThanEqual, greaterThan, greaterThanEqual, equal,
notEqual, and built-in operators.
This patch adds auto-generated tests for all of these new integral
built-in functions and operations.
Reviewed-by: Chad Versace <chad@chad-versace.us>
|
|
With this patch, shader_runner tests can now supply uniform values
using types "uint" and "uvecN".
Reviewed-by: Chad Versace <chad@chad-versace.us>
|
|
This patch adds glUniform{1,2,3,4}ui and glUniform{1,2,3,4}uiv to the
set of GL functions available through aliases beginning with
"piglit_", so that they can be called from piglit tests in the same
manner as other OpenGL functions. Also added the missing versions of
glUniform{1,2,3,4}i and glUniform{1,2,3,4}iv.
Reviewed-by: Chad Versace <chad@chad-versace.us>
|
|
For builtin functions and operators returning bool, added generated
tests that use the return values in if statements like this:
if (a < b)
gl_FragColor = vec4(1.0, 1.0, 0.0, 1.0);
else
gl_FragColor = vec4(0.0, 0.0, 1.0, 1.0);
in addition to the existing tests that convert the return values to
floats, like this:
bool result = a < b;
gl_FragColor = vec4(result, 0.0, 0.0, 0.0);
Since implementations may produce substantially different GPU code for
these two cases.
Reviewed-by: Chad Versace <chad@chad-versace.us>
|
|
This function has been available since as early GLSL 1.10, it was
simply forgotten from the initial implementation of generated tests.
Reviewed-by: Chad Versace <chad@chad-versace.us>
|
|
This patch adds negative and zero values to the set of ints used to
test lessThan, lessThanEqual, greaterThan, greaterThanEqual, and
equal. It also adds ivecs whose elements are all positive to the
tests for operators--these will come in handy when we add tests for %,
which is not defined for negative inputs.
Reviewed-by: Chad Versace <chad@chad-versace.us>
|
|
This patch makes gen_builtin_uniform_tests.py and
gen_constant_array_size_tests.py build tests in a deterministic order,
so that when diffing their outputs from one revision to the next, it
is easier to see what changed.
There is no change in the actual tests generated, just in the *.list
files that are created as a side effect.
Reviewed-by: Chad Versace <chad@chad-versace.us>
|
|
Should fix MSVC build.
|
|
|
|
This patch adds tests for the following built-in GLSL operators:
- op-add, op-sub, op-mult, op-div: binary arithemetic operators on
floats, vecs, mats, ints, and ivecs.
- op-uplus, op-neg: unary arithmetic operators on floats, vecs, mats,
ints, and ivecs.
- op-gt, op-lt, op-ge, op-le: comparison operators on ints and floats.
- op-eq, op-ne: equality and inequality comparison on any GLSL 1.20 type.
- op-and, op-or, op-xor: logical operations on bools.
- op-not: unary logical not on bools.
- op-selection: trinary selection operator (x?y:z), where the first
argument is a bool and the second and third arguments are any GLSL
1.20 type.
Note that implicit type conversions are not tested. So, for instance,
int * ivec is tested, but float * ivec is not. This was in an effort
to avoid generating an outrageous number of tests.
Note also that the "shortcut" behavior of logical and/or and trinary
selection is not tested.
These tests leverage the same test generation framework used to test
built-in functions, so the tests exercise vertex shaders, fragment
shaders, and constant folding.
All in all 1332 tests are added, in the subtrees
spec/glsl-1.{10,20}/{compiler,execution}/built-in-functions.
Reviewed-by: Eric Anholt <eric@anholt.net>
|
|
|
|
In Python 2.6, the str.decode() function can't take keyword arguments,
so x.decode(y, errors=z) must be changed to x.decode(y, z). There is
no difference in functionality.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=40051
|
|
|
|
This patch is a preparation for work I'm about to do to add
gl_ClipDistance support to Mesa, and future work that I hope to do to
fix bugs in gl_ClipVertex in Mesa. It adds a thorough set of tests
for the following behaviors of gl_ClipDistance and gl_ClipVertex:
For gl_ClipVertex:
- It behaves properly when equal to gl_Position.
- It behaves properly when not equal to gl_Position.
- It falls back to gl_Position when it is not set.
- Its homogeneous coordinate is respected.
- The homogeneous coordinate is respected when falling back to gl_Position.
For gl_ClipDistance:
- It works when all 6 clip planes are enabled.
- Its behavior is properly affected by clip plane enable flags.
- It can be explicitly or implicitly sized in the vertex shader.
- It can be sized up to gl_MaxClipDistances but no higher.
- In the fragment shader, it contains properly interpolated values.
For the interaction between the two:
- It is an error to assign to both gl_ClipDistance and gl_ClipVertex.
In addition, this patch renames a few of the existing clipping tests
so that their names more clearly reflect what they're testing.
All of these tests have been validated on the proprietary nVidia
driver for Linux, except the following:
- fs-clip-distance-interpolated: this fails with the error message
"gl_ClipDistance is not accessible in this profile". Based on a
google search for this error message, I suspect this is an nVidia
driver bug. If I replace the fragment shader's reference to
gl_ClipDistance with a reference to a user-defined vertex shader
output that contains the same data, the test passes.
- vs-clip-based-on-position and
vs-clip-based-on-position-homogeneity: these tests fail--no
clipping occurs. But they pass if I add the line "gl_ClipVertex =
gl_Position;" to the end of the vertex shader. The GLSL 1.30 spec
clearly states that if neither gl_ClipVertex nor gl_ClipDistance is
statically written by the vertex shader, then gl_Position should be
used for clipping, so I conclude that this is an nVidia driver bug.
- mixing-clip-distance-and-clip-vertex-disallowed: the nVidia driver
fails to detect this error condition, in spite of clear language in
the GLSL 1.30 spec. I conclude that this is an nVidia driver bug.
|
|
This patch adds a new set of generated tests which parallels those
introduced by commt cccc419e (Add comprehensive tests of builtin
functions with uniform input.)
The new tests validate the correctness of built-in functions when used
to compute array sizes. The tests work by creating arrays whose size
is 1 if the result of applying the built-in function is within
tolerance of the correct answer, and -1 if not. Since negative array
sizes are prohibited, any improperly computed values will generate a
compile error.
Though it may seem absurd to compute an array size based on the result
of calling a built-in function, it's worth testing for two reasons:
(1) It is explicitly allowed in GLSL versions since 1.20.
(2) Since array sizes need to be computed at compile time, this is a
convenient way of testing that the GLSL compiler properly implements
constant folding of built-in functions. Indeed, the original
motivation for these tests was to validate bug fixes to Mesa's
constant folding logic.
Here is an example of one of the generated tests (this test is
exp2-vec2.vert):
/* [config]
* expect_result: pass
* glsl_version: 1.20
* [end config]
*
* Check that the following test vectors are constant folded correctly:
* exp2(vec2(-2.0, -0.66666669)) => vec2(0.25, 0.62996054)
* exp2(vec2(0.66666669, 2.0)) => vec2(1.587401, 4.0)
*/
void main()
{
float[distance(exp2(vec2(-2.0, -0.66666669)), vec2(0.25, 0.62996054)) <= 6.7775386e-06 ? 1 : -1] array0;
float[distance(exp2(vec2(0.66666669, 2.0)), vec2(1.587401, 4.0)) <= 4.3034684e-05 ? 1 : -1] array1;
gl_Position = vec4(array0.length() + array1.length());
}
|
|
To figure out where a test file belongs in the test hierarchy,
import_glsl_parser_tests has to determine the test file's path
relative to the "basepath" argument.
Before this patch, it worked out the relative path by dropping the
first three directories from the test file's path. This worked
because import_glsl_parser_tests was always called with a basepath
that contained exactly three directory names, e.g. "./spec/glsl-1.00".
But it was a fragile assumption.
This patch changes import_glsl_parser_tests so that it uses
os.path.relpath() to work out the relative path.
I've also taken the liberty of fixing a typo in the docstring
explaining how basebath is used, and I've changed
"assert(type(testname) is str)" to "assert isinstance(testname,
basestring)", which works properly with Unicode.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
|
|
This patch creates a function, piglit_make_generated_tests (in
generated_tests/CMakeLists.txt), to encapsulate the logic that builds
a custom command. The new function can be reused to generate tests
using other python scripts.
|
|
This patch ensures that Piglit tests both atan(x) and atan(x,y) for
both very small and very large inputs.
Previously, Piglit only tested the atan() functions over a small range
of input values, causing it to miss a bug in Mesa (which has since
been fixed--see Mesa commit b1b4ea0b).
|
|
Due to a design flaw in Python 2.x, if an 8-bit string containing a
non-ASCII character is ever used in a context requiring a unicode
string, the Python interpreter will raise an exception. This happens
because Python lazily decodes 8-bit strings to unicode as needed, and
when it does the decoding it assumes the 8-bit string is in ASCII
format. Because of this lazy decoding behavior, this means
that 8-bit strings containing non-ASCII characters are unsafe in any
Python program that also uses unicode.
Since Python 3.x doesn't have 8-bit strings (it has "byte arrays",
which don't autoconvert to unicode strings), the most
forward-compatible way to address this problem is to find the source
of the unsafe 8-bit strings, and introduce an explicit decoding step
that translates them to unicode strings and handles errors properly.
This problem manifested in Piglit if the output of a test ever
contained a non-ASCII character. Due to Python 2.x's lazy string
decoding semantics, the exception wouldn't occur until attempting to
serialize the test output as JSON.
This patch introduces an explicit step, right after running a test,
which decodes the test output from 8-bit strings into unicode. The
decoding assumes UTF-8, and silently replaces invalid UTF-8 sequences
with the unicode "replacement character" rather than raise an
exception.
|
|
Previously piglit-summary-html didn't explicitly encode its output at
all--it relied on the default behavior of the Python file.write()
method (which, in Python 2.x, is to write 8-bit strings verbatim and
to encode unicode strings using ASCII). This meant that if a
non-ASCII character appeared in any of the test data,
piglit-summary-html would fail with an exception.
This patch changes piglit-summary-html to explicitly encode its output
using UTF-8. It also updates all of the HTML templates to specify
UTF-8 as the encoding, so that when results are viewed in a web
browser, non-ASCII characters will display correctly.
|
|
See https://bugs.freedesktop.org/show_bug.cgi?id=39966
|
|
Versions of numpy previous to 1.3.0 (such as the one that ships with
Snow Leopard, which is 1.2.1) didn't include an exp2() function, so
commit a5180ddc worked around the problem by emulating it using
power(2, x) when the numpy version was less than 1.3.0.
There is no real advantage to using exp2() over power(2, x) (other
than to save a few keystrokes), but there is a maintenance advantage
to being as consistent as possible across numpy versions. So this
patch changes Piglit to use power(2, x) regardless of the numpy
version.
|
|
This patch modifies the invocation of CMake's add_custom_command()
function so that instead of specifying all 462 output files
explicitly, it instead specifies a single file,
builtin_uniform_tests.list, which receives a list of all the files
generated.
It is safe not to specify the individual output files since there are
no other build steps that depend on them, so there is no danger of the
build step happening at the wrong time.
This prevents CMake from trying to output an outrageously long
diagnostic message listing all the files generated by the custom
command, a message that was too long to work with the NMake back-end
used on Windows.
Bugzilla:https://bugs.freedesktop.org/show_bug.cgi?id=39873
|
|
This is failing on Intel pre-GEN6, but will be fixed shortly.
|
|
The GL_TEXTURE_INTERNAL_FORMAT query isn't an important part of this test.
See http://bugs.freedesktop.org/show_bug.cgi?id=39964
|
|
On Arch Linux, "python" means Python 3.x, and Python 2.x is called
"python2". The test generation code requires Python 2.x. In many
other distributions, "python" refers to Python 2.x.
This patch adds logic to the toplevel CMakeLists that checks both
"python2" and "python" to see which one is Python 2.x, and once it is
found, sets the cmake variable ${python} to point to it.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
|
|
|
|
|
|
|
|
numpy.exp2 became available starting with numpy-1.3.0.
Mac OS X 10.6.8 (Snow Leopard) has numpy-1.2.1.
|
|
This test exercises a bug in Mesa. If a function that is not known to
the compilation unit containing main() (IOW, neither defined not
declared in that compilation unit) attempts to access a global
variable, then improper IR is generated.
I'll be submitting a patch to Mesa to fix this problem, and to check
the IR validity after linking. This test will ensure that the fix
won't regress.
Reviewed-by: Eric Anholt <eric@anholt.net>
|
|
This patch adds six tests of the proper behavior of function out
parameters when used in a context that requires implicit type
conversion.
Two of the tests are based on an explicit example in the GLSL-1.30
spec. The remaining tests adapt this example to GLSL 1.20 (which
seems to be intended to have the same conversion rules, though they
are less clearly articulated).
|
