Nvidia, Floating Point Blending and 'Errors'

[pocketmoon66]

Another interesting snippet that came back to me. May be better off in the coding section but hey, lets start here

Nvidia said they had been looking at problems reported with demo's using FP blending, such as debervec's HDR demo. They were getting reports of all black or white screens. Turns out that NV handle floating point errors such as divide by zero, more fully than others. They have proper values for NAN, -inf and +inf. IIRC NAN & -inf displays as black, +inf displays as white, and they follow the IEEE convention of what you get when multiplying by NAN or Infinity etc.

With HDR demo's there's a lot of downsampling that occurs, even down to 2x2 to get the overall scene brightness (farcry HDR inckuded). This has the effect of propogating NAN's or infs throughout the buffer resulting in all black/white output.

The message was : Handle things like /0 correctly

 

[Dave Baumann]

I understood the issue was that they could never represent 0 (although I can't remember if that was NV2x specific or not), whereas others can.

 

[pocketmoon66]

I understood the issue was that they could never represent 0 (although I can't remember if that was NV2x specific or not), whereas others can.

Hmm... The NV dev guys where quiet precise on this one. The fp exceptions spread, so while other cards may give 0*inf as 0, Nvidia would give it as inf or nan (cant remember which). So, the exceptions spread throughout the buffer as you blend e.g error * +0.5 still equals error. If your hardware just sticks zero (or whatever) in instead of a true error value then you get 0 + 0.5 = 0.5

When my PNY GT turns up tomorrow (to replace the BORKED leadtek card) I'll give it a try

I've certainly coded OpenGL demo's on NV30 hardware that handled zero values fine in FP buffers.

cheers,

Rob

 

[Simon F]

Hmm... The NV dev guys where quiet precise on this one. The fp exceptions spread,

That is what happens with IEEE behaviour.

so while other cards may give 0*inf as 0,

Older DX specs had things like 0* anything giving zero..

Nvidia would give it as inf or nan (cant remember which).

IEEE says 0*Inf is a NAN. NonZero*INF is INF and 0* anything else is 0.

OH... and "Nan OP anything" etc is always a NaN.

 

[bloodbob]

The didn't used to do this a while ago one of humus' demos had problems because Nvidia didn't handle divided by zero properly or something ( it was his text renderer ).

What should MS really do about float blending and NAN/INF? should they stick with the IEEE or should they say replace INF with MAX FLOAT?

 

[pocketmoon66]

What should MS really do about float blending and NAN/INF? should they stick with the IEEE or should they say replace INF with MAX FLOAT?

Tricky one .Having the errors handled the IEEE way should be beneficial in the long run - you can get your shaders right BUT then again sometimes it's just damn usefull to throw a /0 in there and be able to ignore the result

 

[Gubbi]

Saturating divide by zero is a can of worms.

x / 0+ -> INF
x / 0- -> -INF

So even though the divisor is the same numerical value you flip between two extremes.

If the developer could configure exception behaviour (ie. specify saturation values for different exceptions) that would probably be preferably. But exception handling is going to cost.

Cheers
Gubbi

 

[Simon F]

Saturating divide by zero is a can of worms.

x / 0+ -> INF
x / 0- -> -INF

So even though the divisor is the same numerical value you flip between two extremes.

If the developer could configure exception behaviour (ie. specify saturation values for different exceptions) that would probably be preferably. But exception handling is going to cost.

Cheers
Gubbi

Isn't there an "abs" modifier these days? That would clean up those sorts of problems. Anyway, division by zero is bad and shouldn't be in people's code, IMHO, of course.

 

[darkblu]

Saturating divide by zero is a can of worms.

x / 0+ -> INF
x / 0- -> -INF

So even though the divisor is the same numerical value you flip between two extremes.

If the developer could configure exception behaviour (ie. specify saturation values for different exceptions) that would probably be preferably. But exception handling is going to cost.

Isn't there an "abs" modifier these days? That would clean up those sorts of problems. Anyway, division by zero is bad and shouldn't be in people's code, IMHO, of course.

now, now. division by zero is bad in real math terms. OTH, in not so real terms (as in 'real'-like arithmetics provided by the fpu) you could get a zero quantity out of mere inadequate precision (i.e. underflow), in which case the best you can do is to honor it; a division of a regular number by an underflow produces an overflow, signed at that -- the hw did its best to provide you with the full info from the op. i personally believe this has its rightful application in HDR techniques.

 

[pocketmoon66]

Anyway, division by zero is bad and shouldn't be in people's code, IMHO, of course.

I think thats what Nvidia told Paul Debervec

 

[trinibwoy]

Tricky one .Having the errors handled the IEEE way should be beneficial in the long run - you can get your shaders right BUT then again sometimes it's just damn usefull to throw a /0 in there and be able to ignore the result

Would there ever be a situation where NaN or infinity would be useful? Also, what would be the potential issues associated with making inf*0 = 0?

 

[ERP]

Mostly Nan and Inf are useful for knowing you did your numeric analysis wrong.

I was most displeased when I first started working on Xbox and discovered that X86's don't just throw an exception and stop when they generate inf or Nan.

NaN's are like virus' they are just plain evil by the time you spot one it's usually thousands of instruction after where you screwed up and every variable it touched has been converted to NaN so you have no useful debugging info.

Personally I prefer getting the NaN'a and Inf's in the frame buffer, at least I know there's a problem.

 

[radar1200gs]

I think you will find nVidia's/ IEEE's way to be the correct way. What follows is an excerpt from Microsofts WinHEC powerpoint presentations regarding Longhorn.

Windows Graphics Foundation
TW04079_WINHEC2004.ppt

Slide 8
Heavy emphasis on arithmetic rules points way towards CPU/GPU load-sharing

Slide 11
IEEE compliance for floating point

 

[trinibwoy]

NaN's are like virus' they are just plain evil by the time you spot one it's usually thousands of instruction after where you screwed up and every variable it touched has been converted to NaN so you have no useful debugging info.

Sounds like some serious suckage. And I complain when I have to find a Null Pointer exception in Java

 

[aaronspink]

Nvidia said they had been looking at problems reported with demo's using FP blending, such as debervec's HDR demo. They were getting reports of all black or white screens. Turns out that NV handle floating point errors such as divide by zero, more fully than others. They have proper values for NAN, -inf and +inf. IIRC NAN & -inf displays as black, +inf displays as white, and they follow the IEEE convention of what you get when multiplying by NAN or Infinity etc.

The message was : Handle things like /0 correctly

Seems like people have been snorting at the tree of IEEE FP too much. For something like graphics, you probably do not want IEEE FP and want more of the generally available partial IEEE FP implementation available.

On Div by 0, the card and driver should error out.
On generation of NAN, they should error out.
On underflow, they should flush to zero.

In the alternative, you should implement saturation FP in which Div by 0 results in Num(Max).

Aaron Spink
speaking for myself inc.

 

[aaronspink]

I think you will find nVidia's/ IEEE's way to be the correct way. What follows is an excerpt from Microsofts WinHEC powerpoint presentations regarding Longhorn.

I think you'll find a lot of disagreement on this from the vast majority of users who give a damn.

IEEE FP is Kahan's wet dream, but pointless and impracticle. There is no point in continuing with a calculation when you have started to propogate NaN's. Most advances design's with simply trap on the generation of an NaN and any Inf. This allow much easier debugging of the code.

For something like computer graphics though, the best solution is to implement saturating FP in which INF is set equal to Max_Num, Anything * 0 = 0, and NaNs don't exist.

That or a proper error reporting and handling system needs to designed and implemented in DX_Next. Which is rather unlikely.

Aaron Spink
speaking for myself inc.

 

[Xmas]

I very much prefer configurable behavior over "error out" (discard pixels?)

 

[Dio]

There is no point in continuing with a calculation when you have started to propogate NaN's.

But there's no point in starting a calculation that generates one.

And "I didn't know it was going to" is not an answer. Coders should know when their code might generate NaN's and avoid them.

 

[KimB]

Personally, I think we should be asking less about what is best for graphics (to NaN or not to NaN), and more what possible algorithms could produce saturation across an entire frame??

 

[Humus]

But there's no point in starting a calculation that generates one.

And "I didn't know it was going to" is not an answer. Coders should know when their code might generate NaN's and avoid them.

The problem with that is that it can be quite expensive to handle division by zero cases. If you instead generate MAX_FLOAT, chances are you'll get a useful enough value so that you don't have to do any extra math just to avoid getting artifacts. Say you're doing a simple projection for a spot light. Somewhere there's going to be a line of division by zeros. If I can just mask away this area along with backlighting the problem goes away. Cheap and easy. If on the other hand I'm getting NAN or INF the artifacts remain and I'll have to explicitely take care of it, unneccesarily wasting computing power.
It seems lot of people see IEEE as the golden standard to reach for. I see IEEE as an old standard with little to no use it practice typically generating more problems than it solves. It's hardly useful on CPUs, but I can live with it. But on GPUs I just don't want it there. A waste of silicon that's making our lives harder.