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, 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. > > 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 _______________________________________________ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel