Re: [PATCH xserver 02/10 v2] glamor: Require that 16bpp pixmap depths match for Render copies.

[Michel Dänzer]

On 26/09/16 03:53 AM, Eric Anholt wrote:
> Michel Dänzer  writes:
>> On 23/09/16 09:51 PM, Eric Anholt wrote:
>>>
>>> We do need some concerted effort on actually fixing our rendering bugs
>>> and reenabling the skipped tests.  I've spent a while trying to come up
>>> with why the remaining rendercheck test fails and come up with nothing
>>> yet.
>>
>> How can others help with this?

[...]

> and rendercheck/cacomposite/all/a8:

FWIW, this test passes with radeonsi. The other tests you mentioned also
have failures with radeonsi, but different ones.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver 02/10 v2] glamor: Require that 16bpp pixmap depths match for Render copies.

[Eric Anholt]

Michel Dänzer  writes:

> On 23/09/16 09:51 PM, Eric Anholt wrote:
>> Michel Dänzer  writes:
>>> On 23/09/16 04:57 PM, Eric Anholt wrote:
 The copy optimization in d37329cba42fa8e72fe4be8a7be18e512268b5bd
 replicated a bug from last time we did a copy optimization, and didn't
 get rendercheck run on it.
>>>
>>> Actually, I'm pretty sure I did run rendercheck, but didn't notice the
>>> regression due to the radeonsi bug affecting the same test. Please
>>> consider removing that language from the commit log.
>> 
>> OK.  I'll drop the comment about running rendercheck.
>
> Thanks.
>
>
>> We do need some concerted effort on actually fixing our rendering bugs
>> and reenabling the skipped tests.  I've spent a while trying to come up
>> with why the remaining rendercheck test fails and come up with nothing
>> yet.
>
> How can others help with this?

I fixed the remaining glamor-specific case in the scripts on the plane.
Now we're down to:

# Skip some tests that are failing at the time of importing the script.
#"REPORT: min_bounds, rbearing was 0, expecting 2"
PIGLIT_ARGS="$PIGLIT_ARGS -x xlistfontswithinfo@3"
PIGLIT_ARGS="$PIGLIT_ARGS -x xlistfontswithinfo@4"
PIGLIT_ARGS="$PIGLIT_ARGS -x xloadqueryfont@1"
PIGLIT_ARGS="$PIGLIT_ARGS -x xqueryfont@1"
PIGLIT_ARGS="$PIGLIT_ARGS -x xqueryfont@2"
#"REPORT: Incorrect pixel on inside of area at point (0, 0): 0x0 != 0x1"
PIGLIT_ARGS="$PIGLIT_ARGS -x xgetimage@7"
PIGLIT_ARGS="$PIGLIT_ARGS -x xgetsubimage@7"

in the current XTS set across fb and glamor/llvmpipe.  XGetImage/7 seems
to be BadMatching.  I have no idea about the font thing, but it doesn't
seem too rendering-related either.

So, at this point, I think it's up to us to go bang on our hardware 3D
drivers to make sure that they're rendering glamor correctly.  Sending
out a script to make that easier, even if we're not going to put it in
make check.

For i965, I'm seeing failures in:

rendercheck/blend/over:

Beginning blend test on a4r4g4b4
Over blend test error of 15. at (0, 0) --
   R G B A
got:   0.000 0.000 0.000 0.000
expected:  0.000 0.000 0.000 1.000
src color: 0.00 0.00 0.00 1.00 (a8)
dst color: 0.00 0.00 0.00 1.00
src: 1x1R a8, dst: a4r4g4b4
Beginning blend test on a4b4g4r4
Over blend test error of 15. at (0, 0) --
   R G B A
got:   0.000 0.000 0.000 0.000
expected:  0.000 0.000 0.000 1.000
src color: 0.00 0.00 0.00 1.00 (a8)
dst color: 0.00 0.00 0.00 1.00
src: 1x1R a8, dst: a4b4g4r4

and rendercheck/blend/src:

Beginning blend test on b8g8r8a8
Src blend test error of 255. at (0, 0) --
   R G B A
got:   0.000 0.000 0.000 0.000
expected:  0.000 0.000 0.000 1.000
src color: 0.00 0.00 0.00 1.00 (a8)
dst color: 0.00 0.00 0.00 1.00
src: 1x1R a8, dst: b8g8r8a8

Beginning blend test on a4r4g4b4
Src blend test error of 15. at (0, 0) --
   R G B A
got:   0.000 0.000 0.000 0.000
expected:  0.000 0.000 0.000 1.000
src color: 0.00 0.00 0.00 1.00 (a8)
dst color: 0.00 0.00 0.00 1.00
src: 1x1R a8, dst: a4r4g4b4
Beginning blend test on a4b4g4r4
Src blend test error of 15. at (0, 0) --
   R G B A
got:   0.000 0.000 0.000 0.000
expected:  0.000 0.000 0.000 1.000
src color: 0.00 0.00 0.00 1.00 (a8)
dst color: 0.00 0.00 0.00 1.00
src: 1x1R a8, dst: a4b4g4r4

and rendercheck/cacomposite/all/a8:

Ignoring server-supported format: x2b10g10r10
Beginning composite CA mask test on a8
Saturate CA composite test error of 128. at (0, 0) --
   R G B A
