Re: [glean-dev] catching FP exceptions in C++

[Keith W. <ke...@tu...>]

Brian Paul wrote:
> Keith Whitwell wrote:
> 
>> Brian Paul wrote:
>>
>>> Keith Whitwell wrote:
>>>
>>>> Brian Paul wrote:
>>>>
>>>>> Allen Akin wrote:
>>>>>
>>>>>> On Tue, Nov 08, 2005 at 04:08:19PM -0700, Brian Paul wrote:
>>>>>> | I'm going to be writing a new glean test to see how OpenGL 
>>>>>> handles | infinite/nan/denorm/etc floating point values.
>>>>>>
>>>>>> You're a braver man than I am. :-)
>>>>>>
>>>>>> | My experience with exception handling in C++ is pretty slim and 
>>>>>> I'm | not even sure if there's a standard way to handle them.
>>>>>>
>>>>>> I'm not either.  I've checked my printed references and done a few 
>>>>>> web
>>>>>> searches, and I haven't found anything that claims to work 
>>>>>> universally.
>>>>>>
>>>>>> I suspect the most portable thing we could do would be to use the C99
>>>>>> standard IEEE exception mechanism.  (See "man fetestexcept", 
>>>>>> etc.)  It
>>>>>> depends on the ANSI C signal-catching utilities, but nothing
>>>>>> *nix-specific as far as I can tell.
>>>>>>
>>>>>> However, I don't have any experience with it, so I don't know for 
>>>>>> sure
>>>>>> that it'll do the job.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Thanks, Allen.  I wasn't even aware of those functions.
>>>>>
>>>>> I'm checking in what I have so far.  There's no attempt at trapping 
>>>>> exceptions yet.
>>>>>
>>>>> Both Mesa and NVIDIA's driver pass the test in that FP exceptions 
>>>>> aren't raised by default.  If I enable FP exceptions in Mesa with 
>>>>> export MESA_DEBUG=FP things blow up as soon as I do this assignment:
>>>>>
>>>>> 285:        v[1][0] = make_signaling_nan();
>>>>>
>>>>> I guess the various make_*() functions should take a pointer to the 
>>>>> destination float and store the bit pattern as an integer to avoid 
>>>>> blowing up in Glean before we even get into OpenGL.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> It does make me question whether having the traps enabled is going 
>>>> to work - if you can't even handle the values without provoking an 
>>>> exception, it would mean that all the gl entrypoints will also 
>>>> provoke the exceptions.  You may get out of glean, but you'll get 
>>>> caught in the libGL.so dispatch functions...
>>>
>>>
>>>
>>>
>>> I was thinking about that too.
>>>
>>> Here's a sneaky approach: only enable exceptions before calling 
>>> glEnd.  In Mesa (and probably other OpenGLs) we don't actually do 
>>> anything with the vertex data until glEnd, or some other state-change 
>>> command.
>>>
>>> If exceptions are enabled at that point, only the exceptions 
>>> generated inside OpenGL should get caught.
>>
>>
>>
>> If this is to be the case, GL will have to examine every floating 
>> point input for NaN and/or Inf, and take some action if appropriate.  
>> Is that the specified behaviour?  What should be done if someone 
>> passes an Inf or NaN in a matrix or light parameter?
>>
>> I'm not sure that we should be trying to move towards a GL that 
>> religiously guards against these values entering inside it, and then 
>> equally religoiusly guards against their ever being created 
>> internally.  But I do want to make sure that they are coped with 
>> appropriately, which I felt meant that the library should function, 
>> perhaps with undefined results, but without crashing.  I would qualify 
>> that by saying that turning fp exceptions on isn't fair game...
>>
>> Of course if the GL spec says "you shall never create a NaN floating 
>> point value" or "you shall never create an Inf", and "you shall never 
>> load a user-supplied floating point value into the FPU without 
>> checking if it is an inf or nan", that's a different matter...
>>
>> It seems like the implementation cost of that would be pretty high, 
>> and I don't know if it would be a sensible thing to do, or what would 
>> motivate such a requirement.
>>
>> I would however like to see some confidence that, eg. passing inf/nan 
>> vertex values doesn't cause the rasterization engine to blow up and 
>> segfault, etc.
>>
>> Maybe this is more like a "crashme" test where we write an application 
>> that deliberately does random nasty stuff to GL in the hope of causing 
>> a failure rather than something which belongs in a visual correctness 
>> test like glean?
> 
> 
> The OpenGL spec says that even if NaN, infinity, etc are passed to 
> OpenGL (or a divide by zero happens) that it "must not lead to GL 
> interruption or termination". (sec 2.1.1)
> 
> Since exceptions are silently ignored by default (on most systems 
> anyway) we can get away with ignoring a lot of potential error 
> conditions.  Still, we do occasionally have to deal with some 
> rasterization overflow/underflow issues, like you mention.  Over the 
> years, I've just been fixing those as they're discovered.

In fact the biggest problems we have (ie Jouk's vax system) arise (I think!) 
because there is no representation for inf or nan on that hardware, and so 
floating point operations which would on an ieee system happily evaluate to inf 
or nan, instead are forced(?) to raise exceptions.  That hardware design 
predates IEEE floating point...

Keith