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

[Zack Rusin]

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.

z