[Mesa-dev] [PATCH] radeonsi: Fix blending using destination alpha factor but non-alpha destination
Christian König
deathsimple at vodafone.de
Tue Feb 19 01:33:55 PST 2013
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.
>
>> src/gallium/drivers/radeonsi/si_state.c | 116 +++++++++++++++++---------------
>> src/gallium/drivers/radeonsi/si_state.h | 3 +-
>> 2 files changed, 61 insertions(+), 58 deletions(-)
>>
>> diff --git a/src/gallium/drivers/radeonsi/si_state.c b/src/gallium/drivers/radeonsi/si_state.c
>> index d20e3ff..144a29d 100644
>> --- a/src/gallium/drivers/radeonsi/si_state.c
>> +++ b/src/gallium/drivers/radeonsi/si_state.c
>> @@ -36,33 +36,6 @@
>> #include "si_state.h"
>> #include "sid.h"
>>
>> -/*
>> - * inferred framebuffer and blender state
>> - */
>> -static void si_update_fb_blend_state(struct r600_context *rctx)
>> -{
>> - struct si_pm4_state *pm4;
>> - struct si_state_blend *blend = rctx->queued.named.blend;
>> - uint32_t mask;
>> -
>> - if (blend == NULL)
>> - return;
>> -
>> - pm4 = CALLOC_STRUCT(si_pm4_state);
>> - if (pm4 == NULL)
>> - return;
>> -
>> - mask = (1ULL << ((unsigned)rctx->framebuffer.nr_cbufs * 4)) - 1;
>> - mask &= blend->cb_target_mask;
>> - si_pm4_set_reg(pm4, R_028238_CB_TARGET_MASK, mask);
>> -
>> - si_pm4_set_state(rctx, fb_blend, pm4);
>> -}
>> -
>> -/*
>> - * Blender functions
>> - */
>> -
>> static uint32_t si_translate_blend_function(int blend_func)
>> {
>> switch (blend_func) {
>> @@ -84,7 +57,7 @@ static uint32_t si_translate_blend_function(int blend_func)
>> return 0;
>> }
>>
>> -static uint32_t si_translate_blend_factor(int blend_fact)
>> +static uint32_t si_translate_blend_factor(int blend_fact, bool dst_alpha)
>> {
>> switch (blend_fact) {
>> case PIPE_BLENDFACTOR_ONE:
>> @@ -94,7 +67,7 @@ static uint32_t si_translate_blend_factor(int blend_fact)
>> case PIPE_BLENDFACTOR_SRC_ALPHA:
>> return V_028780_BLEND_SRC_ALPHA;
>> case PIPE_BLENDFACTOR_DST_ALPHA:
>> - return V_028780_BLEND_DST_ALPHA;
>> + return dst_alpha ? V_028780_BLEND_DST_ALPHA : V_028780_BLEND_ONE;
>> case PIPE_BLENDFACTOR_DST_COLOR:
>> return V_028780_BLEND_DST_COLOR;
>> case PIPE_BLENDFACTOR_SRC_ALPHA_SATURATE:
>> @@ -110,7 +83,7 @@ static uint32_t si_translate_blend_factor(int blend_fact)
>> case PIPE_BLENDFACTOR_INV_SRC_ALPHA:
>> return V_028780_BLEND_ONE_MINUS_SRC_ALPHA;
>> case PIPE_BLENDFACTOR_INV_DST_ALPHA:
>> - return V_028780_BLEND_ONE_MINUS_DST_ALPHA;
>> + return dst_alpha ? V_028780_BLEND_ONE_MINUS_DST_ALPHA : V_028780_BLEND_ZERO;
>> case PIPE_BLENDFACTOR_INV_DST_COLOR:
>> return V_028780_BLEND_ONE_MINUS_DST_COLOR;
>> case PIPE_BLENDFACTOR_INV_CONST_COLOR:
>> @@ -133,30 +106,25 @@ static uint32_t si_translate_blend_factor(int blend_fact)
>> return 0;
>> }
> I think you might also need to patch up SRC_ALPHA_SATURATE (to zero).
>
> Can't comment on the hw stuff but at least llvmpipe does the same
> otherwise :-).
Why should we do so? SRC_ALPHA_SATURATE should still work fine, even
when the destination buffer doesn't have an alpha component.
Christian.
>
> Roland
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
More information about the mesa-dev
mailing list