Am 02.07.2014 23:56, schrieb clipka:
> Am 02.07.2014 21:43, schrieb Le_Forgeron:
>> Le 02/07/2014 20:49, clipka nous fit lire :
>>> Am 02.07.2014 19:58, schrieb Le_Forgeron:
>>>> Le 02/07/2014 19:37, clipka nous fit lire :
>>>>> Am 02.07.2014 19:23, schrieb Le_Forgeron:
>>>>>
>>>>>>> Can you please give me the output with ">>" corrected to "> >"?
>>>>>>> Thanks a
>>>>>>> lot!
>>>>>>>
>>>>>> Here it is, attached.
>>>>>
>>>>> Thanks. Next incarnation of feature/colour_model is ready for testing.
>>>>>
>>>>
>>>> It's getting bigger (here the clang version, as gcc is above 5M)
>>>
>>> Future versions will be in experimental/colour_model from now on.
>>>
>>
>> Beware, gcc errors once un-bzip2-ed is 1 699 869 bytes long in
>> errorcolor.txt.
>>
>> clang errors in the other file.
>
> I don't really understand why both gcc and clang insist that mColour is
> undefined, when it's a protected member of the publicly inherited base
> class.
>
> Let's see what the latest change does.

I think I got it; the problem is dependent base class name lookup. 
f9d1c6ba should solve the mColour problem, let's see what else crops up.

(I've found by now that the "nasty" part of the "nasty template stuff", 
which I was afraid might not work at all, isn't really that nasty, and 
is actually an established pattern going by the name of "Curiously 
Recurring Template Pattern", aka CRTP.)

Post a reply to this message

Am 03.07.2014 00:30, schrieb clipka:

> I think I got it; the problem is dependent base class name lookup.
> f9d1c6ba should solve the mColour problem, let's see what else crops up.

Forget f9d1c6ba, commit 81627c72 is now the latest and greatest.

Post a reply to this message

Le 03/07/2014 00:49, clipka nous fit lire :
> Am 03.07.2014 00:30, schrieb clipka:
> 
>> I think I got it; the problem is dependent base class name lookup.
>> f9d1c6ba should solve the mColour problem, let's see what else crops up.
> 
> Forget f9d1c6ba, commit 81627c72 is now the latest and greatest.
> 

It's not yet that.

As tomorrow I'm in holidays... if you have a bit of disk space on your
Windows (about 10 Giga ?), you might get faster return by installing
something like virtualbox and putting inside it a virtual machine to
install a linux iso-cd/dvd (ubuntu ?). I recommend at least 10G of
virtual disk size, but you can allocate more. (interestingly, the disk
image used by virtualbox is about the size of used data, but resizing
the whole disk later is problematic, so sizing big at start is better)

(Well, I wouldn't do it on the opposite path (linux->windows), so feel
no obligation).

CRTP is quite usual, but it might not be the simplest to understand when
you start with template (oh well, variadic templates of C++11 are even
stranger...).

-- 
IQ of crossposters with FU: 100 / (number of groups)
IQ of crossposters without FU: 100 / (1 + number of groups)
IQ of multiposters: 100 / ( (number of groups) * (number of groups))

Post a reply to this message

Attachments:
Download 'error81627c72gcc.txt.bz2.zip' (63 KB)

Le 02/07/2014 23:23, clipka nous fit lire :
> Am 02.07.2014 22:01, schrieb Le_Forgeron:
> 
>> It might be a long road.
>> I just went back to compile 3.7-stable with gcc and the image of
>> benchmark is even a bit different from the one at head with icpc.
>>
>> There is a change in the clouds, basically the same place and
>> shape...but some holes...
> 
> That's a known side effect of commit 5a081e92, which fixes a bug in the
> way media used to be sampled (see also FS#318).
> 
Ok, that's one less point to search. Great & thanks.

I will dive into that exploration after my holidays.

-- 
IQ of crossposters with FU: 100 / (number of groups)
IQ of crossposters without FU: 100 / (1 + number of groups)
IQ of multiposters: 100 / ( (number of groups) * (number of groups))

Post a reply to this message

Am 03.07.2014 18:06, schrieb Le_Forgeron:
> Le 03/07/2014 00:49, clipka nous fit lire :
>> Am 03.07.2014 00:30, schrieb clipka:
>>
>>> I think I got it; the problem is dependent base class name lookup.
>>> f9d1c6ba should solve the mColour problem, let's see what else crops up.
>>
>> Forget f9d1c6ba, commit 81627c72 is now the latest and greatest.
>>
>
> It's not yet that.
>
> As tomorrow I'm in holidays...

Have a nice time!

Post a reply to this message

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.

Post a reply to this message

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.

Post a reply to this message

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

clipka <ano### [at] anonymousorg> wrote:
> 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.

Its in C99 and C++11, but indeed will not work with fast math on for the
respective function. Other than disabling fast math for said function, using a
less likely magic value like HUGE_VALF or a separate store for the flag are all
the portable ways left.

Post a reply to this message

Am 06.07.2014 13:18, schrieb clipka:

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

Solved as follows:

Configure will now test whether NaNs and/or Infinities are available for 
both double and single precision, survive conversion between the two 
types, and can be tested for.

Attempted ways to test for NaNs include std::isnan(), global isnan(), or 
comparison of the value with itself (or, more precisely, a volatile copy 
thereof, to prevent the test from being optimized away).

Attempted ways to test for Infinities include std::isnan(), global 
isnan(), or comparison of the value's absolute with the highest finite 
value representable by the respective type (or, more precisely, a 
volatile copy thereof, to prevent the test from being optimized away).


If NaNs are available, survive type conversion and are testable, those 
will be used to mark a colour as invalid.

Otherwise, if Infinities are available, survive type conversion and are 
testable, negative infinity will be used instead.

Otherwise, as a last resort, the negative of the highest finite value 
representable by single-precision float will be used instead.


On g++ with -ffast_math, it turns out that negative infinity is a viable 
option; while isinf() is dysfunctional as expected, infinities do 
survive type conversion and can be tested for by comparing the value's 
absolute with the highest finite value representable.

Post a reply to this message