[Mesa-dev] [RFC PATCH] mesa/st/cb_clear: in st_Clear also validate the render state (needed by virgl)
Marek Olšák
maraeo at gmail.com
Tue May 8 06:49:18 UTC 2018
On Tue, May 8, 2018 at 2:09 AM, Gert Wollny <gert.wollny at collabora.com>
wrote:
> Am Montag, den 07.05.2018, 22:55 -0400 schrieb Marek Olšák:
> >
> > tl;dr. Is the problem that Clear in virgl obeys rasterizer_discard?
> > Well then you have a bigger problem, because rasterizer_discard
> > should have no effect on Clear like in this example where glClear
> > should be executed normally:
> >
> > glEnable(GL_RASTERIZER_DISCARD);
> > glClear(GL_COLOR_BUFFER_BIT);
>
> No, glClear should obey GL_RASTERIZER_DISCARD (see standard 14.1, and
> this is actually handled in _mesa_Clear).
>
> > glDisable(GL_RASTERIZER_DISCARD);
>
> The problem is that rasterizer state changes are not send to the host
> before gallium clear is sent, so when the guest calls
>
> glEnable(GL_RASTERIZER_DISCARD);
> ..draw something ..
> glDisable(GL_RASTERIZER_DISCARD);
> glClear(GL_COLOR_BUFFER_BIT);
>
> then the host still thinks that GL_RASTERIZER_DISCARD is enabled, and
> since it emulates gallium_clear by galling glClear it fails.
>
> Initially, I proposed to also validate the rasterizer state in st_Clear
> to properly update the host state, but Ilia talked me out of it.
>
I see now. pipe->clear is not affected by pipe_rasterizer_state, thus
st/mesa doesn't have to do anything. st/mesa only considers the official
behavior of pipe->clear, not the behavior of drivers. If you wanna change
this, you have to officially re-define the behavior of pipe->clear, though
there may be some resistance from VMWare, because they prefer the behavior
of pipe->clear to match DX11, and everybody else also prefers the current
behavior. If you somehow managed to get everybody to agree with your new
behavior of pipe->clear, st/mesa could be modified to take it into account.
Marek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20180508/ce3c96c8/attachment.html>
More information about the mesa-dev
mailing list