Mac OS

Discussion related to the Engine functionality, implementations and API.
User avatar
Dade
Developer
Posts: 1458
Joined: Mon Dec 04, 2017 8:36 pm

Re: Mac OS

Post by Dade » Sun Oct 21, 2018 6:56 pm

But is it happening also on your Linux box, not only on MacOS ?
Support LuxCoreRender project with salts and bounties

robbrown
Developer
Posts: 36
Joined: Mon Sep 03, 2018 1:04 am

Re: Mac OS

Post by robbrown » Mon Oct 22, 2018 7:43 am

With GCC? no

Still working on clang version. I'm getting farther by turning off LLVMgold plugin which appears to just be a link time optimization so I don't mind if that takes longer as long as it compiles and it can be determined if the problem is related to clang or a MacOS specific thing. I have it compiling but am running into a python error running the tests now.

Code: Select all

ImportError: numpy.core.umath failed to import
Seems like others have had the issue before so I'll continue investigating tomorrow.

User avatar
Dade
Developer
Posts: 1458
Joined: Mon Dec 04, 2017 8:36 pm

Re: Mac OS

Post by Dade » Mon Oct 22, 2018 9:21 am

robbrown wrote:
Mon Oct 22, 2018 7:43 am
With GCC? no
Does MacOS uses Clang and not GCC ?

It may be issue like GCC "-mfast-math" option, it allows to ignore some corner case of floating point (IEEE-754 specs) in order to improve performance but ends to produce incorrect code with Lux.
Support LuxCoreRender project with salts and bounties

robbrown
Developer
Posts: 36
Joined: Mon Sep 03, 2018 1:04 am

Re: Mac OS

Post by robbrown » Mon Oct 22, 2018 6:43 pm

Yes, they switched to Clang only some where around Mac OS 10.7

clang has a "-ffast-math" option available which is suppose to be equivalent to the GCC's fast-math but I don't have that selected in the build flags. I did notice just notice "-mno-ssse3" in Linux compile which I have turned on for MacOS (Was with old lux as well) but I don't think that's related to the INF problem.

Pretty much all of the clang flags for floating point and math are for allowing shortcuts rather then disabling them so should be set to be the most accurate math by default. The only one I see is "-mno-implicit-float Don't generate implicit floating point instructions", I can give it a try. No harm in compile and run tests with a new flag.

I hear it's possible to install GCC with brew but I'm not sure if that's compatible with the Xcode project generation in CMake that's currently in Lux so might require some rework to compile with GCC on MacOS.

User avatar
Dade
Developer
Posts: 1458
Joined: Mon Dec 04, 2017 8:36 pm

Re: Mac OS

Post by Dade » Mon Oct 22, 2018 9:21 pm

robbrown wrote:
Mon Oct 22, 2018 6:43 pm
I did notice just notice "-mno-ssse3" in Linux compile which I have turned on for MacOS (Was with old lux as well) but I don't think that's related to the INF problem.
The "-mno-ssse3" is only required to have the binaries compatible with some quite old AMD CPU lacking the support for SSSE3 (we are talking of 10 years old CPUs). The problem was noticed by some user and not using SSS3 instructions has not any impact on performance so I prefer to have the offfical builds more "compatible" as possible with any hardware.

The problem is quite strange. Can you add some printf and confirm that InfiniteLight::GetRadiance() returns a Spectrum != from black but the PDF is 0.0 ?

I'm looking at the code (https://github.com/LuxCoreRender/LuxCor ... ht.cpp#L82) ... wait a sec ... I have pushed a commit that may fix the problem, can you try if it works now ? There may be more points like this I will have to fix but it should not fail the assertion now.
Support LuxCoreRender project with salts and bounties

robbrown
Developer
Posts: 36
Joined: Mon Sep 03, 2018 1:04 am

Re: Mac OS

Post by robbrown » Tue Oct 23, 2018 6:56 pm

Not quite but that got me close enough to get the tests we've been talking about to complete, currently digging into BIDIR Cloth...

Short story need to check for both PDFs in a few places:

Code: Select all

(directPdfA == 0.f || latLongMappingPdf == 0.f)
	return Spectrum();
latLongMapping didn't seem to make any difference at first but replacing latLongMapping with directPdfA worked for a few more samples before it failed. Checking for both it's all good to go, but I'm not sure the background of the image is correct. I'm assuming the background is not suppose to have black areas and should look more like the PATHOCL one attached?
Attachments
InfiniteLight_BIDIRCPU_METROPOLIS.png
InfiniteLight_BIDIRCPU_METROPOLIS
InfiniteLight_BIDIRCPU_RANDOM.png
InfiniteLight_BIDIRCPU_RANDOM
InfiniteLight_BIDIRCPU_SOBOL.png
InfiniteLight_BIDIRCPU_SOBOL
InfiniteLight_PATHOCL_METROPOLIS.png
InfiniteLight_PATHOCL_METROPOLIS

User avatar
Dade
Developer
Posts: 1458
Joined: Mon Dec 04, 2017 8:36 pm

Re: Mac OS

Post by Dade » Tue Oct 23, 2018 10:46 pm

robbrown wrote:
Tue Oct 23, 2018 6:56 pm
Not quite but that got me close enough to get the tests we've been talking about to complete, currently digging into BIDIR Cloth...

Short story need to check for both PDFs in a few places:

Code: Select all

(directPdfA == 0.f || latLongMappingPdf == 0.f)
	return Spectrum();
latLongMapping didn't seem to make any difference at first but replacing latLongMapping with directPdfA worked for a few more samples before it failed. Checking for both it's all good to go, but I'm not sure the background of the image is correct. I'm assuming the background is not suppose to have black areas and should look more like the PATHOCL one attached?
Yes, it should and directPdfA can be == 0.0 if, and only if, the result is black (so your additional test is not required if all the code is working as expected). If you have "directPdfA == 0.f" for a color != from black there is something going (very) wrong with "imageMapDistribution". It is a Distribution2D (made of multiple Distribution1D): https://github.com/LuxCoreRender/LuxCor ... tion.h#L80
Support LuxCoreRender project with salts and bounties

robbrown
Developer
Posts: 36
Joined: Mon Sep 03, 2018 1:04 am

Re: Mac OS

Post by robbrown » Wed Oct 24, 2018 6:50 am

Ok, based on print statements I've placed in the bidircputhread.cpp file just before the assert it's not looking great. The print statement dumps not black, throughput.IsInf(), and lightDirectPdfW is 0.f, because lightDirectPdfW looks to be the same as directPdfA.

If I make an if block above line 373 and set it to black with a printed output, it's very infrequent, maybe twice (I'll have to go re-run it with your latLongMappingPdf == 0.f test added in).

It's interesting to me that this only happens for BIDIRCPU. I'm still working through more general Ray Tracer book material so my lack of bi-directional tracing experience probably isn't much help, my apologies. Still not sure if the Floating Point Calculation is an issue with Clang/GCC, because rounding could be compounded with bi-directional?

I will see what I can keep chipping away at here.

User avatar
Dade
Developer
Posts: 1458
Joined: Mon Dec 04, 2017 8:36 pm

Re: Mac OS

Post by Dade » Tue Oct 30, 2018 10:42 am

@robbrown, I upgraded the Embree version to v3.2.4 (from v3.2.0, not a big deal, just to keep all version aligned).
Support LuxCoreRender project with salts and bounties

robbrown
Developer
Posts: 36
Joined: Mon Sep 03, 2018 1:04 am

Re: Mac OS

Post by robbrown » Tue Oct 30, 2018 4:31 pm

Thanks for letting me know. I'll try to get it updated this afternoon.

Post Reply