Windows drivers 101.3430 fix an important GUI-related crash and it's
best to prevent users from running into it.
Linux drivers weren't affected but still had relevant gpu binary
compatibility fixes, so it makes sense to keep the min-supported version
aligned across OSes.
This is very similar to D14077. There are two differences though.
First is that vertex creases are already stored in a separate layer,
and second is that we can now completely remove use of `Mesh.cd_flag`,
since that information is now inherent to whether the layers exist.
There are two functional differences here:
* Operators are used to add and remove layers instead of a property.
* The "crease" attribute can be created and removed by geometry nodes.
The second change should make various geometry nodes slightly faster,
since the "crease" attribute was always processed before. Creases are
now interpolated generically in the CustomData API too, which should
help maintain the values across edits better.
Meshes get an `edge_creases` RNA property like the existing vertex
property, to provide more efficient access to the data in Cycles.
One test failure is expected, where different rounding between float
the old char storage means that 5 additional points are scattered in
a geometry nodes test.
Differential Revision: https://developer.blender.org/D15927
This is already the case for most CMake usage.
Although some find modules are an exception to this, as they were
originally maintained externally they use some different conventions.
Also corrected bad indentation in: intern/cycles/CMakeLists.txt
For the Metal shader translation support for shader-global uniforms are remapped via macro's, and in such cases where a uniform name matches a vertex attribute name, compilation errors will occur due to this injected syntax being incompatible with the immediate code.
Also adding source-level function interface alternatives where sized arrays are passed in. These are not supported directly in Metal shading language and are instead handled as pointers. These pointers require explicit address-space qualifiers in some cases, if device/constant address space memory is passed into the function.
Ref T96261
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D15898
MTLContext provides functionality for command encoding, binding management and graphics device management. MTLImmediate provides simple draw enablement with dynamically encoded data. These draws utilise temporary scratch buffer memory to provide minimal bandwidth overhead during workload submission.
This patch also contains empty placeholders for MTLBatch and MTLDrawList to enable testing of first pixels on-screen without failure.
The Metal API also requires access to the GHOST_Context to ensure the same pre-initialized Metal GPU device is used by the viewport. Given the explicit nature of Metal, explicit control is also needed over presentation, to ensure correct work scheduling and rendering pipeline state.
Authored by Apple: Michael Parkin-White
Ref T96261
(The diff is based on 043f59cb3b)
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D15953
Now explicitly including math.h first before #defining funcitons.
This avoids undefined behavior and improves compatibility with
different SYCL compilers and backends.
Check modifier keys using XKB_STATE_MODS_DEPRESSED which is used
to check if modifiers are physically held. In practice it's unlikely
this would have caused an error for key-maps in common use.
Holding the OS (Windows) key on Win32 used key-repeat behavior.
While as far as I know it didn't cause user visible errors - sending
repeated modifier events isn't expected behavior and doesn't happen
on other platforms (or for other modifier keys).
Handling the OS key now match other modifiers in GHOST which detect
each key separately, making the behavior simpler to reason about since
mapping a single key to a modifier state is simpler, avoiding handling
that only applied to the OS-Key.
This means simulating key up/down events can use the correct modifier.
In the window-manager this is still only accessed accessed via KM_OSKEY.
Cleans up the file structure to be more similar to that of the SVM
and also makes it possible to build kernels with OSL support, but
without having to include SVM support.
This patch was split from D15902.
Differential Revision: https://developer.blender.org/D15949
Additionally, just stick to a pure error stating. Such messages
are aimed for developers and it is rather implied that oneAPI
rendering will be disabled.
A continuation of previous fix for malloc hooks which got removed
from the new glibc library.
The pre-compiled jemalloc has definitions which interpose hooks
in glibc leading to linking errors with multiple hook definitions.
A simple fix is to skip doing the workaround when using jemalloc
from pre-compiled libraries.
This will likely be revisited in the future, but for now it is
important to fix compilation errors for developers.
The pre-processor blocks contained un-balanced braces, causing a syntax
error when building with WAYLAND but not X11.
Use the same number of opening & closing braces in each pre-processor
block so changes aren't as likely to break other platforms.
Also assert when unexpected states are reached.
Starting from GLibC 2.34, deprecated `__malloc_hook` & co. have been
removed from headers, while still present in the shared library itself.
This means that it is no more possible to build Blender with USD 22.03
on recent linux systems.
While USD 22.08 has a fix to this issue, it is unlikely to be upgraded
for Blender 3.4, and definitely not for Blender 3.3.
This commit ensures Blender can build with USD 22.03 and glibc >= 2.34.
Ref.: T99618,
https://devtalk.blender.org/t/building-blender-on-linux-using-glibc-2-34-raises-linking-errors-from-the-usd-library/24185
Patch by @brecht, many thanks.
This has the advantage of being able to use information about the
existing OSL closures in various places without code duplication. In
addition, the setup code for all closures was moved to standalone
functions to avoid usage of virtual function calls in preparation for GPU
support.
This patch was split from D15902.
Differential Revision: https://developer.blender.org/D15917
