Upstream builds and tests with a specific Python version. Further, the
Blender addon ecosystem generally expects that version to be used, so
ensure that the correct version is used when upstream changes. Python
often makes backwards-incompatible changes in “minor” releases.
To quote upstream source code:
> Blender only supports a single Python version at the moment.
Perform the check during preConfigure since we can check it then and so
it avoids wasting time configuring+building and then failing.
An unwrapped check for `nix run`-ing on the host platform,
instead of `nix build`-ing in the sandbox
E.g.:
```
❯ nix run -f ./. --arg config '{ cudaSupport = true; cudaCapabilities = [ "8.6" ]; cudaEnableForwardCompat = false; allowUnfree = true; }' -L blender.gpuChecks.cudaAvailable.unwrapped
Blender 4.0.1
Read prefs: "/home/user/.config/blender/4.0/config/userpref.blend"
CUDA is available
Blender quit
❯ nix build -f ./. --arg config '{ cudaSupport = true; cudaCapabilities = [ "8.6" ]; cudaEnableForwardCompat = false; allowUnfree = true; }' -L blender.gpuChecks
blender> Blender 4.0.1
blender> could not get a list of mounted file-systems
blender> CUDA is available
blender> Blender quit
```
currently builds on aarch64-darwin, but not on x86_64-darwin.
Blender (specifically the ghost window library) depends on "metal" on
apple devices.
(For details see source/intern/ghost/intern/GHOST_System.cc line 416ff)
It cannot build without it. Metal support should be
introduced by apple sdk 11_1 (?) onward. Once this has been updated in
nixpkgs, this derivation can be revised.
Signed-off-by: Florian Brandes <florian.brandes@posteo.de>
Co-authored-by: Alexis Hildebrandt <afh@surryhill.net>
We build openusd without OSL support as we don’t build Blender with OSL
support normally, and so seems unnecessary and adds significantly to the
closure size due to (as noted in Blender drv comments) the inclusion of
LLVM.
This makes them match what the fn param names *would* be, making it
easier to refactor e.g. to `{ python3Packages, ... }: mkDerivation …` in
the future if desired. It also potentially reduces first-glance
confusion that it might be Python 2 in-use.
Leave the passthru names as-is to preserve backwards-compatibility, but
also as there appears to be some precedent for naming them like this.
- Format to draft RFC 0166 style (via nixfmt-rfc-style)
- Alphabetize lists unless there is a somewhat-apparent reason not to
- Reorder attrs based roughly on the order they are used by the builder
As noted in comment, Blender is now using private libdecor APIs not in
the headers, so need to patch to build against it. I think it probably
works when Blender does dynamic loading at runtime since it uses the fn
defs it defines in that case, but we don’t want to do that, it seems (as
we already set `-DWITH_GHOST_WAYLAND_DYNLOAD=OFF`).
Based on #257780, separated since it introduces significant changes.
bpycv: update passthru.tests.render
blender-with-packages: deprecated
it is still backwards compatible, but no longer preferred.
blender: fixup for ROCm 5.7.0
opensycl: fixup for ROCm 5.7.0
magma: fixup for ROCm 5.7.0
torch: fixup for ROCm 5.7.0
cp2k: fixup for ROCm 5.7.0
sirius: fixup for ROCm 5.7.0
spfft: fixup for ROCm 5.7.0
spla: fixup for ROCm 5.7.0
Basic headless render test for Eevee and Cycles CPU. Did this because I
got a bit tired of testing render manually for both renderers (though
it’s not that much work).
Note that `render.threads` config is used only by Cycles. Using 1 thread
chosen because it’s not meaningfully slower than more for this render,
and it simplifies things to just pick 1 instead of making it dynamic.
Have chosen 32 samples since it’s not meaningfully slower than 1 (even
with `--cores 1`), and it’s not so small that maybe it’s not
representative, and too-low a number and there are artifacts that may
make it appear like something is broken.
Cycles denoising needs openimagedenoise and is not currently included in
aarch64 build.
See https://github.com/NixOS/nixpkgs/issues/217921
Blender sets WITH_DRACO=OFF if WITH_PYTHON_INSTALL=OFF, however that’s
not totally necessary. Removing that forced-set then builds with
WITH_DRACO=ON, however Blender fails to launch because this creates
e.g. `share/blender/3.6/python`, and Blender then sets this as Python’s
home dir, so Python fails to init since it expects Python core to be
there (and it’s not). I couldn’t figure out how Blender sets Python’s
home dir, and explicitly setting PYTHONHOME in the env didn’t have any
effect. So instead just rename that dir to python-ext to avoid this
behavior. All that is left then is to adjust where Blender is looking
for the Draco lib.
This functionality may be verified by:
1. Visiting File → Export → glTF 2.0
2. In the right side panel (press the gear icon in top-right if not
visible), expanding “Data”
3. Enabling “Compression”
4. Press “Export glTF 2.0”
5. Verify:
- Blender stdout+stderr shows “Draco mesh compression is available”
- no error or warning message
- exported file exists
Eliminate uses of `config.cudaSupport or false` and alike, since the
option is now declared in config.nix with a default value
fd .nix -t f -x sed 's/config\.cudaSupport or false, cudaPackages [?] [{][}]/config.cudaSupport, cudaPackages ? { }/' '{}' -i
fd .nix -t f -x sed 's/config\.cudaSupport or false/config.cudaSupport/' '{}' -i
fd .nix -t f -x sed 's/cudaSupport = pkgs.config.cudaSupport/inherit (pkgs.config) cudaSupport/' '{}' -i
fd .nix -t f -x sed 's/cudaSupport = config.cudaSupport/inherit (config) cudaSupport/' '{}' -i
