On Tue, May 8, 2018 at 2:09 AM, Gert Wollny <gert.wol...@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
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
