| Age | Commit message (Collapse) | Author |
|---|
|
With this patch the build system checks whether the "CUDA10_NVCC_EXECUTABLE" CMake
variable is set and if so will use that to build sm_30 kernels. Similarily for sm_8x kernels it
checks "CUDA11_NVCC_EXECUTABLE". All other kernels are built using the default CUDA
toolkit. This makes it possible to use either the CUDA 10 or CUDA 11 toolkit by default and
only selectively use the other for the kernels where its a hard requirement.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D9179
|
|
one is found
This patch changes the discovery of pre-compiled kernels, to look for any PTX, even if
it does not match the current architecture version exactly. It works because the driver can
JIT-compile PTX generated for architectures less than or equal to the current one.
This e.g. makes it possible to render on a new GPU architecture even if no pre-compiled
binary kernel was distributed for it as part of the Blender installation.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D8332
|
|
Building RC builds would parse `BLENDER_VERSION_CYCLE_NUMBER` that
doesn't exist anymore. It was removed by {D7748}.
This change removes it from `buildbot_utils.py`.
|
|
Pass codesign errors (if any) from codesign buildbot server to the
buildbot worker, so that the latter one can abort build process if
the error happens. This solves issues when non-properly-notarized
DMG package gets uploaded to the buildbot website.
|
|
Buildbot has multiple cuda versions installed. Master selects the right
cuda version based on the architecture that is compiled. {D9179}.
When building BlenderLTS it defaults to CUDA 11.1 what isn't able to
compile `sm_30` architecture. This patch selects CUDA 10.1 as default.
|
|
|
|
|
|
|
|
This is in preparation of doing builds per commit that will not be code signed.
Ref D8438
Differential Revision: https://developer.blender.org/D8451
|
|
|
|
Previously it only picked the appropriate version with the
blender-vX.XX-release branches.
|
|
The release was re-issued for unknown reasons, changes seems like they would
have no impact on Cycles and Embree is disabled by default anyway.
|
|
Follow upstream convention.
|
|
Is achieved by replacing hard-coded signed/unsigned file names with
"<uuid>" which acts as a "request ID". This way multiple workers can
put their requests into a single directory without collisions. The
code sign server will handle the requests sequentially in an unknown
order.
|
|
The directory layout on worker goes as following:
<Worker>
<Builder Name>
blender.git/
build/
install/
lib/
Adding an extra <Builder Name> after build is redundant.
Differential Revision: https://developer.blender.org/D8045
|
|
The file subversion is no longer used in the Python API or user interface,
and is now internal to Blender.
User interface, Python API and file I/O metadata now use more consistent
formatting for version numbers. Official releases use "2.83.0", "2.83.1",
and releases under development use "2.90.0 Alpha", "2.90.0 Beta".
Some Python add-ons may need to lower the Blender version in bl_info to
(2, 83, 0) or (2, 90, 0) if they used a subversion number higher than 0.
https://wiki.blender.org/wiki/Reference/Release_Notes/2.83/Python_API#Compatibility
This change is in preparation of LTS releases, and also brings us more
in line with semantic versioning.
Fixes T76058.
Differential Revision: https://developer.blender.org/D7748
|
|
|
|
This is not as much a fix as a work around, but given the real
involves replacing how we build fftw, it is not eligible for 2.83
which is in BCON3 already.
The root of the issue lies with (how we build) fftw3
The first issue is: fftw does not build with MSVC, there are other
dependencies that are not compatible with MSVC and for those we
build the libraries required with mingw64, same for fftw
The second issue is: for reasons unknown we really really really
liked all deps to link statically so wherever possible we did so.
Now during the building of the fftw it linked a few symbols from
libgcc (which we do not ship) like __chkstk_ms, for which we passed
some flags to stop generating calls to it. Problem solved! There
is no way this could possibly turn around and bite us in the rear.
fast forward to today mystery crashes that look like a race condition.
What is happening is, we tell the linker that each thread will require
a 2-megabyte stack, now if every thread immediately allocated 2 megs,
that be 'rough' on the memory usage. So, what happens is (for all apps
not just blender), 2 megs are reserved but not backed by any real memory
and the first page is allocated for use by the stack, now as the stack
grows, it will eventually grow out of that first page, and end up in
an area that has not been allocated yet, to deal with that the allocated
page is followed by a guard page, someone touches the guard page it's
time to grow the stack!
Meanwhile in FFTW is it's doing substantial allocation using alloca
(up to 64 kb) on the stack, jumping over the guard page, and ending
up in reserved but not yet committed memory, causing an access violation.
Now if you think, that doesn't sound right! something should have
protected us from that! You are correct! That thing was __chkstk_ms
which we disabled.
Given we do not want a dependency on libgcc while building with MSVC
the proper solution is to build fftw as a shared library which will
statically link any bits and pieces it needs, however that change
is a little bit too big to be doing in BCON3.
So as a work around, we change the size the stack grows from 8k to
68k which gives fftw a little bit more wiggle room to keep it out
of trouble most of the time.
Note this only sidesteps the issue, this may come up again if the
conditions are just right, and a proper solution will need to be
implemented for 2.90.
|
|
Search for all potential library names in each directory, otherwise e.g.
libImath-2_2.a from a system directory will be preferred over libImath.a even
if we specified a directory.
|
|
|
|
Found by failing bundled modules test. The bz2 library was compiled without
proper minimum SDK version flags.
|
|
Add root usd library directory to build arguments, same as other libraries.
Also fix error/typo in compile_USD regarding _is_building.
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D7563
|
|
Otherwise file browsers do not recognize the Blender executable. This is
already done for official releases.
We leave it off for non-portable builds, since that's how Linux distribution
packages will typically build Blender and we can continue to follow the OS
default there. Using a file browser to launch executables from e.g. /usr/bin
would be rare as wel.
Differential Revision: https://developer.blender.org/D7363
|
|
Path to the jsons was wrong so they were not copied
|
|
Following up to b555b8d.
Building Blender with hidden symbols but using libraries with visible symbols
was giving linker warnings, specifically for USD. So revert that for now, as
it was not needed for the bugfix.
Hide USD symbols (some of which are not in the USD namespace) to avoid potential
conflicts. May potentially help with AMD OpenCL issues in T74262.
|
|
|
|
On macOS this is part of the collada folder, but for Linux xml2 is in its own
folder for precompiled libraries.
|
|
Differential Revision: https://developer.blender.org/D7309
|
|
Ref D7309
|
|
Inspired by @mrwhite in D7295
|
|
This means symbols from Blender itself and most external libraries. We can't
just hide all because that breaks some libraries. The better solution would
be to rebuild all library dependencies with hidden visibility.
Fixes T75223: Luxrender add-on failing to load on macOS
|
|
This is annoying when one want to use system python and hence disables
the `WITH_PYTHON_INSTALL` options...
|
|
Update for D3078, I think it should be fixed
Benefits:
- after installing python 3.7 with `./build_files/build_environment/install_deps.sh`, user will be able to run `make bpy` without linking error:
- https://blender.stackexchange.com/questions/102933/a-working-guidance-for-building-blender-as-bpy-python-module
- https://stackoverflow.com/questions/36779834/compiling-blender-bpy-recompile-with-fpic
To prevent errors like `/opt/lib/python-3.7.4/bin/python3.7: error while loading shared libraries: libpython3.7m.so.1.0: cannot open shared object file: No such file or directory`, add python .so lib to ldconfig
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D7177
|
|
Need to give correct SDKROOT.
|
|
The spelling should match exactly between how package is called in
find_package and in FIND_PACKAGE_HANDLE_STANDARD_ARGS.
|
|
Happens on macOS 10.15.4 and Xcode 11.4.
The reason of failure is caused by following factors:
- xcodebuild reports full semantic macOS SDK version 10.15.4
- The actual SDK file path will only include major and minor part
of the version (10.15, MacOSX10.15.sdk)
- Previous CMake code of ours expected direct match between SDK
version and file path.
The solution is to make our detection code a bit more flexible and
additionally check for major.minor macOS SDK version in the path.
|
|
The specific goal of this change is to get rid of separate code paths
for older and newer Xcode versions.
The version 8.2 is picked since it's the latest version which runs on
macOS 10.11 (which is our current deployment target). If that turns
out too new for some reason the alternative would be to require Xcode
version 5.
|
|
The main CMakeLists already requires CMake 3.5, so there is no point of
requiring "newer" CMake on macOS.
This was a code from a while back where CMake 3 was not required on all
platforms.
|
|
Legacy code did not take into account the fact that major version can
be two digits. This was causing "Xcode 11.4" to be detected as "11.".
|
|
VS2015 has not been supported for a while now but make.bat
still had some support for it.
|
|
As a result the MD5sum of the downloaded package also changed.
|
|
Force the SDK to use its own, bundled JsonCpp sources.
|
|
|
|
|
|
|
|
- Harvest to a proper location.
- Disable STD's filesystem which is experimental and caused
linking errors when OpenXR is usedi n Blender.
|
|
Allows to have 2.82a as a beta version on buildbot.
|
|
Should be `XR_OPENXR_SDK_ROOT_DIR`.`
|
|
The OpenXR-SDK contains utilities for using the OpenXR standard
(https://www.khronos.org/openxr/). Namely C-headers and a so called
"loader" to manage runtime linking to OpenXR platforms ("runtimes")
installed on the user's system.
The WITH_XR_OPENXR build option is disabled by default for now, as there
is no code using it yet. On macOS it will remain disabled for now, it's
untested and there's no OpenXR runtime in sight for it.
Some points on the OpenXR-SDK dependency:
* The repository is located at
https://github.com/KhronosGroup/OpenXR-SDK (Apache 2).
* Notes on updating the dependency:
https://wiki.blender.org/wiki/Source/OpenXR_SDK_Dependency
* It contains a bunch of generated files, for which the sources are in a
separate repository
(https://github.com/KhronosGroup/OpenXR-SDK-Source).
* We could use that other repo by default, but I'd rather go with the
simpler solution and allow people to opt in if they want advanced dev
features.
* We currently use the OpenXR loader lib from it and the headers.
* To use the injected OpenXR API-layers from the SDK (e.g. API
validation layers), the SDK needs to be compiled from this other
repository.
The extra "XR_" prefix in the build option is to avoid mix-ups of OpenXR
with OpenEXR.
Most of this comes from the 2019 GSoC project, "Core Support of Virtual
Reality Headsets through OpenXR"
(https://wiki.blender.org/wiki/User:Severin/GSoC-2019/).
Differential Revision: https://developer.blender.org/D6188
Reviewed by: Campbell Barton, Sergey Sharybin, Bastien Montagne, Ray
Molenkamp
|
|
|
