Perform delayed freeing of the geometry BVHs similar to OptiX.
Previously BLAS memory was allocated in the device class as part of
device_update, but released in the BVHHIPRT destructor which gets called
when deleting geometry outside of device_update.
To avoid the GPU accessing unmapped memory, do a delayed free of this
memory in the device class as part of either device_update or device
destruction. This ensures it is in sync with other device memory changes.
Fix#148276Fix#139013Fix#138043Fix#140763
Pull Request: https://projects.blender.org/blender/blender/pulls/147247
Caused by some tricky use after-free / stack corruption.
This affect both Cycles and EEVEE.
The `sms` local variable is getting dereferenced by `get_inscattering`
inside the threaded for loop but is passed by copy to the lambda expression.
This makes its lifetime ill-defined in a multithreaded context.
I am not fully sure about the rules at play here so maybe my understanding
is wrong. But removing the call to `get_inscattering` avoids the crash.
Note that `SkyMultipleScattering` is also very big (it contains the whole LUT).
So copying it might have caused stack overflow. But that should trigger a
system interupt.
Passing everything by references fixes the issue.
This seems to be safe since all as the other local variables are `const` anyway.
Also the loop doesn't seem to modify the one that aren't.
Pull Request: https://projects.blender.org/blender/blender/pulls/148260
The Cycles cpu/device.cpp `device_cpu_capabilities()` function used to
fill out a string of supported CPU capabilities separated with spaces,
with some trailing-space cleaning logic at the end of the function.
However, if no check succeeded, and especially after commit 2bf6d0fd71
which left only one check and removed the need for removing trailing
spaces, the check would run against an empty string, resulting in an
unsigned 0 - 1 operation which would then cause an out of bound access
catched by ASan.
Fixed by removing the now superflous trailing space cleaning logic and
simplifying to a direct return.
Pull Request: https://projects.blender.org/blender/blender/pulls/148227
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
