FP16 and market support

DaveBaumann said:
a.) Dio's example isn't even a complex case, it basic texturing, so we don't need to look very far at all.

b.) Fairly simple lighting shaders have been shown to have errors with FP16 precision - remember, in this can be lower precision than the FX12 modes available in the original NV30.

Yes, lighting is likely to be where FP16 will most noticeably show its limitations, however you can use FP32/FP24 for lighting and FP16 for all other textures.

Doom3 will be extremely interesting. The entire game is about the lighting system and JC has coded a NV3x path into the game. It will be interesting to see just how large the rendering differences between ATi and nVidia turn out in actual practice.
 
radar1200gs said:
That is a case where FP16 clearly is inadequate. As I said before in the thread, anywhere there is a lot of recursion (and mandelbrots are recursive but their very nature) happening FP16 is likely to be inadequate. That is why FP32 is there - for the cases that FP16 can't handle.

I'd like the critics to show precisely where in a game over the next 18 months or so you would employ a shader with the complexity of a mandelbrot generator.

HDR lighting that is coming with Half-life 2, and how many games will use this engine.

http://www.daionet.gr.jp/~masa/rthdribl/index.html


IMG0006345.jpg
 
radar1200gs said:
Doom3 will be extremely interesting. The entire game is about the lighting system and JC has coded a NV3x path into the game. It will be interesting to see just how large the rendering differences between ATi and nVidia turn out in actual practice.

Doom 3 uses OpenGL 1.4/DX8 class precision (FX12/FX16)...Doom 3 will not show any of the high dynamic range issues that plague the FX cards.
Doom 3 requires a DX7 class 3D card for a majority of its supposed advanced engine features.

The Doom 3 engine is also extremely overy-hyped...and getting dated quickly :!:
 
A bit of an unfair comparison as that demo uses FP render targets for the ATI cards but converts to and from integer targets for NVIDIA cards. Considering the number of passes used (up to 40 with all the effects running), there is always going to be an image difference.
 
Neeyik said:
A bit of an unfair comparison as that demo uses FP render targets for the ATI cards but converts to and from integer targets for NVIDIA cards. Considering the number of passes used (up to 40 with all the effects running), there is always going to be an image difference.

Perhaps, but it goes on to show how Nvidia is stumbling to support standard DX9 features -- FP render-targets.
 
Neeyik said:
A bit of an unfair comparison as that demo uses FP render targets for the ATI cards but converts to and from integer targets for NVIDIA cards. Considering the number of passes used (up to 40 with all the effects running), there is always going to be an image difference.

Unfair ??

:LOL:
 
Unfair because you posted those images in response to a comment about FP16 and associated rendering errors with shaders - those in the rthdribl demo are due to the render target precision not shader precision.
 
Doomtrooper:

First of of all the mandelbrot program is a demo, not a game and a biased one at that.

secondly, you don't know how good or bad NV3x's HDR rendering is since nVidia hasn't exposed the feature in its drivers yet - you are simply hoping it will be bad (I seem to recall 3dfx thinking they had nVidia beat with FSAA too... - never say never).

3rd I was unaware that DX7 supported floating point pixel shading... Doom3 takes advantage of the hardware it runs on and does not necessarily limit itself to a DX7 class feature set contrary to what you would have us believe.
 
radar1200gs said:
secondly, you don't know how good or bad NV3x's HDR rendering is since nVidia hasn't exposed the feature in its drivers yet - you are simply hoping it will be bad (I seem to recall 3dfx thinking they had nVidia beat with FSAA too... - never say never).

HDR is not a feature and as long as FP render targets are concerned, I have read an interview with some Nvidia guy explaining how to do HDR without them so I wouldn't hold my breath...

radar1200gs said:
3rd I was unaware that DX7 supported floating point pixel shading... Doom3 takes advantage of the hardware it runs on and does not necessarily limit itself to a DX7 class feature set contrary to what you would have us believe.

are you serious? from that logic no DX8.1 or less games should run on R3xx because it lacks integer processing. no, doom 3 doesn't take advantage in any way of fp processing, it just uses it as it would use an integer unit. [/b]
 
vb said:
radar1200gs said:
secondly, you don't know how good or bad NV3x's HDR rendering is since nVidia hasn't exposed the feature in its drivers yet - you are simply hoping it will be bad (I seem to recall 3dfx thinking they had nVidia beat with FSAA too... - never say never).

HDR is not a feature and as long as FP render targets are concerned, I have read an interview with some Nvidia guy explaining how to do HDR without them so I wouldn't hold my breath...

I have seen that interview myself. Until the drivers actually support HDR though, its actual form & quality are mere speculation.

radar1200gs said:
3rd I was unaware that DX7 supported floating point pixel shading... Doom3 takes advantage of the hardware it runs on and does not necessarily limit itself to a DX7 class feature set contrary to what you would have us believe.

