Nathan Monson (nmo@spamaway.com) on 3/11/11 wrote:
---------------------------
>Are there any references on bandwidth mix in modern GPUs?
>
>NVIDIA slides have suggested that Fermi tries to avoid spilling intermediate data
>by pipelining geometry, vertex, and pixel shaders.
>
>That seems to leave updating frame/Z buffers and fetching textures as the major
>bandwidth hogs, plus a little for command lists and vertices.
>
>I have no experience profiling texture use in a modern engine, but I do know that
>texture fetches fall into at least three categories:
>
>1) Pre-baked function tables. These tend to be uncompressed, but cache well because
>interpolation (usually) allows small dimensions.
>2) Pre-baked compressed textures. These contain surface normals, lighting parameters,
>the actual images (what most people think of as texture maps), etc. They are large,
>but compress well. Z-prepass and mipmapping further reduce fetches.

After compression textures are basically cheap.
Some people will try and use 16 bit or 32 bit textures for a few items in a scene to increase the quality, then revert the upgrade when they see what that does to frame rate.

The biggest problem here is the complete lack of choices for compression.
Art is chosen to fit the one compression family you get, which is why all games look the same.

Multi-texturing helps dramatically here, this allows you to separate the high frequency texture changes from the low, so your texture does not look like mud.
The classic example is shirt/pants textures, you have a cloth texture, but you also need the pockets to stand out, and some pre-backed shadows in the arm pits.
As one combined texture this will look like crap after compression, as two or three or more separate textures the character will start looking good.
(You also may need a gloss map for metal armor, etc.)

You put four textures compressed to 4 bits each, and you get 16 total bits of texture bandwidth needed, so frame rate suffers.

What we really need is computed textures, with a better family of math to decode the source textures. In an ideal world the artist would paint the shirt texture with pockets, and the tools would separate out the high and low bandwidth parts and decide on two or more textures, some computed and/or tiled, others merely compressed.

Note that the high and low detail maps generated by a computer may not look anything like the separate cloth and pockets texture an artist would create.
The artist created textures would have redundant noise, that the computer would remove to save bits.
The goal here is reduced bandwidth and higher result quality.

The classic DTXc EPIC FAIL is signs with text on them. All we need is a simple 1 bit texure map for this, with a generic dirt map applied on top.
Even uncompressed this is peanuts, and you can get 90% compression.
(Example: "WARNING: Electrified fence, do not touch.")

We cannot afford high res 4 bit DTXc detail maps, so you walk into your post apocalypse mall and all the signage/advertising/boxed_goods you normally would see in the real life is removed.
The result barely looks like a mall at all.

SOMEONE PLEASE COME UP WITH A 1 BIT COMPRESSED TEXURE FORMAT THAT ATI AND NVIDIA CAN USE FOR SIGNAGE!!!

Give me some 1 bit textures and I will give you a game with graphics that will make your jaw drop.

>3) Dynamic/runtime-computed textures. These are Z-buffers, frame buffers, shadow
>maps, environment maps, etc. These tend to be uncompressed, or minimally compressed
>by the shaders (maybe Z-compression works here?).
>
>I always assumed that #3 used most of the texture bandwidth on modern engines,
>due to the lack of compression and (sometimes) lack of mip-mapping.

#3 dominates by an order of magnitude, sometimes two orders of magnitude.
On a high end stealth shooter you have to support things like shooting out lights.
This breaks all the pre-baked lighting you rely on for good frame rate.
You end up dropping several frames while you recompute these maps on the fly, then to DTXc compress the results so you can use them at good frame rates.

Normally your pre-baked lighting is ray traced on a render farm over the course of days.
Artists are not happy when these maps are replaced by cheaper in game code.
Really bad results can happen, you have to carefully place each light the user can shoot out, and what shadow maps are effected, and generally have pre-cooked replacements swapped in, so you dont have to use the in game light re-cooking code.

Shadows are also pain, you will update shadows at 30fps even while the game is rendering at 60fps.

Games are massive collection of high tech kludges, to get good frame rates.

>Some people in this thread seem to have deeper insight into actual bandwidth use. What is the biggest category?