On Monday 19 October 2009 08:58:22 Michel Dänzer wrote: > On Fri, 2009-10-16 at 00:29 +0100, ja...@vmware.com wrote: > > From: Zack Rusin <za...@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 _______________________________________________ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel