Mac OS

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

Re: Mac OS

Post by Dade » Tue Sep 18, 2018 10:02 am

Note: last Blender related commits require Boost NumPy component (i.e. boost_numpy) to be linked to pyluxcore.pyd. It is part of standard Boost so it should be already there and discovered by cmake.
Support LuxCoreRender project with salts and bounties

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

Re: Mac OS

Post by robbrown » Tue Sep 18, 2018 4:38 pm

Yeah it is behaving weirdly, I'm now trying some open source blender files and it's crashing quite a bit so seeming like it's something unrelated to Lux. I'll see if I can isolate it, install blender on another machine/vm without lux, with/without OS X, bla bla bla...

I'm running 2.79b installed from blender's release package (was thinking release version was probably best.)

Just to confirm I'm not doing something totally off like loading files without any material nodes. I assume the test files have textures and material nodes? I also tried luxball7-blender.zip which had missing nodes.

I'll check on the boost_numpy bit, I didn't explicitly look for it or request it in the build process.

User avatar
B.Y.O.B.
Developer
Posts: 1600
Joined: Mon Dec 04, 2017 10:08 pm
Location: Germany
Contact:

Re: Mac OS

Post by B.Y.O.B. » Tue Sep 18, 2018 10:20 pm

That luxball file is quite old.
Try this one: https://github.com/LuxCoreRender/LuxCor ... chmark.zip
Support LuxCoreRender project with salts and bounties

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

Re: Mac OS

Post by robbrown » Tue Sep 18, 2018 11:38 pm

That file seems to load ok, nodes and all. Maybe 2.79b just isn't loading older files well.

After trying to render that benchmark file Blender stalled out on OpenCL compiling kernel, becoming unresponsive to Ctrl-C. Now everything stalls trying to render with Lux CPU or OpenCL, Cycles still works so not sure what's going on there. I did have to tell it to ignore that two OMP libraries are linked so may need to go back and recompile to fix that issue now rather than later.

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

Re: Mac OS

Post by robbrown » Wed Sep 19, 2018 8:09 pm

Weirdly everything is working again, not sure what root cause is at the moment but not able to reproduce for now so I'll continue working on getting a the build going.

Definitely seems to be an intermittent problem. Seems like it's falling into weird state condition or a scheduling bottleneck is causing the issue. I was able to run the LuxCore2.1Benchmark.zip on CPU only this time. Only difference, is I let Blender sit in it's unresponsive state for hours on the 3d cube trying to render with Lux and it eventually succeeded. Now the unresponsiveness is gone on all the blender files I load.

OpenCL mostly works but LuxCore2.1Benchmark.zip does throw an error `PathOCLBase kernel compilation error` so not sure if that's related to this old bug or something else. If it's not related to that bug, I can dig into that further after I get some of the build stuff pushed up into branches.

User avatar
B.Y.O.B.
Developer
Posts: 1600
Joined: Mon Dec 04, 2017 10:08 pm
Location: Germany
Contact:

Re: Mac OS

Post by B.Y.O.B. » Wed Sep 19, 2018 9:19 pm

robbrown wrote:
Wed Sep 19, 2018 8:09 pm
OpenCL mostly works but LuxCore2.1Benchmark.zip does throw an error `PathOCLBase kernel compilation error`
The standard procedure to test if this is an OpenCL compiler bug or a bug in LuxCore code is to run on CPU OpenCL device only.
However, in the Blender addon it is not possible anymore to select the OpenCL CPU device because we now have native C++ plus OpenCL, so it would be confusing for the users to also have the option of OpenCL CPU device.

You could export to text files (select checkbox "Only write LuxCore scene" in config settings).
Then you would have to delete the OpenCL related config lines in the "render.cfg" file: https://wiki.luxcorerender.org/LuxCore_ ... er_Engines
And only write:

Code: Select all

opencl.cpu.use = 1
opencl.gpu.use = 0
This way the OpenCL CPU device is used, these usually have the best compilers, so if the scene works fine there, you can be pretty sure that "PathOCLBase kernel compilation error" is caused by a bug in the GPU OpenCL compiler.
Support LuxCoreRender project with salts and bounties

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

Re: Mac OS

Post by robbrown » Fri Sep 21, 2018 4:46 am

Sounds good thanks for the info, I'll dig into it once I get this OpenMP stuff figured out. I'm planning on digging into where Blender get's there dynamic lib from.

Longer story I currently have to call blender from the terminal with KMP_DUPLICATE_LIB_OK=TRUE to make it work but that's not a great solution for release.

Looks like I'm not compiling OpenMP the same way Blender is and that's causing an issue because it's loading two dynamic libs making OpenMP complain and call an Abort Trap: 6.

Code: Select all

OMP: Error #15: Initializing libomp.dylib, but found libiomp5.dylib already initialized.
Blender seems to have a specific libiomp5.dylib file while mine is a symbolic link to libomp.dylib causing the rpath to be different and making OpenMP say libiomp5.dylib already loaded when it tries to load libomp.dylib.

Code: Select all

otool -L libiomp5.dylib
libiomp5.dylib:
	@rpath/libomp.dylib (compatibility version 5.0.0, current version 5.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.60.2)

otool -L blender.app/Contents/Resources/lib/libiomp5.dylib
blender.app/Contents/Resources/lib/libiomp5.dylib:
	@loader_path/../Resources/lib/libiomp5.dylib (compatibility version 5.0.0, current version 5.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)

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

Re: Mac OS

Post by robbrown » Sun Sep 23, 2018 4:51 am

I figured out more on the OpenMP library business and have been able to run BlendLux without setting environment variables to avoid the system trap now.

I just posted a question on the Blender forums inquiring about if there's a bug. I think symbolic links in the plugins folder is a bandaid for not using rpath in the original dynamic library but want to make sure. We may need to use symbolic links for an initial MacOS release if we don't want to wait for the next Blender release.

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

Re: Mac OS

Post by Dade » Thu Sep 27, 2018 9:15 pm

Rob, is MacOS version ready for a test release like alpha4 ?
Support LuxCoreRender project with salts and bounties

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

Re: Mac OS

Post by robbrown » Thu Sep 27, 2018 11:49 pm

I just posted a PR for LuxCore.

The only part I'm currently concerned about is if I broke anything with the PySide/PySide2 support. Up until now I haven't had a means to test PySide since I need to build/test on a Linux and/or Windows machine for that. Linux would be easier for me but I'm willing to try either so we make sure it's sufficiently tested.

Post Reply