[Mesa-dev] [PATCH] st/mesa: update the blend before a full color clear

[Ilia Mirkin]

On Thu, Feb 8, 2018 at 8:36 PM, Gurchetan Singh
<gurchetansingh at chromium.org> wrote:
> On Thu, Feb 8, 2018 at 5:15 PM, Marek Olšák <maraeo at gmail.com> wrote:
>>
>> On Fri, Feb 9, 2018 at 2:12 AM, Gurchetan Singh
>> <gurchetansingh at chromium.org> wrote:
>> > On Thu, Feb 8, 2018 at 4:46 PM, Marek Olšák <maraeo at gmail.com> wrote:
>> >>
>> >> This is not the correct fix.
>> >>
>> >> clear_with_quad calls cso_set_blend. pipe->clear ignores (and should
>> >> ignore) the blend state. There is no scenario where you would have to
>> >> call st_update_blend for pipe->clear. I think this is a virgl bug in
>> >> pipe->clear.
>> >
>> >
>> > clear_with_quad is only called if a color mask exists (see is_color_masked).
>> > When the state transitions from color-mask exists --> completely unmasked
>> > (the clear_buffers case), how is the driver supposed to be notified?
>>
>> The driver isn't notified. It should ignore the blend state entirely
>> and always use the full mask for full clears.
>
> That was my first approach (see crrev.com/c/909961).  However, that
> causes an issue where we:
>
> 1) Set blendstate B in cso_set_blend, thereby putting it into the cso cache
> 2) Do a full clear (thereby altering the colormask on the host side,
> but not updating the cso blendstate)
> 3) Try to use blendstate B again.  Since the cso context still thinks
> we have blendstate B, it never calls ctx->pipe->bind_blend_state.
>
> Besides updating the cso state, how can I fix this issue?

You need to save the original blend state. In the gallium API,
->clear() ignores the blend state. If you're compensating by setting
the blend state to something else, you must restore the old one after
doing the clear.

Although I think you're going about this wrong. The problem isn't with
virgl, it's with virglrenderer. It should disable colormask/blend
state when processing a clear packet.

  -ilia