[Mesa-dev] [PATCH 1/4] gallium: add pipe_surface::alpha_one field

[Brian Paul]

On 06/24/2016 03:56 AM, Nicolai Hähnle wrote:
> On 24.06.2016 04:07, Brian Paul wrote:
>> If the user requests an RGB drawing surface but we actually create an
>> RGBA surface, we need it to act as if A=1.  For blending, this means
>> adjusting the blending terms to use 1/0 instead of
>> DST_ALPHA/INV_DST_ALPHA.
>> Drivers can use this flag to determine when that's needed.
>
> Having the bit is fine, but shouldn't there be a PIPE_CAP for it?

No.  What would the state tracker do differently if there was a cap?

If there's a driver currently simulating RGB with RGBA they're probably 
already doing blending wrong for the cases in question.  The new flags 
gives the driver a chance of fixing this.  It can be ignored otherwise.

And keep in mind that this is a corner case that should never come up in 
practice: if the app is blending into an RGB surface using blending 
terms that involve destination alpha, that's kind of senseless.

The piglit fbo-blending-formats test hits this, however.

-Brian


>
> Nicolai
>
>> A previous patch I posted last year did this entirely in the state
>> tracker
>> but it involved making blend state dependent on the framebuffer state.
>> This approach avoids that dependency.
>> ---
>>   src/gallium/include/pipe/p_state.h | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/src/gallium/include/pipe/p_state.h
>> b/src/gallium/include/pipe/p_state.h
>> index 9c69355..8b0c3a2 100644
>> --- a/src/gallium/include/pipe/p_state.h
>> +++ b/src/gallium/include/pipe/p_state.h
>> @@ -387,6 +387,7 @@ struct pipe_surface
>>      unsigned height;              /**< logical height in pixels */
>>
>>      unsigned writable:1;          /**< writable shader resource */
>> +   unsigned alpha_one:1;    /**< Should an RGBA surface should act
>> like RGB? */
>>
>>      union {
>>         struct {
>>