[Mesa-dev] slow depth test on Intel gen7+

Chia-I Wu olvaffe at gmail.com
Tue Feb 4 20:02:18 PST 2014


Hi,

I am looking at performance issues for some benchmark for a while, and am able
to identify three issues so far, all related to depth test.

The first issue is slow 16-bit depth buffer.  This is already known and is
fixed for GLES contexts by commit 73bc6061f5c3b6a3bb7a8114bb2e1a.  It is not
fixed for GL contexts because GL3.0 spec states, in section 3.9.1,

  Requesting one of these (sized) internal formats for any texture type will
  allocate exactly the internal component sizes and ...

However, all GL versions other than 3.0 do not require exact component sizes.
There are several possible fixes:

 - ignore GL3.0 spec and always allocate 24-bit depth buffers for best
   performance
 - add an drirc option to determine whether to ignore GL 3.0 spec or not
   in this case (the name of the option is to be determined)
 - allocate 24-bit depth buffers for all except GL 3.0 contexts

The second issue is, when HiZ is enabled, the rendering of small triangles
hitting the same HiZ pixel blocks is slow.  There turned out to be a register
to control the HiZ behavior and a patch to change the behavior has been
committed to the kernel drm-intel tree.

The third issue is the rendering of small triangles becomes very slow when
depth test is enabled and

 - GEN7_WM_PSCDEPTH_ON is set in 3DSTATE_WM, or
 - GEN7_WM_KILL_ENABLE is set in 3DSTATE_WM _and_ some pixels are killed

In both cases, early-Z is likely disabled, and that could easily explain the
slowdown.  But there are other ways to disable early-Z, such as

 - set the depth test function to GL_ALWAYS
 - make sure GEN7_WM_KILL_ENABLE is set but do not kill pixels

and they do not hurt the performance as much.  I have yet to figure out the
cause for the dramatic slowdown.  Kind of hope there is another magic register
to fix it, but that does not happen yet.  Any ideas?

-- 
olv at LunarG.com


More information about the mesa-dev mailing list