got:   0.000 0.000 0.000 0.498
expected:  0.000 0.000 0.000 1.000
src color: 0.00 0.00 0.00 1.00
msk color: 0.00 0.00 0.00 0.50
dst color: 0.00 0.00 0.00 1.00
src: 1x1R a8, mask: 1x1R a8, dst: a8
Beginning composite CA mask test on a8r8g8b8
DisjointIn CA composite test error of 255. at (0, 0) --
   R G B A
got:   0.000 0.000 0.000 0.000
expected:  0.000 0.000 0.000 1.000
src color: 0.00 0.00 0.00 1.00
msk color: 0.00 0.00 0.00 1.00
dst color: 0.00 0.00 0.00 1.00

and rendercheck/triangles:

Beginning Dst Triangles test on a8
triangles test error of 255. at (0, 0) --
   R G B A
got:   0.000 0.000 0.000 0.000
expected:  0.000 0.000 0.000 1.000
...


signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver 02/10 v2] glamor: Require that 16bpp pixmap depths match for Render copies.

[Michel Dänzer]

On 23/09/16 09:51 PM, Eric Anholt wrote:
> Michel Dänzer  writes:
>> On 23/09/16 04:57 PM, Eric Anholt wrote:
>>> The copy optimization in d37329cba42fa8e72fe4be8a7be18e512268b5bd
>>> replicated a bug from last time we did a copy optimization, and didn't
>>> get rendercheck run on it.
>>
>> Actually, I'm pretty sure I did run rendercheck, but didn't notice the
>> regression due to the radeonsi bug affecting the same test. Please
>> consider removing that language from the commit log.
> 
> OK.  I'll drop the comment about running rendercheck.

Thanks.


> We do need some concerted effort on actually fixing our rendering bugs
> and reenabling the skipped tests.  I've spent a while trying to come up
> with why the remaining rendercheck test fails and come up with nothing
> yet.

How can others help with this?


>>> This is effectively a re-cherry-pick of 
>>> 510c8605641803f1f5b5d2de6d3bb422b148e0e7.
>>>
>>> Fixes rendercheck -t blend -o src -f x4r4g4b4,x3r4g4b4
>>>
>>> v2: Drop excessive src->depth == dst->depth check that snuck in.
>>>
>>> Signed-off-by: Eric Anholt 
>>> ---
>>>
>>> Michel, I didn't apply your review becuase you said "second clause",
>>> but I removed the first of the two.
>>
>> Is there any case where the drawable depths don't match, but a copy does
>> what's expected?
> 
> I asked keithp, and he agreed that CopyArea may not be used to copy
> between depths.  Render is totally defined across depths, though.

Right, which is why I thought the first clause was necessary and the
second one redundant.

(I suspect some cases such as copying between depth 24 and 32 may work
out correctly, but it's probably better to use a whitelist approach for
those rather than a blacklist for all cases which don't work correctly)


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer



signature.asc
Description: OpenPGP digital signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver 02/10 v2] glamor: Require that 16bpp pixmap depths match for Render copies.

[Eric Anholt]

Michel Dänzer  writes:

> On 23/09/16 04:57 PM, Eric Anholt wrote:
>> The copy optimization in d37329cba42fa8e72fe4be8a7be18e512268b5bd
>> replicated a bug from last time we did a copy optimization, and didn't
>> get rendercheck run on it.
>
> Actually, I'm pretty sure I did run rendercheck, but didn't notice the
> regression due to the radeonsi bug affecting the same test. Please
> consider removing that language from the commit log.

OK.  I'll drop the comment about running rendercheck.

We do need some concerted effort on actually fixing our rendering bugs
and reenabling the skipped tests.  I've spent a while trying to come up
with why the remaining rendercheck test fails and come up with nothing
yet.

>> This is effectively a re-cherry-pick of 
>> 510c8605641803f1f5b5d2de6d3bb422b148e0e7.
>> 
>> Fixes rendercheck -t blend -o src -f x4r4g4b4,x3r4g4b4
>> 
>> v2: Drop excessive src->depth == dst->depth check that snuck in.
>> 
>> Signed-off-by: Eric Anholt 
>> ---
>> 
>> Michel, I didn't apply your review becuase you said "second clause",
>> but I removed the first of the two.
>
> Is there any case where the drawable depths don't match, but a copy does
> what's expected?

I asked keithp, and he agreed that CopyArea may not be used to copy
between depths.  Render is totally defined across depths, though.


signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver 02/10 v2] glamor: Require that 16bpp pixmap depths match for Render copies.

[Michel Dänzer]

On 23/09/16 04:57 PM, Eric Anholt wrote:
> The copy optimization in d37329cba42fa8e72fe4be8a7be18e512268b5bd
> replicated a bug from last time we did a copy optimization, and didn't
> get rendercheck run on it.

Actually, I'm pretty sure I did run rendercheck, but didn't notice the
regression due to the radeonsi bug affecting the same test. Please
consider removing that language from the commit log.


> This is effectively a re-cherry-pick of 
> 510c8605641803f1f5b5d2de6d3bb422b148e0e7.
> 
> Fixes rendercheck -t blend -o src -f x4r4g4b4,x3r4g4b4
> 
> v2: Drop excessive src->depth == dst->depth check that snuck in.
> 
> Signed-off-by: Eric Anholt 
> ---
> 
> Michel, I didn't apply your review becuase you said "second clause",
> but I removed the first of the two.

Is there any case where the drawable depths don't match, but a copy does
what's expected?


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel