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. Am I missing another patch? (Patch 1 of this series is a NOP, right?) -- 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