FP16 and market support

[radar1200gs]

The return of S3
http://www.extremetech.com/print_article/0,3998,a=114848,00.asp

... The most interesting data point by far is the DX9 floating-point precisions supported by the S8: FP16 and FP24. Recall that DX9 has what are called Partial Precision Hints, which an application can send down to a GPU driver along with a pixel shader program. These hints tell the driver that lower floating-point precision (FP16) will be adequate to correctly execute the pixel shader program, and not introduce any visual artifacts, such as banding, as a result of rounding errors. For pixel shader programs that require higher FP precision, the S8 will use FP24, which is the same precision supported by ATI's DX9 GPUs. ...
... In many ways, S3 design decision here makes some sense given where we are in the evolution of floating-point shader programs. For shorter programs that don't require higher precision, S3 gains the advantage of being able to run FP16 just like nVidia. And for those shader programs that require higher precision, S3 then uses FP24 just like ATI. So the design seems to be the best of both worlds. Are there mathematical differences between results obtained using FP24 versus FP32 precisions? Yes. Will those differences be visually apparent in shader programs being used in current-generation and near-term future games? In all likelihood, no.

Notice that out of the 3 true DX9 architectures available (nVidia, S3 & ATi) 2 of the 3 support FP16 while 1 does not.

Futuremark is going to have to patch 3DMARK03 to allow for partial precision (something that should have been in the benchmark from the start), since more DX9 architectures than not support it and can benefit from its use.

The same thing goes for game developers. In the real world, most DX9 class chips sold to consumers will support FP16 and developers will ignore it and the potential performance increases at their peril.

 

[nelg]

The same thing goes for game developers. In the real world, most DX9 class chips sold to consumers will support FP16 and developers will ignore it and the potential performance increases at their peril.

If you discount the low end nV3x cards, as games will probably treat them as Dx8 class anyway, this may not be the case. Xbit labs recently made mention of how ATI had ~85% of the mid to high range market.

 

[reever]

XGI uses fp24, but spam more boards on your little crusade here

 

[YeuEmMaiMai]

the reason Nvidia has to use FP16 is becuase their hardware cannot deliver FP32 at sufficient speed. S3 is using approximately 1/2 the transistor count but offers excellent DX9 performance for the price...S3 never claimed FP32 support, they only promised to follow the DX9 spec and by the looks of things they are.......

So do us all a favor and be quiet about FP16 the only reason that MS included it was becuase Nvidia was crying like the little 2 year old kid that they are.

The return of S3
http://www.extremetech.com/print_article/0,3998,a=114848,00.asp

... The most interesting data point by far is the DX9 floating-point precisions supported by the S8: FP16 and FP24. Recall that DX9 has what are called Partial Precision Hints, which an application can send down to a GPU driver along with a pixel shader program. These hints tell the driver that lower floating-point precision (FP16) will be adequate to correctly execute the pixel shader program, and not introduce any visual artifacts, such as banding, as a result of rounding errors. For pixel shader programs that require higher FP precision, the S8 will use FP24, which is the same precision supported by ATI's DX9 GPUs. ...
... In many ways, S3 design decision here makes some sense given where we are in the evolution of floating-point shader programs. For shorter programs that don't require higher precision, S3 gains the advantage of being able to run FP16 just like nVidia. And for those shader programs that require higher precision, S3 then uses FP24 just like ATI. So the design seems to be the best of both worlds. Are there mathematical differences between results obtained using FP24 versus FP32 precisions? Yes. Will those differences be visually apparent in shader programs being used in current-generation and near-term future games? In all likelihood, no.

Notice that out of the 3 true DX9 architectures available (nVidia, S3 & ATi) 2 of the 3 support FP16 while 1 does not.

Futuremark is going to have to patch 3DMARK03 to allow for partial precision (something that should have been in the benchmark from the start), since more DX9 architectures than not support it and can benefit from its use.

