The OSL dependency is built with target sm_50 currently, which means
that LLVM defaults to generating PTX version 4.0. However, due to an
apparent bug in LLVM 20 it still uses instructions that were only
introduced in PTX version 6.0. As a result OptiX refuses to load the
shadeops PTX with an `OPTIX_ERROR_INVALID_INPUT` error.
To fix this, raise the PTX version generated by LLVM to 6.0 for both the
shadeops module (which previously used 4.0) and also any generated code
(which previously used 5.0) to be safe. PTX version 6.0 was introduced with
CUDA 9, so it has pretty long driver backwards compatibility still.
This commit contains fixes for the OSL, to fully fix the original report
a recompiled OSL libraries would need to land for the affected platforms.
Ref #147361
Pull Request: https://projects.blender.org/blender/blender/pulls/147620
This new version of the graphics compiler improves performance
for the majority of supported Intel devices and adds support
for upcoming Intel hardware. Such an upgrade also requires
an increase in the minimal supported driver version on Windows,
which is why these changes are combined together with
the ocloc upgrade.
Previously set minimal version 101.6557 was increased to 101.8132.
Pull Request: https://projects.blender.org/blender/blender/pulls/147460
Add sound pitch correction functionality, so that retimed sound strips
can preserve their original pitch.
This has been implemented as a GSoC 2025 project. Actual pitch
correction is done with Rubberband library, which has been already
included into Blender 5.0 library builds; and then most of the other
code has been in Audaspace, which was already updated within Blender
tree earlier.
So this PR just flips on Rubberband build option, and adds the
checkbox to VSE sound strips for pitch correction (on by default for
newly created sound strips). Pitch correction works with both
simple whole-strip retiming, as well as more complex retiming setups
where different parts of the strip use different speeds.
Co-authored-by: Aras Pranckevicius <aras@nesnausk.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/143347
Due to this bug only the first item in the current PATH on the system
is used when running Blender.
The PATH is appended to a string type variable, which is then used as
one element of a list in build_files\cmake\testing.cmake line 24. Since
in cmake the semicolon is a list element delimiter, we need to escape
all the semicolons in our PATH string if we want to use the variable as
a single entry in the list.
Pull Request: https://projects.blender.org/blender/blender/pulls/146770
This is the first step of moving the create infos
back inside shader sources.
All info files are now treated as source files.
However, they are not considered in the include tree
yet. This will come in another following PR.
Each shader source file now generate a `.info` file
containing only the create info declarations.
This renames all info files so that they do not
conflict with their previous versions that were
copied (non-generated).
Pull Request: https://projects.blender.org/blender/blender/pulls/146676
This option has been removed in vs2026 and will cause a build error,
disabling this option results in our default /DEBUG being used
which is equivalent to /debug:full which is the suggested
replacement
There is no CMake version yet that support VS2026, support is
currently limited to ninja based builds.
CMake does not know where to look for the MSVC 2026 Runtime
it copies the wrong CRT leading to startup issues, for this reason
WITH_WINDOWS_BUNDLE_CRT has been disabled for VS2026 + CMake < 4.2.0.
Builds done with VS2026 are for this reason *NOT* distributable to
end users at this point in time.
CMake 4.2.0 Is *expected* to have VS 2026 support [1]
But further testing is likely required.
Things of note:
- They stopped using the "preview" channel and have rebranded to
"Insiders" the make.bat options have been updated accordingly to
select the 2026 Insiders build, you need to pass 2026i to make.bat
- All tests seem to pass on my system
- No new warnings, pretty smooth update
[1] https://gitlab.kitware.com/cmake/cmake/-/merge_requests/11168
Prior to this commit, the Rocky Linux dependency builder environment
setup script would download the latest version of CUDA rather than a
specific version.
This makes it harder to ensure a consistent environment for people
building Blender's libraries, and recently, it has lead to errors
building some of Blender's dependencies due to incompatibilites with
the latest CUDA version and the library versions we build.
E.g. The OSL version we use does not work properly with CUDA 13.
Pull Request: https://projects.blender.org/blender/blender/pulls/145859
Blender had some support for using MoltenVK. However there are some key
issues why MotlenVK cannot be used. Bugs have been reported up-stream.
As it doesn't work and holds back regular developments it will be removed
from the main branch.
Any efforts on making Vulkan run on Apple (including KosmicKrisp)
is considered a community effort and can be done in a development
branch.
Pull Request: https://projects.blender.org/blender/blender/pulls/144602
The setting is called `lfs.remote.searchall`, the `remote` part of it being
an exact string, it is not to be expanded with the name of the remote.
Whenever name of the remote is to be used Git documentation uses `<remote>`
syntax.
Tested by triggering the original issue (clone the Github mirror, make update,
wait for a new LFS object appear in the upstream, make update again). Before
this change the LFS object will not be fetched, and based on the Git Curl's
log only the github origin was used to fetch LFS object, none other remotes
were tried.
Also confirmed by checking the Git-LFS code:
https://github.com/git-lfs/git-lfs/blob/v3.7.0/config/config.go#L232
Pull Request: https://projects.blender.org/blender/blender/pulls/144574
This follows the other CMake "modernization" commits, this time for
`bf_intern_openvdb` and the OpenVDB dependency itself.
The difference with this one is that `intern/openvdb` becomes an
"optional" dependency itself. This is because downstream consumers often
want to include this dependency rather than openvdb directly, so this
target must also be optional. Optional, in this case, means the target
always exists but may be entirely empty.
Summary
- If you are using BKE APIs to access openvdb features, then use the
`bf::blenkernel` target
- If you are only using `intern/openvdb` APIs then use the
`bf::intern::optional::openvdb` target (rare)
- For all other cases, use the `bf::dependencies::optional::openvdb`
target (rare)
context: https://devtalk.blender.org/t/cmake-cleanup/30260
Pull Request: https://projects.blender.org/blender/blender/pulls/137071
Add a [Python code generator][1] that takes an OpenAPI definition and
outputs the corresponding data model as [dataclasses][2]
This is intended to be used in the Remote Asset Library project, to
create, download, parse, and validate information of a remote asset
library.
[1]: https://koxudaxi.github.io/datamodel-code-generator/
[2]: https://docs.python.org/3/library/dataclasses.html
## Running the Generator
The generator is a Python script, which creates its own Python
virtualenv, installs the dependencies it needs, and then runs the
generator within that virtualenv.
The script is intended to run via the `generate_datamodels` CMake
target. For example, `ninja generate_datamodels` in the build
directory.
## Details
The virtualenv is created in Blender's build directory, and is not
cleaned up after running. This means that subsequent runs will just
use it directly, instead of reinstalling dependencies on every run.
## Generated Code & Interaction with Build System
It is my intention that the code generation _only_ happens when the
OpenAPI specification changes. This means that the generated code will
be committed to Git like any hand-written code. Building Blender will
therefore _not_ require the code generator to run. Only people working
on the area that uses the generated code will have to deal with this.
Pull Request: https://projects.blender.org/blender/blender/pulls/139495
Some users still have issues getting LFS files downloaded properly, though the
exact cause is unclear. Normally with a properly installed git lfs, git pull
should already take care of it.
When for whatever reason that is not the case and files have not been fetched
yet, now do lfs pull which is the same as lfs fetch + lfs checkout. Even when
git pull can not run.
Ref #143461
Pull Request: https://projects.blender.org/blender/blender/pulls/143478
Add a simple deprecation message to warn users that macOS pre-compiled
dependencies are no longer provided starting with 5.0, and that they
should either build the libraries themselves or downgrade to 4.5.
This is what the warning looks like in context:
```
$ make update
git lfs install --skip-repo
Git LFS initialized.
Configuring Precompiled Libraries
=================================
Detected platform : macos
Detected architecture : x64
Updating Libraries
==================
* Skipping lib/linux_x64
* Skipping lib/macos_arm64
* Skipping lib/windows_x64
* Skipping lib/windows_arm64
Update finished with the following messages
===========================================
Blender repository skipped: you have unstaged changes
WARNING: macOS x64/Intel support was dropped in Blender 5.0.
As such, pre-compiled dependencies are no longer provided.
You may build the dependencies yourself, or downgrade to Blender 4.5.
For more details, please see: https://devtalk.blender.org/t/38835
```
Pull Request: https://projects.blender.org/blender/blender/pulls/143133
The issue was that `git ls-files` will per default escape unicode
characters. This make it so that our python script couldn't find any
files or folder as it expected unescaped characters.
This reverts commit 81e862140f
binary packages turned out to have issues for debug builds on windows
as they link to python_311d.dll and none of the binary packages offfered
on pypi offered a debug build. Building pydantic from source was rejected
due to no rust build infrastructure being in place yet and deemed not
worth the effort for this one library dependency, an alternate solution
was chosen by the assets team that requested this dependency.
This moves the logic to create the parent folder to data_to_c itself
rather than having cmake do it, preventing several thousand cmake instances
to be started.
see pr#141404 for details/benchmarks
Pull Request: https://projects.blender.org/blender/blender/pulls/141404
As requested by @dr.sybren and approved by the admins
Also pydantics deps :
annotated-types 0.7.0
pydantic-core 2.33.2
typing-extensions 4.14.0
typing-inspection 0.4.1
these are installed as binary packages agreed upon with the admins
versions determined by just pip installing it and seeing what it dragged in.
as some of these are binary packages that will differ per platform, there will
be a per platform hash for some packages now unfortunately
Pull Request: https://projects.blender.org/blender/blender/pulls/140434
