Only use this feature when building for 1 or 2 CUDA architectures.
Otherwise CMake will build the binaries in parallel, and NVCC will then
also launch multiple threads for each binary.
We could add more manual control for this, but the main use case for
this is local builds and an automatic heuristic seems more likely to
help than an option that developers or users might not discover.
For minimal memory usage WITH_CYCLES_CUDA_BUILD_SERIAL still exists
to use only 1 thread for CUDA compilation.
Pull Request: https://projects.blender.org/blender/blender/pulls/147303
This is an alternate solution to !146889 to improve labels in the
camera UI, while being much less invasive. It doesn't take custom
labels into account, but it simply uses the parameter names with title
case.
Pull Request: https://projects.blender.org/blender/blender/pulls/148141
Swapchains can be destroyed safely after a new image
is presented in a new swapchain or when all submission
and presentation fences are signaled, this last ones
where missing causing issues with some drivers when
recreating swapchains.
Pull Request: https://projects.blender.org/blender/blender/pulls/147226
Follow on from PR #141891. The `MTLAccelerationStructureUsagePreferFastIntersection` flag didn't exist until Xcode 26.0, so we ensure that it is defined for forward-compatibility. The runtime `if (@available(macos 26.0, *))` checks still remain.
Pull Request: https://projects.blender.org/blender/blender/pulls/147561
Resolve regression with GNOME-48 & LIBDECOR caused by fix for GNOME-49
(see !148104).
New normal (non-maximized) windows were not refreshing and ignored
cursor input. Workaround the issue be resetting the title.
See code-comments for details.
Ref !148178
Opening "normal" windows (non-maximized) windows was hanging.
Blender was waiting for a "configure" event with a valid size,
which stopped being sent in GNOME-49.
Even though GNOME-49.1 will resolve the problem, according to the
GNOME developers Blender's use of Wayland was incorrect.
Resolve the issue with the following changes:
- Don't wait for the `xdg_toplevel` to be when creating new windows.
Instead, defer setting the window state using logic that was already
used for Vulkan.
- Set new window's pending size - used if no size is received
from LIBDECOR's "configure" callback.
- When the window is "configured" always set the window "state"
even if the size is not yet known.
Ref !148104
Related to https://projects.blender.org/blender/blender/pulls/147994 in
which clang-cl builds failed passing the Windows SDK libraries paths to
the compiler.
The previous CMake implementation tried to reverse engineer these paths
at CMake configuration time but failed with `clang-cl`.
The environment variables set by vcvars that could have been useful
aren't always available when cmake is called, so now we keep the `LIB`
environment variable intact at compile time and pass the other
additional compiler libraries paths - that are better defined at CMake
configuration time - separately through `-L` compiler arguments.
Pull Request: https://projects.blender.org/blender/blender/pulls/148035
This commit fixes an issue where WM cursor grabbing, when used
in "hidden" mode (`GHOST_kGrabHide`) would unexpectedly not prevent the
cursor from escaping the Blender window and revealing itself when
hovering over macOS desktop elements like the application Dock.
Looking at the original issue in past Blender versions, testing with the
Walk Navigation operator, this used to work in Blender 3.2, and broke
in Blender 3.3. Bisecting leads to commit 4c4e8cc926 (Fix T99021:
Walk-mode doesn't work in Wayland), which switched the Walk Navigation
mouse warping method from custom `WM_cursor_warp` logic to using
`WM_cursor_grab_{enable/disable}`.
Then, looking at the WM_cursor_grab Cocoa implementation, more
especially at the `GHOST_kGrabHide` case in `handleMouseEvent`, a
comment ("Cursor hidden grab operation : no cursor move") suggests that
hiding the cursor would previously prevent it from moving (possibly in
earlier macOS versions?).
This fix, the simplest I could come up with other than implementing
simple window warping for the `GHOST_kGrabHide` case (similar to what's
done on Windows, see #113066) is to use
`CGAssociateMouseAndMouseCursorPosition` to disable cursor movements
for the duration of the hidden grab, effectively restoring the original
behavior indicated in the comment.
Pull Request: https://projects.blender.org/blender/blender/pulls/148007
When a Cycles render is uneven (E.g. a small portion of the image takes
significantly longer to render than the rest of the image), then GPUs
typically suffer from poor performance due to low occupancy unless a
large number of samples is scheduled to compensate for that small
complex region.
Due to how Cycles render scheduler is setup, Cycles tries to
increase GPU occupancy by increasing the number of scheduled samples,
but also balance render preview update time by scaling back
the number of scheduled samples based on the previous workloads time
per sample to try and fit within the target update time.
However using the previous workloads time per sample to scale back the
scheduled number of samples gives suboptimal results because the
previous workloads time per sample is usually not representative of the
new time per sample that occurs as GPU occupancy increases, because
increasing GPU occupancy typically results in reduced time per samples.
This commit improves on this issue by assuming that increasing GPU
occupancy linearly improves performance, and adjusts the function
that scales back the sample count to fit within a specific update
window to use this assumption. This leads to Cycles increasing the
amount of work scheduled onto the GPU quicker at the beginning of
uneven/low occupancy scenes, generally leading to improved performance,
especially when rendering at low sample counts or with strict
time limits.
Ref #147954
Pull Request: https://projects.blender.org/blender/blender/pulls/147950
Found when running with ASAN on through Xcode. Crashed on exit.
Multiple threads can release their own context at the same time
and thus release the `metal_layer_` multiple times, resulting
in use after free.
Pull Request: https://projects.blender.org/blender/blender/pulls/147972
Add a command line option to load Blender without a window frame.
Currently this is only used on Wayland, enabled for WITH_UI_TESTS since
attempting to load LIBDECOR caused the tests to crash on start on Fedora.
For tests there is no need to use LIBDECOR, so disable the window frame.
This can also be used by users who don't want to use the X11 fallback if
LIBDECOR can't be found.
Ref !147716
Commit 6c6d1a9b63 allowed several units to OSL camera shaders'
parameters. Only meters 'm' were supported as distance units, because
others cannot be converted automatically into the shader' unit.
This commit allows using 'mm' in addition to 'm', and makes the
Blender property use a 'DISTANCE_CAMERA' subtype. This assumes that
someone using 'mm' specifically wants to use the value for camera
parameters, which means it can be used as is, without any conversion
in the shader.
The camera templates were updated to use a focal length in mm.
Pull Request: https://projects.blender.org/blender/blender/pulls/147347
In OSL custom cameras, the current aperture size depends on the focal
length of the Blender camera, even though it is not usable by the
shader. This gives incoherent values to the depth of field.
To ignore this factor, this commit makes the custom camera behave the
same as the orthographic camera, by not being multiplied by the focal
length.
To compensate for that, the multiplication must happen inside the
shader. This adjustment was done in the advanced camera shader
template.
Pull Request: https://projects.blender.org/blender/blender/pulls/147346
In some hardware configurations, it is possible that DPC++ or
Intel Drivers wrongfully report all devices twice. It is already
being worked on internally, and the fixes will be available in
the future - but for now, we need a workaround for this problem
in Blender as well, to ensure that our end-users are not impacted.
Pull Request: https://projects.blender.org/blender/blender/pulls/147731
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
These changes are already in place de facto, as the check for
the minimal driver version in the Blender code was already
updated. This commit simply adds the UI update, which I
initially forgot to perform.
Pull Request: https://projects.blender.org/blender/blender/pulls/147459
This PR adds Vulkan/oneAPI graphics interop to Cycles. Just like for
CUDA and HIP interop, persistent memory mapping is used, as there could
potentially be some overhead of continuously mapping/unmapping buffers.
Pull Request: https://projects.blender.org/blender/blender/pulls/144442
For metal version after 3.2 it's possible to log debugging messages, it
works similar to `printf()`, except for a few differences:
- `%s` is not supported,
- `double` doesn't exist, so no casting to double for `%f`,
- no `\n` needed at the end of the format string.
To see the print in the console, environment variables `MTL_LOG_LEVEL`
should be set to `MTLLogLevelDebug`, and `MTL_LOG_TO_STDERR` should be
set to `1`. See
https://developer.apple.com/documentation/metal/logging-shader-debug-messages
Right now `printf()`, `print_float()`, `print_float2()`,
`print_float3()` and `print_float4()` are supported.
Thanks to @fclem for finding this out.
Pull Request: https://projects.blender.org/blender/blender/pulls/146585
We used to set shader->osl_surface_ref during shader compilation and then
pushed it into the shared vectors.
This worked as long as everything was serial - but after the multithreading
change, we a) compile everything and then b) build the shared vectors since
just pushing into them from multiple threads would not work.
However, if there are multiple devices, then each shader will be compiled
multiple times - so in the end, shader->osl_surface_ref etc. will be set
to the last device's value. Then, we end up pushing that value into every
device's vectors, which breaks for the earler devices.
The fix is simple - just preallocate the vectors and pass the correct index
into the compilation function. This way, each thread can safely store its
result and we can get rid of shader->osl_surface_ref entirely.
Note that while multiple shaders are compiled in parallel, the loop over
devices for a given shader is serial, so there's no concern of conflicts
over other shader internals.
Pull Request: https://projects.blender.org/blender/blender/pulls/146617
