[Mesa-dev] gen7 hiz op fixes
Chad Versace
chad.versace at linux.intel.com
Wed Feb 8 18:59:30 PST 2012
On 02/08/2012 03:32 PM, Eric Anholt wrote:
> gen7 appears to be totally broken at the moment -- GL apps are GPU
> hanging, and I've been using piglit fdo23670-drawpix_stencil
> (approximately the first failing test) trying to track it down. Here
> are a couple of little fixes, but they don't actually fix the problem.
These patches look good, and they are
Reviewed-by: Chad Versace <chad.versace at linux.intel.com>
But I believe the reason that "they don't actually fix the problem" is that
the problem you're encountering is elsewhere, not in the HiZ code.
On master, I'm unable to reproduce a failure with fdo23670-drawpix_stencil;
GL apps are running fine on my system; and a full piglit run looks rather
ordinary. I've verified through simulator batch dumps and `glxinfo | grep Mesa`
that I am in fact running master.
Here is a possible explanation why the HiZ code is not hanging the GPU, at
least on my system. I examined the batch dump in the neighborhood of the
buggy packets, 3DSTATE_MULTISAMPLE and 3DSTATE_DS, fixed by your patches.
The result is that, as expected, there is noise and corruption in the
neighborhood of those packets. But, unexpectedly, that corruption is
benign, at least according to the simulator's interpretation of that
corruption. The simulator believes that
- A MI_NOOP is emitted after 3DSTATE_MULTISAMPLE.
- After 3DSTATE_DS, no 3DSTATE_GS is emitted. Instead, there are
five MI_NOOP's between it and 3DSTATE_SOL.
By the way, I'd like future code and commit messages to stop referring
to gen6_hiz_exec as a meta-op. It's misleading, since the current code
is unrelated to _mesa_meta_*. Let's just call it "the HiZ op".
----
Chad Versace
chad.versace at linux.intel.com
More information about the mesa-dev
mailing list