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

[Ilia Mirkin]

On Thu, Feb 8, 2018 at 8:58 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
> 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.

BTW, note that glClear() can be also affected by scissors, window
rectangles, and stencil masks; none of these affect pipe->clear(), so
if you're implementing it with glClear, then it may not work.