FP textures

[Reverend]

In Nick/Richard's FM/Next3DMark interview :

All of our FP textures also act as render targets. We do not use FP formats for things like surface textures within the scenes. We believe that conventional texture formats, especially compressed ones, are still the best option for such use. This is because reflectance values, surface normals, etc. have a very constrained range. The higher precision and range provided by FP formats are much more useful when dealing with actual light values.

What use of FP texture or buffers are you looking at for the next 3DMark? Specifically which do you feel is likely to be used more in near-future games? Do you feel that the choice you're making is influenced more by technical reasons or by hardware support?

I agree with FM's view (and prediction) on this. Are there, however, any instances when the lack of precision is a noticeable one? I can think of, say, having a lot of FP lookup tables, where the lack of precision in conventional textures should be noticeable when there are very slight changes in normal maps with environment mapping, like window glass, for instance. Any other cases in "usual" game implementations?

 

[bloodbob]

We need HDR enviroment maps ( doesn't mean they all have to be ) as demonstrated often we might want better then 8bits for stuff like normal maps and a few other things.

 

[Mintmaster]

For normal maps you won't get much out of FP textures. Once your normal goes significantly (say, 30 degrees) off axis, your mantissa does all the work, and you still need to maintain precision for subtle changes in direction. When specular reflection is involved, precision is quite important to avoid banding. I think Far Cry and HL2 illustrated this when the GeforceFX was up to its shenanigans.

The best example I know is ATI's car demo with the Ferrari F50, which uses normal mapping and looks up an environment map. In the white paper they said even 11-12 bits wasn't enough, so FP16 would barely make the grade.

So IMO 16-bit integer is the best for normal maps and EMBM perturbations. For HDR textures holding colour/light information, Humus made a nice demo of how you can pair a compressed colour texture with a high precision scale factor for a low bandwidth high quality FP substitution.

In short, I agree witht the FM statement. FP16 for ordinary textures is not very important. It's very good for rendertargets, though.

 

[Humus]

So IMO 16-bit integer is the best for normal maps and EMBM perturbations.

For EMBM perturbations you tend to need high precision because you're looking up in a texture with the resulting value, but I would say that it's not the stored precision but the interpolated precision that matters. A RGB565 texture would probably work just fine if it was interpolated at 16bits (which it's not though). It's really hard to detect if the reflection angles are slightly off, but it's very easy to spot banding/blockiness.

 

[Mintmaster]

Good point, Humus.

Just curious, if I was reading a two 16-bit channel texture like R16G16, how many bilinear filtered samples per clock can R520 achieve?

 

[OpenGL guy]

Good point, Humus.

Just curious, if I was reading a two 16-bit channel texture like R16G16, how many bilinear filtered samples per clock can R520 achieve?

I am not positive, but since it's 32bpp, it should go at full speed, even on R300.

 

[bloodbob]

For HDR textures holding colour/light information, Humus made a nice demo of how you can pair a compressed colour texture with a high precision scale factor for a low bandwidth high quality FP substitution.

Its not great in every situation ( high contrast images with pure black pixels lead to problems ).

Since your using pixel shaders to get out a float value for the texture I probably would class this in FP textures category.