are you serious? from that logic no DX8.1 or less games should run on R3xx because it lacks integer processing. no, doom 3 doesn't take advantage in any way of fp processing, it just uses it as it would use an integer unit. [/b]

What the hell are you on about? Doom3 does support floating point shaders when they are present in hardware. I was being sarcastic towards doomtrooper who would have believe that just because doom3 has a base feature set centred around DirectX7 class features, they are the only features it will ever employ regardless of the card in use. That is patently wrong (just read some of JC's notes).
 
radar1200gs said:
secondly, you don't know how good or bad NV3x's HDR rendering is since nVidia hasn't exposed the feature in its drivers yet - you are simply hoping it will be bad (I seem to recall 3dfx thinking they had nVidia beat with FSAA too... - never say never).

It is exposed under their OGL extensions, it can't currently be exposed under DX because it doesn't conform to normal DX specifications.

3rd I was unaware that DX7 supported floating point pixel shading... Doom3 takes advantage of the hardware it runs on and does not necessarily limit itself to a DX7 class feature set contrary to what you would have us believe.

Float rendering is unimportant to Doom 3 - the point DT was making is that the fundamental technology behind D3 is "DX7 Class" based, its just achieved via multiple passes. D3 does not have float rendering as a requirement (although it will use whateve precisions are best for the hardware). Things like vector nomralisation are not done via shaders under the N30 path either IIRC.
 
In DOOM3, if you can manage to spot any difference (textures), you'll almost certainly need to run the game in ARB2 mode, and that only on a NV3x... you'll see no difference on a R3x0.

Even then, depending on how dedicated you are in the floating point quality argument you want to undertake just for the sake of it, you'd be hard pressed to say any difference you spot are substantial or important.

DOOM3 is not where the importance of higher precision really matters. Textures hardly are the best example for stressing the importance of FP.
 
are you serious? from that logic no DX8.1 or less games should run on R3xx because it lacks integer processing. no, doom 3 doesn't take advantage in any way of fp processing, it just uses it as it would use an integer unit.
Perhaps you are forgetting NOLF2's problems with R300 when first released and somewhere in these forums there is a post from an ATi employee stating they had to go back and write DX8 drivers for R300.

Not saying this continues to be the case though.
 
radar1200gs said:
are you serious? from that logic no DX8.1 or less games should run on R3xx because it lacks integer processing. no, doom 3 doesn't take advantage in any way of fp processing, it just uses it as it would use an integer unit.
Perhaps you are forgetting NOLF2's problems with R300 when first released and somewhere in these forums there is a post from an ATi employee stating they had to go back and write DX8 drivers for R300.

Not saying this continues to be the case though.

DX9 wasn't released when R300 was out so the shipping drivers were DX8. All the operation are carried out internally at FP precision and converted at input and output to the relevant require precision.

Now, are you going to persist with this pointlessness still? You are not really making any valuabale point here and your just perpetuating a pointless discussion with equally pointless replies.
 
Chalnoth said:
It looked pretty close to me:
Tridam said:
It could be interesting to look at performances of these codes :) HLSL code uses 6 registers and the Cg code only 4. Your HLSL code has 17% less instructions.

...

GeForce FX 5600 HLSL : 11.2 MPix/s
GeForce FX 5600 Cg : 12.4 MPix/s

GeForce FX 5600 HLSL_pp : 14.8 MPix/s
GeForce FX 5600 Cg_pp : 13.8 MPix/s

GeForce FX 5600 HLSL AA/AF : 7.0 MPix/s
GeForce FX 5600 Cg AA/AF : 6.1 MPix/s
Anyway, that was one possibility for a pixel shader. There are others.

Regardless, I don't think Cg is going anywhere. I just hope Microsoft realizes (as they have done many times in the past) that OpenGL is doing things in a much better way.

Heh, leaving out this:
Tridam said:
Radeon 9800 Pro HLSL : 125 MPix/s
Radeon 9800 Pro Cg : 100 MPix/s


25% difference for non-Cg tailored hardware is not close in my book.
 
Ostsol said:
Even if texture filtering were handled by the fragment pipeline, ATI's FP24 and even NVidia's FP16 is more than enough.
I wasn't talking about color blending, but rather texture addressing.
 
radar1200gs said:
Yes, lighting is likely to be where FP16 will most noticeably show its limitations, however you can use FP32/FP24 for lighting and FP16 for all other textures.
Not in the least. FP16 is more than enough for any color data (provided, of course, that we're not talking about a recursive algorithm like rendering a mandelbrot set).

Consider:
With 10 bits of mantissa, which is roughly equivalent to 11 bits of unisgned integer precision (since one bit is always implied), and 5 bits of exponent, FP16 has a full-precision dynamic range of about 65000:1. Since the final output only has a dynamic range of 256:1, you'd have to be exceedingly irresponsible in creating an algorithm that exhausted the precision of FP16 for simple color data.

FP24 and FP32 precision is only required for non-color data (or the obvious situation where recursive errors build too much).
 
Back
Top