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? -- o...@lunarg.com _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
