[virglrenderer-devel] [PATCH] vrend_clear: clear and restore rasterizer discard and depth clamp

Gurchetan Singh gurchetansingh at chromium.org
Fri May 11 21:33:44 UTC 2018


This regresses the following dEQP tests when run on a Nvidia GL host:

dEQP-GLES3.functional.fragment_ops.interaction.basic_shader.2
dEQP-GLES3.functional.fragment_ops.interaction.basic_shader.10
dEQP-GLES3.functional.fragment_ops.interaction.basic_shader.11
dEQP-GLES3.functional.fragment_ops.interaction.basic_shader.14
dEQP-GLES3.functional.fragment_ops.interaction.basic_shader.16
dEQP-GLES3.functional.fragment_ops.interaction.basic_shader.25
dEQP-GLES3.functional.fragment_ops.interaction.basic_shader.26
dEQP-GLES3.functional.fragment_ops.interaction.basic_shader.39
dEQP-GLES3.functional.fragment_ops.interaction.basic_shader.40
dEQP-GLES3.functional.fragment_ops.interaction.basic_shader.41
dEQP-GLES3.functional.fragment_ops.interaction.basic_shader.56
dEQP-GLES3.functional.fragment_ops.interaction.basic_shader.61
dEQP-GLES3.functional.fragment_ops.interaction.basic_shader.68
dEQP-GLES3.functional.fragment_ops.interaction.basic_shader.70
dEQP-GLES3.functional.fragment_ops.interaction.basic_shader.73
dEQP-GLES3.functional.fragment_ops.interaction.basic_shader.90
dEQP-GLES3.functional.fragment_ops.interaction.basic_shader.96

Commenting out the depth clamp changes seems to fix them, though...

On Tue, May 8, 2018 at 11:35 AM Gurchetan Singh
<gurchetansingh at chromium.org>
wrote:

> Reviewed-by: Gurchetan Singh <gurchetansingh at chromium.org>

> On Tue, May 8, 2018 at 3:47 AM, Gert Wollny <gert.wollny at collabora.com>
wrote:
> > vrend_clear is passed in from gallium clear which, unlike glClear, must
> > not obey rasterizer discard and depth_clmap. However, the guest doesn't
> > foreard the latest update of the rendering states to the host before
issuing
> > "clear". Therefore, the host clear command must clear these states
before
> > calling glClear in turn. After calling glClear these states are again
brought
> > into sync with what the host assumes.
> >
> > Fixes CTS:
> >    dEQP-GLES3.functional.rasterizer_discard.fbo.*
> >
> > Signed-off-by: Gert Wollny <gert.wollny at collabora.com>
> > ---
> >  src/vrend_renderer.c | 17 ++++++++++++++++-
> >  1 file changed, 16 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/vrend_renderer.c b/src/vrend_renderer.c
> > index ac9723c..34fa32b 100644
> > --- a/src/vrend_renderer.c
> > +++ b/src/vrend_renderer.c
> > @@ -2486,6 +2486,8 @@ void vrend_clear(struct vrend_context *ctx,
> >        } else {
> >           glClearDepth(depth);
> >        }
> > +      if (!ctx->sub->hw_rs_state.depth_clip)
> > +          glDisable(GL_DEPTH_CLAMP);
> >     }
> >
> >     if (buffers & PIPE_CLEAR_STENCIL) {
> > @@ -2493,6 +2495,9 @@ void vrend_clear(struct vrend_context *ctx,
> >        glClearStencil(stencil);
> >     }
> >
> > +   if (ctx->sub->hw_rs_state.rasterizer_discard)
> > +       glDisable(GL_RASTERIZER_DISCARD);
> > +
> >     if (buffers & PIPE_CLEAR_COLOR) {
> >        uint32_t mask = 0;
> >        int i;
> > @@ -2526,9 +2531,19 @@ void vrend_clear(struct vrend_context *ctx,
> >     if (bits)
> >        glClear(bits);
> >
> > -   if (buffers & PIPE_CLEAR_DEPTH)
> > +   /* Is it really necessary to restore the old states? The only
reason we
> > +    * get here is because the guest cleared all those states but
gallium
> > +    * didn't forward them before calling the clear command
> > +    */
> > +   if (ctx->sub->hw_rs_state.rasterizer_discard)
> > +       glEnable(GL_RASTERIZER_DISCARD);
> > +
> > +   if (buffers & PIPE_CLEAR_DEPTH) {
> >        if (!ctx->sub->dsa_state.depth.writemask)
> >           glDepthMask(GL_FALSE);
> > +      if (!ctx->sub->hw_rs_state.depth_clip)
> > +          glEnable(GL_DEPTH_CLAMP);
> > +   }
> >
> >     /* Restore previous stencil buffer write masks for both front and
back faces */
> >     if (buffers & PIPE_CLEAR_STENCIL) {
> > --
> > 2.16.1
> >
> > _______________________________________________
> > virglrenderer-devel mailing list
> > virglrenderer-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/virglrenderer-devel


More information about the virglrenderer-devel mailing list