[Mesa-dev] [RFC PATCH] mesa/st/cb_clear: in st_Clear also validate the render state (needed by virgl)

[Ilia Mirkin]

On Thu, May 3, 2018 at 1:15 PM, Gert Wollny <gert.wollny at collabora.com> wrote:
> Am Donnerstag, den 03.05.2018, 12:51 -0400 schrieb Ilia Mirkin:
>>
>> virgl_clear implements a gallium API call which is meant to clear the
>> surface. It sounds like virglrenderer does not properly implement
>> that
>> call. Either workaround your buggy "hardware" (i.e. virglrenderer) by
>> throwing in an explicit "no, really, do this" call, or fix
>> virglrenderer to do the clear irrespective of what the last-set
>> rasterizer discard state might be. I'd recommend the latter (i.e.
>> fixing this in virglrenderer).
>>
>
> IMNSHO doing a clear regardless of the last-set rasterizer discard is
> just replacing one bug with another. Besides, there is another CTS test
> that apparently gets fixed by this patch
>
> dEQP-GLES3.functional.shaders.indexing.
>    moredynamic.with_value_from_indexing_expression_fragment
>
> and this doesn't use rasterizer discard.
>
> In any case, virglrendere doesn't know about the state change because
> the client (virgl) doesn't send the state change before the clear. This
> is the bug.
>
> My problem is to fix this in the right place I need access to the
> current render state in virgl_clear so that I can send the updated
> state like it is done for other hardware when they call the blitter
> (and that's why I put an RFC into the subject, in the hope that someone
> who is more knowledgabe with the data structures used by virgl could
> give me a hint).
>
> Another option would be to always send state changes to the host,
> regardless of whether they will be used or not, but this seems to me
> like a waste of cycles.

The api call is "clear", not "glClear in the context of whatever
random GL state there might be". When the gallium clear API is
invoked, the bound framebuffer needs to be cleared. This is how the
API works, this is how all drivers implement it. It's basically
memset(). It doesn't care about rasterizer discard or anything else.

As long as you're not implementing that API, you're going to have problems.

Sounds like the other test is also fixed with extra flushing, which
means that you have some other piece of state not being properly
tracked.

  -ilia