If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Intel HiZ Is Finally Ready For Sandy Bridge

Phoronix: Intel HiZ Is Finally Ready For Sandy Bridge

As reported earlier this week, HiZ support is now ready for Intel Sandy Bridge graphics under Linux with the Mesa driver. A set of more than three dozen patches were published that finalize this support for Sandy Bridge (Gen6) while the Ivy Bridge (Gen7) support is almost there but there are some performance regressions still being worked out by Intel's OSTC developers.

An ideal visibility algorithm should a) quickly reject most of the hidden geometry in a model and b) exploit the spatial and perhaps temporal coherence of the images being generated. Ray casting with spatial subdivision does well on criterion (a), but poorly on criterion (b). Traditional Z-buffer scan conversion does well on criterion (b), but poorly on criterion (a). Here we present a hierarchical Z-buffer scan-conversion algorithm that does well on both criteria. The method uses two hierarchical data structures, an object-space octree and an image-space Z pyramid, to accelerate scan conversion. The two hierarchical data structures make it possible to reject hidden geometry very rapidly while rendering visible geometry with the speed of scan conversion. For animation, the algorithm is also able to exploit temporal coherence. The method is well suited to models with high depth complexity, achieving orders of magnitude acceleration in some cases compared to ordinary Z-buffer scan conversion.

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.

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 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?