Re: [Piglit] [ANNOUNCE] python 3 is here... and python 2 is staying

2016-02-09 Thread Dylan Baker 
Quoting Ilia Mirkin (2016-02-09 11:35:14)
> On Tue, Feb 9, 2016 at 2:14 PM, Dylan Baker  wrote:
> > Quoting Matt Turner (2016-02-09 10:03:59)
> >> On Tue, Feb 9, 2016 at 10:02 AM, Ilia Mirkin  wrote:
> >> > On Tue, Feb 9, 2016 at 12:55 PM, Dylan Baker  
> >> > wrote:
> >> >> Quoting Matt Turner (2016-02-08 21:06:58)
> >> >>> On Mon, Feb 8, 2016 at 3:12 PM, Dylan Baker  
> >> >>> wrote:
> >> >>> > I just pushed patches to hybridize the framework to use either python
> >> >>> > 3.3+ or 2.7.
> >> >>> >
> >> >>> > Everything should keep working as normal. Unless you have python 3.x,
> >> >>> > then you'll need to rerun CMake to pick up the changes.
> >> >>>
> >> >>> There's still a handful of *.py files with #!/usr/bin/env python2:
> >> >>>
> >> >>> generated_tests/random_ubo-arb_uniform_buffer_object.py:#!/usr/bin/env 
> >> >>> python2
> >> >>> generated_tests/random_ubo.py:#!/usr/bin/env python2
> >> >>> generated_tests/random_ubo_trim.py:#!/usr/bin/env python2
> >> >>> piglit-print-commands.py:#!/usr/bin/env python2
> >> >>> piglit-resume.py:#!/usr/bin/env python2
> >> >>> piglit-run.py:#!/usr/bin/env python2
> >> >>> piglit-summary-html.py:#!/usr/bin/env python2
> >> >>> piglit-summary.py:#!/usr/bin/env python2
> >> >>> self-tests/test-installed-piglit-script-imports-correct-framework-module:#!/usr/bin/env
> >> >>> python2
> >> >>
> >> >>
> >> >> I thought I'd mentioned that in the commit, but apparently I did only in
> >> >> the cover letter.
> >> >>
> >> >> The random_ubo_stuff is not plugged into anything at the moment, and I
> >> >> have a WIP branch for those, but getting the same output from python 2
> >> >> and python 3 for generators without numpy is tricky.
> >> >>
> >> >> The piglit-* command were left intentionally. They're legacy interfaces
> >> >> and we don't add new ones when adding new functions to the 'piglit'
> >> >> command (piglit summary aggregate, for example). Personally, I'd rather
> >> >> get rid of them (other than print-commands, which I should probably
> >> >> update).
> >> >
> >> > Really? I think it's a lot more straightforward to use them than the
> >> > "piglit" megarunner thing... not sure why that was added tbh. But
> >> > since the regular commands stayed, I didn't object at the time. Should
> >> > I have?
> >>
> >> Yeah, I've continued using the piglit-run.py/piglit-summary.py
> >> scripts. I don't know what I would gain by switching, but I would lose
> >> the ability to tab complete their names. :)
> >
> > One of these days I should really finish writing those zsh and bash
> > completions I started, and then got frustrated by how difficult it is to
> > write bash and zsh completions
> 
> FWIW my experience is that, while very cool and high "h" factor,
> bash completions greatly degrade the usability of bash. I never enable
> them on my own systems. For example it breaks completion with the tar
> command on annarchy -- I haven't figured out how to turn them off but
> every time it's a huge pain that I can't tab-complete the name of a
> tar archive because it doesn't know about .xz or something.
> 
>   -ilia

Well, annarchy is running debian stale... 

fwiw, they're sourced out of
/usr/share/bash_completions/bash_completion, though I'm sure they're
included in /etc/profile so they may be somewhat hard to remove the link
on a machine you don't administer.

Anecdotally, I find the opposite, not having completions is maddening.
so, to each his own I guess.

Dylan


signature.asc
Description: signature
___
Piglit mailing list
Piglit@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/piglit

Re: [Piglit] [ANNOUNCE] python 3 is here... and python 2 is staying

2016-02-09 Thread Brian Paul 

On 02/09/2016 01:33 PM, Dylan Baker wrote:

Quoting Brian Paul (2016-02-09 11:10:06)

On 02/09/2016 11:03 AM, Matt Turner wrote:

On Tue, Feb 9, 2016 at 10:02 AM, Ilia Mirkin  wrote:

On Tue, Feb 9, 2016 at 12:55 PM, Dylan Baker  wrote:

Quoting Matt Turner (2016-02-08 21:06:58)

On Mon, Feb 8, 2016 at 3:12 PM, Dylan Baker  wrote:

I just pushed patches to hybridize the framework to use either python
3.3+ or 2.7.

Everything should keep working as normal. Unless you have python 3.x,
then you'll need to rerun CMake to pick up the changes.


There's still a handful of *.py files with #!/usr/bin/env python2:

generated_tests/random_ubo-arb_uniform_buffer_object.py:#!/usr/bin/env python2
generated_tests/random_ubo.py:#!/usr/bin/env python2
generated_tests/random_ubo_trim.py:#!/usr/bin/env python2
piglit-print-commands.py:#!/usr/bin/env python2
piglit-resume.py:#!/usr/bin/env python2
piglit-run.py:#!/usr/bin/env python2
piglit-summary-html.py:#!/usr/bin/env python2
piglit-summary.py:#!/usr/bin/env python2
self-tests/test-installed-piglit-script-imports-correct-framework-module:#!/usr/bin/env
python2



I thought I'd mentioned that in the commit, but apparently I did only in
the cover letter.

The random_ubo_stuff is not plugged into anything at the moment, and I
have a WIP branch for those, but getting the same output from python 2
and python 3 for generators without numpy is tricky.

The piglit-* command were left intentionally. They're legacy interfaces
and we don't add new ones when adding new functions to the 'piglit'
command (piglit summary aggregate, for example). Personally, I'd rather
get rid of them (other than print-commands, which I should probably
update).


Really? I think it's a lot more straightforward to use them than the
"piglit" megarunner thing... not sure why that was added tbh. But
since the regular commands stayed, I didn't object at the time. Should
I have?


Yeah, I've continued using the piglit-run.py/piglit-summary.py
scripts. I don't know what I would gain by switching, but I would lose
the ability to tab complete their names. :)


I never use the 'piglit' command either.  But I just tried it now and it
crashed:

$ ./piglit
Traceback (most recent call last):
File "./piglit", line 107, in 
  import framework.programs.run as run
File "/home/brian/projects/piglit/framework/programs/run.py", line
34, in 
  from framework import core, backends, exceptions, options
File "/home/brian/projects/piglit/framework/core.py", line 35, in

  from framework import exceptions
File "/home/brian/projects/piglit/framework/exceptions.py", line 57,
in 
  @six.python_2_unicode_compatible
AttributeError: 'module' object has no attribute
'python_2_unicode_compatible'

Dylan?

-Brian

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


