Re: [Piglit] [PATCH] util: probe pixel rectangles as ubyte if possible (v2)
Looks good.
Reviewed-by: Brian Paul
Sorry for being slow. I'm on vacation this week.
On Sat, Apr 16, 2016 at 8:25 AM, Marek Olšák wrote:
> From: Marek Olšák
>
> v2: int -> bool, unify all new functions into one
> ---
> tests/util/piglit-util-gl.c | 94
> +
> 1 file changed, 94 insertions(+)
>
> diff --git a/tests/util/piglit-util-gl.c b/tests/util/piglit-util-gl.c
> index e8a47c5..09eb99d 100644
> --- a/tests/util/piglit-util-gl.c
> +++ b/tests/util/piglit-util-gl.c
> @@ -1060,6 +1060,23 @@ piglit_read_pixels_float(GLint x, GLint y, GLsizei
> width, GLsizei height,
> return pixels;
> }
>
> +static bool
> +piglit_can_probe_ubyte()
> +{
> + int r,g,b,a;
> +
> + glGetIntegerv(GL_RED_BITS, &r);
> + glGetIntegerv(GL_GREEN_BITS, &g);
> + glGetIntegerv(GL_BLUE_BITS, &b);
> + glGetIntegerv(GL_ALPHA_BITS, &a);
> +
> + /* it could be LUMINANCE32F, etc. */
> + if (!r && !g && !b && !a)
> + return false;
> +
> + return r <= 8 && g <= 8 && b <= 8 && a <= 8;
> +}
> +
> int
> piglit_probe_pixel_rgb_silent(int x, int y, const float* expected, float
> *out_probe)
> {
> @@ -1158,6 +1175,74 @@ piglit_probe_pixel_rgba(int x, int y, const float*
> expected)
> return 0;
> }
>
> +static void
> +piglit_array_float_to_ubyte(int n, const float *f, GLubyte *b)
> +{
> + int i;
> +
> + for (i = 0; i < n; i++)
> + b[i] = f[i] * 255;
> +}
> +
> +static void
> +piglit_array_float_to_ubyte_roundup(int n, const float *f, GLubyte *b)
> +{
> + int i;
> +
> + for (i = 0; i < n; i++)
> + b[i] = ceil(f[i] * 255);
> +}
> +
> +static bool
> +piglit_probe_rect_ubyte(int x, int y, int w, int h, int num_components,
> + const float *fexpected, bool silent)
> +{
> + int i, j, p;
> + GLubyte *probe;
> + GLubyte *pixels;
> + GLubyte tolerance[4];
> + GLubyte expected[4];
> +
> + piglit_array_float_to_ubyte_roundup(num_components,
> piglit_tolerance, tolerance);
> + piglit_array_float_to_ubyte(num_components, fexpected, expected);
> +
> + /* RGBA readbacks are likely to be faster */
> + pixels = malloc(w*h*4);
> + glReadPixels(x, y, w, h, GL_RGBA, GL_UNSIGNED_BYTE, pixels);
> +
> + for (j = 0; j < h; j++) {
> + for (i = 0; i < w; i++) {
> + probe = &pixels[(j*w+i)*4];
> +
> + for (p = 0; p < num_components; ++p) {
> + if (abs((int)probe[p] - (int)expected[p])
> >= tolerance[p]) {
> + if (!silent) {
> + printf("Probe color at
> (%i,%i)\n", x+i, y+j);
> + if (num_components == 4) {
> + printf("
> Expected: %u %u %u %u\n",
> +
> expected[0], expected[1],
> +
> expected[2], expected[3]);
> + printf("
> Observed: %u %u %u %u\n",
> + probe[0],
> probe[1], probe[2], probe[3]);
> + } else {
> + printf("
> Expected: %u %u %u\n",
> +
> expected[0], expected[1],
> +
> expected[2]);
> + printf("
> Observed: %u %u %u\n",
> + probe[0],
> probe[1], probe[2]);
> + }
> + }
> + free(pixels);
> + return false;
> + }
> + }
> + }
> + }
> +
> + free(pixels);
> + return true;
> +}
> +
> int
> piglit_probe_rect_rgb_silent(int x, int y, int w, int h, const float
> *expected)
> {
> @@ -1165,6 +1250,9 @@ piglit_probe_rect_rgb_silent(int x, int y, int w,
> int h, const float *expected)
> GLfloat *probe;
> GLfloat *pixels;
>
> + if (piglit_can_probe_ubyte())
> + return piglit_probe_rect_ubyte(x, y, w, h, 3, expected,
> true);
> +
> pixels = piglit_read_pixels_float(x, y, w, h, GL_RGB, NULL);
>
> for (j = 0; j < h; j++) {
> @@ -1223,6 +1311,9 @@ piglit_probe_rect_rgb(int x, int y, int w, int h,
> const float *expected)
> GLfloat *probe;
> GLfloat *pixels;
>
> + if (piglit_can_probe_ubyte())
> + return piglit_probe_rect_ubyte(x, y, w, h, 3, expected,
> false);
> +
> pixels = piglit_read_pixels_float(x, y, w, h, GL_RGBA, NULL);
>
> for (j = 0; j < h; j++) {
> @@ -1290,6 +1381,9 @@ piglit_probe_rect_rgba(int x, int y, int w, int h,
> const float *expected)
> GLfloat *probe
[Piglit] [PATCH] tex-miplevel-selection: only require glsl 1.30 for textureOffset 2DArrayShadow
From: Roland Scheidegger
The spec doesn't really say this should work in older versions. It was first
added in glsl 4.30, mentioning it was forgotten (initially part of
EXT_gpu_shader4, hence should have been added with 1.30), but with the wrong
syntax. Finally fixed in glsl 4.40.
It does, however, work with nvidia blob with version 130 directive.
Also works with llvmpipe (with mesa fix).
---
tests/texturing/tex-miplevel-selection.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/tests/texturing/tex-miplevel-selection.c
b/tests/texturing/tex-miplevel-selection.c
index 959bab2..59030b5 100644
--- a/tests/texturing/tex-miplevel-selection.c
+++ b/tests/texturing/tex-miplevel-selection.c
@@ -322,12 +322,6 @@ piglit_init(int argc, char **argv)
}
piglit_require_gl_version(NEED_GL3(test) ? 30 : 14);
- if (target == TEX_2D_ARRAY_SHADOW &&
- test == GL3_TEXTURE_OFFSET) {
- piglit_require_GLSL_version(430);
- version = "430";
- }
-
switch (target) {
case TEX_1D:
gltarget = GL_TEXTURE_1D;
--
2.1.4
___
Piglit mailing list
Piglit@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/piglit
Re: [Piglit] [PATCH] gen_flat_interpolation_qualifier.py: Adds non-flat interpolation tests generator
Acked-by: Dave Airlie On 18 April 2016 at 23:06, Andres Gomez wrote: > Hi, > > this patch is still unreviewed. > > We'd welcome some help to get this into piglit with guarantees that the > tests added are OK :) > > Br. > > On Mon, 2016-04-04 at 20:05 +0300, Andres Gomez wrote: >> This patch provides additional tests for the patch under review at: >> https://lists.freedesktop.org/archives/mesa-dev/2016-April/111842.htm >> l >> >> Also, this generator provides additional tests for the >> ARB_gpu_shader_fp64 extension: >> https://www.opengl.org/registry/specs/ARB/gpu_shader_fp64.txt >> >> Which has previous patches for new tests under review at: >> https://lists.freedesktop.org/archives/piglit/2016-March/019167.html >> >> This work is complemented with the corresponding bug to add support >> for this extension into the i965 shader backend at: >> https://bugs.freedesktop.org/show_bug.cgi?id=92760 >> >> Br. >> >> On Mon, 2016-04-04 at 20:00 +0300, Andres Gomez wrote: >> > >> > Generator for error checking on "flat" keyword. >> > >> > This generator adds, additionally, checks for variables inside >> > structs >> > and interface blocks, which weren't explicitly mentioned in the >> > GLSL >> > specs and, partially, in the GLSL ES specs. >> > >> > For a discussion about this check >> > https://lists.freedesktop.org/archives/mesa-dev/2016-March/109117.h >> > tm >> > l >> > and Khronos bug #15671. >> > >> > Also, removed 8 redundant tests replaced by the generator. >> > >> > Signed-off-by: Andres Gomez >> > --- >> > generated_tests/CMakeLists.txt | 7 + >> > .../gen_flat_interpolation_qualifier.py| 170 >> > + >> > .../gen_flat_interpolation_qualifier/compiler.mako | 98 >> > >> > .../template.frag.mako | 60 >> > .../nonflat-int-array.frag | 31 >> > .../interpolation-qualifiers/nonflat-int.frag | 26 >> > .../interpolation-qualifiers/nonflat-ivec4.frag| 26 >> > .../interpolation-qualifiers/nonflat-uint.frag | 26 >> > .../interpolation-qualifiers/nonflat-uvec4.frag| 26 >> > .../nonflat-int-array.frag | 22 --- >> > .../interpolation-qualifiers/nonflat-int.frag | 22 --- >> > .../interpolation-qualifiers/nonflat-ivec4.frag| 22 --- >> > .../interpolation-qualifiers/nonflat-uint.frag | 22 --- >> > .../interpolation-qualifiers/nonflat-uvec4.frag| 22 --- >> > .../varying-struct-nonflat-int.frag| 29 >> > .../varying-struct-nonflat-uint.frag | 29 >> > 16 files changed, 335 insertions(+), 303 deletions(-) >> > create mode 100644 >> > generated_tests/gen_flat_interpolation_qualifier.py >> > create mode 100644 >> > generated_tests/templates/gen_flat_interpolation_qualifier/compiler >> > .m >> > ako >> > create mode 100644 >> > generated_tests/templates/gen_flat_interpolation_qualifier/template >> > .f >> > rag.mako >> > delete mode 100644 tests/spec/glsl-1.30/compiler/interpolation- >> > qualifiers/nonflat-int-array.frag >> > delete mode 100644 tests/spec/glsl-1.30/compiler/interpolation- >> > qualifiers/nonflat-int.frag >> > delete mode 100644 tests/spec/glsl-1.30/compiler/interpolation- >> > qualifiers/nonflat-ivec4.frag >> > delete mode 100644 tests/spec/glsl-1.30/compiler/interpolation- >> > qualifiers/nonflat-uint.frag >> > delete mode 100644 tests/spec/glsl-1.30/compiler/interpolation- >> > qualifiers/nonflat-uvec4.frag >> > delete mode 100644 tests/spec/glsl-es-3.00/compiler/interpolation- >> > qualifiers/nonflat-int-array.frag >> > delete mode 100644 tests/spec/glsl-es-3.00/compiler/interpolation- >> > qualifiers/nonflat-int.frag >> > delete mode 100644 tests/spec/glsl-es-3.00/compiler/interpolation- >> > qualifiers/nonflat-ivec4.frag >> > delete mode 100644 tests/spec/glsl-es-3.00/compiler/interpolation- >> > qualifiers/nonflat-uint.frag >> > delete mode 100644 tests/spec/glsl-es-3.00/compiler/interpolation- >> > qualifiers/nonflat-uvec4.frag >> > delete mode 100644 tests/spec/glsl-es-3.00/compiler/interpolation- >> > qualifiers/varying-struct-nonflat-int.frag >> > delete mode 100644 tests/spec/glsl-es-3.00/compiler/interpolation- >> > qualifiers/varying-struct-nonflat-uint.frag >> > >> > diff --git a/generated_tests/CMakeLists.txt >> > b/generated_tests/CMakeLists.txt >> > index 569ca21..3c5b11a 100644 >> > --- a/generated_tests/CMakeLists.txt >> > +++ b/generated_tests/CMakeLists.txt >> > @@ -124,6 +124,12 @@ piglit_make_generated_tests( >> > templates/gen_inout_fp64/template.shader_test.mako >> > ) >> > piglit_make_generated_tests( >> > + flat_interpolation_qualifier.list >> > + gen_flat_interpolation_qualifier.py >> > + templates/gen_flat_interpolation_qualifier/compiler.mako >> > + templates/gen_flat_interpolation_qualifier/template.frag.m >> > ak >> > o >> > + ) >> > +piglit_make_generated_tests( >> >
Re: [Piglit] [PATCH 0/8] Additional tests for ARB_gpu_shader_fp64 extension
On 18 April 2016 at 23:01, Andres Gomez wrote: > Hi Dave, > > can I, then, assume a "ack-b" from you for the all the patches but the > 3/8 and 5/8? Yup, you should be able to run the SSBO one against softpipe now in master, I'm not sure why the GetUniform test would fail, probably should push it and we can investigate. Dave. ___ Piglit mailing list Piglit@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/piglit
Re: [Piglit] [PATCH v3] arb_get_program_binary/retrievable_hint: fix typo
Pinging for comment regarding patch v3. Thank you.
On Thu, Apr 14, 2016 at 4:09 PM, Haixia Shi wrote:
> The function GLboolean piglit_check_gl_error() returns GL_TRUE when there
> is
> no error, and GL_FALSE when there is an error.
>
> v3: edited according to Ian's comments.
>
> Signed-off-by: Haixia Shi
> Cc: Dylan Baker
> Cc: Ian Romanick
> ---
> tests/spec/arb_get_program_binary/retrievable_hint.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/tests/spec/arb_get_program_binary/retrievable_hint.c
> b/tests/spec/arb_get_program_binary/retrievable_hint.c
> index 8283c5b..8155ac0 100644
> --- a/tests/spec/arb_get_program_binary/retrievable_hint.c
> +++ b/tests/spec/arb_get_program_binary/retrievable_hint.c
> @@ -63,7 +63,6 @@ piglit_init(int argc, char **argv)
> GLuint prog;
> GLint value;
> bool pass = true;
> - bool got_error;
>
> piglit_require_gl_version(20);
> piglit_require_extension("GL_ARB_get_program_binary");
> @@ -79,9 +78,8 @@ piglit_init(int argc, char **argv)
> */
> value = 0xDEADBEEF;
> glGetProgramiv(prog, GL_PROGRAM_BINARY_RETRIEVABLE_HINT, &value);
> - got_error = piglit_check_gl_error(0);
>
> - if (!got_error) {
> + if (piglit_check_gl_error(GL_NO_ERROR)) {
> if (value == 0xDEADBEEF) {
> fprintf(stderr,
> "No error generated for "
> --
> 2.8.0.rc3.226.g39d4020
>
>
___
Piglit mailing list
Piglit@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/piglit
[Piglit] [PATCH] ext_image_dma_buf_import/sample_rgb: Make sure the window has alpha.
Fixes test result in non-auto-fbo mode on Intel, where you end up without an alpha channel if you forget to ask for one. --- tests/spec/ext_image_dma_buf_import/sample_rgb.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tests/spec/ext_image_dma_buf_import/sample_rgb.c b/tests/spec/ext_image_dma_buf_import/sample_rgb.c index f279730b6db9..e6df06b64354 100644 --- a/tests/spec/ext_image_dma_buf_import/sample_rgb.c +++ b/tests/spec/ext_image_dma_buf_import/sample_rgb.c @@ -35,6 +35,7 @@ PIGLIT_GL_TEST_CONFIG_BEGIN config.supports_gl_es_version = 20; + config.window_visual = PIGLIT_GL_VISUAL_RGBA; PIGLIT_GL_TEST_CONFIG_END -- 2.8.0.rc3 ___ Piglit mailing list Piglit@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/piglit
Re: [Piglit] Nearly finished: shader_runner running THOUSANDS of tests per process
Quoting Marek Olšák (2016-04-18 10:39:46) > On Mon, Apr 18, 2016 at 6:45 PM, Dylan Baker wrote: [snip] > > > > Thanks for working on this Marek, > > > > This has been discussed here several times amongst the intel group, and > > the recurring problem to solve is crashing. I don't have a strong > > opinion on python vs catching a fail in the signal handler, except that > > handling in the python might be more robust, but I'm not really familiar > > with what a C signal handler can recover from, so it may not. > > I can catch signals like exceptions and report 'crash'. Then I can > open a new process from the handler to run the remaining tests, wait > and exit. > > The signal catching won't work on Windows. > > Also, there are piglit GL framework changes that have only been tested > with Waffle and may break other backends. It wouldn't be difficult to handle in the python framework. I have some patches that are half baked to do exactly this sort of thing for piglit/deqp, it shouldn't be too hard to generalize that code and handle it that way. I think it would be better to handle it in shader_runner if we can, but as a fallback if we decide that having one solution that works everywhere is better than having one for windows and one for not-windows it can be done in python. > > > > > The one concern I have is using subtests. There are a couple of > > limitations to them, first we'll loose all of the per test stdout/stderr > > data, and that seems less than optimal. I wonder if it would be better > > to have shader runner print some sort of scissor to stdout and stderr > > when it starts a test and when it finishes one, and then report results > > as normal without the subtest. That would maintain the output of each > > test file, which seems like what we want, otherwise the output will be > > That can be done easily in C. > > > jumbled. The other problem with subtests is that the JUnit backend > > doesn't have a way to represent subtests at the moment. That would be > > problematic for both us and for VMWare. > > I can't help with anything related to python. > > The goal is to make piglit faster for general regression testing. > Other use cases can be affected negatively, but the time savings are > worth it. Well, we either need to not use subtests, or the junit subtest handling deficiency needs to be solved before landing this or its going to be a huge problem, since we rely on the CI heavily and this would hide a lot of specifics about regressions. What we'd end up with is something like 'spec/ARB_ham_sandwich: fail', which is completely insufficient, since most of piglit is shader_runner based. Personally, I think using the scissoring approach is better anyway since it also allows us to link the stdout/stderr to the specific test, and with that approach we don't need to use subtests either, the python layer can just make a test result per scissor and the changes wouldn't be user visible at all (barring any bugs). There's a few changes to the python that would need to happen to make this work, but I don't think it's going to be more than a couple of patches. > > > > > Looking at the last patch the python isn't all correct there, it will > > run in some cases and fail in others, particularly it will do something > > odd if fast skipping is enabled, but I'm not sure exactly what. I think > > it's worth measuring and seeing if the fast skipping path is even an > > optimization with your enhancements, if it's not we should just disable > > it for shader_runner or remove it entirely, it would remove a lot of > > complexity. > > If the fast skipping is the only issue, I can remove it. I'd be fine with just removing it from shader_runner for now and I could run tests to see if it's actually an improvement later, and get it working at that point if it is advantageous, and rip it out if it isn't. I could see it still being a win for some of the very old platforms we support, since they tend to have slow CPUs and limited OpenGL support. The most straightforward way to disable it would be to just remove or comment out "self.__find_requirements" in ShaderTest.__init__, I think. > > > > > I'd be more than happy to help get the python work done and running, > > since this would be really useful for us in our CI system. > > What else needs to be done in python? > > Marek I guess that depends on what approach you want to take on things. If you want to try the scissor output approach we'll need to write an extended interpret_result method for ShaderTest. I don't think it'll be that complicated since it'll just be looking for the scissor marks and the test name, and passing the rest up via super(). There's a few more changes that would be needed, but I don't think they'd be too complicated. If you want to have the crash handler/rerunner in python we'll need to implement that, that's probably a bit more complicated, but shouldn't be bad. Dylan signature.asc Description: signature _
Re: [Piglit] [PATCH] Strengthen arb_shader_image_load_store-shader-mem-barrier test
Nicolai Hähnle writes:
> From: Nicolai Hähnle
>
> By transposing the loop and the writer/reader branching, the effective level
> of parallelism in the test is increased for a typical wave-based architecture.
>
> Increasing the window size on top of that helps to reliably expose different
> implementation errors for AMD GCN.
>
> Cc: Francisco Jerez
> ---
> After trying a bunch of different things, it turns out that the combination
> of these rather small changes ends up covering all the cases.
>
Thanks! I haven't tested yet whether I can still reproduce an inversion
with the control test on Intel hardware, but the change looks good
anyway so feel free to push:
Reviewed-by: Francisco Jerez
> .../shader-mem-barrier.c | 32
> ++
> 1 file changed, 15 insertions(+), 17 deletions(-)
>
> diff --git a/tests/spec/arb_shader_image_load_store/shader-mem-barrier.c
> b/tests/spec/arb_shader_image_load_store/shader-mem-barrier.c
> index 5fdd86b..ddf5da6 100644
> --- a/tests/spec/arb_shader_image_load_store/shader-mem-barrier.c
> +++ b/tests/spec/arb_shader_image_load_store/shader-mem-barrier.c
> @@ -48,7 +48,7 @@
> #define W 256
>
> /** Window height. */
> -#define H 16
> +#define H 64
>
> /** Total number of pixels in the image. */
> #define N (W * H)
> @@ -142,15 +142,15 @@ run_test(const struct image_test_info *test,
> " int x = (idx.x % K) + (idx.x / (2 * K))
> * (2 * K);\n"
> " int i, n = 1000;\n"
> "\n"
> -" if (check) {\n"
> -" /*\n"
> -" * Consumer: Monitor the
> evolution of a pair of\n"
> -" * image locations until the test
> runs to\n"
> -" * completion or an inconsistency
> is observed.\n"
> -" */\n"
> -" for (i = 0; i < n; ++i) {\n"
> -" uint u, v;\n"
> +" for (i = 0; i < n; ++i) {\n"
> +" uint u, v;\n"
> "\n"
> +" if (check) {\n"
> +" /*\n"
> +" * Consumer: Monitor the
> evolution of a pair of\n"
> +" * image locations until
> the test runs to\n"
> +" * completion or an
> inconsistency is observed.\n"
> +" */\n"
> " v = imageLoad(img,
> ivec2(x, idx.y)).x;\n"
> " MEMORY_BARRIER();\n"
> " u = imageLoad(img, ivec2(x
> + K, idx.y)).x;\n"
> @@ -158,14 +158,12 @@ run_test(const struct image_test_info *test,
> " if (u < v)\n"
> " /* Fail. */\n"
> " return GRID_T(v <<
> 16 | u, 0, 0, 1);\n"
> -" }\n"
> -" } else {\n"
> -" /*\n"
> -" * Producer: Update the same pair
> of image locations\n"
> -" * sequentially with increasing
> values ordering the\n"
> -" * stores with a barrier.\n"
> -" */\n"
> -" for (i = 0; i < n; ++i) {\n"
> +" } else {\n"
> +" /*\n"
> +" * Producer: Update the
> same pair of image locations\n"
> +" * sequentially with
> increasing values ordering the\n"
> +" * stores with a
> barrier.\n"
> +" */\n"
> " imageStore(img, ivec2(x +
> K, idx.y), DATA_T(i));\n"
> " MEMORY_BARRIER();\n"
> " imageStore(img, ivec2(x,
> idx.y), DATA_T(i));\n"
> --
> 2.5.0
signature.asc
Description: PGP signature
___
Piglit mailing list
Piglit@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/piglit
Re: [Piglit] Nearly finished: shader_runner running THOUSANDS of tests per process
On Mon, Apr 18, 2016 at 6:45 PM, Dylan Baker wrote: > Quoting Marek Olšák (2016-04-16 15:16:34) >> Hi, >> >> This makes shader_runner very fast. The expected result is 40% >> decrease in quick.py running time, or a 12x faster piglit run if you >> run shader tests alone. >> >> Branch: >> https://cgit.freedesktop.org/~mareko/piglit/log/?h=shader-runner >> >> Changes: >> >> 1) Any number of test files can be specified as command-line >> parameters. Those command lines can be insanely long. >> >> 2) shader_runner can re-create the window & GL context if test >> requirements demand different settings when going from one test to >> another. >> >> 3) all.py generates one shader_runner instance per group of tests >> (usually one or two directories - tests and generated_tests). >> Individual tests are reported as subtests. >> >> The shader_runner part is done. The python part needs more work. >> >> >> What's missing: >> >> Handling of crashes. If shader_runner crashes: >> - The crash is not shown in piglit results (other tests with subtests >> already have the same behavior) >> - The remaining tests will not be run. >> >> The ShaderTest python class has the list of all files and should be >> able to catch a crash, check how many test results have been written, >> and restart shader_runner with the remaining tests. >> >> shader_runner prints TEST %i: and then the subtest result. %i is the >> i-th file in the list. Python can parse that and re-run shader_runner >> with the first %i tests removed. (0..%i-1 -> parse subtest results; %i >> -> crash; %i+1.. -> run again) >> >> >> I'm by no means a python expert, so here's an alternative solution (for me): >> - Catch crash signals in shader_runner. >> - In the single handler, re-run shader_runner with the remaining tests. >> >> Opinions welcome, >> >> Marek >> ___ >> Piglit mailing list >> Piglit@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/piglit > > Thanks for working on this Marek, > > This has been discussed here several times amongst the intel group, and > the recurring problem to solve is crashing. I don't have a strong > opinion on python vs catching a fail in the signal handler, except that > handling in the python might be more robust, but I'm not really familiar > with what a C signal handler can recover from, so it may not. I can catch signals like exceptions and report 'crash'. Then I can open a new process from the handler to run the remaining tests, wait and exit. The signal catching won't work on Windows. Also, there are piglit GL framework changes that have only been tested with Waffle and may break other backends. > > The one concern I have is using subtests. There are a couple of > limitations to them, first we'll loose all of the per test stdout/stderr > data, and that seems less than optimal. I wonder if it would be better > to have shader runner print some sort of scissor to stdout and stderr > when it starts a test and when it finishes one, and then report results > as normal without the subtest. That would maintain the output of each > test file, which seems like what we want, otherwise the output will be That can be done easily in C. > jumbled. The other problem with subtests is that the JUnit backend > doesn't have a way to represent subtests at the moment. That would be > problematic for both us and for VMWare. I can't help with anything related to python. The goal is to make piglit faster for general regression testing. Other use cases can be affected negatively, but the time savings are worth it. > > Looking at the last patch the python isn't all correct there, it will > run in some cases and fail in others, particularly it will do something > odd if fast skipping is enabled, but I'm not sure exactly what. I think > it's worth measuring and seeing if the fast skipping path is even an > optimization with your enhancements, if it's not we should just disable > it for shader_runner or remove it entirely, it would remove a lot of > complexity. If the fast skipping is the only issue, I can remove it. > > I'd be more than happy to help get the python work done and running, > since this would be really useful for us in our CI system. What else needs to be done in python? Marek ___ Piglit mailing list Piglit@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/piglit
Re: [Piglit] [PATCH] glx_arb_sync_control: Add timeout
On 18/04/16 13:22, Marta Lofstedt wrote: From: Marta Lofstedt The glx_arb_sync_control piglit tests should fail after a timeout expired, instead of not terminating. Signed-off-by: Marta Lofstedt All the files in tests/spec/glx_oml_sync_control/ already have this timeout ... except one, waitformsc.c. Since each test may have a different run time, I would rather want to keep it that way, to avoid surprises. How about adding the timeout in waitformsc.c:52? Other than that, the commit message is a bit strange though. How about this? -- glx_arb_sync_control/wait_for_msc: Add a missing timeout This test requests via GLX to wait until a certain vertical retrace event (based on the Media Stream Counter, AKA MSC) before being unblocked by the X-Server. Since there can be bugs in the implementation, it is possible for the test to hang. Re-enforcing this idea is that all the other glx_arb_sync_control tests already have a timeout set. This change adds a timeout to guard against this case and report a failure. ___ Piglit mailing list Piglit@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/piglit
Re: [Piglit] [PATCH] dir-locals.el: Added emacs setup based (v2)
Reviewed-by: Ilia Mirkin Seems fine to me. I assume you tested this :) On Mon, Apr 18, 2016 at 12:37 PM, Andres Gomez wrote: > Based on current conventions at .editorconfig > > v2: Changed automatic deletion of trailing white spaces in python > files upon saving for just highlighting them in any format, as > suggested by Ilia Mirkin. > > Signed-off-by: Andres Gomez > --- > .dir-locals.el | 11 +++ > 1 file changed, 11 insertions(+) > create mode 100644 .dir-locals.el > > diff --git a/.dir-locals.el b/.dir-locals.el > new file mode 100644 > index 000..3bdca17 > --- /dev/null > +++ b/.dir-locals.el > @@ -0,0 +1,11 @@ > +((nil . ((indent-tabs-mode . t) > +(tab-width . 8) > +(show-trailing-whitespace . t))) > + (prog-mode . > + ((c-file-style . "linux"))) > + (cmake-mode . > +((cmake-tab-width . 8))) > + (python-mode . > + ((indent-tabs-mode . nil) > + (tab-width . 4))) > + ) > -- > 2.8.0.rc3 > ___ Piglit mailing list Piglit@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/piglit
Re: [Piglit] Nearly finished: shader_runner running THOUSANDS of tests per process
Quoting Marek Olšák (2016-04-16 15:16:34) > Hi, > > This makes shader_runner very fast. The expected result is 40% > decrease in quick.py running time, or a 12x faster piglit run if you > run shader tests alone. > > Branch: > https://cgit.freedesktop.org/~mareko/piglit/log/?h=shader-runner > > Changes: > > 1) Any number of test files can be specified as command-line > parameters. Those command lines can be insanely long. > > 2) shader_runner can re-create the window & GL context if test > requirements demand different settings when going from one test to > another. > > 3) all.py generates one shader_runner instance per group of tests > (usually one or two directories - tests and generated_tests). > Individual tests are reported as subtests. > > The shader_runner part is done. The python part needs more work. > > > What's missing: > > Handling of crashes. If shader_runner crashes: > - The crash is not shown in piglit results (other tests with subtests > already have the same behavior) > - The remaining tests will not be run. > > The ShaderTest python class has the list of all files and should be > able to catch a crash, check how many test results have been written, > and restart shader_runner with the remaining tests. > > shader_runner prints TEST %i: and then the subtest result. %i is the > i-th file in the list. Python can parse that and re-run shader_runner > with the first %i tests removed. (0..%i-1 -> parse subtest results; %i > -> crash; %i+1.. -> run again) > > > I'm by no means a python expert, so here's an alternative solution (for me): > - Catch crash signals in shader_runner. > - In the single handler, re-run shader_runner with the remaining tests. > > Opinions welcome, > > Marek > ___ > Piglit mailing list > Piglit@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/piglit Thanks for working on this Marek, This has been discussed here several times amongst the intel group, and the recurring problem to solve is crashing. I don't have a strong opinion on python vs catching a fail in the signal handler, except that handling in the python might be more robust, but I'm not really familiar with what a C signal handler can recover from, so it may not. The one concern I have is using subtests. There are a couple of limitations to them, first we'll loose all of the per test stdout/stderr data, and that seems less than optimal. I wonder if it would be better to have shader runner print some sort of scissor to stdout and stderr when it starts a test and when it finishes one, and then report results as normal without the subtest. That would maintain the output of each test file, which seems like what we want, otherwise the output will be jumbled. The other problem with subtests is that the JUnit backend doesn't have a way to represent subtests at the moment. That would be problematic for both us and for VMWare. Looking at the last patch the python isn't all correct there, it will run in some cases and fail in others, particularly it will do something odd if fast skipping is enabled, but I'm not sure exactly what. I think it's worth measuring and seeing if the fast skipping path is even an optimization with your enhancements, if it's not we should just disable it for shader_runner or remove it entirely, it would remove a lot of complexity. I'd be more than happy to help get the python work done and running, since this would be really useful for us in our CI system. Dylan signature.asc Description: signature ___ Piglit mailing list Piglit@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/piglit
[Piglit] [PATCH] dir-locals.el: Added emacs setup based (v2)
Based on current conventions at .editorconfig v2: Changed automatic deletion of trailing white spaces in python files upon saving for just highlighting them in any format, as suggested by Ilia Mirkin. Signed-off-by: Andres Gomez --- .dir-locals.el | 11 +++ 1 file changed, 11 insertions(+) create mode 100644 .dir-locals.el diff --git a/.dir-locals.el b/.dir-locals.el new file mode 100644 index 000..3bdca17 --- /dev/null +++ b/.dir-locals.el @@ -0,0 +1,11 @@ +((nil . ((indent-tabs-mode . t) +(tab-width . 8) +(show-trailing-whitespace . t))) + (prog-mode . + ((c-file-style . "linux"))) + (cmake-mode . +((cmake-tab-width . 8))) + (python-mode . + ((indent-tabs-mode . nil) + (tab-width . 4))) + ) -- 2.8.0.rc3 ___ Piglit mailing list Piglit@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/piglit
Re: [Piglit] [PATCH] dir-locals.el: Added emacs setup based
On Mon, 2016-04-18 at 09:22 -0400, Ilia Mirkin wrote: > On Apr 13, 2016 5:52 PM, "Andres Gomez" wrote: > > + (python-mode . > > + ((indent-tabs-mode . nil) > > + (tab-width . 4) > > + (eval . (progn > > +(add-to-list 'write-file-functions > 'delete-trailing-whitespace) > > Definitely not. Showing trailing whitespace seems fine though. Fair enough. I will send a new version of the patch. Thanks! -- Br, Andres signature.asc Description: This is a digitally signed message part ___ Piglit mailing list Piglit@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/piglit
Re: [Piglit] [PATCH] dir-locals.el: Added emacs setup based
On Apr 13, 2016 5:52 PM, "Andres Gomez" wrote: > > Based on current conventions at .editorconfig > > Signed-off-by: Andres Gomez > --- > .dir-locals.el | 12 > 1 file changed, 12 insertions(+) > create mode 100644 .dir-locals.el > > diff --git a/.dir-locals.el b/.dir-locals.el > new file mode 100644 > index 000..d16914b > --- /dev/null > +++ b/.dir-locals.el > @@ -0,0 +1,12 @@ > +((nil . ((indent-tabs-mode . t) > +(tab-width . 8))) > + (prog-mode . > + ((c-file-style . "linux"))) > + (cmake-mode . > +((cmake-tab-width . 8))) > + (python-mode . > + ((indent-tabs-mode . nil) > + (tab-width . 4) > + (eval . (progn > +(add-to-list 'write-file-functions 'delete-trailing-whitespace) Definitely not. Showing trailing whitespace seems fine though. > + ) > -- > 2.8.0.rc3 > > ___ > Piglit mailing list > Piglit@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/piglit ___ Piglit mailing list Piglit@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/piglit
Re: [Piglit] [PATCH] dir-locals.el: Added emacs setup based
Hi, anyone with some emacs-fu can review this? Thanks! :) On Thu, 2016-04-14 at 00:51 +0300, Andres Gomez wrote: > Based on current conventions at .editorconfig > > Signed-off-by: Andres Gomez > --- > .dir-locals.el | 12 > 1 file changed, 12 insertions(+) > create mode 100644 .dir-locals.el > > diff --git a/.dir-locals.el b/.dir-locals.el > new file mode 100644 > index 000..d16914b > --- /dev/null > +++ b/.dir-locals.el > @@ -0,0 +1,12 @@ > +((nil . ((indent-tabs-mode . t) > + (tab-width . 8))) > + (prog-mode . > + ((c-file-style . "linux"))) > + (cmake-mode . > + ((cmake-tab-width . 8))) > + (python-mode . > + ((indent-tabs-mode . nil) > + (tab-width . 4) > + (eval . (progn > + (add-to-list 'write-file-functions 'delete- > trailing-whitespace) > + ) -- Br, Andres signature.asc Description: This is a digitally signed message part ___ Piglit mailing list Piglit@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/piglit
Re: [Piglit] [PATCH] gen_flat_interpolation_qualifier.py: Adds non-flat interpolation tests generator
Hi, this patch is still unreviewed. We'd welcome some help to get this into piglit with guarantees that the tests added are OK :) Br. On Mon, 2016-04-04 at 20:05 +0300, Andres Gomez wrote: > This patch provides additional tests for the patch under review at: > https://lists.freedesktop.org/archives/mesa-dev/2016-April/111842.htm > l > > Also, this generator provides additional tests for the > ARB_gpu_shader_fp64 extension: > https://www.opengl.org/registry/specs/ARB/gpu_shader_fp64.txt > > Which has previous patches for new tests under review at: > https://lists.freedesktop.org/archives/piglit/2016-March/019167.html > > This work is complemented with the corresponding bug to add support > for this extension into the i965 shader backend at: > https://bugs.freedesktop.org/show_bug.cgi?id=92760 > > Br. > > On Mon, 2016-04-04 at 20:00 +0300, Andres Gomez wrote: > > > > Generator for error checking on "flat" keyword. > > > > This generator adds, additionally, checks for variables inside > > structs > > and interface blocks, which weren't explicitly mentioned in the > > GLSL > > specs and, partially, in the GLSL ES specs. > > > > For a discussion about this check > > https://lists.freedesktop.org/archives/mesa-dev/2016-March/109117.h > > tm > > l > > and Khronos bug #15671. > > > > Also, removed 8 redundant tests replaced by the generator. > > > > Signed-off-by: Andres Gomez > > --- > > generated_tests/CMakeLists.txt | 7 + > > .../gen_flat_interpolation_qualifier.py| 170 > > + > > .../gen_flat_interpolation_qualifier/compiler.mako | 98 > > > > .../template.frag.mako | 60 > > .../nonflat-int-array.frag | 31 > > .../interpolation-qualifiers/nonflat-int.frag | 26 > > .../interpolation-qualifiers/nonflat-ivec4.frag| 26 > > .../interpolation-qualifiers/nonflat-uint.frag | 26 > > .../interpolation-qualifiers/nonflat-uvec4.frag| 26 > > .../nonflat-int-array.frag | 22 --- > > .../interpolation-qualifiers/nonflat-int.frag | 22 --- > > .../interpolation-qualifiers/nonflat-ivec4.frag| 22 --- > > .../interpolation-qualifiers/nonflat-uint.frag | 22 --- > > .../interpolation-qualifiers/nonflat-uvec4.frag| 22 --- > > .../varying-struct-nonflat-int.frag| 29 > > .../varying-struct-nonflat-uint.frag | 29 > > 16 files changed, 335 insertions(+), 303 deletions(-) > > create mode 100644 > > generated_tests/gen_flat_interpolation_qualifier.py > > create mode 100644 > > generated_tests/templates/gen_flat_interpolation_qualifier/compiler > > .m > > ako > > create mode 100644 > > generated_tests/templates/gen_flat_interpolation_qualifier/template > > .f > > rag.mako > > delete mode 100644 tests/spec/glsl-1.30/compiler/interpolation- > > qualifiers/nonflat-int-array.frag > > delete mode 100644 tests/spec/glsl-1.30/compiler/interpolation- > > qualifiers/nonflat-int.frag > > delete mode 100644 tests/spec/glsl-1.30/compiler/interpolation- > > qualifiers/nonflat-ivec4.frag > > delete mode 100644 tests/spec/glsl-1.30/compiler/interpolation- > > qualifiers/nonflat-uint.frag > > delete mode 100644 tests/spec/glsl-1.30/compiler/interpolation- > > qualifiers/nonflat-uvec4.frag > > delete mode 100644 tests/spec/glsl-es-3.00/compiler/interpolation- > > qualifiers/nonflat-int-array.frag > > delete mode 100644 tests/spec/glsl-es-3.00/compiler/interpolation- > > qualifiers/nonflat-int.frag > > delete mode 100644 tests/spec/glsl-es-3.00/compiler/interpolation- > > qualifiers/nonflat-ivec4.frag > > delete mode 100644 tests/spec/glsl-es-3.00/compiler/interpolation- > > qualifiers/nonflat-uint.frag > > delete mode 100644 tests/spec/glsl-es-3.00/compiler/interpolation- > > qualifiers/nonflat-uvec4.frag > > delete mode 100644 tests/spec/glsl-es-3.00/compiler/interpolation- > > qualifiers/varying-struct-nonflat-int.frag > > delete mode 100644 tests/spec/glsl-es-3.00/compiler/interpolation- > > qualifiers/varying-struct-nonflat-uint.frag > > > > diff --git a/generated_tests/CMakeLists.txt > > b/generated_tests/CMakeLists.txt > > index 569ca21..3c5b11a 100644 > > --- a/generated_tests/CMakeLists.txt > > +++ b/generated_tests/CMakeLists.txt > > @@ -124,6 +124,12 @@ piglit_make_generated_tests( > > templates/gen_inout_fp64/template.shader_test.mako > > ) > > piglit_make_generated_tests( > > + flat_interpolation_qualifier.list > > + gen_flat_interpolation_qualifier.py > > + templates/gen_flat_interpolation_qualifier/compiler.mako > > + templates/gen_flat_interpolation_qualifier/template.frag.m > > ak > > o > > + ) > > +piglit_make_generated_tests( > > shader_precision_tests.list > > gen_shader_precision_tests.py > > builtin_function.py > > @@ -181,6 +187,7 @@ add_custom_target(gen-gl-tests > > builtin_unif
Re: [Piglit] [PATCH] gen_flat_interpolation_qualifier.py: Adds non-flat interpolation tests generator
Hi Dave, can I asume an "ack-by" from you for this patch, then? On Wed, 2016-04-06 at 15:39 +0300, Andres Gomez wrote: > Dave, continuing with your request at: > https://lists.freedesktop.org/archives/piglit/2016-April/019350.html > > Tested with the needed patch at mesa-dev landed: > https://lists.freedesktop.org/archives/mesa-dev/2016-April/111842.htm > l > > Tested with llvmpipe > > > FAIL: > None. > > SKIP: > * All the GLSL 4.00 tests. They PASS if we override the version with > an env variable. > * All the GLSL ES 3.20 tests. > > PASS: > The rest of the tests > > ___ > Piglit mailing list > Piglit@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/piglit -- Br, Andres signature.asc Description: This is a digitally signed message part ___ Piglit mailing list Piglit@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/piglit
Re: [Piglit] [PATCH 0/8] Additional tests for ARB_gpu_shader_fp64 extension
Hi, we are still in need of reviews for this series. If we don't manage to get explicit reviews by the end of this week we will assume that all is OK and will proceed to land them. Br. On Tue, 2016-04-05 at 11:09 +0300, Andres Gomez wrote: > Hi, > > this series is, for the most of it, still unreviewed. > > We'd welcome some help to get this into piglit with guarantees that > the > tests added are OK :) > > Br. > > On Tue, 2016-03-15 at 17:50 +0200, Andres Gomez wrote: > > > > This series provides additional tests for the ARB_gpu_shader_fp64 > > extension: > > > > https://www.opengl.org/registry/specs/ARB/gpu_shader_fp64.txt > > > > This work is complemented with the corresponding bug to add support > > for this extension into the i965 shader backend at: > > > > https://bugs.freedesktop.org/show_bug.cgi?id=92760 > > > > There will still come more patches once we have clarified the > > expected > > behavior with certain conversions and certain uses of the "flat" > > interpolation qualifier: > > > > https://lists.freedesktop.org/archives/mesa-dev/2016-March/109117.h > > tm > > l > > https://lists.freedesktop.org/archives/mesa-dev/2016-March/110038.h > > tm > > l > > > > Cheers, > > Andres (on behalf of the team that worked on this). > > > > -- > > > > Andres Gomez (2): > > arb_gpu_shader_fp64: Adds GS preprocessor define test > > arb_gpu_shader_fp64: Adds uniform buffers VS tests > > > > Juan A. Suarez Romero (6): > > arb_gpu_shader_fp64: test glGetUniformdv interface > > arb_gpu_shader_fp64: gl_FragColor is deprecated in glsl >= 1.30 > > arb_gpu_shader_fp64: add tests for SSBO > > arb_gpu_shader_fp64: use generator to test in/out attributes > > arb_gpu_shader_fp64: add tests for UBOs > > arb_gpu_shader_fp64: add more tests for this spec > > > > generated_tests/CMakeLists.txt | 8 + > > generated_tests/gen_inout_fp64.py | 219 > > + > > .../templates/gen_inout_fp64/template.frag.mako| 15 + > > .../templates/gen_inout_fp64/template.vert.mako| 15 + > > .../gen_inout_fp64/vs-out-fs-in_template.mako | 25 +- > > tests/all.py | 13 +- > > tests/spec/arb_gpu_shader_fp64/CMakeLists.txt | 1 + > > .../execution/CMakeLists.gl.txt| 5 +- > > .../execution/double-suffix-value.shader_test | 33 ++ > > .../execution/fs-getuniformdv.c| 339 > > > > .../fs-indirect-temp-double-const-src.shader_test | 9 +- > > .../fs-indirect-temp-double-dst.shader_test| 10 +- > > .../fs-indirect-temp-double-src.shader_test| 10 +- > > .../execution/fs-isinf-dvec.shader_test| 66 > > .../execution/fs-isnan-dvec.shader_test| 73 + > > .../arb_gpu_shader_fp64/execution/getuniformdv.c | 302 - > > - > > .../execution/gs-fs-vs-double.shader_test | 12 +- > > .../execution/gs-getuniformdv.c| 355 > > + > > .../execution/gs-isinf-dvec.shader_test| 96 ++ > > .../execution/gs-isnan-dvec.shader_test| 104 ++ > > .../execution/uniform-invalid-operation.c | 128 > > .../execution/vs-constructors.shader_test | 124 +++ > > .../execution/vs-decrement-dvec.shader_test| 67 > > .../execution/vs-getuniformdv.c| 339 > > > > .../execution/vs-increment-dvec.shader_test| 67 > > .../execution/vs-isinf-dvec.shader_test| 78 + > > .../execution/vs-isnan-dvec.shader_test| 85 + > > .../execution/vs-out-fs-in-double.shader_test | 43 --- > > .../arb_gpu_shader_fp64/preprocessor/define.geom | 19 ++ > > .../preprocessor/fs-output-double.frag | 23 -- > > .../preprocessor/vs-input-double.vert | 24 -- > > .../shader_storage/CMakeLists.gl.txt | 15 + > > .../shader_storage/CMakeLists.txt | 1 + > > .../layout-std140-fp64-mixed-shader.c | 285 > > + > > .../shader_storage/layout-std140-fp64-shader.c | 232 > > ++ > > .../layout-std430-fp64-mixed-shader.c | 318 > > ++ > > .../shader_storage/layout-std430-fp64-shader.c | 266 > > +++ > > .../uniform_buffers/fs-array-copy.shader_test | 40 +++ > > .../uniform_buffers/fs-dmat4-row-major.shader_test | 33 ++ > > .../uniform_buffers/fs-dmat4.shader_test | 34 ++ > > .../fs-double-array-const-index.shader_test| 37 +++ > > .../fs-double-array-variable-index.shader_test | 45 +++ > > .../fs-double-bool-double.shader_test | 38 +++ > > ...ouble-uniform-array-direct-indirect.shader_test | 34 ++ > > .../fs-doubles-float-mixed.shader_test | 40 +++ > > .../uniform_buffers/fs-doubles.shader_test | 40
Re: [Piglit] [PATCH 0/8] Additional tests for ARB_gpu_shader_fp64 extension
Hi Dave, can I, then, assume a "ack-b" from you for the all the patches but the 3/8 and 5/8? Br. On Wed, 2016-04-06 at 15:12 +0300, Andres Gomez wrote: > On Wed, 2016-04-06 at 08:03 +1000, Dave Airlie wrote: > > > > On 5 April 2016 at 18:09, Andres Gomez wrote: > > > > > > > > > Hi, > > > > > > this series is, for the most of it, still unreviewed. > > > > > > We'd welcome some help to get this into piglit with guarantees > > > that > > > the > > > tests added are OK :) > > Do the pass against softpipe/llvmpipe? > > > > I'd ack any that do, let me know of any that don't I suppose so we > > can > > work out why. > Tested with llvmpipe > > > PASS: > [PATCH 1/8] arb_gpu_shader_fp64: Adds GS preprocessor define test > [PATCH 2/8] arb_gpu_shader_fp64: Adds uniform buffers VS tests > [PATCH 4/8] arb_gpu_shader_fp64: gl_FragColor is deprecated in glsl > >= 1.30 > [PATCH 7/8] arb_gpu_shader_fp64: add tests for UBOs > [PATCH 8/8] arb_gpu_shader_fp64: add more tests for this spec > > SKIP (GL_ARB_shader_storage_buffer_object missing): > [PATCH 5/8] arb_gpu_shader_fp64: add tests for SSBO > > SKIP (only the ones requiring GLSL 4.00, they PASS if the version is > override with env variables): > [PATCH 6/8] arb_gpu_shader_fp64: use generator to test in/out > attributes > > FAIL: > [PATCH 3/8] arb_gpu_shader_fp64: test glGetUniformdv interface > > ___ > Piglit mailing list > Piglit@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/piglit -- Andres Gomez Computer Science Engineer mailto:ago...@igalia.com http://blogs.igalia.com/agomez/category/igaliacom/ IGALIA, S.L. http://www.igalia.com signature.asc Description: This is a digitally signed message part ___ Piglit mailing list Piglit@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/piglit
[Piglit] [PATCH] glx_arb_sync_control: Add timeout
From: Marta Lofstedt
The glx_arb_sync_control piglit tests should fail after a
timeout expired, instead of not terminating.
Signed-off-by: Marta Lofstedt
---
tests/spec/glx_oml_sync_control/common.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tests/spec/glx_oml_sync_control/common.c
b/tests/spec/glx_oml_sync_control/common.c
index 6873ef1..ffd6261 100644
--- a/tests/spec/glx_oml_sync_control/common.c
+++ b/tests/spec/glx_oml_sync_control/common.c
@@ -58,6 +58,8 @@ piglit_oml_sync_control_test_run(bool fullscreen, enum
piglit_result (*draw)(Dis
Display *dpy;
GLXContext ctx;
+ piglit_set_timeout(5, PIGLIT_FAIL);
+
dpy = XOpenDisplay(NULL);
if (dpy == NULL) {
fprintf(stderr, "couldn't open display\n");
--
2.5.0
___
Piglit mailing list
Piglit@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/piglit
