Re: [Piglit] [PATCH] Add shader_runner GLSL version specification via requirements section.

[Paul Berry]

On 27 August 2012 17:23, Stuart Abercrombie  wrote:

> Thanks for the detailed response.  I had various other changes bundled
> up with this but I thought it best to get some feedback before going
> too far.
>
> 1. I got ESSL from gles2_shader_runner.c.  I wanted to use a more
> obvious string but the way the parser is written made it more
> convenient to have a string the same length as GLSL.  It's easy enough
> to change with a minor cost in source ugliness.
>
> 2. I envisaged all the shader_test files specifying both GLSL
> versions.  Since all .shader_test files would need modification in the
> end I was thinking they could be updated to conform to new
> expectations.
>
> I guess there's some value in handling missing GLSL version
> specifiers.


The main value I see is to cover the case where there is no GLSL ES version
that makes sense for the test (e.g. clipping tests) or where there is no
desktop GLSL version that makes sense (probably rarer, but I bet we'll come
up with a few).


>  I assume then that we would also have a GL ES version
> requirement to go with the GL version requirement, operating in a
> similar way.
>

Ah, good point, yes.


>
> 3. I'm very glad to hear about the multiple file loading being
> unnecessary.  That does indeed make things much simpler.
>
> 4. I thought a lot about trying to use the existing GLSL requirement
> instead of introducing a new one.  As you say, the problem lies with
> general comparison operators.  I verified that operators other than >=
> weren't being used, so I was tempted to do exactly what you suggest
> and reject them.
>
> In the end I was worried about a) effectively introducing a more
> irregular syntax and b) foreclosing the possibility of testing GLSL
> features with #version strings decoupled from the GLSL requirement
> (not that I can think of a particular scenario for this).  I'm fine
> with a) if you are.  As for b), it seems it would be covered by your
> suggestion of making #version strings in the source optional.
>
> Minor problems:
>
> 1. Thanks.  I was planning to revisit this.
>
> 2. I hadn't noticed the Open GL ES 3 #version syntax change -- thanks.
>
> The multi-patch plan sounds good.  I'll pursue that.
>
> Stuart
>
> On Mon, Aug 27, 2012 at 1:46 PM, Paul Berry 
> wrote:
> > On 24 August 2012 16:09, Stuart Abercrombie 
> > wrote:
> >>
> >> The idea is to allow different GLSL versions for GL vs GL ES.  There
> >> shouldn't be a functional change until shader scripts are altered too.
> >>
> >> Added ES GLSL version string parsing.
> >
> >
> > I like where you're going with this.  A few comments before we get into
> the
> > patch itself:
> >
> > 1. "ESSL" is a nonstandard name for the GLES shading language.  Let's use
> > "GLSL ES".
> >
> > 2. How to we want the two different builds of shader_runner to handle the
> > following four possible requirements sections?
> >
> > (a)
> > GLSL >= 130
> >
> > (b)
> > GLSL ES >= 300
> >
> > (c)
> > GLSL >= 130
> > GLSL ES >= 300
> >
> > (d) (no versions specified)
> >
> > My expectation would be:
> > - test (a) should only be run when desktop GLSL version 130 or above is
> > available, and should be skipped when testing GLES.
> > - test (b) should only be run when GLSL ES version 300 or above is
> > available, and should be skipped when testing desktop GL*.
> > - test (c) should be run with GLSL version 130 when testing desktop GL,
> and
> > GLSL ES version 300 when testing GLES*.
> > - test (d) should produce an error message regardless of whether desktop
> GL
> > or GLSL ES is being tested.
> >
> > *At a later date we will probably also to be able to run the GLSL ES
> tests
> > under desktop GL using the ARB_ES{2,3}_compatibility extension, but I'm
> > happy not to worry about that yet :)
> >
> > As written, the patch will run test (a) when desktop GLSL version 130 or
> > above is available, as expected, but it will aso run test (a) when
> testing
> > GLES, which is unlikely to be the test author's intention.  Vice versa
> for
> > test (b).  Test (c) will work as I would expect.  Test (d) will be run on
> > all implementations, which I again think is unlikely to be the author's
> > intention (because in this case the author probably just forgot to
> include
> > the version annotation).
> >
> > 3. A lot of the complexity of the patch has to do with the fact that the
> > version string is inserted into element 0 of the shader_strings array, so
> > the code has to treat it specially, and the special treatment that was
> > previously given to shader_strings[0] has to be shifted over to
> > shader_strings[1].  I don't think we actually have to introduce this
> kind of
> > complication, because it turns out that the only reason that
> shader_strings
> > is an array in the first place is to support a feature that is never used
> > (the ability to specify multiple files in a single "[vertex shader
> file]" or
> > "[fragment shader file]" and have them concatenated).  I've talked to Ian
> > about this and