The same thing goes for game developers. In the real world, most DX9 class chips sold to consumers will support FP16 and developers will ignore it and the potential performance increases at their peril.

 

[gkar1]

Exactly my thoughts, the perils are for the hardware manufacturers who don't follow the spec by offering lower than required precission.

 

[StealthHawk]

Notice that out of the 3 true DX9 architectures available (nVidia, S3 & ATi) 2 of the 3 support FP16 while 1 does not.

Futuremark is going to have to patch 3DMARK03 to allow for partial precision (something that should have been in the benchmark from the start), since more DX9 architectures than not support it and can benefit from its use.

The same thing goes for game developers. In the real world, most DX9 class chips sold to consumers will support FP16 and developers will ignore it and the potential performance increases at their peril.

There are 3 IHVs that have DX9 boards available (ATI, NVIDIA, XGI), and out of those, 2 of the 3 do not support FP16 while only 1 does.

In the coming months with 4 DX9 architectures, 2 will support FP16, and 2 will not. 3 support FP24 while 1 does not.

 

[radar1200gs]

The XGI/Volari solution is a complete and utter joke.

Only those who sincerely believed bitboys would take over the 3d world will take this chipset seriously.

So as far as I'm concerned there are currently 3 viable DX9 architectures out there.

as for the FP32 comment, full precision does not have an exact value in DX9 - it can be anything from FP24 on up. FP32 is > FP24.

 

[reever]

The XGI/Volari solution is a complete and utter joke.

Of course, instead of admitting your mistake you just gloss over the facts, whatever serves your personal agenda better

 

[radar1200gs]

The XGI/Volari solution is a complete and utter joke.

Of course, instead of admitting your mistake you just gloss over the facts, whatever serves your personal agenda better

I made no mistake.

I was aware of xgi/volari well before starting this thread.

I stand by my original post.

 

[KimB]

the reason Nvidia has to use FP16 is becuase their hardware cannot deliver FP32 at sufficient speed.

The reason that nVidia chose to expose FP16 was because they wanted to allow higher speeds. They decided that the vast majority of calculations will not need higher than FP16 precision (which is true if the vast majority of shaders are relatively short and/or aren't prone to recursion artifacts, and most calculations are on color data).

The support of FP16 was a design decision, and wasn't an inherently bad one. It did buy nVidia higher-precision FP support, after all. And FP16 is enough precision and dynamic range for any color calculations (where recursion artifacts aren't a major problem).

 

[Althornin]

I made no mistake.

Notice that out of the 3 true DX9 architectures available (nVidia, S3 & ATi) 2 of the 3 support FP16 while 1 does not.

Huh, i guess "True DX9" means "fits radar1200gs's obvious and blindly fanatical hugely biased posting agenda".

 

[Althornin]

The reason that nVidia chose to expose FP16 was because they wanted to allow higher speeds. They decided that the vast majority of calculations will not need higher than FP16 precision (which is true if the vast majority of shaders are relatively short and/or aren't prone to recursion artifacts, and most calculations are on color data).

The support of FP16 was a design decision, and wasn't an inherently bad one. It did buy nVidia higher-precision FP support, after all. And FP16 is enough precision and dynamic range for any color calculations (where recursion artifacts aren't a major problem).

whatever.
Strange how ATI managed to get FP24 AND high speed. Strange how you used to boast about nVidias FP16, how it was gonna be so much faster than ATI and the FP32 was gonna be as fast....then the nv30 comes out and all yoru arguments change. Every time you do this, i will mention it.

 

[KimB]

whatever.
Strange how ATI managed to get FP24 AND high speed. Strange how you used to boast about nVidias FP16, how it was gonna be so much faster than ATI and the FP32 was gonna be as fast....then the nv30 comes out and all yoru arguments change. Every time you do this, i will mention it.

*sigh* My arguments on the speed of the NV30 were more based on process and release timing than precision support.