Interesting. That looks like a six version issue. What version of six do
you have? If it's a problem we can replace or open-code the decorator
ourselves, it's not very complex.


$ dpkg -l python-six
Desired=Unknown/Install/Remove/Purge/Hold
| 
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend

|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---=
ii  python-six 1.5.2-1  all  Python 2 and 3 
compatibility libr



-Brian


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

Re: [Piglit] [ANNOUNCE] python 3 is here... and python 2 is staying

2016-02-09 Thread Dylan Baker 
Quoting Matt Turner (2016-02-09 10:03:59)
> On Tue, Feb 9, 2016 at 10:02 AM, Ilia Mirkin  wrote:
> > On Tue, Feb 9, 2016 at 12:55 PM, Dylan Baker  
> > wrote:
> >> Quoting Matt Turner (2016-02-08 21:06:58)
> >>> On Mon, Feb 8, 2016 at 3:12 PM, Dylan Baker  
> >>> wrote:
> >>> > I just pushed patches to hybridize the framework to use either python
> >>> > 3.3+ or 2.7.
> >>> >
> >>> > Everything should keep working as normal. Unless you have python 3.x,
> >>> > then you'll need to rerun CMake to pick up the changes.
> >>>
> >>> There's still a handful of *.py files with #!/usr/bin/env python2:
> >>>
> >>> generated_tests/random_ubo-arb_uniform_buffer_object.py:#!/usr/bin/env 
> >>> python2
> >>> generated_tests/random_ubo.py:#!/usr/bin/env python2
> >>> generated_tests/random_ubo_trim.py:#!/usr/bin/env python2
> >>> piglit-print-commands.py:#!/usr/bin/env python2
> >>> piglit-resume.py:#!/usr/bin/env python2
> >>> piglit-run.py:#!/usr/bin/env python2
> >>> piglit-summary-html.py:#!/usr/bin/env python2
> >>> piglit-summary.py:#!/usr/bin/env python2
> >>> self-tests/test-installed-piglit-script-imports-correct-framework-module:#!/usr/bin/env
> >>> python2
> >>
> >>
> >> I thought I'd mentioned that in the commit, but apparently I did only in
> >> the cover letter.
> >>
> >> The random_ubo_stuff is not plugged into anything at the moment, and I
> >> have a WIP branch for those, but getting the same output from python 2
> >> and python 3 for generators without numpy is tricky.
> >>
> >> The piglit-* command were left intentionally. They're legacy interfaces
> >> and we don't add new ones when adding new functions to the 'piglit'
> >> command (piglit summary aggregate, for example). Personally, I'd rather
> >> get rid of them (other than print-commands, which I should probably
> >> update).
> >
> > Really? I think it's a lot more straightforward to use them than the
> > "piglit" megarunner thing... not sure why that was added tbh. But
> > since the regular commands stayed, I didn't object at the time. Should
> > I have?
> 
> Yeah, I've continued using the piglit-run.py/piglit-summary.py
> scripts. I don't know what I would gain by switching, but I would lose
> the ability to tab complete their names. :)

One of these days I should really finish writing those zsh and bash
completions I started, and then got frustrated by how difficult it is to
write bash and zsh completions


signature.asc
Description: signature
___
Piglit mailing list
Piglit@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/piglit

Re: [Piglit] [PATCH] fcc: Combine fast clear with mipmap generation

2016-02-09 Thread Ben Widawsky 
On Tue, Feb 09, 2016 at 03:33:30PM +0200, Topi Pohjolainen wrote:
> This test demonstrates a bug in the Intel mesa driver meta
> operation state restore logic. Originally it was found when
> developing lossless compression support. Current piglit tests
> just didn't exercise the resolve code path that would interfere
> with any ongoing meta operation.
> 
> Signed-off-by: Topi Pohjolainen 
> CC: Ben Widawsky 
> CC: Chad Versace 
> ---
>  tests/fast_color_clear/read-after-clear.c | 19 +++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/tests/fast_color_clear/read-after-clear.c 
> b/tests/fast_color_clear/read-after-clear.c
> index 98c7169..bbd638e 100644
> --- a/tests/fast_color_clear/read-after-clear.c
> +++ b/tests/fast_color_clear/read-after-clear.c
> @@ -243,6 +243,25 @@ piglit_display(void)
>   glUniform1i(glGetUniformLocation(prog_sample, "samp"), 0);
>   glActiveTexture(GL_TEXTURE0);
>   glBindTexture(GL_TEXTURE_2D, tex1);
> +
> + /* Initial buffer for texture is not large enough to hold
> +  * subsequent mipmap levels. As a side effect mipmap
> +  * generation will trigger Intel driver to allocate new buffer
> +  * and to copy the original level zero to the newly allocated.
> +  * Moreover, this will happen inside a meta operation that aims
> +  * to generate level one using level zero as source. The copy
> +  * from original level zero to the new buffer falls to blitter
> +  * engine. This in turn requires the fast cleared content in
> +  * the original buffer to be resolved resulting into another
> +  * nested meta operation.
> +  * This will exercise a bug in Intel driver, the nested meta
> +  * operation will interfere with vertex buffer state of the
> +  * outer meta operation causing the generated level one to
> +  * hold wrong pixel values.
> +  */
> + glGenerateMipmap(GL_TEXTURE_2D);
> + glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_BASE_LEVEL, 1);
> +
>   piglit_draw_rect_tex(-1, -1, 2, 2, 0, 0, 1, 1);
>   glBindFramebuffer(GL_READ_FRAMEBUFFER, piglit_winsys_fbo);
>   pass = piglit_probe_rect_rgba(0, 0, piglit_width,

Hmm. Maybe we should make this a separate subtest? SUBTEST_SAMPLE is relatively
simple, and now it's less simple. (Just a thought).
Reviewed-by: Ben Widawsky 

-- 
Ben Widawsky, Intel Open Source Technology Center
___
Piglit mailing list
Piglit@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/piglit

Re: [Piglit] [ANNOUNCE] python 3 is here... and python 2 is staying

2016-02-09 Thread Brian Paul 

On 02/09/2016 11:03 AM, Matt Turner wrote:

On Tue, Feb 9, 2016 at 10:02 AM, Ilia Mirkin  wrote:

On Tue, Feb 9, 2016 at 12:55 PM, Dylan Baker  wrote:

Quoting Matt Turner (2016-02-08 21:06:58)

On Mon, Feb 8, 2016 at 3:12 PM, Dylan Baker  wrote:

I just pushed patches to hybridize the framework to use either python
3.3+ or 2.7.

Everything should keep working as normal. Unless you have python 3.x,
then you'll need to rerun CMake to pick up the changes.


There's still a handful of *.py files with #!/usr/bin/env python2:

generated_tests/random_ubo-arb_uniform_buffer_object.py:#!/usr/bin/env python2
generated_tests/random_ubo.py:#!/usr/bin/env python2
generated_tests/random_ubo_trim.py:#!/usr/bin/env python2
piglit-print-commands.py:#!/usr/bin/env python2
piglit-resume.py:#!/usr/bin/env python2
piglit-run.py:#!/usr/bin/env python2
piglit-summary-html.py:#!/usr/bin/env python2
piglit-summary.py:#!/usr/bin/env python2
self-tests/test-installed-piglit-script-imports-correct-framework-module:#!/usr/bin/env
python2



I thought I'd mentioned that in the commit, but apparently I did only in
the cover letter.

The random_ubo_stuff is not plugged into anything at the moment, and I
have a WIP branch for those, but getting the same output from python 2
and python 3 for generators without numpy is tricky.

The piglit-* command were left intentionally. They're legacy interfaces
and we don't add new ones when adding new functions to the 'piglit'
command (piglit summary aggregate, for example). Personally, I'd rather
get rid of them (other than print-commands, which I should probably
update).


Really? I think it's a lot more straightforward to use them than the
"piglit" megarunner thing... not sure why that was added tbh. But
since the regular commands stayed, I didn't object at the time. Should
I have?


Yeah, I've continued using the piglit-run.py/piglit-summary.py
scripts. I don't know what I would gain by switching, but I would lose
the ability to tab complete their names. :)


