I’m involved in packaging Blender for the openSUSE eco system, based here and was asked to add OptiX support for Cycles. Further investigation revealed, that - unlike CUDA - OptiX support requires a working CUDA stack during build time, which in turn requires a working nvidia driver installed.
A public packaging/build infrastructure like OBS, which generates all builds of the distribution cannot provide such an environment for a multitude of reasons (starting with non-free NVidia driver code).
The best way to deal with this issue would be a deferred compilation of Cycles IMHO.
AFAIK to build Blender with Optix enabled is need use CUDA SDK and Optix Library, i build my Blender on VM without OpenGL support and surely without NVidia drivers installed, yoyu can check my compiled Blender from here. Fork is not mine, i only compiled this Blender branch/fork.
Unfortunately downloading that SDK requires singing up for an NVIDIA developer account, and redistributing the headers is not permitted by the license.
The build tries to call nvcc (I guess), but that isn’t available at build time. This is the reason for my statement above.
@brecht Without defining OPTIX_INCLUDE_DIR, the result is:
[ 14s] -- Could NOT find OptiX (missing: OPTIX_INCLUDE_DIR)
[ 14s] -- OptiX not found, disabling it from Cycles
While at it, due to the license issues, my first attempt was to supply the SDK include tree, which might be a feasible workaround, but that fails in the same way…
These seems cmake messages though, not runtime builds, looks like the NVCC is not found, try setting -DCUDA_NVCC_EXECUTABLE=/where/ever/nvcc/lives/at/build/time/nvcc
Guess, basic infrastructure is in place but as always, the devil is in the details…
Will keep the bug on hold until then. A brief notice, when you’re ready for testing, is much appreciated.
Thanks, @LazyDodo, the matter is, at the time and place, when and where such distribution packages are build, nvcc cannot exist for a multitude of reasons (with the foremost: legal aka NVidia License Agreement). In fact, that’s the way, CUDA works for Blender: whenever you attempt to run Cycles on a new Blender build, it attempts to compile the module first, which is - as usual being expected from this project - a very smart way to solve such issues. Of course, this comes with a prize: these modules must be created even more carefully than others, given the variants (CUDA versions) available today.
Soory, @LazyDodo, I don’t get your question. As written before, it’s not possible to officially build Blender with the drivers installed for any Linux distribution. That is a restriction of the build systems, that disallow builds with non-free drivers installed (and typically are done in virtualized build environments, where such drivers won’t fit). Specialized builds are possible of course, but these would make the whole package non-free, since NVidia’s License Agreement forbids publishing the sources (headers et al).
Take it as an unfortunate legal and technical interaction.
At the moment, @brecht has mangled the OptiX integration into Cycles into a runtime dependency, all will be well again. You will not notice anything apart from a small delay on the first usage. And for the impatient ones, you can always use the precompiled packages from blender.org.
OptiX runtime kernel compilation is now supported. But you’re always going to need the OptiX header files to compile Blender/Cycles with OptiX support, which is where your error is.
OptiX runtime kernel compilation is now supported. But you’re always going to need the OptiX header files to compile Blender/Cycles with OptiX support, which is where your error is.
Here we’re ending in a Catch 22: even the referenced includes clearly states:
* Copyright (c) 2021 NVIDIA Corporation. All rights reserved.
*
* NVIDIA Corporation and its licensors retain all intellectual property and proprietary
* rights in and to this software, related documentation and any modifications thereto.
* Any use, reproduction, disclosure or distribution of this software and related
* documentation without an express license agreement from NVIDIA Corporation is strictly
* prohibited.
therefore, we are not allowed to build Blender based on these headers and still call it Open Source. My cheeky attempt has already been rejected.
Since you already have solved this partway, wouldn’t it be possible to do it the cuda style, meaning we just specify a bunch of config variables during build, and require the system being set up in a specific way (on users side with cuda and OptiX). For cuda, this is working fine already since long, just OptiX isn’t up to the task yet, and I get regular requests for it.
BTW, with providing the includes in a test build (well, I used 7.4 headers), I managed to build 3.1.0 with proper OptiX support. It just cannot be distributed that way.
However I’m not really sure how you got to that error even, CMake configuration should already disable OptiX when it can’t find the SDK.
This was an attempt to fake the includes. But since you access more headers during build (e.g. optix_stubs.h here), this attempt failed miserable.
Would it then help to have a Blender build option to download the SDK as part of the build? Though I guess downloading files as part of a build may not be allowed?
It does not matter when or how the headers are added to the build. The headers become part of the packaged binary, just a little bit transformed by the compiler.
As long as NVidia does not provide the headers in a redistributable way, or Blender finds another way to include Optix support, there is no legal way to distribute such a Blender build. (Probably NVidia could do it, which would imply an “express agreement”.)
I’ve forwarded the concern to contacts at NVIDIA. Not sure I exactly agree with the interpretation, but I’m not qualified to convince people about legal interpretations of licenses.
@Brecht, I tried your suggested approach, and it works for a local build, but Factory builds are done with no internet connectivity, hence this approach failed as well (on top of the concerns, that Stefan raised).
Consequently, we’re back on square one, and I have to tell people, that we cannot provide Blender including OptiX support for openSUSE Tumbleweed without going through further loops.
The “simplest” solution would be, that NVidia changes the copyright in order to allow unrestricted redistribution of the OptiX headers package.
- a very smart way to solve such issues. Of course, this comes with a prize: these modules must be created even more carefully than others, given the variants (CUDA versions) available today.