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

[Ilia Mirkin]

On Fri, May 4, 2018 at 5:30 PM, Gert Wollny <gert.wollny at collabora.com> wrote:
> Am Freitag, den 04.05.2018, 16:11 -0400 schrieb Ilia Mirkin:
>> On Fri, May 4, 2018 at 2:50 PM, Gert Wollny <gert.wollny at collabora.co
>> m> wrote:
>> > For that reason I think that a render state validation within
>> > st_Clear  makes sense, because it makes sure that the states
>> > like  SCISSOR_TEST or DISCARD_RASTERIZER are properly send to the
>> > driver, before clear() is executed that makes use of these states.
>> > And while the workaround for DISCARD_RASTERIZER is possible because
>> > if it is set then the host should actually never see the clear
>> > command, SCISSOR_TEST is different, its state can not be guessed on
>> > the host.
>> >
>> > Anyway, I happily take every hint on how this can be fixed directly
>> > in virgl_clear or virgl in general, and thank you for taking the
>> > time to answer me,
>>
>> I thought someone else took care of the scissor thing for clears. At
>> least they were asking about it.
>
> When I implemented the "disable rasterizer_discard" before clear in
> virglrenderer I had tests failing that include scissors, so that's why
> I assumed that it migt be a problem, but with your list below, I don't
> think that it is really that important which state gets not updated
> properly, because they all should be send to virglrenderer.
>
>>
>> I have to assume that virglrenderer keeps track of the last-set
>> rasterizer state. Based on that, you have to turn off scissors,
>> rasterizer discard, window rectangles, stencil tests, sample
>> masks(?), and anything else which affects clears (have a look at
>> st_Clear -- anything that causes it to hit the fallback path which
>> draws should be something you turn off because calling glClear() in
>> virglrenderer).
> As far as I can seen the rasterizer state is updated with the last draw
> command, but, to take scissors as an example, when I set and enable
> scissors before a clear, then this is not transmitted, and the clear on
> the host doesn't take a possible active scissore state into a account.
> How does turning off scissors in virglrenderer help me with that? (same
> for the other states).
>
>> If you don't keep track of the last-set rasterizer state, then now
>> may be a good time to start :)
> When you refer to the states that are set after the last draw command
> but before a clear, then no, they are not updated in virglrenderer
> because there is no code path that exposed them to the driver, and this
> is where I'm stuck.
>
> Now reading a bit more in the code I find it strange that in
> st_validate_state with (pipeline = ST_PIPELINE_CLEAR) not all states
> that actually have an influenze on the clear command are updated (i.e.
> the render states). I find this surprising ...

Rasterizer state doesn't affect the gallium clear callback. clear just
clears -- it's a memset. However rasterizer state affects glClear() so
you have to make sure to keep that in mind when you try to implement
clear() with glClear() (i.e. turn off whatever GL state the rasterizer
may have set which would cause you issues).

Note that the idea of gallium is that it's close to how the hardware
works. For example on NVIDIA, the CLEAR_BUFFERS command just clears.
No questions asked. No dependency on the rast state (except if you
explicitly ask it). You're running into problems because you're using
GL to implement the gallium API, and it doesn't quite match.

If you want, you could construct a temporary rasterizer state, bind
that, do the glClear() and then bind the old one back.

  -ilia