I never use the 'piglit' command either.  But I just tried it now and it 
crashed:


$ ./piglit
Traceback (most recent call last):
  File "./piglit", line 107, in 
import framework.programs.run as run
  File "/home/brian/projects/piglit/framework/programs/run.py", line 
34, in 

from framework import core, backends, exceptions, options
  File "/home/brian/projects/piglit/framework/core.py", line 35, in 


from framework import exceptions
  File "/home/brian/projects/piglit/framework/exceptions.py", line 57, 
in 

@six.python_2_unicode_compatible
AttributeError: 'module' object has no attribute 
'python_2_unicode_compatible'


Dylan?

-Brian

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

Re: [Piglit] [ANNOUNCE] python 3 is here... and python 2 is staying

2016-02-09 Thread Ilia Mirkin 
On Tue, Feb 9, 2016 at 2:14 PM, Dylan Baker  wrote:
> Quoting Matt Turner (2016-02-09 10:03:59)
>> On Tue, Feb 9, 2016 at 10:02 AM, Ilia Mirkin  wrote:
>> > On Tue, Feb 9, 2016 at 12:55 PM, Dylan Baker  
>> > wrote:
>> >> Quoting Matt Turner (2016-02-08 21:06:58)
>> >>> On Mon, Feb 8, 2016 at 3:12 PM, Dylan Baker  
>> >>> wrote:
>> >>> > I just pushed patches to hybridize the framework to use either python
>> >>> > 3.3+ or 2.7.
>> >>> >
>> >>> > Everything should keep working as normal. Unless you have python 3.x,
>> >>> > then you'll need to rerun CMake to pick up the changes.
>> >>>
>> >>> There's still a handful of *.py files with #!/usr/bin/env python2:
>> >>>
>> >>> generated_tests/random_ubo-arb_uniform_buffer_object.py:#!/usr/bin/env 
>> >>> python2
>> >>> generated_tests/random_ubo.py:#!/usr/bin/env python2
>> >>> generated_tests/random_ubo_trim.py:#!/usr/bin/env python2
>> >>> piglit-print-commands.py:#!/usr/bin/env python2
>> >>> piglit-resume.py:#!/usr/bin/env python2
>> >>> piglit-run.py:#!/usr/bin/env python2
>> >>> piglit-summary-html.py:#!/usr/bin/env python2
>> >>> piglit-summary.py:#!/usr/bin/env python2
>> >>> self-tests/test-installed-piglit-script-imports-correct-framework-module:#!/usr/bin/env
>> >>> python2
>> >>
>> >>
>> >> I thought I'd mentioned that in the commit, but apparently I did only in
>> >> the cover letter.
>> >>
>> >> The random_ubo_stuff is not plugged into anything at the moment, and I
>> >> have a WIP branch for those, but getting the same output from python 2
>> >> and python 3 for generators without numpy is tricky.
>> >>
>> >> The piglit-* command were left intentionally. They're legacy interfaces
>> >> and we don't add new ones when adding new functions to the 'piglit'
>> >> command (piglit summary aggregate, for example). Personally, I'd rather
>> >> get rid of them (other than print-commands, which I should probably
>> >> update).
>> >
>> > Really? I think it's a lot more straightforward to use them than the
>> > "piglit" megarunner thing... not sure why that was added tbh. But
>> > since the regular commands stayed, I didn't object at the time. Should
>> > I have?
>>
>> Yeah, I've continued using the piglit-run.py/piglit-summary.py
>> scripts. I don't know what I would gain by switching, but I would lose
>> the ability to tab complete their names. :)
>
> One of these days I should really finish writing those zsh and bash
> completions I started, and then got frustrated by how difficult it is to
> write bash and zsh completions

FWIW my experience is that, while very cool and high "h" factor,
bash completions greatly degrade the usability of bash. I never enable
them on my own systems. For example it breaks completion with the tar
command on annarchy -- I haven't figured out how to turn them off but
every time it's a huge pain that I can't tab-complete the name of a
tar archive because it doesn't know about .xz or something.

  -ilia
___
Piglit mailing list
Piglit@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/piglit

Re: [Piglit] [ANNOUNCE] python 3 is here... and python 2 is staying

2016-02-09 Thread Dylan Baker 
Quoting Brian Paul (2016-02-09 11:10:06)
> On 02/09/2016 11:03 AM, Matt Turner wrote:
> > On Tue, Feb 9, 2016 at 10:02 AM, Ilia Mirkin  wrote:
> >> On Tue, Feb 9, 2016 at 12:55 PM, Dylan Baker  
> >> wrote:
> >>> Quoting Matt Turner (2016-02-08 21:06:58)
>  On Mon, Feb 8, 2016 at 3:12 PM, Dylan Baker  
>  wrote:
> > I just pushed patches to hybridize the framework to use either python
> > 3.3+ or 2.7.
> >
> > Everything should keep working as normal. Unless you have python 3.x,
> > then you'll need to rerun CMake to pick up the changes.
> 
>  There's still a handful of *.py files with #!/usr/bin/env python2:
> 
>  generated_tests/random_ubo-arb_uniform_buffer_object.py:#!/usr/bin/env 
>  python2
>  generated_tests/random_ubo.py:#!/usr/bin/env python2
>  generated_tests/random_ubo_trim.py:#!/usr/bin/env python2
>  piglit-print-commands.py:#!/usr/bin/env python2
>  piglit-resume.py:#!/usr/bin/env python2
>  piglit-run.py:#!/usr/bin/env python2
>  piglit-summary-html.py:#!/usr/bin/env python2
>  piglit-summary.py:#!/usr/bin/env python2
>  self-tests/test-installed-piglit-script-imports-correct-framework-module:#!/usr/bin/env
>  python2
> >>>
> >>>
> >>> I thought I'd mentioned that in the commit, but apparently I did only in
> >>> the cover letter.
> >>>
> >>> The random_ubo_stuff is not plugged into anything at the moment, and I
> >>> have a WIP branch for those, but getting the same output from python 2
> >>> and python 3 for generators without numpy is tricky.
> >>>
> >>> The piglit-* command were left intentionally. They're legacy interfaces
> >>> and we don't add new ones when adding new functions to the 'piglit'
> >>> command (piglit summary aggregate, for example). Personally, I'd rather
> >>> get rid of them (other than print-commands, which I should probably
> >>> update).
> >>
> >> Really? I think it's a lot more straightforward to use them than the
> >> "piglit" megarunner thing... not sure why that was added tbh. But
> >> since the regular commands stayed, I didn't object at the time. Should
> >> I have?
> >
> > Yeah, I've continued using the piglit-run.py/piglit-summary.py
> > scripts. I don't know what I would gain by switching, but I would lose
> > the ability to tab complete their names. :)
> 
> I never use the 'piglit' command either.  But I just tried it now and it 
> crashed:
> 
> $ ./piglit
> Traceback (most recent call last):
>File "./piglit", line 107, in 
>  import framework.programs.run as run
>File "/home/brian/projects/piglit/framework/programs/run.py", line 
> 34, in 
>  from framework import core, backends, exceptions, options
>File "/home/brian/projects/piglit/framework/core.py", line 35, in 
> 
>  from framework import exceptions
>File "/home/brian/projects/piglit/framework/exceptions.py", line 57, 
> in 
>  @six.python_2_unicode_compatible
> AttributeError: 'module' object has no attribute 
> 'python_2_unicode_compatible'
> 
> Dylan?
> 
> -Brian
> 
> ___
> Piglit mailing list
> Piglit@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/piglit

