Am 06.07.2014 13:58, schrieb Thorsten Froehlich:
> clipka <ano### [at] anonymousorg> wrote:
>> Am 02.07.2014 18:44, schrieb Le_Forgeron:
>>
>>> Rendering benchmark gives the attached pictures (the icpc seems ok,
>>> within usual time, but gcc is bogus and too fast, far too fast)
>>
>> I finally found out what's going on here.
>>
>> The implementation of adaptive area lights uses an N*M cache for
>> "lightlet" data it has already computed. Previously, yet-uncomputed data
>> was flagged by setting the respective colour's red channel to -1. I had
>> changed this to use a NaN ("Not-a-Number") value instead, to avoid
>> problems when a user deliberately sets a light source's colour to
>> negative red.
>>
>> Now of course this NaN value has to be tested for; according to IEEE
>> standard, a NaN value has the property that it is non-equal to anything,
>> even itself. So I wrote the test: "if (red != red)...".
>>
>> Well, it turns out that the g++ compiler optimizes this comparison away
>> when in "-ffast_math" mode.
>
> Use std::isnan - it works because IEEE 754 and C++ floats are not exactly the
> same, and for most practical purposes NaNs will have a valid and identical
> storage in memory. Be aware that NaNs and Infinites may raise exceptions
> regardless though.

std::isnan() is not a universal solution either, as it's not C++(03) 
standard; for instance, Microsoft Visual C++ doesn't have it (it has an 
_isnan() function instead). And I haven't tested whether it actually 
solves the problem - according to the gcc documentation, -ffast_math 
means that the compiler doesn't know anything about infinities and NaNs 
at all, and the std::isnan function might just as well always return false.

So while it is now clear what's happening, this is not solved yet, so I 
have my work cut out for me tonight.

Post a reply to this message