Intel HiZ Is Finally Ready For Sandy Bridge

[chadversary]

Re: How to toggle HIZ?

How do you toggle INTEL_HIZ and INTEL_SEPARATE_STENCIL? kernel parameter? export INTEL_HIZ=1?

It's now enabled by default in the git master. To disable it, set these environment variables.

export INTEL_HIZ=0
export INTEL_SEPARATE_STENCIL=0

When running Mesa master, proceed with caution. In some OpenGL corner cases, HiZ causes some nasty bugs that we haven't solved yet.

[curaga]

I recall Imagination's ace card was tiled rendering, not Z tricks. HiZ has been in Radeons since ~8500.

[liam]

HiZ is a trick for getting much higher performance out of any renderer that makes heavy use of expensive fragment programs and which was coded on the assumption that HiZ exists (which excludes many older games and most FOSS games, neither of which are coded with any significant knowledge of modern GPU features). The idea is that for any Z-buffer test, instead of testing that individual fragment the GPU can instead test an entire tile (say, a 64x64 chunk of fragments) based on the furthest depth of all fragments in that tile, which is much faster. This works because the assumption is that fragments next to each other are generally part of the same object and will have very similar depth values, with the exception being the areas around object edges (or edges in level geometry), but those are generally a small fraction of the entire scene.

One thing that a lot of renderers do horribly wrong is that they still sort geometry back-to-front, which completely screws over the use of HiZ. This was a trick back before the z-buffer was around (e.g., old versions of Quake that ran in software renderers) which made rendering geometry easy (painter's algorithm vs z-buffering), and it's still used for transparent objects (although screen door transparency is also used pretty often, as its much faster, doesn't require sorting albeit not doing so hurts HiZ, and on modern high resolutions it's really hard to tell the difference between real blending and screendoor transparency). Sorting back-to-front means that every object drawn will pass the Z-buffer test because every fragment drawn is closer than any previous fragment drawn, so HiZ is not really doing anything in that case and fragment shaders are run for every single fragment in the view even though many/most are going to be covered up by closer objects or level geometry.

The ideal pipeline today will sort solid objects front-to-back and transparent objects back-to-front (and use as little transparency as possible). Sorting front to back means that the closer objects are drawn first, causing all the occluded objects to fail the early-Z test before fragment shaders are ever run, which can have a massive performance improvement on shader-bound apps, as well as allowing HiZ to actually do something useful. Sorting is not always feasible though, so a lot of renderers just render everything in whatever order happens to be most convenient, giving an average okay-ish improvement from HiZ/early-Z.

Sorting solid geometry back-to-front is absolutely totally wrong and anyone who's still doing that on 2011-era hardware (or even 2001-era hardware) for solid geometry should be hit with a hardcover copy of GPU Gems.

Note that the ioQuake3 based games are all based on an engine released in 1999 (and hence developed a year or three before that), so they basically just added shaders and other basic features on top of an ancient graphics engine that's totally inappropriate for modern hardware, which is likely why they see no improvement from HiZ being turned on. Doom3 should see more of an improvement since it was released after HiZ was introduced in hardware (ATI R200 being the first I know of, released in 2001) and so I'd expect Carmack and crew to have coded against the assumption that the user's hardware had that feature.

I thought that only Imagination had this Z-discard IP? Has it been licensed out to all parties, or do they do something slightly differently? AFAIK, that was the sole thing that made their gpus both power efficient and fast (well, the two in this case being directly related).

[seandarcy]

How to toggle HIZ?

How do you toggle INTEL_HIZ and INTEL_SEPARATE_STENCIL? kernel parameter? export INTEL_HIZ=1?

Clueless,

sean

[olbi]

I said it - Intel sucks now and it didnt change until they have same drivers like AMD and NVIDIA actually. Sic! is that that people from marketing dont see needed for OpenGL 4.x cause users dont need it. That's why I dont like theirs IGP which are ugly, have so much bugs and others thing. Their HiZ isnt so great like we saw on tests? 13% more performence? So joke?

[baffledmollusc]

Great explanation, elanthis! I feel I've learned something this morning :-)

[elanthis]

HiZ is a trick for getting much higher performance out of any renderer that makes heavy use of expensive fragment programs and which was coded on the assumption that HiZ exists (which excludes many older games and most FOSS games, neither of which are coded with any significant knowledge of modern GPU features). The idea is that for any Z-buffer test, instead of testing that individual fragment the GPU can instead test an entire tile (say, a 64x64 chunk of fragments) based on the furthest depth of all fragments in that tile, which is much faster. This works because the assumption is that fragments next to each other are generally part of the same object and will have very similar depth values, with the exception being the areas around object edges (or edges in level geometry), but those are generally a small fraction of the entire scene.

One thing that a lot of renderers do horribly wrong is that they still sort geometry back-to-front, which completely screws over the use of HiZ. This was a trick back before the z-buffer was around (e.g., old versions of Quake that ran in software renderers) which made rendering geometry easy (painter's algorithm vs z-buffering), and it's still used for transparent objects (although screen door transparency is also used pretty often, as its much faster, doesn't require sorting albeit not doing so hurts HiZ, and on modern high resolutions it's really hard to tell the difference between real blending and screendoor transparency). Sorting back-to-front means that every object drawn will pass the Z-buffer test because every fragment drawn is closer than any previous fragment drawn, so HiZ is not really doing anything in that case and fragment shaders are run for every single fragment in the view even though many/most are going to be covered up by closer objects or level geometry.

The ideal pipeline today will sort solid objects front-to-back and transparent objects back-to-front (and use as little transparency as possible). Sorting front to back means that the closer objects are drawn first, causing all the occluded objects to fail the early-Z test before fragment shaders are ever run, which can have a massive performance improvement on shader-bound apps, as well as allowing HiZ to actually do something useful. Sorting is not always feasible though, so a lot of renderers just render everything in whatever order happens to be most convenient, giving an average okay-ish improvement from HiZ/early-Z.

Sorting solid geometry back-to-front is absolutely totally wrong and anyone who's still doing that on 2011-era hardware (or even 2001-era hardware) for solid geometry should be hit with a hardcover copy of GPU Gems.

Note that the ioQuake3 based games are all based on an engine released in 1999 (and hence developed a year or three before that), so they basically just added shaders and other basic features on top of an ancient graphics engine that's totally inappropriate for modern hardware, which is likely why they see no improvement from HiZ being turned on. Doom3 should see more of an improvement since it was released after HiZ was introduced in hardware (ATI R200 being the first I know of, released in 2001) and so I'd expect Carmack and crew to have coded against the assumption that the user's hardware had that feature.

[FireBurn]

Am I the only one who does not know what the heck Intel HiZ is and wonders why it is not explained in both "articles"?

Usually if big pieces of information like that are missing it's because Michael himself doesn't know

If he did there would no doubt be an article explaining it and it would be referenced in every HiZ story

[bridgman]

Nah, no, you are not. I can only guess from the name HiZ that it is something related to early Z buffer checks.

There's another recent thread with the same questions. On our GPUs, HiZ is short for Hierarchical Z, basically an on-chip cache storing a low-resolution copy of the Z buffer, allowing the graphics pipe to check and discard objects without having to render them or access the Z buffer in many cases. I imagine the same name refers to something similar on other GPUs but I don't know that for sure.

There are references to HyperZ in the other thread but that is just our term for a collection of Z-related techniques, where HiZ is one of those techniques.

[blacknova]

Am I the only one who does not know what the heck Intel HiZ is and wonders why it is not explained in both "articles"?

Nah, no, you are not. I can only guess from the name HiZ that it is something related to early Z buffer checks.