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

[Marek Olšák]

On Tue, Feb 19, 2013 at 3:55 PM, Michel Dänzer <michel at daenzer.net> wrote:
> 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.

We do have a choice: let's do nothing. ReadPixels and GetTexImage
always set the alpha to one, and we can patch the blend state manually
to get correct RGB blending. What could possibly be broken if the
alpha is modified by the hardware?

Marek