[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 <michel at daenzer.net> 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 <eric at anholt.net>
>>> ---
>>>
>>> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: OpenPGP digital signature
URL: <https://lists.x.org/archives/xorg-devel/attachments/20160925/50c685ba/attachment.sig>