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

Gurchetan Singh gurchetansingh at chromium.org
Fri Feb 9 02:16:23 UTC 2018


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

Good tips.  I think save and restore on the virglrender side may work
... I'll look into it ...


More information about the mesa-dev mailing list