[Mesa-dev] [PATCH 1/2] st/mesa: adjust blending modes if we don't have destination alpha

[Jose Fonseca]

On 29/04/15 15:56, Brian Paul wrote:
> On 04/29/2015 05:52 AM, Marek Olšák wrote:
>> On Wed, Apr 29, 2015 at 12:44 PM, Jose Fonseca <jfonseca at vmware.com>
>> wrote:
>>> I think there are two different things here: one is the driver
>>> internally
>>> fakes BGRX with BGRA, and obviously it's the pipe driver that needs
>>> to fix
>>> up alpha channel blending to simulate it's one.
>>>
>>> The other is the state tracker is faking BGRX with BGRA, and in that
>>> case,
>>> it's the state tracker that needs to do the fix up (as the pipe has
>>> no way
>>> to know if that's intentional or not).
>>
>> That's a fair point. On the other hand, I don't see why drivers can't
>> support BGRX even if they can force A=1 for texturing only.
>
> Yeah, the key thing is whether the driver advertises support for alpha
> "X" formats.  We've only been doing that for one case
> (PIPE_FORMAT_B8G8R8X8_UNORM) which directly corresponds to an SVGA3D_
> format (SVGA3D_X8R8G8B8).
>
> If the state tracker can always find a PIPE_FORMAT_RGBX format for a
> GL_RGB format then the driver can detect this particular blend / format
> combination and work things out itself.
>
> But if the state tracker can't find a PIPE_FORMAT_RGBX format for GL_RGB
> and uses a PIPE_FORMAT_RGBA format, it's really up to the state tracker
> to fix-up the blend mode in this case.
>
> The gallium interface has never specified a required set of surface
> formats.  Maybe we need to establish a policy for that first.
>
>
>>> Or are you saying that state trackers should never attempt to fulfill
>>> BGRX
>>> formats with BGRA, and that every driver needs to workaround this
>>> internally?
>>
>> Not necessarily.
>>
>>>
>>> I don't fill too strongly about this, but it wouldn't sound consistent.
>>> Nowadays have a pipe cap for every single little thing out there.  I
>>> don't
>>> see a reason to treat render target formats differently. Otherwise
>>> something
>>> that can be easily done once in the state tracker now needs to be
>>> replicated
>>> in every driver.
>>>
>>>
>>> But you have a point about _NEW_BUFFERS.  It could be avoided.  We could
>>> introduce a new flag _NEW_BUFFERS_EMULATED, set when fbo's with emulated
>>> formats (e.g., backing BGRX with BGRA), so that drivers that support (or
>>> workaround) these things internally don't .  On the other hand,
>>> _NEW_BUFFERS
>>> probably doesn't change that frequently, blend state probably changes
>>> much
>>> more often.
>>
>> A new CAP would work. There is an easier way to do it though, see the
>> attached patch (assuming blend_force_dst_alpha_to_one is set
>> correctly).
>
> I guess we could do yet another new cap.

I think that the is_format_support suffices.  Like you said, if the 
driver doesn't support the RGBX format, the state tracker will emulate 
it with the RGBA.  So no new cap necessary, unless some driver actually 
doesn't want this automatic conversion.

Jose