Re: [Piglit] [PATCH] arb_texture_buffer_object/indexed: test indexed samplers with tbo
Reviewed-by: Fabian Bieler
On 2018-01-04 04:46, srol...@vmware.com wrote:
> From: Roland Scheidegger
>
> This just verifies that sampler arrays indexed with a uniform work with TBOs.
> (Broken on r600 evergreen pending a fix.)
>
> v2: fix compiler warnings, directly assign index uniform in shader
> ---
> tests/all.py | 1 +
> .../arb_texture_buffer_object/CMakeLists.gl.txt| 1 +
> tests/spec/arb_texture_buffer_object/indexed.c | 110
> +
> 3 files changed, 112 insertions(+)
> create mode 100644 tests/spec/arb_texture_buffer_object/indexed.c
>
> diff --git a/tests/all.py b/tests/all.py
> index ac1947ca4..0a1a65ef4 100644
> --- a/tests/all.py
> +++ b/tests/all.py
> @@ -2483,6 +2483,7 @@ with profile.test_list.group_manager(
> g(['arb_texture_buffer_object-subdata-sync'], 'subdata-sync')
> g(['arb_texture_buffer_object-unused-name'], 'unused-name')
> g(['arb_texture_buffer_object-render-no-bo'], 'render-no-bo')
> +g(['arb_texture_buffer_object-indexed'], 'indexed')
>
> with profile.test_list.group_manager(
> PiglitGLTest,
> diff --git a/tests/spec/arb_texture_buffer_object/CMakeLists.gl.txt
> b/tests/spec/arb_texture_buffer_object/CMakeLists.gl.txt
> index ec0d0b463..959ca0c2f 100644
> --- a/tests/spec/arb_texture_buffer_object/CMakeLists.gl.txt
> +++ b/tests/spec/arb_texture_buffer_object/CMakeLists.gl.txt
> @@ -24,3 +24,4 @@ piglit_add_executable
> (arb_texture_buffer_object-render-no-bo render-no-bo.c)
> piglit_add_executable (arb_texture_buffer_object-subdata-sync subdata-sync.c)
> piglit_add_executable (arb_texture_buffer_object-unused-name unused-name.c)
> piglit_add_executable (arb_texture_buffer_object-fetch-outside-bounds
> fetch-outside-bounds.c)
> +piglit_add_executable (arb_texture_buffer_object-indexed indexed.c)
> diff --git a/tests/spec/arb_texture_buffer_object/indexed.c
> b/tests/spec/arb_texture_buffer_object/indexed.c
> new file mode 100644
> index 0..e62c246f3
> --- /dev/null
> +++ b/tests/spec/arb_texture_buffer_object/indexed.c
> @@ -0,0 +1,110 @@
> +/* Copyright © 2015 Ilia Mirkin
> + * Copyright © 2017 VMware, Inc.
> + *
> + * 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 indexed.c
> + *
> + * Tests that we can sample texture buffers with sampler indexing.
> + */
> +
> +#include "piglit-util-gl.h"
> +
> +PIGLIT_GL_TEST_CONFIG_BEGIN
> + config.supports_gl_core_version = 32;
> + config.window_visual = PIGLIT_GL_VISUAL_DOUBLE | PIGLIT_GL_VISUAL_RGBA;
> + config.khr_no_error_support = PIGLIT_NO_ERRORS;
> +PIGLIT_GL_TEST_CONFIG_END
> +
> +enum piglit_result
> +piglit_display(void)
> +{
> + static const float green[4] = {0, 1, 0, 0};
> + bool pass;
> +
> + glViewport(0, 0, piglit_width, piglit_height);
> + glClearColor(0.2, 0.2, 0.2, 0.2);
> + glClear(GL_COLOR_BUFFER_BIT);
> +
> + piglit_draw_rect(-1, -1, 2, 2);
> +
> + pass = piglit_probe_rect_rgba(0, 0, piglit_width, piglit_height, green);
> +
> + piglit_present_results();
> +
> + return pass ? PIGLIT_PASS : PIGLIT_FAIL;
> +}
> +
> +void
> +piglit_init(int argc, char **argv)
> +{
> + static const char *vs_source =
> + "#version 150\n"
> + "in vec4 piglit_vertex;\n"
> + "void main()\n"
> + "{\n"
> + " gl_Position = piglit_vertex;\n"
> + "}\n";
> +
> + static const char *fs_source =
> + "#version 150\n"
> + "#extension GL_ARB_gpu_shader5: require\n"
> + "uniform samplerBuffer s[2];\n"
> + "uniform int offset;\n"
> + "uniform int index = 1;\n"
> + "void main()\n"
> + "{\n"
> + " gl_FragColor = texelFetch(s[index], offset);\n"
> + "}\n";
> +
> + GLuint tex[2],
Re: [Piglit] [PATCH] teximage-colors: accept -127 instead of -128 for exact snorm up/download
Am 11.01.2018 um 23:08 schrieb Brian Paul:
> On 01/11/2018 02:45 PM, Roland Scheidegger wrote:
>> ping?
>>
>> Am 08.01.2018 um 01:20 schrieb srol...@vmware.com:
>>> From: Roland Scheidegger
>>>
>>> -128 and -127 represent exactly the same value (-1.0) for snorm8 values,
>>> as do -32768/-32767 for snorm16. Therefore it seems quite reasonable
>>> that an
>>> implementation would return the other representation (in particular
>>> r600 will
>>> do this with a blit, and the snorm->float->snorm conversion implied
>>> by this
>>> will never return the -128/-32768 values).
>>> ---
>>> tests/texturing/teximage-colors.c | 39
>>> +++
>>> 1 file changed, 35 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/tests/texturing/teximage-colors.c
>>> b/tests/texturing/teximage-colors.c
>>> index de2024644..61a3c5d15 100644
>>> --- a/tests/texturing/teximage-colors.c
>>> +++ b/tests/texturing/teximage-colors.c
>>> @@ -833,10 +833,41 @@ test_exact()
>>> observed);
>>> pass &= piglit_check_gl_error(GL_NO_ERROR);
>>> - for (i = 0; i < texture_size; ++i)
>>> - pass &= memcmp(&data[i * texture_size * Bpp],
>>> - &observed[i * tex_width * Bpp],
>>> - texture_size * Bpp) == 0;
>>> + /*
>>> + * For snorm formats, -127/-128 and -32767/-32768 represent the
>>> exact
>>> + * same value (-1.0). Therefore, it is quite reasonable to expect
>>> + * an implementation could return the other representation.
>>> + * (We'll assume it will happen only one way the other way seems
>>> rather
>>> + * unlikely.)
>>> + */
>>> + if (format->data_type == GL_BYTE) {
>>> + int j;
>>> + for (j = 0; j < texture_size; ++j) {
>>> + for (i = 0; i < tex_width * channels; i++) {
>>> + if (!(data[i] == observed[i] ||
>>> + (data[i] == 128 && observed[i] == 129))) {
>
> This might be more obvious if you you'd cast the data and observed
> pointers to GLbyte types (like you do for GLshort below) and then test
> for the -127 and -128 values directly.
Ah yes, I was lazy with the typing there (I didn't actually fix the
GLshort case initially, because I needed to try like 20 seed values to
finally hit a failure)...
> In any case, Reviewed-by: Brian Paul
Thanks!
Roland
>
>
>>> + pass = GL_FALSE;
>>> + }
>>> + }
>>> + }
>>> + } else if (format->data_type == GL_SHORT) {
>>> + int j;
>>> + for (j = 0; j < texture_size; ++j) {
>>> + for (i = 0; i < tex_width * channels; i++) {
>>> + GLshort datas = ((GLshort *)data)[i];
>>> + GLshort obss = ((GLshort *)observed)[i];
>>> + if (!(datas == obss ||
>>> + (datas == -32768 && obss == -32767))) {
>>> + pass = GL_FALSE;
>>> + }
>>> + }
>>> + }
>>> + } else {
>>> + for (i = 0; i < texture_size; ++i)
>>> + pass &= memcmp(&data[i * texture_size * Bpp],
>>> + &observed[i * tex_width * Bpp],
>>> + texture_size * Bpp) == 0; >> + }
>>> free(observed);
>>> free(tmp_float);
>>>
>>
>> ___
>> 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] teximage-colors: accept -127 instead of -128 for exact snorm up/download
On 01/11/2018 02:45 PM, Roland Scheidegger wrote:
ping?
Am 08.01.2018 um 01:20 schrieb srol...@vmware.com:
From: Roland Scheidegger
-128 and -127 represent exactly the same value (-1.0) for snorm8 values,
as do -32768/-32767 for snorm16. Therefore it seems quite reasonable that an
implementation would return the other representation (in particular r600 will
do this with a blit, and the snorm->float->snorm conversion implied by this
will never return the -128/-32768 values).
---
tests/texturing/teximage-colors.c | 39 +++
1 file changed, 35 insertions(+), 4 deletions(-)
diff --git a/tests/texturing/teximage-colors.c
b/tests/texturing/teximage-colors.c
index de2024644..61a3c5d15 100644
--- a/tests/texturing/teximage-colors.c
+++ b/tests/texturing/teximage-colors.c
@@ -833,10 +833,41 @@ test_exact()
observed);
pass &= piglit_check_gl_error(GL_NO_ERROR);
- for (i = 0; i < texture_size; ++i)
- pass &= memcmp(&data[i * texture_size * Bpp],
- &observed[i * tex_width * Bpp],
- texture_size * Bpp) == 0;
+ /*
+* For snorm formats, -127/-128 and -32767/-32768 represent the exact
+* same value (-1.0). Therefore, it is quite reasonable to expect
+* an implementation could return the other representation.
+* (We'll assume it will happen only one way the other way seems rather
+* unlikely.)
+*/
+ if (format->data_type == GL_BYTE) {
+ int j;
+ for (j = 0; j < texture_size; ++j) {
+ for (i = 0; i < tex_width * channels; i++) {
+ if (!(data[i] == observed[i] ||
+ (data[i] == 128 && observed[i] == 129))) {
This might be more obvious if you you'd cast the data and observed
pointers to GLbyte types (like you do for GLshort below) and then test
for the -127 and -128 values directly.
In any case, Reviewed-by: Brian Paul
+ pass = GL_FALSE;
+ }
+ }
+ }
+ } else if (format->data_type == GL_SHORT) {
+ int j;
+ for (j = 0; j < texture_size; ++j) {
+ for (i = 0; i < tex_width * channels; i++) {
+ GLshort datas = ((GLshort *)data)[i];
+ GLshort obss = ((GLshort *)observed)[i];
+ if (!(datas == obss ||
+ (datas == -32768 && obss == -32767))) {
+ pass = GL_FALSE;
+ }
+ }
+ }
+ } else {
+ for (i = 0; i < texture_size; ++i)
+ pass &= memcmp(&data[i * texture_size * Bpp],
+ &observed[i * tex_width * Bpp],
+ texture_size * Bpp) == 0; >> +}
free(observed);
free(tmp_float);
___
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
[Piglit] [Bug 99293] piglit test for render reordering
https://bugs.freedesktop.org/show_bug.cgi?id=99293 --- Comment #3 from Fabian Bieler --- Created attachment 136668 --> https://bugs.freedesktop.org/attachment.cgi?id=136668&action=edit gles2: Add fbo ping-pong test. There are fbo-flushing and fbo-flushing2 in Piglit which draw to an FBO and then sample from the fbo to piglit_winsys_fbo. But they only use a single draw call for the entire FBO and don't do back and forth rendering between two FBOs. Based on your description I came up with the attached test. Maybe I'll write an ssbo and an image store test, too. No promises, though. -- You are receiving this mail because: You are the QA Contact for the bug.___ Piglit mailing list Piglit@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/piglit
Re: [Piglit] [PATCH] teximage-colors: accept -127 instead of -128 for exact snorm up/download
ping?
Am 08.01.2018 um 01:20 schrieb srol...@vmware.com:
> From: Roland Scheidegger
>
> -128 and -127 represent exactly the same value (-1.0) for snorm8 values,
> as do -32768/-32767 for snorm16. Therefore it seems quite reasonable that an
> implementation would return the other representation (in particular r600 will
> do this with a blit, and the snorm->float->snorm conversion implied by this
> will never return the -128/-32768 values).
> ---
> tests/texturing/teximage-colors.c | 39
> +++
> 1 file changed, 35 insertions(+), 4 deletions(-)
>
> diff --git a/tests/texturing/teximage-colors.c
> b/tests/texturing/teximage-colors.c
> index de2024644..61a3c5d15 100644
> --- a/tests/texturing/teximage-colors.c
> +++ b/tests/texturing/teximage-colors.c
> @@ -833,10 +833,41 @@ test_exact()
> observed);
> pass &= piglit_check_gl_error(GL_NO_ERROR);
>
> - for (i = 0; i < texture_size; ++i)
> - pass &= memcmp(&data[i * texture_size * Bpp],
> -&observed[i * tex_width * Bpp],
> -texture_size * Bpp) == 0;
> + /*
> + * For snorm formats, -127/-128 and -32767/-32768 represent the exact
> + * same value (-1.0). Therefore, it is quite reasonable to expect
> + * an implementation could return the other representation.
> + * (We'll assume it will happen only one way the other way seems rather
> + * unlikely.)
> + */
> + if (format->data_type == GL_BYTE) {
> + int j;
> + for (j = 0; j < texture_size; ++j) {
> + for (i = 0; i < tex_width * channels; i++) {
> + if (!(data[i] == observed[i] ||
> + (data[i] == 128 && observed[i] == 129))) {
> + pass = GL_FALSE;
> + }
> + }
> + }
> + } else if (format->data_type == GL_SHORT) {
> + int j;
> + for (j = 0; j < texture_size; ++j) {
> + for (i = 0; i < tex_width * channels; i++) {
> + GLshort datas = ((GLshort *)data)[i];
> + GLshort obss = ((GLshort *)observed)[i];
> + if (!(datas == obss ||
> + (datas == -32768 && obss == -32767))) {
> + pass = GL_FALSE;
> + }
> + }
> + }
> + } else {
> + for (i = 0; i < texture_size; ++i)
> + pass &= memcmp(&data[i * texture_size * Bpp],
> + &observed[i * tex_width * Bpp],
> + texture_size * Bpp) == 0;
> + }
>
> free(observed);
> free(tmp_float);
>
___
Piglit mailing list
Piglit@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/piglit
Re: [Piglit] [PATCH] gl 1.0: Stress test GL_LINE_LOOP.
Reviewed-by: Brian Paul On 01/11/2018 12:54 PM, Fabian Bieler wrote: Draw circles with long line loops and check the result. In particular, check that the last line segment is drawn and that no additional segments in between arbitrary vertices are drawn. V2: Increase vertex size and count to exhaust Mesa's vbo buffer and Gallium's auxiliary draw buffer. Add command line argument to set vertex count. --- I fixed some long line loop issues in Mesa/gallium a few years ago. I _think_ 0x2000 (8192) is enough, but you might want to check more (Note that Mesa llvmpipe reports GL_MAX_ELEMENTS_VERTICES = 3000). Also, I see you're stepping the vertex count by <<=2 in the test loop below. That _might_ skip some magic vertex counts which tickle bugs. Off-hand I don't have a good suggesting for how to be thorough about this without being really slow. I toyed and dismissed the idea of additional tests with random vertex counts as I don't think the occasional failure of this test would be investigated. I did add a command line option to manually set the vertex count for easier debugging, though. There's (at least) two places where the vertex buffer limits (the VBO module and draw/vbuf code) will trigger splitting/continuing long line loops. This test should try to exceed both those buffer limits. You might set some breakpoints in the Mesa/gallium code to see if they're getting hit. Mesa's VBO buffer is 1MB. Gallium's auxiliary draw code buffer size varies from driver to driver, but it's never bigger than 1MB. I increased the vertex size and count so that the vertex array is at least 3MB in size. tests/all.py| 1 + tests/spec/gl-1.0/CMakeLists.gl.txt | 1 + tests/spec/gl-1.0/long-line-loop.c | 199 3 files changed, 201 insertions(+) create mode 100644 tests/spec/gl-1.0/long-line-loop.c diff --git a/tests/all.py b/tests/all.py index 32ab2b610..6abcb3aa8 100644 --- a/tests/all.py +++ b/tests/all.py @@ -727,6 +727,7 @@ with profile.test_list.group_manager( g(['gl-1.0-edgeflag-quads']) g(['gl-1.0-empty-begin-end-clause']) g(['gl-1.0-long-dlist']) +g(['gl-1.0-long-line-loop']) g(['gl-1.0-readpixels-oob']) g(['gl-1.0-rendermode-feedback']) g(['gl-1.0-front-invalidate-back'], run_concurrent=False) diff --git a/tests/spec/gl-1.0/CMakeLists.gl.txt b/tests/spec/gl-1.0/CMakeLists.gl.txt index 355df7472..2df3a8cf4 100644 --- a/tests/spec/gl-1.0/CMakeLists.gl.txt +++ b/tests/spec/gl-1.0/CMakeLists.gl.txt @@ -26,6 +26,7 @@ piglit_add_executable (gl-1.0-fpexceptions fpexceptions.c) piglit_add_executable (gl-1.0-front-invalidate-back front-invalidate-back.c) piglit_add_executable (gl-1.0-logicop logicop.c) piglit_add_executable (gl-1.0-long-dlist long-dlist.c) +piglit_add_executable (gl-1.0-long-line-loop long-line-loop.c) piglit_add_executable (gl-1.0-ortho-pos orthpos.c) piglit_add_executable (gl-1.0-no-op-paths no-op-paths.c) piglit_add_executable (gl-1.0-polygon-line-aa polygon-line-aa.c) diff --git a/tests/spec/gl-1.0/long-line-loop.c b/tests/spec/gl-1.0/long-line-loop.c new file mode 100644 index 0..02b756caa --- /dev/null +++ b/tests/spec/gl-1.0/long-line-loop.c @@ -0,0 +1,199 @@ +/* + * Copyright © 2017 Fabian Bieler + * + * 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 long-line-loop.c + * Draw cricles with line loops and a line strips blended on top of each + * other and check that the renderings match. + */ + +#include "piglit-util-gl.h" + +PIGLIT_GL_TEST_CONFIG_BEGIN + + config.supports_gl_compat_version = 10; + config.window_width = 1024; + config.window_height = 1024; + config.window_visual = PIGLIT_GL_VISUAL_RGB; + config.khr_no_error_support = PIGLIT_NO_ERRORS; + +PIGLIT_GL_TEST_CONFIG_END + +static int max_vertices; +static int num_vertice
[Piglit] [PATCH] gl 1.0: Stress test GL_LINE_LOOP.
Draw circles with long line loops and check the result. In particular, check that the last line segment is drawn and that no additional segments in between arbitrary vertices are drawn. V2: Increase vertex size and count to exhaust Mesa's vbo buffer and Gallium's auxiliary draw buffer. Add command line argument to set vertex count. --- > I fixed some long line loop issues in Mesa/gallium a few years ago. I > _think_ 0x2000 (8192) is enough, but you might want to check more (Note that > Mesa llvmpipe reports GL_MAX_ELEMENTS_VERTICES = 3000). > Also, I see you're stepping the vertex count by <<=2 in the test loop below. > That _might_ skip some magic vertex counts which tickle bugs. Off-hand I > don't have a good suggesting for how to be thorough about this without being > really slow. I toyed and dismissed the idea of additional tests with random vertex counts as I don't think the occasional failure of this test would be investigated. I did add a command line option to manually set the vertex count for easier debugging, though. > There's (at least) two places where the vertex buffer limits (the VBO module > and draw/vbuf code) will trigger splitting/continuing long line loops. This > test should try to exceed both those buffer limits. You might set some > breakpoints in the Mesa/gallium code to see if they're getting hit. Mesa's VBO buffer is 1MB. Gallium's auxiliary draw code buffer size varies from driver to driver, but it's never bigger than 1MB. I increased the vertex size and count so that the vertex array is at least 3MB in size. tests/all.py| 1 + tests/spec/gl-1.0/CMakeLists.gl.txt | 1 + tests/spec/gl-1.0/long-line-loop.c | 199 3 files changed, 201 insertions(+) create mode 100644 tests/spec/gl-1.0/long-line-loop.c diff --git a/tests/all.py b/tests/all.py index 32ab2b610..6abcb3aa8 100644 --- a/tests/all.py +++ b/tests/all.py @@ -727,6 +727,7 @@ with profile.test_list.group_manager( g(['gl-1.0-edgeflag-quads']) g(['gl-1.0-empty-begin-end-clause']) g(['gl-1.0-long-dlist']) +g(['gl-1.0-long-line-loop']) g(['gl-1.0-readpixels-oob']) g(['gl-1.0-rendermode-feedback']) g(['gl-1.0-front-invalidate-back'], run_concurrent=False) diff --git a/tests/spec/gl-1.0/CMakeLists.gl.txt b/tests/spec/gl-1.0/CMakeLists.gl.txt index 355df7472..2df3a8cf4 100644 --- a/tests/spec/gl-1.0/CMakeLists.gl.txt +++ b/tests/spec/gl-1.0/CMakeLists.gl.txt @@ -26,6 +26,7 @@ piglit_add_executable (gl-1.0-fpexceptions fpexceptions.c) piglit_add_executable (gl-1.0-front-invalidate-back front-invalidate-back.c) piglit_add_executable (gl-1.0-logicop logicop.c) piglit_add_executable (gl-1.0-long-dlist long-dlist.c) +piglit_add_executable (gl-1.0-long-line-loop long-line-loop.c) piglit_add_executable (gl-1.0-ortho-pos orthpos.c) piglit_add_executable (gl-1.0-no-op-paths no-op-paths.c) piglit_add_executable (gl-1.0-polygon-line-aa polygon-line-aa.c) diff --git a/tests/spec/gl-1.0/long-line-loop.c b/tests/spec/gl-1.0/long-line-loop.c new file mode 100644 index 0..02b756caa --- /dev/null +++ b/tests/spec/gl-1.0/long-line-loop.c @@ -0,0 +1,199 @@ +/* + * Copyright © 2017 Fabian Bieler + * + * 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 long-line-loop.c + * Draw cricles with line loops and a line strips blended on top of each + * other and check that the renderings match. + */ + +#include "piglit-util-gl.h" + +PIGLIT_GL_TEST_CONFIG_BEGIN + + config.supports_gl_compat_version = 10; + config.window_width = 1024; + config.window_height = 1024; + config.window_visual = PIGLIT_GL_VISUAL_RGB; + config.khr_no_error_support = PIGLIT_NO_ERRORS; + +PIGLIT_GL_TEST_CONFIG_END + +static int max_vertices; +static int num_vertices; +static int probe_location[2]; +static const float radius = 0.9; + +static
Re: [Piglit] [PATCH] travis: add docker based cmake build job
With below comments, Review-by: Juan A. Suarez
On Fri, 2017-12-29 at 04:04 +0200, Andres Gomez wrote:
> Until now we were only running the python unit tests.
>
> It seems desirable to also check that the CMake based build compiles
> successfully. We do that now using docker.
>
> The docker build can be tweaked with some environment variables and,
> also, be stored in the docker hub if desired. Check the changes for
> extra details regarding these variables.
>
> Cc: Dylan Baker
> Cc: Juan A. Suarez Romero
> Signed-off-by: Andres Gomez
> ---
> We choose to do this task using docker instead of directly in the
> Travis CI VM because of various reasons.
>
> First, the Travis env is configured for a python execution. Adding the
> bits for a C compilation will mean some extra complication which is
> not that big by just delegating this to a docker service.
>
> Second, docker brings some additional benefits. For example, using
> docker makes the CI indepent from the CI infrastructure; docker images
> are storable and downloadable so we can get the same building setting
> that was used in a specific moment; etc.
>
> .travis.yml | 47 --
> docker/Rockerfile.piglit | 88
>
> 2 files changed, 132 insertions(+), 3 deletions(-)
> create mode 100644 docker/Rockerfile.piglit
>
> diff --git a/.travis.yml b/.travis.yml
> index b47829ff9..32a6b53e5 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -1,5 +1,16 @@
> +sudo: false
> +os: linux
> language: python
> -cache: pip
> +cache:
> + - ccache
> + - pip
> +services:
> + - docker
> +
> +env:
> + global:
> +- BUILD=pytest
> +
> matrix:
>include:
> - python: 2.7
> @@ -12,7 +23,37 @@ matrix:
>env: TOX_ENV="py35-{generator,noaccel,accel-nix,streams}"
> - python: 3.6
>env: TOX_ENV="py36-{generator,noaccel,accel-nix,streams}"
> +- env: BUILD=cmake
> +
> install:
> -pip install tox
> + - |
> +if [[ $BUILD == pytest ]]; then
> + pip install tox
> +else
> + wget
> https://github.com/grammarly/rocker/releases/download/1.3.1/rocker-1.3.1-linux_amd64.tar.gz
> + tar xvf rocker-1.3.1-linux_amd64.tar.gz
> + rm rocker-1.3.1-linux_amd64.tar.gz
> +fi
> +
> +before_script:
> + - |
> +if [[ $BUILD != pytest ]]; then
> + mkdir -p -m777 ~/.ccache
> +fi
> +
> script:
> -- tox -e $TOX_ENV
> + - |
> +if [[ $BUILD == pytest ]]; then
> + tox -e $TOX_ENV
> +else
> + ./rocker build -f docker/Rockerfile.piglit .
> +fi
> +
> +after_success:
> + - |
> +if [[ $BUILD != pytest ]]; then
> + if [[ -n $DOCKER_USERNAME && $TRAVIS_BRANCH == master ]]; then
> +docker login -u "$DOCKER_USERNAME" -p "$DOCKER_PASSWORD"
> +docker push ${DOCKER_IMAGE:-freedesktop/mesa}:piglit
> + fi
> +fi
> diff --git a/docker/Rockerfile.piglit b/docker/Rockerfile.piglit
> new file mode 100644
> index 0..989b7d919
> --- /dev/null
> +++ b/docker/Rockerfile.piglit
> @@ -0,0 +1,88 @@
> +#
> +# This builds and installs Piglit.
> +#
> +# ~~~
> +# rocker build -f Rockerfile.piglit [--attach] \
> +#[--var TAG=piglit] # piglit-17.0, piglit-13.0, ... \
> +#[--var RELEASE=xenial] # master, pre-release-17.0,
> pre-release-13.0, ...
> +# ~~~
> +#
> +# Environment variables that are used in the build:
> +# - BASE_DOCKER_IMAGE: name of the image in which this will be based
> (default: ubuntu)
> +# - DOCKER_IMAGE: name of the final image to be tagged (default:
> freedesktop/mesa)
> +# - BASE_PIGLIT_REPO: custom piglit repository to use with a specific
> release
> +# - MAKEFLAGS: flags to pass to make (e.g., "-j8")
> +# - CCACHE_DIR: ccache directory (default: ~/.ccache)
> +#
> +# To run
> +#
> +# ~~~
> +# mkdir -p -m777 ~/my_results_dir
> +# docker run --privileged --rm -t -v ~/my_results_dir:/results:Z \
> +# -v /tmp/.X11-unix:/tmp/.X11-unix freedesktop/mesa:piglit
> +# ~~~
> +#
> +
> +{{ $base_image := (or .Env.BASE_DOCKER_IMAGE "ubuntu") }}
> +{{ $image := (or .Env.BASE_DOCKER_IMAGE "freedesktop/mesa") }}
> +{{ $release := (or .RELEASE "xenial") }}
> +{{ $ccachedir := (or .Env.CCACHE_DIR "~/.ccache") }}
> +
> +FROM {{ $base_image }}:{{ $release }}
> +
> +LABEL maintainer "Andres Gomez "
> +
> +USER root
> +
> +ENV LC_ALL=C.UTF-8
> +
> +RUN apt-get update \
> + && apt-get -y --no-install-recommends install sudo gcc g++ ccache \
> +git pkg-config bash-completion cmake\
> +libz-dev libpng-dev libgl-dev libegl1-mesa-dev libwaffle-dev\
> +python3-setuptools python3-pip \
> + && rm -fr /var/lib/apt/lists/*
> +
> +RUN pip3 install numpy six mako
> +
> +RUN getent passwd local > /dev/null || adduser --gecos "" local && passwd -d
> local && adduser local sudo
> +
> +USER local
> +
