Brett (ggtgp@yahoo.com) on 3/15/11 wrote:
---------------------------
>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.

Cheap bandwidth-wise, though the fillrate demand is unchanged. But the point stands. Compressed textures are not where most of the bandwidth is going.

>Some people will try and use 16 bit or 32 bit textures for a few items in a scene

What is a 16-bit texture? Do you mean 16 bits per pixel, or 16 bits per color channel?

>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're doing it wrong. The pocket is a separate piece of cloth and should have its own separate polygon sheet.
It will stand out automatically, because it has different surface normals where it meets the underlying cloth, and thus responds differently to the lighting.

Trying to flatten this into a texture like you have a polygon shortage or something is just lame.

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

If you do it this way, you will likely be fillrate-limited, not bandwidth-limited. It takes four times as many texture fetches, but no additional framebuffer or z-buffer accesses.

>What we really need is computed textures,

This is already available. You just have to choose to use it.
Downsides:
-eats fillrate, especially shader ops. But shader ops are pretty cheap.
-bandwidth savings may be less than expected. Most good procedural textures use a texture lookup for part of the work...
-you have to actually write some code, so it's unsuitable for those who can't (most artists) or won't (game companies that won't hire more programmers).

>with a better family of math to decode
>the source textures. In an ideal world the artist would paint the shirt texture
>with pockets,

This is your ideal world??? Goddamn, your standards are low.

In an ideal world, the shirt would be modeled from individual cotton threads, and the rough surface of each thread would be built up from polygons, and all this work would be done automatically by software rather than by an artist.

The artist would say "Holodeck! give this dude a shirt!" and the holodeck computer would flash through a bunch of example shirts.
And then the artist would say "like that one, but eleven percent looser, and with greener pockets." And the computer would make it so.

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

A lot of the signs I see in the mall are not flat textured quads. There are neon signs made of glass tubing. There are signs with letters made of blocks of plastic.
Posters can be flat, but posters in a mall are not usually the compressible 1-bit road-sign look.
They have pictures of people, brand logos, color gradients, and all sort of stuff to try and catch your attention.

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

You don't need textures at all for this. It can be done 0-bit per texel.
Intead of using textures to define the shapes of letters in the text, you build up the text and background from colored untextured polygons.

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

I have just given you 0-bit textures. But given your short-sightedness and total lack of vision, I'm not expecting anything jawdropping.

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

Prebaked lightmaps are what we used ten years ago. A modern engine should have dynamic lighting, recalculated every frame, or close to it.

>Normally your pre-baked lighting is ray traced on a render farm over the course of days.

If it takes days, you're probably doing it wrong.
I remember running offline raytracers on a single core cpu, ten years ago, and it was not even close to that slow.

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

This "problem" was solved years ago by dynamic lighting. Even Doom 3 lets you turn lights on and off without problems.
Why are you still using an obsolete technique and then complaining about its known flaws?

It's like "My horse is too slow to keep up with traffic on the highway!" Stop riding a horse and get a car.

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

"also"? Shadows ARE the lighting results. Computing shadows and computing shadows are one and the same.

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