[Mesa-dev] [PATCH] st/mesa: update the blend before a full color clear
imirkin at alum.mit.edu
Fri Feb 9 02:01:16 UTC 2018
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.
More information about the mesa-dev