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

[Marek Olšák]

On Tue, Feb 19, 2013 at 10:33 AM, Christian König
<deathsimple at vodafone.de> wrote:
> Am 18.02.2013 20:11, schrieb Roland Scheidegger:
>
>> Am 18.02.2013 19:14, schrieb Michel Dänzer:
>>>
>>> From: Michel Dänzer <michel.daenzer at amd.com>
>>>
>>> 11 more little piglits.
>>>
>>> NOTE: This is a candidate for the 9.1 branch.
>>>
>>> Signed-off-by: Michel Dänzer <michel.daenzer at amd.com>
>>> ---
>>>
>>> Any ideas why this seems necessary with radeonsi but not with r600g?
>>
>> Maybe the hw uses an implicit 1 if the format has no alpha (though I'm
>> not sure if it can always know with bgrx formats and the like).
>> I'm wondering if there should be a helper for those fixups. Looks to me
>> like quite some drivers need it (though well so far I think just
>> non-gallium i965 does this plus llvmpipe, but for some of the others I'm
>> skeptical if not doing it is really correct...).
>
>
> I agree alpha blending with a buffer format that doesn't have alpha is a bit
> strange, that should be catched by the upper layers.

I think it's better to do that in drivers instead.

r300g also uses a different blend state for RGBX and RGBA. The R300
blend state CSO actually contains 11 command buffers and the driver
switches between them when needed. Two of those command buffers
contain blend state for RGBX and RGBA. This approach of having
multiple command buffers per CSO has a much lower overhead than any
other solution I've seen (including rebuilding states on the fly and
having the state tracker figure it out).

Marek