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

[Gurchetan Singh]

On Sun, May 13, 2018 at 9:51 PM Gert Wollny <gert.wollny at collabora.com>
wrote:

> Am Sonntag, den 13.05.2018, 09:36 +0200 schrieb Gert Wollny:
> > Am Freitag, den 11.05.2018, 14:33 -0700 schrieb Gurchetan Singh:
> > > 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
> >
> > Sorry, I probably didn't recheck on R600 after testing with my first
> > patch (the one on the guser side).
> Actually, it is a bit more complicated: The tests pass when deqp-gles3
> is run without specifying a gl-config name, but when I specify --deqp-
> gl-config-name=rgba8888d24s8 then the tests fail.

It's possible the default gl-config-name doesn't have any depth bits. Can
you test with different configs?

> When I emit a clear rasterizer state from the guest before the actual
> clear, then the tests pass, same when I emit an
> st_validate_state(...RENDER) in the guest st_Clear.

Ideally, a guest side patch won't be required since we can infer the
desired state from the semantics of a pipe->clear().  What does sending out
a default rasterizer state from the guest change that our current logic
doesn't?

> Best,
> Gert