Page 10 of 22

Re: Mac OS

Posted: Tue Sep 18, 2018 10:02 am
by Dade
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.

Re: Mac OS

Posted: Tue Sep 18, 2018 4:38 pm
by robbrown
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.

Re: Mac OS

Posted: Tue Sep 18, 2018 10:20 pm
by B.Y.O.B.
That luxball file is quite old.
Try this one: https://github.com/LuxCoreRender/LuxCor ... chmark.zip

Re: Mac OS

Posted: Tue Sep 18, 2018 11:38 pm
by robbrown
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.

Re: Mac OS

Posted: Wed Sep 19, 2018 8:09 pm
by robbrown
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.

Re: Mac OS

Posted: Wed Sep 19, 2018 9:19 pm
by B.Y.O.B.
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.

Re: Mac OS

Posted: Fri Sep 21, 2018 4:46 am
by robbrown
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)

Re: Mac OS

Posted: Sun Sep 23, 2018 4:51 am
by robbrown
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.

Re: Mac OS

Posted: Thu Sep 27, 2018 9:15 pm
by Dade
Rob, is MacOS version ready for a test release like alpha4 ?

Re: Mac OS

Posted: Thu Sep 27, 2018 11:49 pm
by robbrown
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.