Interesting. That looks like a six version issue. What version of six do
you have? If it's a problem we can replace or open-code the decorator
ourselves, it's not very complex.

Dylan


signature.asc
Description: signature
___
Piglit mailing list
Piglit@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/piglit

Re: [Piglit] [ANNOUNCE] python 3 is here... and python 2 is staying

2016-02-09 Thread Ilia Mirkin 
On Tue, Feb 9, 2016 at 3:31 PM, Dylan Baker  wrote:
> Anecdotally, I find the opposite, not having completions is maddening.
> so, to each his own I guess.

Yeah, I'm sure lots of people love them -- a ton of packages include
them, etc -- that wouldn't happen without at least *someone* liking
them :) Just pointing out that the bash completions aren't necessarily
going to be used by everyone.

  -ilia
___
Piglit mailing list
Piglit@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/piglit

[Piglit] [PATCH] fcc: Combine fast clear with mipmap generation

2016-02-09 Thread Topi Pohjolainen 
This test demonstrates a bug in the Intel mesa driver meta
operation state restore logic. Originally it was found when
developing lossless compression support. Current piglit tests
just didn't exercise the resolve code path that would interfere
with any ongoing meta operation.

Signed-off-by: Topi Pohjolainen 
CC: Ben Widawsky 
CC: Chad Versace 
---
 tests/fast_color_clear/read-after-clear.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/tests/fast_color_clear/read-after-clear.c 
