[Piglit] [PATCH 1/1] gles2: new test to render triangle and validate via glReadPixels

[Eric Anholt]

Tom Gall <tom.gall at linaro.org> writes:

> new gles2 test which very simply renders a triangle and validates
>   it was rendered correctly via reading from glReadPixels
>   and checking the returned buffer for values of alpha, red,
>   green and blue.

Is a triangle really important for this test?  This really looks like it
ought to be a shader_runner test if you're trying to test minimal "can I
render a primitive and read back?" and not the specific pixels lit by
the triangle.  But if you have shader_runner support then there are a
ton of tests that are equivalent to rasterizing pixels with a constant
color and reading back.

Also, I'm not going to enumerate them, but there are a bunch of
whitespace issues (spaces instead of tabs, trailing whitespace), and //
comments instead of piglit style of /* */

> Signed-off-by: Tom Gall <tom.gall at linaro.org>
> ---
>  tests/all_es2.tests                           |    5 +
>  tests/gles2/CMakeLists.gles2.txt              |    5 +
>  tests/gles2/data/shaders/simple_triangle.frag |    6 +
>  tests/gles2/data/shaders/simple_triangle.vert |    5 +

I recommend just folding trivial shaders like these into the .c file.
Or using shader_runner so you don't have to have a .c file at all.

> +gles2_tests = Group()
> +spec['gles2_tests'] = gles2_tests
> +gles2_tests['gles2_simple_triangle'] =  PlainExecTest(['gles2_simple_triangle', '-auto'])
> +gles2_tests['gles2_simple_triangle'].runConcurrent = False

PlainExecTest implies !runConcurrent, but why would you want
non-concurrent anyway?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/piglit/attachments/20121126/f7d2260a/attachment.pgp>