FP12 ?????

[parhelia]

Ok, lots of people are saying that NV GeforceFX cards run fast because it uses only FP12 instead of FP32.
What I want to know is :
- What is the FP for Radeon 9800?
- Some other sites say that it uses 96 bit pixel shaders precision. Is this the same as FP ?

 

[Ilfirin]

FX12, not FP12. (integer vs floating point)
The 9x00 (x>=5) cards are all FP24.
The FP/FX numbers are all for a single channel, when talking about the full 4-component color it is, of course, 4x that number (thus the 9x00 cards are 96-bit, FX cards range from 48-bits to 128-bits)

 

[Hyp-X]

There's no such thing as FP12.

FX supports the following formats:
FX12 (fast) - 12 bit fixed point: s1.10 range [-2;+2)
FP16 (slow) - 16 bit floating point: 1s 5e 10m
FP32 (slow) - 32 bit floating point: 1s 8e 23m

R3xx supports the following format:
FP24 (fast) - 24 bit floating point: 1s 7e 16m

Edit: changed fp description.

 

[Ilfirin]

There's no such thing as FP12.

FX supports the following formats:
FX12 (fast) - 12 bit fixed point: s1.10 range [-2;+2)
FP16 (slow) - 16 bit floating point: s5e10
FP32 (slow) - 32 bit floating point: s8e23

R3xx supports the following format:
FP24 (fast) - 24 bit floating point: s7e16

You got the mantissa/exponents backwards on the FPs:
FP16 - s10e5
FP24 - s16e7
FP32 - s23e8

 

[Hyp-X]

FP16 - 16 bit floating point: s5e10
FP32 - 32 bit floating point: s8e23
FP24 - 24 bit floating point: s7e16

You got the mantissa/exponents backwards on the FPs:
FP16 - s10e5
FP24 - s16e7
FP32 - s23e8

Sigh.
I never liked that format.

Using sign-exp-mantissa ordering would be more "natural" because that's the actual order in which they are stored.

 

[Doomtrooper]

Isn't FX12 basically the same rendering precision of a DX8 class card like a 8500 or GF4 ??

 

[Dave Baumann]

Well, its integer, but its higher precision than GF4 (which was FX9).

 

[Doomtrooper]

Is all DX8 class cards FX9 ?? If so what gave the improved dynamic range on the 8500 difuse bump mapping example ?

 

[Zeross]

Is all DX8 class cards FX9 ?? If so what gave the improved dynamic range on the 8500 difuse bump mapping example ?

R2x0 chips are using FX16 precision

 

[Doomtrooper]

Tx Zeross

 

[Reverend]

R3xx supports the following format:
FP24 (fast) - 24 bit floating point: 1s 7e 16m

To be absolutely correct (hey, the word "supports" can get kinda flaky these times!), the R3xx can accept FP32 requests.

 

[Freak'n Big Panda]

can accept FP32 requests but just converts them to FP24 correct?

 

[LeStoffer]

can accept FP32 requests but just converts them to FP24 correct?

Correct. The texture address (data input if you wish) can be FP32, but is converted to an ATI 'internal' FP24 during the pixel shader calculations. The R3x0 can expand the result from the pixel shader up to FP32 data afterwards, however.

sireric (ATI) has told us that writing out their internal format to 128b (FP32) and reading it back in as a texture 'causes no precision loss'.

 

[Hyp-X]

Yes of course R300 supports float textures and rendertargets both in FP16 and FP32 format.

A more complete support list:

R300 internal   R300 external   FX internal   FX external
                     FX8           FX12          FX8
                     FX16                     (*)FX16
     FP24            FP16          FP16       (+)FP16
                     FP32          FP32       (+)FP32

(*) only as texture but not as rendertarget and only up to 2 components
(+) only under OpenGL

 

[parhelia]

thanks for clearing this up

 

[Reverend]

sireric (ATI) has told us that writing out their internal format to 128b (FP32) and reading it back in as a texture 'causes no precision loss'.

Eric said that?

 

[digitalwanderer]

can accept FP32 requests but just converts them to FP24 correct?

Correct. The texture address (data input if you wish) can be FP32, but is converted to an ATI 'internal' FP24 during the pixel shader calculations. The R3x0 can expand the result from the pixel shader up to FP32 data afterwards, however.

sireric (ATI) has told us that writing out their internal format to 128b (FP32) and reading it back in as a texture 'causes no precision loss'.

Does it cause a performance hit?

 

[LeStoffer]

Eric said that?

Yeah. The comment is over a year old and I'm not sure why I came by the thread, but here it is:

http://216.180.225.194/~beyond3d/forum/viewtopic.php?t=1902

Look towards the end for Erics nice inside information.

 

[Reverend]

Eric said that?

Yeah. The comment is over a year old and I'm not sure why I came by the thread, but here it is:

http://216.180.225.194/~beyond3d/forum/viewtopic.php?t=1902

Look towards the end for Erics nice inside information.

From the link and for the record, sireric actually said this :

In the same way, when reading a full 128b (4x32b SPFP) per texel texture, we convert the external format to our internal format. Writing out our internal format to 128b and reading it back in as a texture causes no precision loss.

In my experience, sireric's last sentence (when taking into account his first) is not true, if he meant it to mean all absolute cases.

 

[Ilfirin]

Those look like 2 independent statements to me:
(1) The r300 can read FP32 textures, but the data is converted to FP24
(2) The r300 can write to FP32 textures at FP24, and load the data back in at no precision loss (as would be expected).