3DMark03 Mother Nature IQ comparison b/w FX & R300

[darkblu]

Hmmm I just learn today that M is between 1 and 2. With a signed bit. (For fp32 anyway) So my teacher is wrong?

'between 1 and 2' is actually [1, 2), and 'With a sign bit.' makes that (-2, -1] U [1, 2). so your teacher is not wrong. luckily.

 

[arjan de lumens]

arjan, in all IEEE fp standards and the likes the exponent is taken as unsigned, then biased by half its power (i.e. and 8-bit exponent is taken as unsigned_exp - 128), and the lowest 2-3 values of the exponent usually signify special numbers. so the ranges should be more along the following lines:

Biased by half its power minus 1, so it's unsigned_exp - 127 for single-precision. Exponent with all 0s signify 0 (mantissa == 0) or denormalized numbers (mantissa != 0), all 1s signify Infinities (mantissa == 0) or NaNs (mantissa != 0).

• FP16 - range 2^-14 to 2^16
• FP24 - range 2^-126 to 2^128 (that's was correct)
• FP32 - range 2^-126 to 2^128.
• FP64 - range 2^-1022 to 2^1024.
• FP80 - range 2^-16382 to 2^16384
• FP128 - range 2^-16382 to 2^16384

Wrong. You are not counting in denormalized numbers, which are supported for all formats (except FP24) and are outside the ranges you are giving.

also, keep in mand those ranges should be interpreted as open from both ends (i.e. (a, b)) as the complete exponential formula for a fp number is M * 2^E, where M is (-2, 2), so the range actually is (-2^(max_E + 1), 2^(max_E + 1))

Point taken.

 

[darkblu]

Biased by half its power minus 1, so it's unsigned_exp - 127 for single-precision.

yes, my bad, forgot the 1.

• FP16 - range 2^-14 to 2^16
• FP24 - range 2^-126 to 2^128 (that's was correct)
• FP32 - range 2^-126 to 2^128.
• FP64 - range 2^-1022 to 2^1024.
• FP80 - range 2^-16382 to 2^16384
• FP128 - range 2^-16382 to 2^16384

Wrong. You are not counting in denormalized numbers, which are supported for all formats (except FP24) and are outside the ranges you are giving.

ok, i did omit the denormalized flavor (point taken on my part) but then we don't know how each particular hw handles them - can denormalized values be passed on the input, and are they implicitly normalized on the output.

 

[kyleb]

moo!

 

[andypski]

any chance you can get a 1280x1024 version Reverand? i scaled down the other pics and added that one to the rotation to compare things as fair as i could and got this (blatantly ripping off Rev's clicky trick ):




interesting results, as they both are off in some ways, never mind the aa and af. i am very curious as to see a better comparison and gain an understanding as to why the differences are what they are.

I think that you'll find that the greater texture detail in the FX and 9700 shots is due to the higher resolution of the original captures.

 

[kyleb]

oh ya, there is most defiantly a bit of that. i was speaking more of the position of the leaves/branches that differ between all three of the shots.

 

[Himself]

There is definitely some skew in what frame is being displayed, afaik, FSAA doesn't remove leaves.

 

[andypski]

There is definitely some skew in what frame is being displayed, afaik, FSAA doesn't remove leaves.

The 9700 and FX shots appear to have the leaves in basically the same positions. The leaf/branch positions appear to be generated using some overlapping waveforms, so maybe the seeding is going wrong resulting in different positions?

 

[arjan de lumens]

ok, i did omit the denormalized flavor (point taken on my part) but then we don't know how each particular hw handles them - can denormalized values be passed on the input, and are they implicitly normalized on the output.

IEEE-754 is pretty specific that denormalized numbers must be supported and exactly how they must be treated for full compliance. That said, it's not uncommon for hardware FP units to skimp on the actual implementation:

• NV30 supports denormals for FP16 but not FP32.
• I'm guessing that R300 doesn't support them.
• x87-type FPUs always support them, but they usually come with a substantial performance penalty.
• The 3dNow and SSE extensions to the x86 instruction set generally don't support them; SSE2 allows support to be turned on/off as desired.
• Other processors (Itanium, PowerPC, etc) sometimes have a "Non-IEEE" mode that just flushes denormals to 0 and an "IEEE" mode where denormals cause exceptions and are handled in software.

The usual behavior when not supporting denormals seems to be to treat them as 0 if they appear on inputs, and flush them to 0 if they appear on the output.

 

[Reverend]

OOPS! That wasn't a refrast image! I'll post the actual refrast later.

PS. I'm deleting my post and editing those whose quotes contain the image.

 

[RussSchultz]

I thought it looked too much like the GFFX image.

 

[Reverend]

Actually, it was 9700Pro image that I posted.

 

[kyleb]

doh, considering that i desided to edit my post and also removed the pic from my webspace and will await the refrat image. a 1280x1024 pic would be great if you can swing it Rev.

 

[Mintmaster]

Oops, looks like I made a mistake.

FP24 has 5.2*10^33 times the range of FP16, not 8 times. I thought there was something funny about my answer.

In any case, I think its pretty clear how the step from 16 to 24 is much more significant than the step from 24 to 32.

 

[KimB]

But the range of 16-bit FP is still approximately 0.000015 to 64000 (this is rather rough...and I am purposely only considering positive numbers), and the final display is between 0 and 1. I really do not see how this range can be inadequate for the vast majority of situations when just calculating color.

 

[Dave H]

But the range of 16-bit FP is still approximately 0.000015 to 64000 (this is rather rough...and I am purposely only considering positive numbers), and the final display is between 0 and 1. I really do not see how this range can be inadequate for the vast majority of situations when just calculating color.

Exactly. FP16 should be plenty more than adequate for simple overbright colors. Either the GFfx is using ints instead of FP, or there is some bug somewhere.

 

[Bigus Dickus]

Any chance the NV30 was using the integer units for some reason?

 

[Sharkfood]

Any chance the NV30 was using the integer units for some reason?

Hmmm interesting but a logical theory. Could the difference be simply accuracy truncation and round off? Very interesting indeed.

 

[DemoCoder]

Doubtful. The nature demo isn't doing anything complex enough to run afoul of 10-bit mantissa or 5-bit exponent precision limits. I would suggest that any obvious differences are either the result of different light/camera/surface positions, or driver bugs. In practice, for most shaders, the differences between FP16, FP24, and FP32 will be indistinguishable.

 

[AJ]

IQ discussion is something I haven't been following closely so this might already be on your radar, but here goes anyway: If you have the DX9 SDK installed you can also take a screen capture using the DirectX reference rasteriser. That might be helpful for comparison purposes?

Please note that using the reference rasteriser is _dog_ slow (I dunno why, and our technical guys could give you a better answer anyway ). We ran it a few times to verify that Nature Scene works with it, but it took about 5 hours just to get a single frame out of it so it's best to leave it on for the night and come back in the morning to check out the results.

Cheers,

AJ