All of the random values are positive. Mixing uint texture with isampler
is not allowed, and happens to cause problems for freedreno. Using uint
works.
---
tests/spec/gl-3.0/texture-integer.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/spec/gl-3.0/texture-integer.
On Sat, 21 Nov 2015 02:10:03 +0100, wrote:
From: Dylan Baker
This patch allows passing '/' separated tests into the
-t/--include-tests -x/--exclude-tests options. This becomes
particularly important to fix since the verbose logger now prints '/'
separated names, as does the console logger.
S
On Sat, 21 Nov 2015 02:10:02 +0100, wrote:
From: Dylan Baker
This stops the logger from using '@', and instead prints '/'.
cc: Glenn Kennard
Signed-off-by: Dylan Baker
---
framework/log.py | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/framework/log.py b/framework/l
On Sat, 21 Nov 2015 02:10:01 +0100, wrote:
From: Dylan Baker
This adds a function to grouptools that replaces grouptools.SEPARATOR
with '/'. This function is meant for use when printing to the console,
since most people find '/' easier to read than whatever is being used
internally to separat
From: Dylan Baker
This patch fixes the behavior of glsl_parser_test in cases other that
OpenGL and OpenGL ES are available. This means that if OpenGL ES isn't
available then OpenGL ES shaders will be passed to the regular version
of glslparsertest, which can run them with an ARB_ES_compatibility
From: Dylan Baker
There are two versions of glslparsertest, an undecorated one for desktop
OpenGL, and a '_gles2' suffixed one for OpenGL ES. Piglit should pass 3.1
and 3.2 to the '_gles2' version like it does for GLES 2 and GLES 3.0
This also extends the test generator to cover these new cases
From: Dylan Baker
This adds a new environment variable, PIGLIT_FORCE_GLSLPARSER_DESKTOP,
which forces glsl_parser_test.py to use "glslparsertest" for GLES tests
(instead of "glslparsertest_gles2").
This could be used to force testing ES__compatibility extensions
even when OpenGL ES tests are bei
From: Dylan Baker
Changes from previous version:
- rebase on master
- fix bug in v3
- small cleanups
Dylan Baker (3):
glsl_parser_test.py: Fix which versions are sent to
glslparsertest_gles2
framework/test/glsl_parser_test.py: Handle gl versions correctly
framework/test/glsl_parser_tes
From: Dylan Baker
This adds a function to grouptools that replaces grouptools.SEPARATOR
with '/'. This function is meant for use when printing to the console,
since most people find '/' easier to read than whatever is being used
internally to separate a group, and because consistance counts.
The
From: Dylan Baker
For reasons that are mostly historical at this point, piglit uses '@' as a
group separator internally. Part of the work that allowed this created a
package for dealing with groups strings (grouptools), the replaces '/'
with '@'.
Of course, '@' is much harder to read in a string
From: Dylan Baker
This patch allows passing '/' separated tests into the
-t/--include-tests -x/--exclude-tests options. This becomes
particularly important to fix since the verbose logger now prints '/'
separated names, as does the console logger.
Signed-off-by: Dylan Baker
---
framework/optio
From: Dylan Baker
This stops the logger from using '@', and instead prints '/'.
cc: Glenn Kennard
Signed-off-by: Dylan Baker
---
framework/log.py | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/framework/log.py b/framework/log.py
index c2c3677..e80f48e 100644
--- a/frame
On Fri, Nov 20, 2015 at 03:05:49PM -0800, Ian Romanick wrote:
> On 11/20/2015 02:14 PM, Dylan Baker wrote:
> > On Thu, Nov 19, 2015 at 08:00:09PM -0800, Ian Romanick wrote:
> >> From: Ian Romanick
> >>
> >> If this test has problems with odd sample counts, the test should detect
> >> that and SKIP
On Fri, Nov 20, 2015 at 03:21:23PM -0800, Ian Romanick wrote:
> On 11/20/2015 02:13 PM, Dylan Baker wrote:
> > On Thu, Nov 19, 2015 at 08:00:08PM -0800, Ian Romanick wrote:
> >> From: Ian Romanick
> >>
> >> I could not figure out how to get
> >>
> >> for sample_count in (str(x) for x in MSAA_S
On 11/20/2015 03:21 PM, Ian Romanick wrote:
> On 11/20/2015 02:13 PM, Dylan Baker wrote:
>> On Thu, Nov 19, 2015 at 08:00:08PM -0800, Ian Romanick wrote:
>>> From: Ian Romanick
>>>
>>> I could not figure out how to get
>>>
>>> for sample_count in (str(x) for x in MSAA_SAMPLE_COUNTS):
>>>
>>> t
On 11/20/2015 02:13 PM, Dylan Baker wrote:
> On Thu, Nov 19, 2015 at 08:00:08PM -0800, Ian Romanick wrote:
>> From: Ian Romanick
>>
>> I could not figure out how to get
>>
>> for sample_count in (str(x) for x in MSAA_SAMPLE_COUNTS):
>>
>> to work with the (0,) + MSAA_SAMPLE_COUNTS places.
>
>
On 11/20/2015 02:10 PM, Dylan Baker wrote:
> On Thu, Nov 19, 2015 at 08:00:07PM -0800, Ian Romanick wrote:
>> From: Ian Romanick
>>
>> Signed-off-by: Ian Romanick
>> ---
>> tests/all.py | 13 ++---
>> 1 file changed, 6 insertions(+), 7 deletions(-)
>>
>> diff --git a/tests/all.py b/tests
On 11/20/2015 02:14 PM, Dylan Baker wrote:
> On Thu, Nov 19, 2015 at 08:00:09PM -0800, Ian Romanick wrote:
>> From: Ian Romanick
>>
>> If this test has problems with odd sample counts, the test should detect
>> that and SKIP.
>
> I'm not sure I agree. I think it's pretty reasonable for all.py to
Ah, okay. Never mind then.
On Fri, Nov 20, 2015 at 05:19:45PM -0500, Ilia Mirkin wrote:
> Right... so I'm looking for concrete things I can look for in tests to
> determine whether the run_concurrent=False is set incorrectly. I know
> the *approximate* reasons, but I'd like to be certain and then
Right... so I'm looking for concrete things I can look for in tests to
determine whether the run_concurrent=False is set incorrectly. I know
the *approximate* reasons, but I'd like to be certain and then go grep
it all and remove the run_concurrent flag from 75% of those that have
it (either by upd
I don't remember. I asked Ken about it when Marek updated a huge swath
of tests to run concurrent and I swapped the default flag from
non-concurrent to concurrent, but I don't remember all of the details.
Front buffer rendering and timer query were two cases where concurrent
definitely wasn't safe
On Thu, Nov 19, 2015 at 08:00:09PM -0800, Ian Romanick wrote:
> From: Ian Romanick
>
> If this test has problems with odd sample counts, the test should detect
> that and SKIP.
I'm not sure I agree. I think it's pretty reasonable for all.py to only
pass valid inputs to a test binary.
>
> Signe
On Thu, Nov 19, 2015 at 08:00:08PM -0800, Ian Romanick wrote:
> From: Ian Romanick
>
> I could not figure out how to get
>
> for sample_count in (str(x) for x in MSAA_SAMPLE_COUNTS):
>
> to work with the (0,) + MSAA_SAMPLE_COUNTS places.
I think it actually makes sense to just convert MSAA
On Thu, Nov 19, 2015 at 08:00:07PM -0800, Ian Romanick wrote:
> From: Ian Romanick
>
> Signed-off-by: Ian Romanick
> ---
> tests/all.py | 13 ++---
> 1 file changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/tests/all.py b/tests/all.py
> index 8dd7487..578bcae 100644
> --- a/tes
And how do you tell if a test is using front buffer rendering? Is that
the only situation, or are there others?
On Fri, Nov 20, 2015 at 3:41 PM, Dylan Baker wrote:
> Any tests that use front buffer rendering cannot be run concurrently. I
> think that's some other cases.
>
> On Nov 20, 2015 12:32,
On Fri, 2015-11-20 at 08:59 +0200, Tapani Pälli wrote:
> BTW I bisected that this test has failed since AoA was enabled in Mesa
> by commit 5b75dbd, would be nice to have it passing before adding new
> subtests
Yeah I've been meaning to look into this, it was working I think but seemed to
have
Any tests that use front buffer rendering cannot be run concurrently. I
think that's some other cases.
On Nov 20, 2015 12:32, "Ilia Mirkin" wrote:
> It looks like we're up to something like 1K non-concurrent piglit
> tests... maybe more. Can someone who actually understands the issues
> explain w
It looks like we're up to something like 1K non-concurrent piglit
tests... maybe more. Can someone who actually understands the issues
explain what makes a piglit test unreliable when run concurrently with
another test? Then we can go and enable concurrency on probably 75% of
the currently-marked-n
On 11/20/2015 07:45 AM, Ilia Mirkin wrote:
> On Thu, Nov 19, 2015 at 11:00 PM, Ian Romanick wrote:
>> diff --git a/tests/spec/CMakeLists.txt b/tests/spec/CMakeLists.txt
>> index a5c42dc..408649d 100644
>> --- a/tests/spec/CMakeLists.txt
>> +++ b/tests/spec/CMakeLists.txt
>> @@ -76,6 +76,7 @@ add_s
We test linking of programs that copy a large array, and a large
structure.
Signed-off-by: Jordan Justen
---
tests/spec/arb_shader_storage_buffer_object/execution/large-field-copy.shader_test
seemed a bit too complex, when the more immediate issue was the linking
failure. Maybe it would be go
On Thu, Nov 19, 2015 at 11:00 PM, Ian Romanick wrote:
> diff --git a/tests/spec/CMakeLists.txt b/tests/spec/CMakeLists.txt
> index a5c42dc..408649d 100644
> --- a/tests/spec/CMakeLists.txt
> +++ b/tests/spec/CMakeLists.txt
> @@ -76,6 +76,7 @@ add_subdirectory (ext_framebuffer_multisample)
> add_s
Reviewed-by: Iago Toral Quiroga
If the only point of this test is to reproduce the link failure, notice
that it is sufficient to do this:
[fragment shader]
#version 330
#extension GL_ARB_shader_storage_buffer_object: require
#define SIZE 16
layout (std430) buffer SSBO {
mat4 m1[SIZE];
32 matches
Mail list logo