And there are so many other differences between the architectures that one cannot single out FP24 vs. FP32 support as the reason for the performance differences.

The fact remains that the NV30 gains performance when using FP16. If nVidia only supported FP32, or even FP24, it might have been even slower in the end (than it is now with mixed FP support). My point is that FP16 is plenty for many calculations, and the support of FP16 should not be seen as a drawback of the NV3x architecture.

 

[sonix666]

Chalnoth, just ignore this thread. I find it awkward how much non-regulars start to appear in any thread that starts to be a flame.

 

[StealthHawk]

The XGI/Volari solution is a complete and utter joke.

What pray tell makes DeltraChrome less of a joke?

So as far as I'm concerned there are currently 3 viable DX9 architectures out there.

Problem: DeltraChrome isn't "out there" yet and won't be for months.

 

[Reverend]

Futuremark is going to have to patch 3DMARK03 to allow for partial precision (something that should have been in the benchmark from the start), since more DX9 architectures than not support it and can benefit from its use.

I can't speak for FM but IMO such a patch has as much chance of happening as NVIDIA and ATI merging before the next 3DMark appears.

Better that we talk about the next 3DMark regarding this though...

The same thing goes for game developers. In the real world, most DX9 class chips sold to consumers will support FP16 and developers will ignore it and the potential performance increases at their peril.

So... you're saying you're recommending developers to have "fallback" precisions while wanting to "push the envelope", solely because of market (=$$$) reasons? I'm sure developers don't already know that

 

[KimB]

Anyway, just wanted to say:

Now that we have some released drivers that support GLSL, I can't wait to see what sorts of benchmarks come to the table. GLSL provides some very interesting problems as well as opportunities. This will be a very exciting time, almost as exciting to me as the release of a new architecture

Hopefully nVidia will follow very quickly with some GLSL drivers of their own, though I do expect it to be a couple of driver releases before they get their performance up to par (mostly, I expect it to be decent out of the gate for many situations, but many other situations will just perform unexpectedly badly, even though you'd think they really should run fine on the hardware). That shouldn't affect most people, of course, since GLSL won't be used for some time in games.

It will be interesting to see how challenging it is for developers to avoid making disastrous performance mistakes. Since GLSL is another step removed from the hardware, it won't be as obvious by examining the code that it will perform horribly on some hardware. I'm sure this will take some getting used to by developers, and it shouldn't be insurmountable.

It will also be interesting to see how quickly nVidia's drivers get up to par in performance, compared to their current OpenGL and Direct3D drivers (i.e. comparing to a similar program in D3D HLSL or Cg).

 

[radar1200gs]

Futuremark is going to have to patch 3DMARK03 to allow for partial precision (something that should have been in the benchmark from the start), since more DX9 architectures than not support it and can benefit from its use.

I can't speak for FM but IMO such a patch has as much chance of happening as NVIDIA and ATI merging before the next 3DMark appears.

Better that we talk about the next 3DMark regarding this though...

The same thing goes for game developers. In the real world, most DX9 class chips sold to consumers will support FP16 and developers will ignore it and the potential performance increases at their peril.

So... you're saying you're recommending developers to have "fallback" precisions while wanting to "push the envelope", solely because of market (=$$$) reasons? I'm sure developers don't already know that

Oh, I don't know, futuremark have seemed to be quite prolific with their patches up until now. Of course fully supporting all the features of something you are trying to test is never a bad idea either (partial precision IS a part of DX9).

 

[Reverend]

Changing precision is not an easy thing to do when you're talking about a whole application.

The patches to 3DM03 that FM has done are extremely easy by comparison when you're talking about what those patches are. Re-ordering and changing instructions are much easier than changing changing precision.

In case you don't know, of course.

 

[Hanners]

Oh, I don't know, futuremark have seemed to be quite prolific with their patches up until now.

Not for the purpose of adding features or changing the dynamic of the benchmark though.