Add "Pre" ebuilds to separate branch to test new APIs?

[dracwyrm]

There are patches in master trunk for full complete python 2 and 3 compatibility. It's multi-levels of patches that include other enhancements as well, so back porting would be a complete nightmare. The patch that we are currently using is a hack that "just" works. I'm wondering if this hack patch would give us issues when using the python modules.

My other thought is that there are a number of speed enhancements and loads of bug fixes: https://github.com/dreamworksanimation/openvdb/blob/master/openvdb/CHANGES

Also, once 3.2.0 lands, the patch we have will need to be removed and libraries take an extra long time to make stable. If we put a "Pre" in, then the final is basically a bug fix version rather than a whole new API. It shows that the new version will play nice with things. Since they have 3.2.0 in the changelog, new features are generally frozen at the moment and mainly bug fixes are done, so it shouldn't be too much longer.

We can drop the python 3 compat patch now then, and not worry about removing it later.

Loads of reasons, but I think we would need to test stability with Blender first. I think I will make a branch with the new ebuild, so others don't try to install it.

[redchillipadi]

I think that when we put blender into the tree, we should just depend on releases from the other packages, trying to avoid development or live ebuilds wherever possible. This way we avoid having to support bugs in or created by linking to the development code.

However, creating a branch for testing is a great idea, as then we will be ready to upgrade to it once it is released.

[dracwyrm]

It's a good thing I did test it as there was a build failure against Python 3.x. I tracked down the issue and did a PR with the fix for them.

I have it compiled now with the patch, so if upstream fixes it, then I can remove that. The branch should be up now.

[dracwyrm]

OpenVDB 3.2 Pre works really well! It's good to know the next release will be compatible. :)

Have you tried it yet?

[redchillipadi]

I am currently working on boost 1.61 for osl so blender doesn't compile yet. Will try it out soon.

[dracwyrm]

I am adding a OSL v1.8 Pre as well. :) I need to downgrade my LLVM/Clang, so I'll let you know. In master branch, OSL compiles with LLVM 3.6, but the tests don't work. That's a start. :) So, trying that out. Also trying it with boost 1.61. If this works right, we may need to depend on OSL Pre, which can be made stable. I did a search and a lot of things in portage depend on a Pre.

Also, OpenCV with Contrib use flag needs to have this kind of change in the depends: https://github.com/dracwyrm/gentoo-ebuilds/commit/c61fd158868324ee800bf6edb47fdb88a5b22c29 Using Cuda with nvidia drivers and OpenCL with only ati-drivers. ;) so it would something like contrib?( opencl? ( blah ) )

[dracwyrm]

I can't get the latest master code to compile with boost 1.61. It was just one part:

[ 88%] Linking CXX shared library liboslexec.so
cd /var/tmp/portage/media-libs/osl-1.8.0_pre20160614/work/osl-1.8.0_pre20160614_build/src/liboslexec && /usr/bin/cmake -E cmake_link_script CMakeFiles/oslexec.dir/link.txt --verbose=1
/usr/bin/x86_64-pc-linux-gnu-g++  -fPIC -march=native -O2 -w -pipe  -fno-rtti -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS  -Wl,-O1 -Wl,--as-needed -shared -Wl,-soname,liboslexec.so -o liboslexec.so CMakeFiles/oslexec.dir/shadingsys.cpp.o CMakeFiles/oslexec.dir/closure.cpp.o CMakeFiles/oslexec.dir/dictionary.cpp.o CMakeFiles/oslexec.dir/context.cpp.o CMakeFiles/oslexec.dir/instance.cpp.o CMakeFiles/oslexec.dir/loadshader.cpp.o CMakeFiles/oslexec.dir/master.cpp.o CMakeFiles/oslexec.dir/opcolor.cpp.o CMakeFiles/oslexec.dir/opmatrix.cpp.o CMakeFiles/oslexec.dir/opmessage.cpp.o CMakeFiles/oslexec.dir/opnoise.cpp.o CMakeFiles/oslexec.dir/simplexnoise.cpp.o CMakeFiles/oslexec.dir/gabornoise.cpp.o CMakeFiles/oslexec.dir/opspline.cpp.o CMakeFiles/oslexec.dir/opstring.cpp.o CMakeFiles/oslexec.dir/optexture.cpp.o CMakeFiles/oslexec.dir/oslexec.cpp.o CMakeFiles/oslexec.dir/pointcloud.cpp.o CMakeFiles/oslexec.dir/rendservices.cpp.o CMakeFiles/oslexec.dir/constfold.cpp.o CMakeFiles/oslexec.dir/runtimeoptimize.cpp.o CMakeFiles/oslexec.dir/typespec.cpp.o CMakeFiles/oslexec.dir/lpexp.cpp.o CMakeFiles/oslexec.dir/lpeparse.cpp.o CMakeFiles/oslexec.dir/automata.cpp.o CMakeFiles/oslexec.dir/accum.cpp.o CMakeFiles/oslexec.dir/opclosure.cpp.o CMakeFiles/oslexec.dir/shadeimage.cpp.o CMakeFiles/oslexec.dir/backendllvm.cpp.o CMakeFiles/oslexec.dir/llvm_gen.cpp.o CMakeFiles/oslexec.dir/llvm_instance.cpp.o CMakeFiles/oslexec.dir/llvm_util.cpp.o CMakeFiles/oslexec.dir/__/liboslcomp/ast.cpp.o CMakeFiles/oslexec.dir/__/liboslcomp/codegen.cpp.o CMakeFiles/oslexec.dir/__/liboslcomp/oslcomp.cpp.o CMakeFiles/oslexec.dir/__/liboslcomp/symtab.cpp.o CMakeFiles/oslexec.dir/__/liboslcomp/typecheck.cpp.o CMakeFiles/oslexec.dir/__/liboslquery/oslquery.cpp.o CMakeFiles/oslexec.dir/osogram.cpp.o CMakeFiles/oslexec.dir/osolex.cpp.o CMakeFiles/oslexec.dir/oslgram.cpp.o CMakeFiles/oslexec.dir/osllex.cpp.o CMakeFiles/oslexec.dir/llvm_ops.bc.cpp.o -lOpenImageIO -lImath -lIex -lHalf -lIlmThread -lpthread -lpugixml -lz -lboost_filesystem-mt -lboost_regex-mt -lboost_system-mt -lboost_thread-mt -lboost_wave-mt -lboost_chrono-mt -lboost_date_time-mt -lboost_atomic-mt -lboost_serialization-mt -lrt -ldl -lLLVM-3.6.2 -Wl,-Bstatic -lLLVMMCJIT -Wl,-Bdynamic -L/usr/lib64 -Wl,-rpath,:::::::: 
make[2]: Leaving directory '/var/tmp/portage/media-libs/osl-1.8.0_pre20160614/work/osl-1.8.0_pre20160614_build'
[ 88%] Built target oslexec
make[1]: Leaving directory '/var/tmp/portage/media-libs/osl-1.8.0_pre20160614/work/osl-1.8.0_pre20160614_build'

[dracwyrm]

OSL Pre is up on pre-ebuilds branch. :) It's surprisingly stable. Tests don't work, but that's expected. Things work with Blender. It can't use Boost >1.60, but it's nice. :) Boost 1.61 support would be nice, but I have that masked on my system anyways because of other issues with programs I use, so it's really no loss to me. I need LLVM >=3.7 as there are several packages that depend on that, namely to do with AMD graphics card stuff.

[dracwyrm]

Just gonna leave this here: http://www.blendernation.com/2016/06/21/story-expose-3d-established-3d-visualization-company-switch-blender-entirely/ Really cool! Think we can convince them to use Blender on Gentoo and Gentoo Render Farms? :D

[redchillipadi]

Love the idea of using Gentoo on the Render Farms!

As far as the boost failure, its the same as with the 1.7.2 version. The actual error is higher up:

[ 86%] Linking CXX executable oslc
cd /var/tmp/portage/media-libs/osl-1.8.0_pre20160614/work/osl-1.8.0_pre20160614_build/src/oslc && /usr/bin/cmake -E cmake_link_script CMakeFiles/oslc.dir/link.txt --verbose=1
/usr/bin/x86_64-pc-linux-gnu-g++   -march=corei7-avx -O2 -pipe  -fno-rtti   -Wl,-O1 -Wl,--as-needed CMakeFiles/oslc.dir/oslcmain.cpp.o  -o oslc -rdynamic ../liboslcomp/liboslcomp.so -lOpenImageIO -lboost_filesystem-mt -lboost_regex-mt -lboost_system-mt -lboost_thread-mt -lboost_wave-mt -lrt -ldl -lImath -lIex -lHalf -lIlmThread -lpthread -lboost_filesystem-mt -lboost_regex-mt -lboost_system-mt -lboost_thread-mt -lboost_wave-mt -lrt -ldl -Wl,-rpath,/var/tmp/portage/media-libs/osl-1.8.0_pre20160614/work/osl-1.8.0_pre20160614_build/src/liboslcomp: 
../liboslcomp/liboslcomp.so: undefined reference to `boost::wave::grammars::defined_grammar_gen<boost::wave::cpplexer::lex_iterator<boost::wave::cpplexer::lex_token<boost::wave::util::file_position<boost::wave::util::flex_string<char, std::char_traits<char>, std::allocator<char>, boost::wave::util::CowString<boost::wave::util::AllocatorStringStorage<char, std::allocator<char> >, char*> > > > > >::parse_operator_defined(boost::wave::util::unput_queue_iterator<boost::wave::cpplexer::lex_iterator<boost::wave::cpplexer::lex_token<boost::wave::util::file_position<boost::wave::util::flex_string<char, std::char_traits<char>, std::allocator<char>, boost::wave::util::CowString<boost::wave::util::AllocatorStringStorage<char, std::allocator<char> >, char*> > > > >, boost::wave::cpplexer::lex_token<boost::wave::util::file_position<boost::wave::util::flex_string<char, std::char_traits<char>, std::allocator<char>, boost::wave::util::CowString<boost::wave::util::AllocatorStringStorage<char, std::allocator<char> >, char*> > > >, std::list<boost::wave::cpplexer::lex_token<boost::wave::util::file_position<boost::wave::util::flex_string<char, std::char_traits<char>, std::allocator<char>, boost::wave::util::CowString<boost::wave::util::AllocatorStringStorage<char, std::allocator<char> >, char*> > > >, boost::fast_pool_allocator<boost::wave::cpplexer::lex_token<boost::wave::util::file_position<boost::wave::util::flex_string<char, std::char_traits<char>, std::allocator<char>, boost::wave::util::CowString<boost::wave::util::AllocatorStringStorage<char, std::allocator<char> >, char*> > > >, boost::default_user_allocator_new_delete, std::mutex, 32u, 0u> > > const&, boost::wave::util::unput_queue_iterator<boost::wave::cpplexer::lex_iterator<boost::wave::cpplexer::lex_token<boost::wave::util::file_position<boost::wave::util::flex_string<char, std::char_traits<char>, std::allocator<char>, boost::wave::util::CowString<boost::wave::util::AllocatorStringStorage<char, std::allocator<char> >, char*> > > > >, boost::wave::cpplexer::lex_token<boost::wave::util::file_position<boost::wave::util::flex_string<char, std::char_traits<char>, std::allocator<char>, boost::wave::util::CowString<boost::wave::util::AllocatorStringStorage<char, std::allocator<char> >, char*> > > >, std::list<boost::wave::cpplexer::lex_token<boost::wave::util::file_position<boost::wave::util::flex_string<char, std::char_traits<char>, std::allocator<char>, boost::wave::util::CowString<boost::wave::util::AllocatorStringStorage<char, std::allocator<char> >, char*> > > >, boost::fast_pool_allocator<boost::wave::cpplexer::lex_token<boost::wave::util::file_position<boost::wave::util::flex_string<char, std::char_traits<char>, std::allocator<char>, boost::wave::util::CowString<boost::wave::util::AllocatorStringStorage<char, std::allocator<char> >, char*> > > >, boost::default_user_allocator_new_delete, std::mutex, 32u, 0u> > > const&, std::list<boost::wave::cpplexer::lex_token<boost::wave::util::file_position<boost::wave::util::flex_string<char, std::char_traits<char>, std::allocator<char>, boost::wave::util::CowString<boost::wave::util::AllocatorStringStorage<char, std::allocator<char> >, char*> > > >, boost::fast_pool_allocator<boost::wave::cpplexer::lex_token<boost::wave::util::file_position<boost::wave::util::flex_string<char, std::char_traits<char>, std::allocator<char>, boost::wave::util::CowString<boost::wave::util::AllocatorStringStorage<char, std::allocator<char> >, char*> > > >, boost::default_user_allocator_new_delete, std::mutex, 32u, 0u> >&)'
../liboslcomp/liboslcomp.so: undefined reference to `boost::wave::grammars::defined_grammar_gen<boost::wave::cpplexer::lex_iterator<boost::wave::cpplexer::lex_token<boost::wave::util::file_position<boost::wave::util::flex_string<char, std::char_traits<char>, std::allocator<char>, boost::wave::util::CowString<boost::wave::util::AllocatorStringStorage<char, std::allocator<char> >, char*> > > > > >::parse_operator_defined(boost::wave::util::unput_queue_iterator<std::_List_iterator<boost::wave::cpplexer::lex_token<boost::wave::util::file_position<boost::wave::util::flex_string<char, std::char_traits<char>, std::allocator<char>, boost::wave::util::CowString<boost::wave::util::AllocatorStringStorage<char, std::allocator<char> >, char*> > > > >, boost::wave::cpplexer::lex_token<boost::wave::util::file_position<boost::wave::util::flex_string<char, std::char_traits<char>, std::allocator<char>, boost::wave::util::CowString<boost::wave::util::AllocatorStringStorage<char, std::allocator<char> >, char*> > > >, std::list<boost::wave::cpplexer::lex_token<boost::wave::util::file_position<boost::wave::util::flex_string<char, std::char_traits<char>, std::allocator<char>, boost::wave::util::CowString<boost::wave::util::AllocatorStringStorage<char, std::allocator<char> >, char*> > > >, boost::fast_pool_allocator<boost::wave::cpplexer::lex_token<boost::wave::util::file_position<boost::wave::util::flex_string<char, std::char_traits<char>, std::allocator<char>, boost::wave::util::CowString<boost::wave::util::AllocatorStringStorage<char, std::allocator<char> >, char*> > > >, boost::default_user_allocator_new_delete, std::mutex, 32u, 0u> > > const&, boost::wave::util::unput_queue_iterator<std::_List_iterator<boost::wave::cpplexer::lex_token<boost::wave::util::file_position<boost::wave::util::flex_string<char, std::char_traits<char>, std::allocator<char>, boost::wave::util::CowString<boost::wave::util::AllocatorStringStorage<char, std::allocator<char> >, char*> > > > >, boost::wave::cpplexer::lex_token<boost::wave::util::file_position<boost::wave::util::flex_string<char, std::char_traits<char>, std::allocator<char>, boost::wave::util::CowString<boost::wave::util::AllocatorStringStorage<char, std::allocator<char> >, char*> > > >, std::list<boost::wave::cpplexer::lex_token<boost::wave::util::file_position<boost::wave::util::flex_string<char, std::char_traits<char>, std::allocator<char>, boost::wave::util::CowString<boost::wave::util::AllocatorStringStorage<char, std::allocator<char> >, char*> > > >, boost::fast_pool_allocator<boost::wave::cpplexer::lex_token<boost::wave::util::file_position<boost::wave::util::flex_string<char, std::char_traits<char>, std::allocator<char>, boost::wave::util::CowString<boost::wave::util::AllocatorStringStorage<char, std::allocator<char> >, char*> > > >, boost::default_user_allocator_new_delete, std::mutex, 32u, 0u> > > const&, std::list<boost::wave::cpplexer::lex_token<boost::wave::util::file_position<boost::wave::util::flex_string<char, std::char_traits<char>, std::allocator<char>, boost::wave::util::CowString<boost::wave::util::AllocatorStringStorage<char, std::allocator<char> >, char*> > > >, boost::fast_pool_allocator<boost::wave::cpplexer::lex_token<boost::wave::util::file_position<boost::wave::util::flex_string<char, std::char_traits<char>, std::allocator<char>, boost::wave::util::CowString<boost::wave::util::AllocatorStringStorage<char, std::allocator<char> >, char*> > > >, boost::default_user_allocator_new_delete, std::mutex, 32u, 0u> >&)'
../liboslcomp/liboslcomp.so: undefined reference to `boost::wave::grammars::cpp_grammar_gen<boost::wave::cpplexer::lex_iterator<boost::wave::cpplexer::lex_token<boost::wave::util::file_position<boost::wave::util::flex_string<char, std::char_traits<char>, std::allocator<char>, boost::wave::util::CowString<boost::wave::util::AllocatorStringStorage<char, std::allocator<char> >, char*> > > > >, std::list<boost::wave::cpplexer::lex_token<boost::wave::util::file_position<boost::wave::util::flex_string<char, std::char_traits<char>, std::allocator<char>, boost::wave::util::CowString<boost::wave::util::AllocatorStringStorage<char, std::allocator<char> >, char*> > > >, boost::fast_pool_allocator<boost::wave::cpplexer::lex_token<boost::wave::util::file_position<boost::wave::util::flex_string<char, std::char_traits<char>, std::allocator<char>, boost::wave::util::CowString<boost::wave::util::AllocatorStringStorage<char, std::allocator<char> >, char*> > > >, boost::default_user_allocator_new_delete, std::mutex, 32u, 0u> > >::parse_cpp_grammar(boost::wave::cpplexer::lex_iterator<boost::wave::cpplexer::lex_token<boost::wave::util::file_position<boost::wave::util::flex_string<char, std::char_traits<char>, std::allocator<char>, boost::wave::util::CowString<boost::wave::util::AllocatorStringStorage<char, std::allocator<char> >, char*> > > > > const&, boost::wave::cpplexer::lex_iterator<boost::wave::cpplexer::lex_token<boost::wave::util::file_position<boost::wave::util::flex_string<char, std::char_traits<char>, std::allocator<char>, boost::wave::util::CowString<boost::wave::util::AllocatorStringStorage<char, std::allocator<char> >, char*> > > > > const&, boost::wave::util::file_position<boost::wave::util::flex_string<char, std::char_traits<char>, std::allocator<char>, boost::wave::util::CowString<boost::wave::util::AllocatorStringStorage<char, std::allocator<char> >, char*> > > const&, bool&, boost::wave::cpplexer::lex_token<boost::wave::util::file_position<boost::wave::util::flex_string<char, std::char_traits<char>, std::allocator<char>, boost::wave::util::CowString<boost::wave::util::AllocatorStringStorage<char, std::allocator<char> >, char*> > > >&, std::list<boost::wave::cpplexer::lex_token<boost::wave::util::file_position<boost::wave::util::flex_string<char, std::char_traits<char>, std::allocator<char>, boost::wave::util::CowString<boost::wave::util::AllocatorStringStorage<char, std::allocator<char> >, char*> > > >, boost::fast_pool_allocator<boost::wave::cpplexer::lex_token<boost::wave::util::file_position<boost::wave::util::flex_string<char, std::char_traits<char>, std::allocator<char>, boost::wave::util::CowString<boost::wave::util::AllocatorStringStorage<char, std::allocator<char> >, char*> > > >, boost::default_user_allocator_new_delete, std::mutex, 32u, 0u> >&)'
collect2: error: ld returned 1 exit status
src/oslc/CMakeFiles/oslc.dir/build.make:110: recipe for target 'src/oslc/oslc' failed

I have been spending most of this week getting up to speed on boost::wave and searching through libraries for all the different symbols that are required. From my work on opencv for amynka I feel that liboslcomp needs to be linked with another library, just not sure which one yet!

[dracwyrm]

Good catch on the part that failed. I was racking my brain trying to get this as well. The file that is compiled has boost headers, so we just need a complete diff between those few headers between 1.60 and 1.61. That difference is where they failure is. It could be a regression or a removed function or a moved function. If the function was moved, then we just need to patch that in. It won't matter if it is compile with boost 1.60, it will just be an extra header file that isn't used.

[dracwyrm]

Upstream is saying that Boost needs to be built with C++11. I checked the ebuild and it does hard set c++96. I don't know why they don't have a use flag on that. I did a search in b.g.o and there are several reports of packages failing because boost isn't built with C++11. GCC 5.x and above build with C++11 by default unless told not to. GCC 6 will be C++14 by default. They really need to fix Boost to be built right. It's a major component of the system and if it's not built right, then things will suffer.

[dracwyrm]

I can confirm that Boost compiled C++11 and OSL compile fine without patches. :) So, all we need to do is convince Boost devs to add a C++11 flag.

[dracwyrm]

After looking in OSL master branch, they are releasing versions of 1.8. They are already up to 1.8.2. They consider those stable enough for those point releases. However, they aren't releasing them in tarball form.

Though, they need C++11 and I think they compile with newer LLVM, so we might be in luck. :D I hope. Maybe. We'll see.

[redchillipadi]

Well, osl 1.8.2 from master compiles under LLVM-3.6. However rendering with an osl shader (following the example from http://elbrujodelatribu.blogspot.com.au/2013/04/blender-cycles-osl-mandelbrot-fractal.html) crashes blender.

I think we need to wait until we can use orcjit with LLVM-3.7 before we upgrade from 1.7.4. lgritz has said he is working on this rather than fix mcjit in LLVM-3.6. See https://github.com/imageworks/OpenShadingLanguage/issues/631

[dracwyrm]

If it works with LLVM-3.7, would it work with 3.8 and 3.9 (coming really soon)?

[redchillipadi]

I think that is likely to be the case.

[dracwyrm]

@redchillipadi I added a new 1.8.2 pre ebuild to the main repo so it can be tested. I included now ORC Jit patches and the min LLVM version is now 3.8. I tried to get OSL working in Blender, but it would not render the pattern. It didn't crash Blender though, like it happened with you. If you could give it a try, that'd be great as you got it working before. :) If 1.8.2 works for you, then that might be the version we go with as LLVM is the current stable, so 3.8 is next.

Cheers.

[redchillipadi]

This is great news. I have put off updating my system for the last 3 weeks as emerge wanted me to upgrade to LLVM-3.9 for some reason and I knew was not compatible with OSL. Now I will give it a try!

[dracwyrm]

@redchillipadi Thanks!!! For some reason I could not figure out why OSL wasn't doing anything. It'd render and take a while to render, and not crash the computer, so it was doing something. I'm using LLVM 3.8.2, if that helps.

I pulled the patch from the fork of the guy working on it. :P Seems stable enough.

[redchillipadi]

Well, I have updated 375 packages and everything compiled, including blender and osl.

But unfortunately something has happened during the update and I now get a black screen when running startx. I eventually worked out that I could hook up to my tv so that I can test blender.

I am using blender-2.78, boost-1.62 and LLVM-3.8.1-r2 and osl-1.8.2_pre20161004. Whenever it tries to render the material (either to display it in the material panel, or rendering the actual image) blender has a segmentation fault.

# Blender 2.78 (sub 0), Commit date: 1970-01-01 00:00, Hash unknown
bpy.context.space_data.context = 'RENDER'  # Property
bpy.context.scene.cycles.shading_system = True  # Property
bpy.context.space_data.context = 'CONSTRAINT'  # Property
bpy.context.space_data.context = 'MODIFIER'  # Property
bpy.context.space_data.context = 'DATA'  # Property
bpy.context.space_data.context = 'MATERIAL'  # Property

# backtrace
blender(BLI_system_backtrace+0x30) [0x1432a90]
blender() [0xa2ab60]
/lib64/libc.so.6(+0x33270) [0x7fd51d320270]
/usr/lib64/liboslexec.so(_ZN3OSL9LLVM_Util4Impl11module_doneEv+0x46c) [0x7fd5239c45bc]
/usr/lib64/liboslexec.so(_ZN3OSL3pvt11BackendLLVM3runEv+0x102e) [0x7fd5239b43ce]
/usr/lib64/liboslexec.so(_ZN3OSL3pvt17ShadingSystemImpl14optimize_groupERNS_11ShaderGroupE+0x539) [0x7fd5238c3589]
/usr/lib64/liboslexec.so(_ZN3OSL3pvt17ShadingSystemImpl19optimize_all_groupsEiii+0x5e9) [0x7fd5238c54d9]
/usr/lib64/libboost_thread.so.1.62.0(+0x135f5) [0x7fd526bd45f5]
/lib64/libpthread.so.0(+0x7444) [0x7fd51d894444]
/lib64/libc.so.6(clone+0x6d) [0x7fd51d3d64cd]

The blend file I used was mandelbrot.zip

I am going to get my system working properly again before looking further into this. The black screen is a common issue in systems with multiple graphics cards using Nvidia Optimus, but I can't solve it with the soIutions in the gentoo wiki at the moment.

[dracwyrm]

This is what I keep getting including when I was using other projects, just a single color. It's not processing it correctly. Is there something I need to do to set OSL up?

[redchillipadi]

My system is now back up again, the issue was that I had upgraded xorg-server I needed some changes to xorg.conf and also to add the glamor use flag. Unfortunately I still get the same crash in blender using osl.

To get the previous version of OSL to run, the only things I needed were to choose cycles rendering, and in the render panel select CPU as the device, and check the Open Shading Language checkbox.

[dracwyrm]

Okay. I get the crash now. I started blender from the command line, and I get this: /var/tmp/portage/media-libs/osl-1.8.2_pre20161004/work/osl-1.8.2_pre20161004/src/liboslexec/llvm_instance.cpp:1097: failed assertion 'll.get_compiled_function(name)' Aborted (core dumped) I traced that cpp file to the OSL patch. Will hit the dev up with a comment about this.

[dracwyrm]

I got a rather harsh reply from upstream. I don't think they are ever going to support LLVM greater than 3.5. Radeon drivers need current versions 3.7 and 3.8. Also other programs are now making 3.7 the min version, so this is falling by the way side. Dropping OSL until Upstream gets their shit together.

The only current way of supporting OSL is to fix llvm_instance.cpp. It's not returning the right parameter, thus it's causing the assert to fail. Then it should work properly, but the person working on it says that's it abandoned code, so I have no idea what they are planning now if they aren't working on Orc Jit compat anymore.

[redchillipadi]

I got the same impression when I read their response. Its a shame we can't include it as it worked well in blender-2.77a with osl-1.7.4, but it will need to be updated to keep it maintainable.

I spent some time looking at this error running blender from gdb and for me it occurs during line 1088 call to ll.module_done() and produces a crash in part of the stl functions, rather than reaching the ll.get_compiled_function(name) on 1097.

What was the command line you were using to start blender and run the script, and do you still have the core dump (it might be in /tmp)?

[dracwyrm]

I just typed in blender in the terminal. Then I just browsed to the file you attached in this report and rendered by checking the OSL box. I didn't see a core dump in /tmp and I don't restart my computer.

[dracwyrm]

We have Pre's now, so closing. :)

[dracwyrm]

@redchillipadi they have this commit: https://github.com/imageworks/OpenShadingLanguage/commit/fe6dcd0db4a6e669aadd5d0693bc778928aaa504

Does this mean they have llvm 3.8/9 support or working on it? If so, we can work on OSL again.

[redchillipadi]

I wondered about that too but haven't had time to test it out yet.

[dracwyrm]

@redchillipadi I'll investigate it.

BTW... This is how the Peer review is going: https://github.com/gentoo/gentoo/pull/2531

[redchillipadi]

Good to see the peer review is underway. It is quite thorough. I did like the part about slapping upstream, though :)

If I judged right from the comments in https://github.com/OpenImageIO/oiio/pull/1529, the commit is there to prevent compiler warnings under clang 3.9. But I haven't seen any patches relating to ORC JIT yet, so even if it does compile, it might just crash like our version did.

Changing from JIT to ORC JIT sounds like a major task. It seems that the initial development of the JIT code took the whole team 3 months. See http://llvm.org/devmtg/2010-11/Gritz-OpenShadingLang.pdf

[dracwyrm]

@redchillipadi The patch I used was from June to add Orc Jit, and it seemed mostly complete, so why wasn't that developed further? That's what I don't like.

Yeah. That part about slapping upstream was pure gold.