On 23/09/16 11:08 AM, Michel Dänzer wrote: > On 22/09/16 05:45 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. This is effectively a re-cherry-pick of >> 510c8605641803f1f5b5d2de6d3bb422b148e0e7. >> >> Fixes rendercheck -t blend -o src -f x4r4g4b4,x3r4g4b4 >> >> Signed-off-by: Eric Anholt <e...@anholt.net> >> --- >> glamor/glamor_render.c | 6 ++++++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/glamor/glamor_render.c b/glamor/glamor_render.c >> index c590580412c9..26dee05b5ce1 100644 >> --- a/glamor/glamor_render.c >> +++ b/glamor/glamor_render.c >> @@ -1423,6 +1423,12 @@ glamor_composite_clipped_region(CARD8 op, >> /* Is the composite operation equivalent to a copy? */ >> if (!mask && !source->alphaMap && !dest->alphaMap >> && source->pDrawable && !source->transform >> + && source->pDrawable->depth == dest->pDrawable->depth > > This clause ensures the depths match... > > >> + /* We can't do direct copies between different depths at 16bpp >> + * because r,g,b are allocated to different bits. >> + */ >> + && !(dest->pDrawable->bitsPerPixel == 16 && >> + dest->pDrawable->depth != source->pDrawable->depth) > > So this clause will always be true? > > > Anyway, this patch doesn't fix > > rendercheck -t blend -o src -f x4r4g4b4,x3r4g4b4 > > for me.
Correction: It does fix it with llvmpipe[0]. Also without the second clause above, so with that removed, Reviewed-and-Tested-by: Michel Dänzer <michel.daen...@amd.com> [0] I typo'd LIBGL_ALWAYS_SOFTWARE... and it looks like there's a radeonsi bug affecting that test as well. -- 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