b/tests/fast_color_clear/read-after-clear.c
index 98c7169..bbd638e 100644
--- a/tests/fast_color_clear/read-after-clear.c
+++ b/tests/fast_color_clear/read-after-clear.c
@@ -243,6 +243,25 @@ piglit_display(void)
glUniform1i(glGetUniformLocation(prog_sample, "samp"), 0);
glActiveTexture(GL_TEXTURE0);
glBindTexture(GL_TEXTURE_2D, tex1);
+
+   /* Initial buffer for texture is not large enough to hold
+* subsequent mipmap levels. As a side effect mipmap
+* generation will trigger Intel driver to allocate new buffer
+* and to copy the original level zero to the newly allocated.
+* Moreover, this will happen inside a meta operation that aims
+* to generate level one using level zero as source. The copy
+* from original level zero to the new buffer falls to blitter
+* engine. This in turn requires the fast cleared content in
+* the original buffer to be resolved resulting into another
+* nested meta operation.
+* This will exercise a bug in Intel driver, the nested meta
+* operation will interfere with vertex buffer state of the
+* outer meta operation causing the generated level one to
+* hold wrong pixel values.
+*/
+   glGenerateMipmap(GL_TEXTURE_2D);
+   glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_BASE_LEVEL, 1);
+
piglit_draw_rect_tex(-1, -1, 2, 2, 0, 0, 1, 1);
glBindFramebuffer(GL_READ_FRAMEBUFFER, piglit_winsys_fbo);
pass = piglit_probe_rect_rgba(0, 0, piglit_width,
-- 
2.5.0

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

[Piglit] [PATCH 2/2] Add a new GL_ARB_clip_control viewport test.

2016-02-09 Thread Brian Paul 
Verifies the screen position specified by glViewport is not effected by
the GL_CLIP_ORIGIN state.

Passes with nvidia, fails with Mesa until _mesa_get_viewport_xform()
is fixed.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93813
---
 tests/all.py  |   1 +
 tests/spec/arb_clip_control/CMakeLists.gl.txt |   1 +
 tests/spec/arb_clip_control/viewport.c| 197 ++
 3 files changed, 199 insertions(+)
 create mode 100644 tests/spec/arb_clip_control/viewport.c

diff --git a/tests/all.py b/tests/all.py
index b494ed6..4e6bb1d 100644
--- a/tests/all.py
+++ b/tests/all.py
@@ -2552,6 +2552,7 @@ with profile.group_manager(
 PiglitGLTest, grouptools.join('spec', 'arb_clip_control')) as g:
 g(['arb_clip_control-clip-control'])
 g(['arb_clip_control-depth-precision'])
+g(['arb_clip_control-viewport'])
 
 with profile.group_manager(
 PiglitGLTest, grouptools.join('spec', 'arb_color_buffer_float')) as g:
diff --git a/tests/spec/arb_clip_control/CMakeLists.gl.txt 
b/tests/spec/arb_clip_control/CMakeLists.gl.txt
index 7038366..3f55663 100644
--- a/tests/spec/arb_clip_control/CMakeLists.gl.txt
+++ b/tests/spec/arb_clip_control/CMakeLists.gl.txt
@@ -10,5 +10,6 @@ link_libraries (
 
 piglit_add_executable (arb_clip_control-clip-control clip-control.c)
 piglit_add_executable (arb_clip_control-depth-precision 
clip-control-depth-precision.c)
+piglit_add_executable (arb_clip_control-viewport viewport.c)
 
 # vim: ft=cmake:
diff --git a/tests/spec/arb_clip_control/viewport.c 
b/tests/spec/arb_clip_control/viewport.c
new file mode 100644
index 000..73a68cb
--- /dev/null
+++ b/tests/spec/arb_clip_control/viewport.c
@@ -0,0 +1,197 @@
+/*
+ * Copyright (C) 2016 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.
+ */
+
+/**
+ * Test glViewport behaviour with GL_ARB_clip_control.
+ * The position of the viewport in window coordinates should not be
+ * effected by the GL_CLIP_ORIGIN state.
+ *
+ * See https://bugs.freedesktop.org/show_bug.cgi?id=93813
+ *
+ * Brian Paul
+ * 9 Feb 2016
+ */
+
+#include "piglit-util-gl.h"
+
+
+PIGLIT_GL_TEST_CONFIG_BEGIN
+   config.supports_gl_compat_version = 20;
+   config.window_visual = PIGLIT_GL_VISUAL_DOUBLE | PIGLIT_GL_VISUAL_RGBA;
+PIGLIT_GL_TEST_CONFIG_END
+
+
+static const float red[3] = { 1, 0, 0 };
+static const float green[3] = { 0, 1, 0 };
+static const float blue[3] = { 0, 0, 1 };
+static const float white[3] = { 1, 1, 1 };
+
+
+void
+piglit_init(int argc, char **argv)
+{
+   piglit_require_extension("GL_ARB_clip_control");
+}
+
+
+/**
+ * Draw this pattern in the current viewport region, regardless of
+ * the clip control settings:
+ *
+ *   +-+-+
+ *   | | |
+ *   |   blue  |  white  |
+ *   | | |
+ *   +-+-+
+ *   | | |
+ *   |   red   |  green  |
+ *   | | |
+ *   +-+-+
+ *
+ * \param invert_y - if true, NDC_Y=-1=top, else NDC_Y=-1=bottom
+ */
+static void
+draw_test_pattern(bool invert_y)
+{
+   /* Since the modelview and projection matrices are identity matrices,
+* we're effectively drawing in Normalized Device Coordinates which
+* range from [-1,1] in X and Y.
+*/
+
+   /* lower-left quadrant = red */
+   glColor3fv(red);
+   if (invert_y)
+   glRectf(-1, 1, 0, 0);
+   else
+   glRectf(-1, -1, 0, 0);
+
+   /* lower-right quadrant = green */
+   glColor3fv(green);
+   if (invert_y)
+   glRectf(0, 1, 1, 0);
+   else
+   glRectf(0, -1, 1, 0);
+
+   /* upper-left quadrant = blue */
+   glColor3fv(blue);
+   if (invert_y)
+   glRectf(-1, 0, 0, -1);
+   else
+   glRectf(-1, 0, 0, 1);
+
+   /* upper-right quadrant = white */
+

[Piglit] [PATCH 1/2] Fix names of GL_ARB_clip_control executables

2016-02-09 Thread Brian Paul 
The modern piglit convention is "ext_foo_bar-testname".  This patch
renames the executables to:
  arb_clip_control-clip-control
  arb_clip_control-depth-precision

Arguably, the first test should be split into two separate tests that
exercise state setting/getting and rendering.
---
 tests/all.py  | 4 ++--
 tests/spec/arb_clip_control/CMakeLists.gl.txt | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/tests/all.py b/tests/all.py
index b30c577..b494ed6 100644
--- a/tests/all.py
+++ b/tests/all.py
@@ -2550,8 +2550,8 @@ with profile.group_manager(
 
 with profile.group_manager(
 PiglitGLTest, grouptools.join('spec', 'arb_clip_control')) as g:
-g(['clip-control'])
-g(['clip-control-depth-precision'])
+g(['arb_clip_control-clip-control'])
+g(['arb_clip_control-depth-precision'])
 
 with profile.group_manager(
 PiglitGLTest, grouptools.join('spec', 'arb_color_buffer_float')) as g:
diff --git a/tests/spec/arb_clip_control/CMakeLists.gl.txt 
b/tests/spec/arb_clip_control/CMakeLists.gl.txt
index 4a9f7ee..7038366 100644
--- a/tests/spec/arb_clip_control/CMakeLists.gl.txt
+++ b/tests/spec/arb_clip_control/CMakeLists.gl.txt
@@ -8,7 +8,7 @@ link_libraries (
${OPENGL_gl_LIBRARY}
 )
 
-piglit_add_executable (clip-control clip-control.c)
-piglit_add_executable (clip-control-depth-precision 
clip-control-depth-precision.c)
+piglit_add_executable (arb_clip_control-clip-control clip-control.c)
+piglit_add_executable (arb_clip_control-depth-precision 
clip-control-depth-precision.c)
 
 # vim: ft=cmake:
-- 
1.9.1

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

[Piglit] [PATCH] Add a new GL_ARB_clip_control viewport test (v2)

2016-02-09 Thread Brian Paul 
Verifies the screen position specified by glViewport is not effected by
the GL_CLIP_ORIGIN state.

Passes with nvidia, fails with Mesa until _mesa_get_viewport_xform()
is fixed.

v2: also enable back-face culling to make sure front/back-face polygon
orientation isn't upset by the clip origin.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93813
---
 tests/all.py  |   1 +
 tests/spec/arb_clip_control/CMakeLists.gl.txt |   1 +
 tests/spec/arb_clip_control/viewport.c| 202 ++
 3 files changed, 204 insertions(+)
 create mode 100644 tests/spec/arb_clip_control/viewport.c

diff --git a/tests/all.py b/tests/all.py
index b494ed6..4e6bb1d 100644
--- a/tests/all.py
+++ b/tests/all.py
@@ -2552,6 +2552,7 @@ with profile.group_manager(
 PiglitGLTest, grouptools.join('spec', 'arb_clip_control')) as g:
 g(['arb_clip_control-clip-control'])
 g(['arb_clip_control-depth-precision'])
+g(['arb_clip_control-viewport'])
 
 with profile.group_manager(
 PiglitGLTest, grouptools.join('spec', 'arb_color_buffer_float')) as g:
diff --git a/tests/spec/arb_clip_control/CMakeLists.gl.txt 
b/tests/spec/arb_clip_control/CMakeLists.gl.txt
index 7038366..3f55663 100644
--- a/tests/spec/arb_clip_control/CMakeLists.gl.txt
+++ b/tests/spec/arb_clip_control/CMakeLists.gl.txt
@@ -10,5 +10,6 @@ link_libraries (
 
 piglit_add_executable (arb_clip_control-clip-control clip-control.c)
 piglit_add_executable (arb_clip_control-depth-precision 
clip-control-depth-precision.c)
+piglit_add_executable (arb_clip_control-viewport viewport.c)
 
 # vim: ft=cmake:
diff --git a/tests/spec/arb_clip_control/viewport.c 
b/tests/spec/arb_clip_control/viewport.c
new file mode 100644
index 000..9d41ae9
--- /dev/null
+++ b/tests/spec/arb_clip_control/viewport.c
@@ -0,0 +1,202 @@
+/*
+ * Copyright (C) 2016 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.
+ */
+
+/**
+ * Test glViewport behaviour with GL_ARB_clip_control.
+ * The position of the viewport in window coordinates should not be
+ * effected by the GL_CLIP_ORIGIN state.
+ *
+ * See https://bugs.freedesktop.org/show_bug.cgi?id=93813
+ *
+ * Brian Paul
+ * 9 Feb 2016
+ */
+
+#include "piglit-util-gl.h"
+
+
+PIGLIT_GL_TEST_CONFIG_BEGIN
+   config.supports_gl_compat_version = 20;
+   config.window_visual = PIGLIT_GL_VISUAL_DOUBLE | PIGLIT_GL_VISUAL_RGBA;
+PIGLIT_GL_TEST_CONFIG_END
+
+
+static const float red[3] = { 1, 0, 0 };
+static const float green[3] = { 0, 1, 0 };
+static const float blue[3] = { 0, 0, 1 };
+static const float white[3] = { 1, 1, 1 };
+
+
+void
+piglit_init(int argc, char **argv)
+{
+   piglit_require_extension("GL_ARB_clip_control");
+   glEnable(GL_CULL_FACE);
+}
+
+
+/**
+ * Draw this pattern in the current viewport region, regardless of
+ * the clip control settings:
+ *
+ *   +-+-+
+ *   | | |
+ *   |   blue  |  white  |
+ *   | | |
+ *   +-+-+
+ *   | | |
+ *   |   red   |  green  |
+ *   | | |
+ *   +-+-+
+ *
+ * \param invert_y - if true, NDC_Y=-1=top, else NDC_Y=-1=bottom
+ */
+static void
+draw_test_pattern(bool invert_y)
+{
+   /* Since the modelview and projection matrices are identity matrices,
+* we're effectively drawing in Normalized Device Coordinates which
+* range from [-1,1] in X and Y.
+*
+* Note: we're careful with our glRectf coordinates so that the
+* rect is drawn front-facing.  If a rect is not drawn it must be
+* because it was back-face culled by mistake.
+*/
+
+   /* lower-left quadrant = red */
+   glColor3fv(red);
+   if (invert_y)
+   glRectf(-1, 0, 0, 1);
+   else
+   glRectf(-1, -1, 0, 0);
+
+   /* lower-right quadrant = green */
+   glColor3fv(green);
+

Re: [Piglit] [PATCH] Add a new GL_ARB_clip_control viewport test (v2)

2016-02-09 Thread Jose Fonseca 

Looks good to me.  Thanks Brian!

Reviewed-by: Jose Fonseca 


One question: the test case attached to the bug was with a texture bound 
to FBO.  Does this matter and should we add an additional test case for 
FBO vs window drawables? Or is this pretty much orthogonal?


Jose

On 09/02/16 17:14, Brian Paul wrote:

Verifies the screen position specified by glViewport is not effected by
the GL_CLIP_ORIGIN state.

Passes with nvidia, fails with Mesa until _mesa_get_viewport_xform()
is fixed.

v2: also enable back-face culling to make sure front/back-face polygon
orientation isn't upset by the clip origin.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93813
---
  tests/all.py  |   1 +
  tests/spec/arb_clip_control/CMakeLists.gl.txt |   1 +
  tests/spec/arb_clip_control/viewport.c| 202 ++
  3 files changed, 204 insertions(+)
  create mode 100644 tests/spec/arb_clip_control/viewport.c

diff --git a/tests/all.py b/tests/all.py
index b494ed6..4e6bb1d 100644
--- a/tests/all.py
+++ b/tests/all.py
@@ -2552,6 +2552,7 @@ with profile.group_manager(
  PiglitGLTest, grouptools.join('spec', 'arb_clip_control')) as g:
  g(['arb_clip_control-clip-control'])
  g(['arb_clip_control-depth-precision'])
+g(['arb_clip_control-viewport'])

  with profile.group_manager(
  PiglitGLTest, grouptools.join('spec', 'arb_color_buffer_float')) as g:
diff --git a/tests/spec/arb_clip_control/CMakeLists.gl.txt 
b/tests/spec/arb_clip_control/CMakeLists.gl.txt
index 7038366..3f55663 100644
--- a/tests/spec/arb_clip_control/CMakeLists.gl.txt
+++ b/tests/spec/arb_clip_control/CMakeLists.gl.txt
@@ -10,5 +10,6 @@ link_libraries (

  piglit_add_executable (arb_clip_control-clip-control clip-control.c)
  piglit_add_executable (arb_clip_control-depth-precision 
clip-control-depth-precision.c)
+piglit_add_executable (arb_clip_control-viewport viewport.c)

  # vim: ft=cmake:
diff --git a/tests/spec/arb_clip_control/viewport.c 
b/tests/spec/arb_clip_control/viewport.c
new file mode 100644
index 000..9d41ae9
--- /dev/null
+++ b/tests/spec/arb_clip_control/viewport.c
@@ -0,0 +1,202 @@
+/*
+ * Copyright (C) 2016 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.
+ */
+
+/**
+ * Test glViewport behaviour with GL_ARB_clip_control.
+ * The position of the viewport in window coordinates should not be
+ * effected by the GL_CLIP_ORIGIN state.
+ *
+ * See https://bugs.freedesktop.org/show_bug.cgi?id=93813
+ *
+ * Brian Paul
+ * 9 Feb 2016
+ */
+
+#include "piglit-util-gl.h"
+
+
+PIGLIT_GL_TEST_CONFIG_BEGIN
+   config.supports_gl_compat_version = 20;
+   config.window_visual = PIGLIT_GL_VISUAL_DOUBLE | PIGLIT_GL_VISUAL_RGBA;
+PIGLIT_GL_TEST_CONFIG_END
+
+
+static const float red[3] = { 1, 0, 0 };
+static const float green[3] = { 0, 1, 0 };
+static const float blue[3] = { 0, 0, 1 };
+static const float white[3] = { 1, 1, 1 };
+
+
+void
+piglit_init(int argc, char **argv)
+{
+   piglit_require_extension("GL_ARB_clip_control");
+   glEnable(GL_CULL_FACE);
+}
+
+
+/**
+ * Draw this pattern in the current viewport region, regardless of
+ * the clip control settings:
+ *
+ *   +-+-+
+ *   | | |
+ *   |   blue  |  white  |
+ *   | | |
+ *   +-+-+
+ *   | | |
+ *   |   red   |  green  |
+ *   | | |
+ *   +-+-+
+ *
+ * \param invert_y - if true, NDC_Y=-1=top, else NDC_Y=-1=bottom
+ */
+static void
+draw_test_pattern(bool invert_y)
+{
+   /* Since the modelview and projection matrices are identity matrices,
+* we're effectively drawing in Normalized Device Coordinates which
+* range from [-1,1] in X and Y.
+*
+* Note: we're careful with our glRectf coordinates so that the
+* rect is drawn front-facing.  If a

Re: [Piglit] [PATCH] Add a new GL_ARB_clip_control viewport test (v2)

2016-02-09 Thread Roland Scheidegger 
Am 09.02.2016 um 18:14 schrieb Brian Paul:
> Verifies the screen position specified by glViewport is not effected by
> the GL_CLIP_ORIGIN state.
> 
> Passes with nvidia, fails with Mesa until _mesa_get_viewport_xform()
> is fixed.
> 
> v2: also enable back-face culling to make sure front/back-face polygon
> orientation isn't upset by the clip origin.
> 
> Bugzilla: 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.freedesktop.org_show-5Fbug.cgi-3Fid-3D93813=BQIGaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_I=QzYNQWqCjdbrLuMq-4CGFRvPRr0kSORTxvDDC_U6UTM=SOC-12vCnLD2Efw5PaH71Y-e30hm3U0JETnVcvn4_no=
>  
> ---
>  tests/all.py  |   1 +
>  tests/spec/arb_clip_control/CMakeLists.gl.txt |   1 +
>  tests/spec/arb_clip_control/viewport.c| 202 
> ++
>  3 files changed, 204 insertions(+)
>  create mode 100644 tests/spec/arb_clip_control/viewport.c
> 
> diff --git a/tests/all.py b/tests/all.py
> index b494ed6..4e6bb1d 100644
> --- a/tests/all.py
> +++ b/tests/all.py
> @@ -2552,6 +2552,7 @@ with profile.group_manager(
>  PiglitGLTest, grouptools.join('spec', 'arb_clip_control')) as g:
>  g(['arb_clip_control-clip-control'])
>  g(['arb_clip_control-depth-precision'])
> +g(['arb_clip_control-viewport'])
>  
>  with profile.group_manager(
>  PiglitGLTest, grouptools.join('spec', 'arb_color_buffer_float')) as 
> g:
> diff --git a/tests/spec/arb_clip_control/CMakeLists.gl.txt 
> b/tests/spec/arb_clip_control/CMakeLists.gl.txt
> index 7038366..3f55663 100644
> --- a/tests/spec/arb_clip_control/CMakeLists.gl.txt
> +++ b/tests/spec/arb_clip_control/CMakeLists.gl.txt
> @@ -10,5 +10,6 @@ link_libraries (
>  
>  piglit_add_executable (arb_clip_control-clip-control clip-control.c)
>  piglit_add_executable (arb_clip_control-depth-precision 
> clip-control-depth-precision.c)
> +piglit_add_executable (arb_clip_control-viewport viewport.c)
>  
>  # vim: ft=cmake:
> diff --git a/tests/spec/arb_clip_control/viewport.c 
> b/tests/spec/arb_clip_control/viewport.c
> new file mode 100644
> index 000..9d41ae9
> --- /dev/null
> +++ b/tests/spec/arb_clip_control/viewport.c
> @@ -0,0 +1,202 @@
> +/*
> + * Copyright (C) 2016 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.
> + */
> +
> +/**
> + * Test glViewport behaviour with GL_ARB_clip_control.
> + * The position of the viewport in window coordinates should not be
> + * effected by the GL_CLIP_ORIGIN state.
> + *
> + * See 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.freedesktop.org_show-5Fbug.cgi-3Fid-3D93813=BQIGaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_I=QzYNQWqCjdbrLuMq-4CGFRvPRr0kSORTxvDDC_U6UTM=SOC-12vCnLD2Efw5PaH71Y-e30hm3U0JETnVcvn4_no=
>  
> + *
> + * Brian Paul
> + * 9 Feb 2016
> + */
> +
> +#include "piglit-util-gl.h"
> +
> +
> +PIGLIT_GL_TEST_CONFIG_BEGIN
> + config.supports_gl_compat_version = 20;
> + config.window_visual = PIGLIT_GL_VISUAL_DOUBLE | PIGLIT_GL_VISUAL_RGBA;
> +PIGLIT_GL_TEST_CONFIG_END
> +
> +
> +static const float red[3] = { 1, 0, 0 };
> +static const float green[3] = { 0, 1, 0 };
> +static const float blue[3] = { 0, 0, 1 };
> +static const float white[3] = { 1, 1, 1 };
> +
> +
> +void
> +piglit_init(int argc, char **argv)
> +{
> + piglit_require_extension("GL_ARB_clip_control");
> + glEnable(GL_CULL_FACE);
> +}
> +
> +
> +/**
> + * Draw this pattern in the current viewport region, regardless of
> + * the clip control settings:
> + *
> + *   +-+-+
> + *   | | |
> + *   |   blue  |  white  |
> + *   | | |
> + *   +-+-+
> + *   | | |
> + *   |   red   |  green  |
> + *   | | |
> + *   +-+-+
> + *
> + * \param invert_y -

[Piglit] [PATCH] Fix invalid glShaderSource call in pipeline_stats_comp.

2016-02-09 Thread Kenneth Graunke 
The test was passing a pointer to an uninitialized integer value as the
glShaderSource length parameter.  This is meant to be an array
containing the length of each shader string.

Instead, just pass NULL, which makes the GL assume the strings are
null-terminated (which they are).

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93335
Cc: Jordan Justen 
Cc: Mark Janes 
---
 tests/spec/arb_pipeline_statistics_query/pipeline_stats_comp.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/tests/spec/arb_pipeline_statistics_query/pipeline_stats_comp.c 
b/tests/spec/arb_pipeline_statistics_query/pipeline_stats_comp.c
index 47a36b0..3c511f1 100644
--- a/tests/spec/arb_pipeline_statistics_query/pipeline_stats_comp.c
+++ b/tests/spec/arb_pipeline_statistics_query/pipeline_stats_comp.c
@@ -79,7 +79,6 @@ static void
 dispatch_size(uint32_t x, uint32_t y, uint32_t z)
 {
char *compute_shader;
-   GLint shader_string_size;
GLuint shader = glCreateShader(GL_COMPUTE_SHADER);
GLint ok;
static GLint prog = 0;
@@ -92,7 +91,7 @@ dispatch_size(uint32_t x, uint32_t y, uint32_t z)
 
glShaderSource(shader, 1,
   (const GLchar **) _shader,
-  _string_size);
+  NULL);
 
glCompileShader(shader);
 
-- 
2.7.0

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

Re: [Piglit] [ANNOUNCE] python 3 is here... and python 2 is staying

2016-02-09 Thread Dylan Baker 
Quoting Matt Turner (2016-02-08 21:06:58)
> On Mon, Feb 8, 2016 at 3:12 PM, Dylan Baker  wrote:
> > I just pushed patches to hybridize the framework to use either python
> > 3.3+ or 2.7.
> >
> > Everything should keep working as normal. Unless you have python 3.x,
> > then you'll need to rerun CMake to pick up the changes.
> 
> There's still a handful of *.py files with #!/usr/bin/env python2:
> 
> generated_tests/random_ubo-arb_uniform_buffer_object.py:#!/usr/bin/env python2
> generated_tests/random_ubo.py:#!/usr/bin/env python2
> generated_tests/random_ubo_trim.py:#!/usr/bin/env python2
> piglit-print-commands.py:#!/usr/bin/env python2
> piglit-resume.py:#!/usr/bin/env python2
> piglit-run.py:#!/usr/bin/env python2
> piglit-summary-html.py:#!/usr/bin/env python2
> piglit-summary.py:#!/usr/bin/env python2
> self-tests/test-installed-piglit-script-imports-correct-framework-module:#!/usr/bin/env
> python2


I thought I'd mentioned that in the commit, but apparently I did only in
the cover letter.

The random_ubo_stuff is not plugged into anything at the moment, and I
have a WIP branch for those, but getting the same output from python 2
and python 3 for generators without numpy is tricky.

The piglit-* command were left intentionally. They're legacy interfaces
and we don't add new ones when adding new functions to the 'piglit'
command (piglit summary aggregate, for example). Personally, I'd rather
get rid of them (other than print-commands, which I should probably
update).

And the self-tests, I completely forgot those existed. I'll work on a
follow up patch for that one.

Dylan


signature.asc
Description: signature
___
Piglit mailing list
Piglit@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/piglit

Re: [Piglit] [ANNOUNCE] python 3 is here... and python 2 is staying

2016-02-09 Thread Ilia Mirkin 
On Tue, Feb 9, 2016 at 12:55 PM, Dylan Baker  wrote:
> Quoting Matt Turner (2016-02-08 21:06:58)
>> On Mon, Feb 8, 2016 at 3:12 PM, Dylan Baker  wrote:
>> > I just pushed patches to hybridize the framework to use either python
>> > 3.3+ or 2.7.
>> >
>> > Everything should keep working as normal. Unless you have python 3.x,
>> > then you'll need to rerun CMake to pick up the changes.
>>
>> There's still a handful of *.py files with #!/usr/bin/env python2:
>>
>> generated_tests/random_ubo-arb_uniform_buffer_object.py:#!/usr/bin/env 
>> python2
>> generated_tests/random_ubo.py:#!/usr/bin/env python2
>> generated_tests/random_ubo_trim.py:#!/usr/bin/env python2
>> piglit-print-commands.py:#!/usr/bin/env python2
>> piglit-resume.py:#!/usr/bin/env python2
>> piglit-run.py:#!/usr/bin/env python2
>> piglit-summary-html.py:#!/usr/bin/env python2
>> piglit-summary.py:#!/usr/bin/env python2
>> self-tests/test-installed-piglit-script-imports-correct-framework-module:#!/usr/bin/env
>> python2
>
>
> I thought I'd mentioned that in the commit, but apparently I did only in
> the cover letter.
>
> The random_ubo_stuff is not plugged into anything at the moment, and I
> have a WIP branch for those, but getting the same output from python 2
> and python 3 for generators without numpy is tricky.
>
> The piglit-* command were left intentionally. They're legacy interfaces
> and we don't add new ones when adding new functions to the 'piglit'
> command (piglit summary aggregate, for example). Personally, I'd rather
> get rid of them (other than print-commands, which I should probably
> update).

Really? I think it's a lot more straightforward to use them than the
"piglit" megarunner thing... not sure why that was added tbh. But
since the regular commands stayed, I didn't object at the time. Should
I have?

  -ilia
___
Piglit mailing list
Piglit@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/piglit

Re: [Piglit] [PATCH] Add a new GL_ARB_clip_control viewport test (v2)

2016-02-09 Thread Brian Paul 

Running the test with the -fbo flag covers that and passes for me.

-Brian


On 02/09/2016 10:21 AM, Jose Fonseca wrote:

Looks good to me.  Thanks Brian!

Reviewed-by: Jose Fonseca 


One question: the test case attached to the bug was with a texture bound
to FBO.  Does this matter and should we add an additional test case for
FBO vs window drawables? Or is this pretty much orthogonal?

Jose

On 09/02/16 17:14, Brian Paul wrote:

Verifies the screen position specified by glViewport is not effected by
the GL_CLIP_ORIGIN state.

Passes with nvidia, fails with Mesa until _mesa_get_viewport_xform()
is fixed.

v2: also enable back-face culling to make sure front/back-face polygon
orientation isn't upset by the clip origin.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93813
---
  tests/all.py  |   1 +
  tests/spec/arb_clip_control/CMakeLists.gl.txt |   1 +
  tests/spec/arb_clip_control/viewport.c| 202
++
  3 files changed, 204 insertions(+)
  create mode 100644 tests/spec/arb_clip_control/viewport.c

diff --git a/tests/all.py b/tests/all.py
index b494ed6..4e6bb1d 100644
--- a/tests/all.py
+++ b/tests/all.py
@@ -2552,6 +2552,7 @@ with profile.group_manager(
  PiglitGLTest, grouptools.join('spec', 'arb_clip_control'))
as g:
  g(['arb_clip_control-clip-control'])
  g(['arb_clip_control-depth-precision'])
+g(['arb_clip_control-viewport'])

  with profile.group_manager(
  PiglitGLTest, grouptools.join('spec',
'arb_color_buffer_float')) as g:
diff --git a/tests/spec/arb_clip_control/CMakeLists.gl.txt
b/tests/spec/arb_clip_control/CMakeLists.gl.txt
index 7038366..3f55663 100644
--- a/tests/spec/arb_clip_control/CMakeLists.gl.txt
+++ b/tests/spec/arb_clip_control/CMakeLists.gl.txt
@@ -10,5 +10,6 @@ link_libraries (

  piglit_add_executable (arb_clip_control-clip-control clip-control.c)
  piglit_add_executable (arb_clip_control-depth-precision
clip-control-depth-precision.c)
+piglit_add_executable (arb_clip_control-viewport viewport.c)

  # vim: ft=cmake:
diff --git a/tests/spec/arb_clip_control/viewport.c
b/tests/spec/arb_clip_control/viewport.c
new file mode 100644
index 000..9d41ae9
--- /dev/null
+++ b/tests/spec/arb_clip_control/viewport.c
@@ -0,0 +1,202 @@
+/*
+ * Copyright (C) 2016 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.
+ */
+
+/**
+ * Test glViewport behaviour with GL_ARB_clip_control.
+ * The position of the viewport in window coordinates should not be
+ * effected by the GL_CLIP_ORIGIN state.
+ *
+ * See https://bugs.freedesktop.org/show_bug.cgi?id=93813
+ *
+ * Brian Paul
+ * 9 Feb 2016
+ */
+
+#include "piglit-util-gl.h"
+
+
+PIGLIT_GL_TEST_CONFIG_BEGIN
+config.supports_gl_compat_version = 20;
+config.window_visual = PIGLIT_GL_VISUAL_DOUBLE |
PIGLIT_GL_VISUAL_RGBA;
+PIGLIT_GL_TEST_CONFIG_END
+
+
+static const float red[3] = { 1, 0, 0 };
+static const float green[3] = { 0, 1, 0 };
+static const float blue[3] = { 0, 0, 1 };
+static const float white[3] = { 1, 1, 1 };
+
+
+void
+piglit_init(int argc, char **argv)
+{
+piglit_require_extension("GL_ARB_clip_control");
+glEnable(GL_CULL_FACE);
+}
+
+
+/**
+ * Draw this pattern in the current viewport region, regardless of
+ * the clip control settings:
+ *
+ *   +-+-+
+ *   | | |
+ *   |   blue  |  white  |
+ *   | | |
+ *   +-+-+
+ *   | | |
+ *   |   red   |  green  |
+ *   | | |
+ *   +-+-+
+ *
+ * \param invert_y - if true, NDC_Y=-1=top, else NDC_Y=-1=bottom
+ */
+static void
+draw_test_pattern(bool invert_y)
+{
+/* Since the modelview and projection matrices are identity
matrices,
+ * we're effectively drawing in Normalized Device Coordinates which
+ * range from [-1,1] in X and Y.
+ *
+ * Note: we're