[Mesa-dev] [PATCH] radeonsi: Fix blending using destination alpha factor but non-alpha destination

[Michel Dänzer]

On Die, 2013-02-19 at 15:48 +0100, Marek Olšák wrote: 
> On Tue, Feb 19, 2013 at 3:28 PM, Michel Dänzer <michel at daenzer.net> wrote:
> > On Die, 2013-02-19 at 14:04 +0100, Marek Olšák wrote:
> >> On Tue, Feb 19, 2013 at 11:02 AM, Michel Dänzer <michel at daenzer.net> wrote:
> >> >
> >> > Really, what I don't understand is why r600g doesn't seem affected by
> >> > this... at least on my RS880 it's passing the piglit tests this change
> >> > fixes with radeonsi. So maybe I'm just missing some magic bit for
> >> > radeonsi.
> >>
> >> RGB formats do fail fbo-blending-formats with r600g/redwood here.
> >
> > Okay.
> >
> >
> >> However the alpha channel can sometimes contain 1 in memory even if
> >> the format is RGBX. Off the top of my head, glClear, glTex[Sub]Image,
> >> glCopyTex[Sub]Image always set alpha to 1.
> >
> > Well, but they shouldn't for these formats. :) The memory corresponding
> > to X* channels should remain unchanged. I'm working on a separate patch
> > for that for radeonsi.
> 
> I think the only way you could do that is to set the colormask to RGB.

Exactly.

> Doesn't it have a negative effect on performance if some channels are
> masked out?

It might, but I don't see that we really have a choice. If the app /
state tracker doesn't want to preserve those bits, it should use a
non-X* format.


-- 
Earthling Michel Dänzer           |                   http://www.amd.com
Libre software enthusiast         |          Debian, X and DRI developer