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

I wrote a shader to test R300's mantissa, and I found that it is 16 bits (not counting sign bit). So I guess R300's FP24 is s16e7?

My friend tested the same shader on NV30 and found out that its mantissa is 10 bits. So I think the shader is correct...
 
Remember that in IEEE-like formats, the most significant bit of the mantissa is not stored explicitly, because it is known to be always 1. Also, have you verified that the shader isn't sensitive to rounding issues?
 
I assumed that all FP have implicit one. However, I am not sure about the rounding mode (toward +inf can be problematic). I'll check it later at home.
 
cho said:
http://www.gzeasy.com/Ours/cho/compare-gt4.rar

i use the DX9 SDK Reference Rasterizer/R300 + 7.83/NV30+42.72/NV30+42.82 to render same frame .

check it please~(the DX9 SDK Reference Rasterizer need 8~10hours to render one frame of game4 ...wooo !! :)

thanks alot.
 
Thanks a lot cho.

First look:

There are slight discrepancies to the refrast in every pic, but as most of them are "single pixel errors" I guess these are just slight differences in sample positions? The seed values seem OK to me.

The R300 comes fairly close to the refrast. There are slight differences in the riverbed stones and the water. Overall the pic is IMO a nuance darker.

The NV30 42.72 has obviously lost a bright sun. The waterbed differences are similar to R300 but the waterline seems to be lower.
The grass in the background seems to look different because of the lighting issue.
With the 42.82 drivers everything seems to be OK. This looks pretty much like the R300 pic with the same (little) differences compared to the refrast.


Cho, do you have some performance numbers?
 
I modified my shaders to avoid rounding mode affecting the result. However, I still get 16 bits mantissa on a R300. (23 bits for REF)

The primary part of the shader looks like this:

mul r0, r0, c2 // r0 = r0 * 0.5 (r0 initialized to 0.5)
add r1, r0, c0 // r1 = r0 + 1 (c0 = 1)
sub r1, r1, c0 // r1 = r1 - 1
sub r1, r1, r0 // r1 = r1 - r0
max r1, r1, -r1 // r1 = abs(r1)
cmp r2, -r1, c4, r2 // r2 = (-r1 >= 0) ? c4 : r2 (c4 is the "bit number")

It is parallelized so it requires 6 iterations for 24 bits.
 
cho said:
http://www.gzeasy.com/Ours/cho/compare-gt4.rar

i use the DX9 SDK Reference Rasterizer/R300 + 7.83/NV30+42.72/NV30+42.82 to render same frame .

check it please~(the DX9 SDK Reference Rasterizer need 8~10hours to render one frame of game4 ...wooo !! :)

thx Cho!
though i am unable to download the file :(
trying now for the 3rd time....

And 10 hours! Wohooo... wouldnt have thought that it would take so long.
Reminds me of my first 3D-Raytracing experience on my Amiga with 6.8MHz and 4096 colors. Took 2 days sometimes for 1 picture..... seems i am totally off-topic now.... sorry....
 
2B-Maverick said:
And 10 hours! Wohooo... wouldnt have thought that it would take so long.
Reminds me of my first 3D-Raytracing experience on my Amiga with 6.8MHz and 4096 colors. Took 2 days sometimes for 1 picture..... seems i am totally off-topic now.... sorry....

my cpu is athlon xp 2700+ and the motherboard is nforce2 .
 
You know what? That's really sad. The NV30 emulation is many times faster. Takes a few seconds to render a frame in the Dawn demo.
 
Yes, it is OpenGL only, which makes it pointless for this purpose.

I was just stating that it's rather sad that Microsoft's reference rasterizer is so slow.
 
Chalnoth said:
Yes, it is OpenGL only, which makes it pointless for this purpose.

I was just stating that it's rather sad that Microsoft's reference rasterizer is so slow.

Well, that's not quite fair, considering that the reference rasterize presumably uses ZERO hardware accleration, and nVidia's "emulation" drivers still use the Geforce cards for a lot of it.
 
True, but it still seems like such a humungous difference. After all, since the fragment programs must be done in software, which requires that all of the T&L portion be done in software, how much can be done in hardware?
 
I'm willing to bet that the NV30 "emulation" drivers don't actually produce the exact results that the NV30 produces as well.

I think the important thing with the NV30 emulation drivers, was mostly to get people to start writing NV30 code that "works", so that when the NV30 came out (er...comes out?) they already had experience "coding" for it. Not really important that the emlation drivers produced the exact output of NV30.

In other words, I bet there's much more "hardware accleration" in the NV30 emulation than you suspect.
 
I would tend to doubt it. For one, the lack of high dynamic range would become quite obvious for NV_fragment_program shaders. I would tend to bet that the only primary differences noticeable would be the lack of FSAA and anisotropic filtering.
 
The Radeon and Reference image look identical.

Clearly, the "sky" (rendered using PS 2.0) on the GeForceFX pictures is not correct.

What we need now is for someone to run "non 3DMark optimized" (slow) drivers for the FX, and see what the sky looks like.
 
Now you mention it the sky seems duller on the GFFX pic however I dont see the differences elsewhere (until someone points them out to me :p)

The Radeon and Reference Image look about as different to each other than the GFFX to Reference Image to my eyes. The leaf on the left looks different but the GFFX has its edges most similar to the Rasterized (Rastered??) Image.
 
Back
Top