[PATCH] exa: Unset and restore per alpha in exaTryMagicTwoPassCompositeHelper

[Zack Rusin]

On Tuesday 20 October 2009 07:25:02 Michel Dänzer wrote:
> On Mon, 2009-10-19 at 15:02 -0400, Zack Rusin wrote:
> > On Monday 19 October 2009 08:58:22 Michel Dänzer wrote:
> > > On Fri, 2009-10-16 at 00:29 +0100, jakob at vmware.com wrote:
> > > > From: Zack Rusin <zackr at vmware.com>
> > > >
> > > > This fixes the component alpha fallback in exa. I'm not sure which
> > > > branches this should go into. Also before committing this patch make
> > > > sure that we get a Tested-by by somebody with a radeon card as this
> > > > turns on new and wonderful paths not tested in the drivers.
> > >
> > > This shouldn't make any difference for sub-pixel AA text with the
> > > radeon driver, as it doesn't simply check for pMask->componentAlpha
> > > but:
> > >
> > > 	if (pMaskPicture->componentAlpha) {
> > > 	    /* Check if it's component alpha that relies on a source alpha and
> > > 	     * on the source value.  We can only get one of those into the
> > > 	     * single source value that we get to blend with.
> > > 	     */
> > > 	    if (RadeonBlendOp[op].src_alpha &&
> > > 		(RadeonBlendOp[op].blend_cntl & RADEON_SRC_BLEND_MASK) !=
> > > 		RADEON_SRC_BLEND_GL_ZERO) {
> > > 		RADEON_FALLBACK(("Component alpha not supported with source "
> > > 				 "alpha and source value blending.\n"));
> > > 	    }
> > > 	}
> > >
> > > I'm not sure offhand if the proposed change is necessary or even
> > > sensible given this, or if the Gallium Xorg state tracker shouldn't
> > > just use similar checks, and I may not find the time to build a firmer
> > > opinion before I'm back from vacation next month.
> >
> > Well, the question we're asking the driver is: do you support the
> > following operation, we expect an answer based on its own capabilities
> > not on the capabilities of the acceleration architecture.
> >
> > So the question: do you support component alpha when the driver doesn't
> > should always be a no, not a conditional maybe that depends on code it
> > has no control over.
> > IMO if Exa decomposes PictOpOver component alpha into two
> > non-compoment-alpha passes, it should actually do that and not depend on
> > driver being able to figure out what it's trying to do.
> 
> Makes sense - assuming the fact that the mask picture has component
> alpha actually makes a difference for the decomposed operations. Does
> it? I'm not sure offhand, and I'm not inclined to find out before the
> end of the month for reasons stated earlier. :) Though I'm inclined to
> assume it doesn't, or I'm not sure how the decomposition would help for
> hardware that doesn't support component alpha.

Yea, no doubt, you're right, the patch is useless :) I'll fix it appropriately 
in xorg state tracker.

z