[Piglit] [PATCH] egl-util: Add call to piglit_dispatch_default_init()

[Matt Turner]

Fixes egl-nok-swap-region and makes egl-nok-texture-from-pixmap not
crash (but still fails).
---
 tests/egl/egl-util.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/tests/egl/egl-util.c b/tests/egl/egl-util.c
index 440e720..20cd699 100644
--- a/tests/egl/egl-util.c
+++ b/tests/egl/egl-util.c
@@ -222,6 +222,8 @@ egl_util_run(const struct egl_test *test, int argc, char 
*argv[])
piglit_report_result(PIGLIT_FAIL);
}
 
+   piglit_dispatch_default_init();
+
result = event_loop(&state, test);
 
eglTerminate(state.egl_dpy);
-- 
1.7.8.6

___
Piglit mailing list
Piglit@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/piglit

[Piglit] [PATCH] egl_khr_create_context: Allow forward-compatible contexts to be rejected

[Matt Turner]

This reworks the test to test whether
1) forward-compatible contexts can be created, or
2) the correct error is generated when they can't.

Previously the test did only the first and would fail if
forward-compatible contexts couldn't be created.
---
 .../valid-flag-forward-compatible-gl.c |   15 ---
 1 files changed, 12 insertions(+), 3 deletions(-)

diff --git 
a/tests/egl/spec/egl_khr_create_context/valid-flag-forward-compatible-gl.c 
b/tests/egl/spec/egl_khr_create_context/valid-flag-forward-compatible-gl.c
index 1bca548..4b6d6ba 100644
--- a/tests/egl/spec/egl_khr_create_context/valid-flag-forward-compatible-gl.c
+++ b/tests/egl/spec/egl_khr_create_context/valid-flag-forward-compatible-gl.c
@@ -20,6 +20,7 @@
  * IN THE SOFTWARE.
  */
 #include "piglit-util-gl-common.h"
+#include "piglit-util-egl.h"
 #include "common.h"
 
 int gl_version;
@@ -47,11 +48,19 @@ static bool try_flag(int flag)
gl_version = piglit_get_gl_version();
}
eglDestroyContext(egl_dpy, ctx);
-   return true;
+   } else {
+   fprintf(stderr, "Failed to create context with flag %d\n", 
flag);
+
+   /* The EGL_KHR_create_context spec says:
+*
+* "* If an attribute name or attribute value in 
 is not
+*recognized (including unrecognized bits in bitmask 
attributes),
+*then an EGL_BAD_ATTRIBUTE error is generated."
+*/
+   piglit_expect_egl_error(EGL_BAD_ATTRIBUTE, PIGLIT_FAIL);
}
 
-   fprintf(stderr, "Failed to create context with flag %d\n", flag);
-   return false;
+   return true;
 }
 
 int main(int argc, char **argv)
-- 
1.7.8.6

___
Piglit mailing list
Piglit@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/piglit

Re: [Piglit] [PATCH] Add shader_runner GLSL version specification via requirements section.

[Paul Berry]

On 24 August 2012 16:09, Stuart Abercrombie wrote:

