Nvidia, Floating Point Blending and 'Errors'

[Xmas]

I don't see why you should use MAX_FLOAT instead of INF. At least if INF * 0 = 0.
I agree with darkblu on that point.

 

[radar1200gs]

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.

Lots of standards ar old standards. That does not make them any less useful though.

Microsoft wants IEEE compliance for GPU's (if nothing else it helps system wide hardware abstraction by ensuring all processors use a common, widely accepted format).

As for division by zero, anyone who has done any programming at all knows very well that this is something that simply should not be done in the first instance.

 

[dominikbehr]

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.

this should be some help
http://msdn.microsoft.com/library/d...ore98/HTML/_crt__control87.2c_._controlfp.asp

 

[Humus]

As for division by zero, anyone who has done any programming at all knows very well that this is something that simply should not be done in the first instance.

Anyone who has done any real programming knows what a pain in the ass it is to take care of this special case every time you perform a division. The only problem is that division by zero is undefined in the science of math. That however doesn't mean we can't define it to something useful in programming tasks, rather than spending cycles having to take care of a rare special case.

 

[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.

this should be some help
http://msdn.microsoft.com/library/d...ore98/HTML/_crt__control87.2c_._controlfp.asp

We did this later in development after we discovered that we could.

 

[nutball]

As for division by zero, anyone who has done any programming at all knows very well that this is something that simply should not be done in the first instance.

Anyone who has done any real programming knows what a pain in the ass it is to take care of this special case every time you perform a division. The only problem is that division by zero is undefined in the science of math. That however doesn't mean we can't define it to something useful in programming tasks, rather than spending cycles having to take care of a rare special case.

One mans general case is another mans special case.

Some of the compilers I've worked with have had quite sophisticated support for dealing with FP exceptions, configurable behaviour for value replacement when FP ops generate Inf/NaN, etc, or have flags to auto-detect division-by-zero, etc.

 

[pocketmoon66]

Anyone who has done any real programming knows what a pain in the ass it is to take care of this special case every time you perform a division. The only problem is that division by zero is undefined in the science of math. That however doesn't mean we can't define it to something useful in programming tasks, rather than spending cycles having to take care of a rare special case.

Humus flying his flag

In 'real' programming can you imagine how hard it would be to debug an application if it didn't trap fp exceptions such as div0 but rather just set the result to 'something useful' ?

 

[Simon F]

As for division by zero, anyone who has done any programming at all knows very well that this is something that simply should not be done in the first instance.

Anyone who has done any real programming knows what a pain in the ass it is to take care of this special case every time you perform a division. The only problem is that division by zero is undefined in the science of math. That however doesn't mean we can't define it to something useful in programming tasks, rather than spending cycles having to take care of a rare special case.

But Humus, what if HW vendor X's decision on what to do with division by zero is not one you want? AFAICS it's up to the programmer to put in the handling that they want. Personally I think the IEEE behaviour is fairly sensible in this respect. I'm not that keen on its denormalised numbers but that's a different issue.

 

[Drak]

Anyone who has done any real programming knows what a pain in the ass it is to take care of this special case every time you perform a division. The only problem is that division by zero is undefined in the science of math. That however doesn't mean we can't define it to something useful in programming tasks, rather than spending cycles having to take care of a rare special case.

If you don't want to deal with division by zeros, you can condition your division by adding epsilon to your divisor. If you do want to deal with them, you can let the Infs/NaNs propagate and trace them back.

It would be nice if we had fast functions to set NaNs/Infs in the framebuffer/rendertextures to some specified value such a 0.

 

[Rasmoo]

If you don't want to deal with division by zeros, you can condition your division by adding epsilon to your divisor. If you do want to deal with them, you can let the Infs/NaNs propagate and trace them back.

It would be nice if we had fast functions to set NaNs/Infs in the framebuffer/rendertextures to some specified value such a 0.

Yikes! It begins to sound worse than handling the special cases.

Wouldn't it be much better to have some sort of cheap exception handling rather than polluting your code?

 

[nutball]

If you don't want to deal with division by zeros, you can condition your division by adding epsilon to your divisor.

This works fine until you try this with a denominator that happens to be -epsilon.

 

[Simon F]

If you don't want to deal with division by zeros, you can condition your division by adding epsilon to your divisor.

This works fine until you try this with a denominator that happens to be -epsilon.

But in terms of graphics algorithms, where are you going to have division by zero?

Projection? That's handled by doing clipping against the frustum and is generally hardwired in so is a non-issue.

Lighting calcs where the light gets too close? Since that's computing a distance, the value will always be positive and so the epsilon trick should be ok. (In fact, it's probably necessary for realistic modelling since you wouldn't have an infinitely bright light anyway... it would have set fire to the material )

Vector normalisation where the vector is zero? Same sort of situation.

I think that, in general, it should be ok.

 

[pocketmoon66]

But in terms of graphics algorithms, where are you going to have division by zero?

Wel the NV devs were talking about HDR at the time...

 

[Drak]

If you don't want to deal with division by zeros, you can condition your division by adding epsilon to your divisor.

This works fine until you try this with a denominator that happens to be -epsilon.

I have to admit that I don't usually deal with negative denominators when I'm normalising. Anyway, if that's your cup of tea, take the sign off your denominator, then multiply the end result of the division by the sign.

 

[Drak]

Lighting calcs where the light gets too close? Since that's computing a distance, the value will always be positive and so the epsilon trick should be ok. (In fact, it's probably necessary for realistic modelling since you wouldn't have an infinitely bright light anyway... it would have set fire to the material )

Even dividing by very small fractions may result in huge numbers that may not be very useful depending on what you're computing/modelling.

 

[nutball]

I have to admit that I don't usually deal with negative denominators when I'm normalising. Anyway, if that's your cup of tea, take the sign off your denominator, then multiply the end result of the division by the sign.

Who said anything about normalising?

 

[Simon F]

Even dividing by very small fractions may result in huge numbers that may not be very useful depending on what you're computing/modelling.

Oh I agree completely. I certainly made sure Elan/Naomi2 had lighting parameters that could guard against nasty cases.

 

[Drak]

Who said anything about normalising?

I was sharing my personal experience. I usually have to deal with divide by zero when I'm normalising/rescaling.

Dividing by negative numbers with the epsilon trick is not a biggie.

 

[Drak]

Ooops. Double post.

 

[suicuique]

Anyone who has done any real programming knows what a pain in the ass it is to take care of this special case every time you perform a division. The only problem is that division by zero is undefined in the science of math. That however doesn't mean we can't define it to something useful in programming tasks, rather than spending cycles having to take care of a rare special case.

The division by zero is not a "problem" per se in maths.
That it is undefined is a requirement, not an annoyance,

If you want it to be defined you are begging for *real* problems, as you are throwing the consistency of simple arithmetics out of the window.

If you are dividing by zero you already got your problem. Just setting the result to your liking wont help you there.

Say you set something like real/0 = +-MaxNum (with respect to the signs of real and 0).

How do you trace such an "error"?
What about scientific computing on the GPUs?

IMHO it would be of grave error to throw exception handling of Div/0 out of the window, just because it seems convenient.

regards, alex