[Mesa-dev] [PATCH 2/3] intel/blorp/hiz: Always set sample number

[Chad Versace]

On Wed 13 Sep 2017, Matt Turner wrote:
> In-Reply-To: <20170913220107.GD6810 at ivybridge.mattst88.com>

Matt, upgrade your machine. Ivy Bridge is ancient.

> On 09/11, Topi Pohjolainen wrote:
> > Signed-off-by: Topi Pohjolainen <topi.pohjolainen at intel.com>
> 
> Patches 2-3 (because I don't know a lot about this code) are
> 
> Acked-by: Matt Turner <mattst88 at gmail.com>

Patch 2 is
Reviewed-by: Chad Versace <chadversary at chromium.org>

Please reference Chromium commit
https://chromium-review.googlesource.com/c/chromiumos/overlays/chromiumos-overlay/+/490534
somewhere in the message. You can also use the short url
http://crrev.com/c/490534. That's the commit where marcheu disabled HiZ
on Brasswell due to hangs.

But what about 3DSTATE_RASTER? In the same section the Broadwell PRM says that
3DSTATE_RASTER must also be emitted prior to 3DSTATE_WM_HZ_OP, but only
"if 3DSTATE_RASTER is used".

I'm unsure how exactly to interpret that self-referential condition. "If
you use it, then you must emit... ok?"

> Chromium has been disabling HiZ on Braswell for stability reasons
> (trying to find out more information, but I currently don't have
> permissions to view their bug tracker). Not sure if they have the
> bandwidth to test these patches, but Cc'ing Chad in case they do.

Summary of problems we saw on Chrome OS: Brasswell boards were
sporadically GPU hanging in the test lab while running GLBench [1].
marcheu caught an i915_error_state that shows the hang happening shortly
after GEN7_3DSTATE_HIER_DEPTH_BUFFER, se he disabled HiZ on
Brasswell.


I'll submit your patches to the test lab and see what happens.  The hang
is hard to reproduce, though, so don't wait on me for verification that
this patch fixes it.

[1]: https://chromium.googlesource.com/chromiumos/third_party/autotest/+/master/client/deps/glbench/