> The idea is to allow different GLSL versions for GL vs GL ES.  There
> shouldn't be a functional change until shader scripts are altered too.
>
> Added ES GLSL version string parsing.
>

I like where you're going with this.  A few comments before we get into the
patch itself:

1. "ESSL" is a nonstandard name for the GLES shading language.  Let's use
"GLSL ES".

2. How to we want the two different builds of shader_runner to handle the
following four possible requirements sections?

(a)
GLSL >= 130

(b)
GLSL ES >= 300

(c)
GLSL >= 130
GLSL ES >= 300

(d) (no versions specified)

My expectation would be:
- test (a) should only be run when desktop GLSL version 130 or above is
available, and should be skipped when testing GLES.
- test (b) should only be run when GLSL ES version 300 or above is
available, and should be skipped when testing desktop GL*.
- test (c) should be run with GLSL version 130 when testing desktop GL, and
GLSL ES version 300 when testing GLES*.
- test (d) should produce an error message regardless of whether desktop GL
or GLSL ES is being tested.

*At a later date we will probably also to be able to run the GLSL ES tests
under desktop GL using the ARB_ES{2,3}_compatibility extension, but I'm
happy not to worry about that yet :)

As written, the patch will run test (a) when desktop GLSL version 130 or
above is available, as expected, but it will aso run test (a) when testing
GLES, which is unlikely to be the test author's intention.  Vice versa for
test (b).  Test (c) will work as I would expect.  Test (d) will be run on
all implementations, which I again think is unlikely to be the author's
intention (because in this case the author probably just forgot to include
the version annotation).

3. A lot of the complexity of the patch has to do with the fact that the
version string is inserted into element 0 of the shader_strings array, so
the code has to treat it specially, and the special treatment that was
previously given to shader_strings[0] has to be shifted over to
shader_strings[1].  I don't think we actually have to introduce this kind
of complication, because it turns out that the only reason that
shader_strings is an array in the first place is to support a feature that
is never used (the ability to specify multiple files in a single "[vertex
shader file]" or "[fragment shader file]" and have them concatenated).
I've talked to Ian about this and we both agree that this feature isn't
necessary.

