[Mesa-dev] [PATCH] radeonsi: Fix blending using destination alpha factor but non-alpha destination
Michel Dänzer
michel at daenzer.net
Tue Feb 19 06:55:17 PST 2013
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
More information about the mesa-dev
mailing list