Required to solve a crash on windows (T95367)
Mostly an uneventful update, except for FreeType
giving its cmake options a rename.
Reviewed By: brecht, sybren
Differential Revision: https://developer.blender.org/D13968
This commit specifies the exact Python version which is included in the
package name, thereby allowing `install_deps.sh` to suggest
"`-D PYTHON_VERSION=3.10`" correctly.
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D13925
Downgrade the Python zstandard from 0.17.0 to 0.16.0. The Python package
should be linked against the exact same version of libzstd as Blender is,
otherwise it will refuse to load from within the Blender executable.
Python zstandard 0.17.0 links to 1.5.1, whereas we need 1.5.0.
While install_deps tries to stay as close as possible from official
Blender versions of the libraries, it also strives to use as many distro
packages as possible.
OSL 1.11.16.0 is the minimal version that builds with llvm13, which is
the default llvm/clang version in e.g. Debian testing.
This reverts commit 086f191169.
There was apparently a problem using APPEND which wasn't referenced
in the commit log.
Added comment noting the reason for the discrepancy.
This was already done for APPLE & WIN32, which would
reference these libraries twice.
Now append BROTLI_LIBRARIES to FREETYPE_LIBRARIES when they're
required for linking.
No functional changes as all references to FREETYPE_LIBRARIES also
used BROTLI_LIBRARIES.
When LIBDIR existed, searching for system libraries would always
first search 'LIBDIR'.
This meant "WITH_SYSTEM_*" would still prefer LIBDIR versions of
libraries if they exist.
The presence of LIBDIR also ignored the setting for WITH_STATIC_LIBS
which is now restored to the cached value once pre-compiled libraries
have been handled.
This will allow building most deps with VS2019
SDL has some linker issues that are resolved in
a newer version, but that would be better handled
in a separate change.
VS2013 and VS2015 support which was broken has
been removed.
Several sub commands tried on their own
to locate python, given I wanted to look
in several locations for a broader libdir
compatibility this is best done in a
central location.
Python 3.9 is still preferred, but if
3.10-3.12 are available that be accepted
as well.
note: this is about the python version
make.bat uses to run various python helper
scripts, this change has no influence on
the python version blender itself uses.
The Brotli library only needs to be explicitly linked when using the
statically linked libraries. When using system libs they're shared, and
the .so loading mechanism takes care of dependencies.
Brotli seems to add a custom postfix to its static libraries by default,
but in Debian at least libraries are just named the same for both shared
and static versions, as usual.
So add standard name after static-specific ones.
Follow-up to rB4c617c06e9cb and rBa000de7c2a4d.
Add `libbrotlidec-static.a` and `libbrotlicommon-static.a` to the CMake
`$FREETYPE_LIBRARIES` variable; they'll be required when the Linux libs
for the FreeType upgrade lands (D13448).
The order of libraries is different compared to the similar lines in the
Windows and Apple CMake files, to prevent linker errors on Linux.
The UI team requested adding woff2 support to freetype.
this required a new dependency brotli.
This changes adds brotili to the builder and bumps
freetype to version 2.11.0
As freetype now depends on other libraries, for consistency
all use of ${FREETYPE_LIBRARY} in cmake has been updated to
use ${FREETYPE_LIBRARIES} adjustments have been made in the
windows platform file, all other platforms use cmake's
FindFreeType.cmake which already sets this variable.
reviewed by: brecht
Differential Revision: https://developer.blender.org/D13448
Since the option to enable linkers are booleans,
it's possible to enable them all at once.
Now only the first enabled + available linker is used
(with priority given to link is with better performance).
Set the linker using CMAKE_*_LINKER_FLAGS instead of {C/CXX}FLAGS.
There is no advantage in using the CFLAGS to set the linker, it has the
downside of triggering a full rebuild when changing the linker.
Tested building Blender and the bpy.so Python module.
Ref D13833
Reviewed by: sergey, brecht
Blender.xcodeproj User-supplied CFBundleIdentifier value
'org.blenderfoundation.blender' in the Info.plist must be the same as
the PRODUCT_BUNDLE_IDENTIFIER build setting value ''.
Reviewed By: #platform_macos, brecht
Differential Revision: https://developer.blender.org/D13826
Can give considerably faster linking, especially on system with many
cores.
The mold linker recently reached 1.0, see:
https://github.com/rui314/mold
The current stable release of GCC can't use this linker via
-fuse-ld=mold, so this patch uses the "-B" argument to add a binary
directory containing an alternate "ld" command that points to
"mold" (which is part of the default mold installation).
Some timing tests for linking full builds for AMD TR 3970X:
- BFD: 20.78 seconds.
- LLD: 12.16 seconds.
- GOLD: 7.21 seconds.
- MOLD: 2.53 seconds.
Ref D13807
Reviewed by: sergey, brecht
And change install_deps.sh to build shared (instead of static) FFMPEG
libraries, for consistency with other library dependencies and to simplify
the logic. This may require users of install_deps.sh to rebuild FFMPEG.
This is the last step that lets us get rid of LIBPATH variables and
link_directories() entirely, as recommended by the CMake docs.
Some fixes were needed in the find FFMPEG module to make it actually work,
this code was unused up to now.
Followup to D8855.
Differential Revision: https://developer.blender.org/D9177
And change install_deps.sh to build shared (instead of static) FFMPEG
libraries, for consistency with other library dependencies and to simplify
the logic. This may require users of install_deps.sh to rebuild FFMPEG.
This is the last step that lets us get rid of LIBPATH variables and
link_directories() entirely, as recommended by the CMake docs.
Some fixes were needed in the find FFMPEG module to make it actually work,
this code was unused up to now.
Followup to D8855.
Differential Revision: https://developer.blender.org/D9177
This patch implements the vector types (i.e:`float2`) by making heavy
usage of templating. All vector functions are now outside of the vector
classes (inside the `blender::math` namespace) and are not vector size
dependent for the most part.
In the ongoing effort to make shaders less GL centric, we are aiming
to share more code between GLSL and C++ to avoid code duplication.
####Motivations:
- We are aiming to share UBO and SSBO structures between GLSL and C++.
This means we will use many of the existing vector types and others
we currently don't have (uintX, intX). All these variations were
asking for many more code duplication.
- Deduplicate existing code which is duplicated for each vector size.
- We also want to share small functions. Which means that vector
functions should be static and not in the class namespace.
- Reduce friction to use these types in new projects due to their
incompleteness.
- The current state of the `BLI_(float|double|mpq)(2|3|4).hh` is a
bit of a let down. Most clases are incomplete, out of sync with each
others with different codestyles, and some functions that should be
static are not (i.e: `float3::reflect()`).
####Upsides:
- Still support `.x, .y, .z, .w` for readability.
- Compact, readable and easilly extendable.
- All of the vector functions are available for all the vectors types
and can be restricted to certain types. Also template specialization
let us define exception for special class (like mpq).
- With optimization ON, the compiler unroll the loops and performance
is the same.
####Downsides:
- Might impact debugability. Though I would arge that the bugs are
rarelly caused by the vector class itself (since the operations are
quite trivial) but by the type conversions.
- Might impact compile time. I did not saw a significant impact since
the usage is not really widespread.
- Functions needs to be rewritten to support arbitrary vector length.
For instance, one can't call `len_squared_v3v3` in
`math::length_squared()` and call it a day.
- Type cast does not work with the template version of the `math::`
vector functions. Meaning you need to manually cast `float *` and
`(float *)[3]` to `float3` for the function calls.
i.e: `math::distance_squared(float3(nearest.co), positions[i]);`
- Some parts might loose in readability:
`float3::dot(v1.normalized(), v2.normalized())`
becoming
`math::dot(math::normalize(v1), math::normalize(v2))`
But I propose, when appropriate, to use
`using namespace blender::math;` on function local or file scope to
increase readability.
`dot(normalize(v1), normalize(v2))`
####Consideration:
- Include back `.length()` method. It is quite handy and is more C++
oriented.
- I considered the GLM library as a candidate for replacement. It felt
like too much for what we need and would be difficult to extend / modify
to our needs.
- I used Macros to reduce code in operators declaration and potential
copy paste bugs. This could reduce debugability and could be reverted.
- This touches `delaunay_2d.cc` and the intersection code. I would like
to know @howardt opinion on the matter.
- The `noexcept` on the copy constructor of `mpq(2|3)` is being removed.
But according to @JacquesLucke it is not a real problem for now.
I would like to give a huge thanks to @JacquesLucke who helped during this
and pushed me to reduce the duplication further.
Reviewed By: brecht, sergey, JacquesLucke
Differential Revision: https://developer.blender.org/D13791
This patch implements the vector types (i.e:float2) by making heavy
usage of templating. All vector functions are now outside of the vector
classes (inside the blender::math namespace) and are not vector size
dependent for the most part.
In the ongoing effort to make shaders less GL centric, we are aiming
to share more code between GLSL and C++ to avoid code duplication.
Motivations:
- We are aiming to share UBO and SSBO structures between GLSL and C++.
This means we will use many of the existing vector types and others we
currently don't have (uintX, intX). All these variations were asking
for many more code duplication.
- Deduplicate existing code which is duplicated for each vector size.
- We also want to share small functions. Which means that vector functions
should be static and not in the class namespace.
- Reduce friction to use these types in new projects due to their
incompleteness.
- The current state of the BLI_(float|double|mpq)(2|3|4).hh is a bit of a
let down. Most clases are incomplete, out of sync with each others with
different codestyles, and some functions that should be static are not
(i.e: float3::reflect()).
Upsides:
- Still support .x, .y, .z, .w for readability.
- Compact, readable and easilly extendable.
- All of the vector functions are available for all the vectors types and
can be restricted to certain types. Also template specialization let us
define exception for special class (like mpq).
- With optimization ON, the compiler unroll the loops and performance is
the same.
Downsides:
- Might impact debugability. Though I would arge that the bugs are rarelly
caused by the vector class itself (since the operations are quite trivial)
but by the type conversions.
- Might impact compile time. I did not saw a significant impact since the
usage is not really widespread.
- Functions needs to be rewritten to support arbitrary vector length. For
instance, one can't call len_squared_v3v3 in math::length_squared() and
call it a day.
- Type cast does not work with the template version of the math:: vector
functions. Meaning you need to manually cast float * and (float *)[3] to
float3 for the function calls.
i.e: math::distance_squared(float3(nearest.co), positions[i]);
- Some parts might loose in readability:
float3::dot(v1.normalized(), v2.normalized())
becoming
math::dot(math::normalize(v1), math::normalize(v2))
But I propose, when appropriate, to use
using namespace blender::math; on function local or file scope to
increase readability. dot(normalize(v1), normalize(v2))
Consideration:
- Include back .length() method. It is quite handy and is more C++
oriented.
- I considered the GLM library as a candidate for replacement.
It felt like too much for what we need and would be difficult to
extend / modify to our needs.
- I used Macros to reduce code in operators declaration and potential
copy paste bugs. This could reduce debugability and could be reverted.
- This touches delaunay_2d.cc and the intersection code. I would like to
know @Howard Trickey (howardt) opinion on the matter.
- The noexcept on the copy constructor of mpq(2|3) is being removed.
But according to @Jacques Lucke (JacquesLucke) it is not a real problem
for now.
I would like to give a huge thanks to @Jacques Lucke (JacquesLucke) who
helped during this and pushed me to reduce the duplication further.
Reviewed By: brecht, sergey, JacquesLucke
Differential Revision: http://developer.blender.org/D13791
