On Thu, Feb 8, 2018 at 8:36 PM, Gurchetan Singh <gurchetansi...@chromium.org> wrote: > On Thu, Feb 8, 2018 at 5:15 PM, Marek Olšák <mar...@gmail.com> wrote: >> >> On Fri, Feb 9, 2018 at 2:12 AM, Gurchetan Singh >> <gurchetansi...@chromium.org> wrote: >> > On Thu, Feb 8, 2018 at 4:46 PM, Marek Olšák <mar...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