4. It seems inconvenient for every test to have to specify both "GLSL >=
xxx" and "GLSL_#version xxx" in the requirements section.  My
recommendation would be to compute the version string based on the "GLSL >=
xxx" line, and add logic that suppresses autogeneration of a "#version"
line if a "#version" line is already present.  Note that if we do this we
have to decide how to handle requirements of the form "GLSL > xxx", "GLSL <
xxx" and "GLSL != xxx".  I think for now we could just reject those
constructs (they aren't used anyhow), and if later they turn out to be
needed we can figure out what to do when we get to that.

(Note: eventually Chad and I would like shader_runner to be able to run a
"GLSL >= 1.10" test on *all* GLSL versions instead of just one, but I think
we can leave that for a later task).

So I would recommend breaking this into 5 patches:

1. Get rid of the ability to specify multiple files in a single "[vertex
shader file]" or "[fragment shader file]", and replace the shader_strings
array with a single shader_string.
2. Make shader_runner able to generate a "#version" line (if none is
already present).
3. If there are any tests that don't have a version requirement line, add a
"GLSL >= 1.10" requirement (though I don't think there are any).
4. Make shader_runner produce an error if there is no version requirement
line.
5. Make shader_runner support "GLSL ES >= xxx" version requirements.

A few more specific comments follow.


> ---
>  tests/shaders/shader_runner.c |   85
> +---
>  1 files changed, 61 insertions(+), 24 deletions(-)
>
> diff --git a/tests/shaders/shader_runner.c b/tests/shaders/shader_runner.c
> index aa60a62..b9d506a 100644
> --- a/tests/shaders/shader_runner.c
> +++ b/tests/shaders/shader_runner.c
> @@ -48,6 +48,7 @@ extern float piglit_tolerance[4];
>
>  static float gl_version = 0.0;
>  static float glsl_version = 0.0;
> +static float glsl_pound_version = 0.0;
>  static int gl_max_fragment_uniform_components;
>  static int gl_max_vertex_uniform_components;
>
> @@ -69,6 +70,7 @@ GLuint *uniform_block_bos;
>   * Some test script sections, such as "[vertex shader file]", can supply
> shader
>   * source code from multiple disk files.  This array stores those strings.
>   */
> +char shader_ver_string[100];
>  char *shader_strings[256];
>  GLsizei shader_string_sizes[256];
>  unsigned num_shader_strings = 0;
> @@ -129,6 +131,16 @@ compile_glsl(GLenum target, bool release_tex

Re: [Piglit] [PATCH 4/6] Get rid of reshape funcs

[Chad Versace]

On 08/26/2012 12:43 PM, Paul Berry wrote:
> On 25 August 2012 01:12, Chris Forbes  > wrote:
> 
> Converts most of the custom reshape funcs to set the projection
> in either piglit_init or piglit_display, depending on whether
> it depends on the size.
> 
> Signed-off-by: Chris Forbes mailto:chr...@ijw.co.nz>>
> ---
>  tests/bugs/tri-tex-crash.c| 21 ++---
>  tests/general/linestipple.c   | 13 +
>  tests/general/occlusion_query.c   | 15 +--
>  tests/general/point-line-no-cull.c| 15 ++-
>  tests/general/sync_api.c  | 14 +-
>  tests/general/texgen.c| 17 +
>  tests/general/varray-disabled.c   | 16 ++--
>  tests/shaders/fp-fog.c| 21 ++---
>  tests/shaders/fp-incomplete-tex.c | 18 +-
>  tests/shaders/fp-kil.c| 20 ++--
>  tests/shaders/fp-lit-mask.c   | 17 +
>  tests/shaders/fp-lit-src-equals-dst.c | 17 +
>  tests/shaders/vpfp-generic.cpp| 17 +
>  tests/texturing/crossbar.c| 21 +
>  tests/texturing/getteximage-formats.c | 24 +++-
>  tests/texturing/getteximage-simple.c  | 23 ---
>  tests/texturing/tex3d-maxsize.c   | 12 ++--
>  tests/texturing/tex3d-npot.c  | 13 ++---
>  tests/texturing/tex3d.c   | 13 ++---
>  tests/texturing/texdepth.c| 25 ++---
>  tests/texturing/texrect-many.c| 17 +
>  tests/texturing/texredefine.c | 13 ++---
>  22 files changed, 41 insertions(+), 341 deletions(-)
> 
> 
> (snip)
>  
> 
> 
> diff --git a/tests/shaders/fp-fog.c b/tests/shaders/fp-fog.c
> index 2351544..e977a74 100644
> --- a/tests/shaders/fp-fog.c
> +++ b/tests/shaders/fp-fog.c
> @@ -60,6 +60,8 @@ piglit_display(void)
> int pass = 1;
> unsigned i;
> 
> +   piglit_ortho_projection(2.0, 2.0, GL_FALSE);
> +
> 
> 
> This will set up a projection with near=-1 and far=1, but the code you're
> deleting below uses near=-2 and far=6.  I assume you've verified that this
> change is inconsequential?  If so, it would be nice to have a short 
> explanation
> in the commit message as to why it's inconsequential.  A similar comment 
> applies
> to fp-incomplete-tex.c, fp-kil.c, and getteximage-simple.c.

Even if Chris has verified that changing znear and zfar is inconsequential, I
would prefer if this patch did not change their values. The patch's commit
message claims to replace glutReshape with piglit_*_projection, and the patch
should restrict itself to exactly that; it should not additionally change test
parameters.

In each of fp-incomplete-tex.c, fp-kil.c, and getteximage-simple.c, I think the
correct thing to do is to use `piglit_gen_orthoprojection(..., near=-2, far=6)`
rather than piglit_ortho_projection().
___
Piglit mailing list
Piglit@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/piglit

Re: [Piglit] [PATCH] texturing: add full "round trip" test of array depth textures.

[Ian Romanick]

On 08/23/2012 05:00 PM, Paul Berry wrote:

This test provokes a bug in Mesa as of 8/23/12 (commit 1cb07bd): when
fast depth clears are performed on multiple layers of a multilayer
depth texture (such as a 2D array or a cubemap texture), the
implementation doesn't properly track the need for depth resolves,
resulting in incorrect data when the texture is later used for
texturing.  See https://bugs.freedesktop.org/show_bug.cgi?id=50270.

Although the bug was initially discovered using cubemap textures, this
test provokes it using a 2D array texture, so that we don't have to
reason about the coordinate transformations involved in cube map
texture lookup.


Sorry for the lag...

Reviewed-by: Ian Romanick 


---
  tests/all.tests |1 +
  tests/texturing/CMakeLists.gl.txt   |1 +
  tests/texturing/array-depth-roundtrip.c |  203 +++
  3 files changed, 205 insertions(+), 0 deletions(-)
  create mode 100644 tests/texturing/array-depth-roundtrip.c

diff --git a/tests/all.tests b/tests/all.tests
index eb32225..c6c12ae 100644
--- a/tests/all.tests
+++ b/tests/all.tests
@@ -700,6 +700,7 @@ create_context_es2_profile['invalid OpenGL ES version'] = 
PlainExecTest(['glx-cr

  texturing = Group()
  add_concurrent_test(texturing, '1-1-linear-texture')
+add_plain_test(texturing, 'array-depth-roundtrip')
  add_plain_test(texturing, 'array-texture')
  add_plain_test(texturing, 'copytexsubimage')
  add_plain_test(texturing, 'copyteximage-border')
diff --git a/tests/texturing/CMakeLists.gl.txt 
b/tests/texturing/CMakeLists.gl.txt
index e161ece..ca30e4e 100644
--- a/tests/texturing/CMakeLists.gl.txt
+++ b/tests/texturing/CMakeLists.gl.txt
@@ -18,6 +18,7 @@ if(NOT USE_WAFFLE)
  endif(NOT USE_WAFFLE)

  piglit_add_executable (1-1-linear-texture 1-1-linear-texture.c)
+piglit_add_executable (array-depth-roundtrip array-depth-roundtrip.c)
  piglit_add_executable (array-texture array-texture.c)
  piglit_add_executable (compressedteximage compressedteximage.c)
  piglit_add_executable (copytexsubimage copytexsubimage.c)
diff --git a/tests/texturing/array-depth-roundtrip.c 
b/tests/texturing/array-depth-roundtrip.c
new file mode 100644
index 000..3eb71f3
--- /dev/null
+++ b/tests/texturing/array-depth-roundtrip.c
@@ -0,0 +1,203 @@
+/*
+ * Copyright © 2012 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+/** \file array-depth-roundtrip.c
+ *
+ * Test that an array texture containing depth data works properly
+ * when making a full "roundtrip" through both the GPU's rendering
+ * pipeline and texturing operations.
+ *
+ * The test performs the following steps:
+ *
+ * - Create an array texture containing depth data.
+ *
+ * - Bind each slice of the array texture to a framebuffer, clear it,
+ *   and render a quad to it.  A different depth value is used for
+ *   each slice of the array.
+ *
+ * - Use a shader to read from each slice of the array texture and
+ *   render to the window system framebuffer.
+ *
+ * - Verify that correct data was rendered to the window system
+ *   framebuffer.
+ */
+
+#include "piglit-util-gl-common.h"
+
+
+#define TEX_WIDTH 56
+#define TEX_HEIGHT 56
+#define NUM_TILES_ACROSS 4
+#define NUM_TILES_DOWN 4
+#define TEX_DEPTH (NUM_TILES_ACROSS * NUM_TILES_DOWN)
+
+
+PIGLIT_GL_TEST_MAIN(
+TEX_WIDTH * NUM_TILES_ACROSS,
+TEX_HEIGHT * NUM_TILES_DOWN,
+GLUT_DOUBLE | GLUT_RGB)
+
+
+GLuint tex;
+GLuint fb;
+GLuint prog;
+GLint samp_loc;
+GLint proj_loc;
+GLint tex_depth_loc;
+
+
+const char *vs_text = \
+   "#version 130\n"
+   "uniform mat4 proj;\n"
+   "uniform float tex_depth;\n"
+   "out vec3 tex_coord;\n"
+   "void main()\n"
+   "{\n"
+   "  gl_Position = proj * gl_Vertex;\n"
+   "  tex_coord = vec3(gl_Vertex.xy, tex_depth);\n"
+   "}\n";
+
+
+const char *fs_text = \
+   "#version 130\n"
+   "uniform sampler2DAr

Re: [Piglit] [PATCH] texturing: add full "round trip" test of array depth textures.

[Chad Versace]

On 08/23/2012 05:00 PM, Paul Berry wrote:
> This test provokes a bug in Mesa as of 8/23/12 (commit 1cb07bd): when
> fast depth clears are performed on multiple layers of a multilayer
> depth texture (such as a 2D array or a cubemap texture), the
> implementation doesn't properly track the need for depth resolves,
> resulting in incorrect data when the texture is later used for
> texturing.  See https://bugs.freedesktop.org/show_bug.cgi?id=50270.
> 
> Although the bug was initially discovered using cubemap textures, this
> test provokes it using a 2D array texture, so that we don't have to
> reason about the coordinate transformations involved in cube map
> texture lookup.
> ---
>  tests/all.tests |1 +
>  tests/texturing/CMakeLists.gl.txt   |1 +
>  tests/texturing/array-depth-roundtrip.c |  203 
> +++
>  3 files changed, 205 insertions(+), 0 deletions(-)
>  create mode 100644 tests/texturing/array-depth-roundtrip.c

Reviewed-by: Chad Versace 
___
Piglit mailing list
Piglit@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/piglit

Re: [Piglit] [PATCH 6/6] Convert some raw glReadPixels to use piglit probes

[Brian Paul]

On Mon, Aug 27, 2012 at 12:26 PM, Matt Turner  wrote:
> On Sun, Aug 26, 2012 at 12:55 PM, Paul Berry  wrote:
>> Minor nit-pick:  Our usual convention is to make "pass" a bool, and to write
>> this as "pass = piglit_probe_pixel_rgba(...) && pass", just so that it's
>> clear that there aren't any bitwise shenanigans going on.  Note that it
>> would probably make sense to also change the return type of DoTest(), and
>> the type of "pass" in piglit_display(), to bool as well.  I won't be a
>> stickler about it though.
>
> As it turns out, we've got a good mixture of 'pass = ... && pass',
> 'pass = pass && ...", and as I learned today 'pass &= ...'. 445, 351,
> and 281 instances respectively. Ugh.

I think this depends on the nature of what's being tested.  In some
cases a failure may be severe enough that it doesn't make sense to
continue testing subsequent cases.  Other times we want to keep going.
 That said, there's probably lots of places where we're doing the
wrong thing.

-Brian
___
Piglit mailing list
Piglit@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/piglit

Re: [Piglit] [PATCH 6/6] Convert some raw glReadPixels to use piglit probes

[Matt Turner]

On Sun, Aug 26, 2012 at 12:55 PM, Paul Berry  wrote:
> Minor nit-pick:  Our usual convention is to make "pass" a bool, and to write
> this as "pass = piglit_probe_pixel_rgba(...) && pass", just so that it's
> clear that there aren't any bitwise shenanigans going on.  Note that it
> would probably make sense to also change the return type of DoTest(), and
> the type of "pass" in piglit_display(), to bool as well.  I won't be a
> stickler about it though.

As it turns out, we've got a good mixture of 'pass = ... && pass',
'pass = pass && ...", and as I learned today 'pass &= ...'. 445, 351,
and 281 instances respectively. Ugh.
___
Piglit mailing list
Piglit@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/piglit