This commit adds some extra prints to terminal related to oneAPI driver
information in the situation that the driver version is considered
incompatible with the current version of Cycles.
Pull Request: https://projects.blender.org/blender/blender/pulls/137272
This patch adds initial cursor support for the blade tool, with bitmaps
for 16x16, 24x24, and 32x32 cursors.
Additional Changes:
- Locked strips now show a "stop" icon when hovered over.
- Previously, the frame to split was truncated when clicking in between frames.
Now, round to the closest frame.
- Previously, the blade operator was able to select padded strip handles
outside of strip bounds. This bug has been resolved, so that selection with
the blade tool can only happen via box-select passthrough.
Pull Request: https://projects.blender.org/blender/blender/pulls/136749
This will be needed to determine if there are volumes in the scene, before
allocation passes to aid volume sampling.
The kernels are now also loaded in the middle of scene update, at a place
where kernel features are known but before the kernels are needed for
displacement and background light evaluation..
Updating the camera to final resolution for progressive refinement still
happens later.
Pull Request: https://projects.blender.org/blender/blender/pulls/137228
The crash was caused by an overflow in the opgl_path_segment_storage
array. It happened because shadow catcher paths would write to the
segments but not clear them. This made it so the next render loop
iteration for the main path starts with non-empty segments in the
guiding data.
Disable training when megakernel is called for the shadow catcher
state.
To ensure this issue is not forgotten when the guiding is ported to
GPU add asserts in the `guiding.h`. While it is a no-op for default
GPU kernels sometimes we do compile debug kernels. But also it acts
as a plain-text reminder to the future-us in working on the code.
There is now also an assert before the main path megakernel to help
catching such cases in the future.
Pull Request: https://projects.blender.org/blender/blender/pulls/137291
Remove logic to access LIBDECOR's underlying XDG window since it
required an "dummy-buffer" workaround which caused a crash with recent
drivers that require a DMA buffer.
This introduces a slight flicker on startup in some cases
see code-comments for details.
Ref: !136289
Some OpenXR platforms do not support OpenGL or Vulkan. To support these
platforms we use a bridge. Blender still renders in OpenGL/Vulkan, but
will copy the render result into a D3D11 swapchain.
OpenGL doesn this by importing the D3D11 swapchain into the OpenGL
context and perfor OpenGL calls to update the swapchain. However for
vulkan that could lead to construct 3 context for OpenXR
- Blender GPU Context
- OpenXR D3D Context
- New context that imports the Blender render result and the OpenXR
Swapchain image and copies them.
Due to Direct3D limitations importing into a vulkan context has known
issues (driver + extensions). Secondly we are not sure if we are running
on the same device as the OpenXR swapchain. The solution provided with
this PR is to only support CPU data transfers.
**SteamVR using d3d bridge**
SteamVR normally would use the Vulkan binding. But by changing the binding
priority in code you can make it select the D3D bridge.
<img width="1518" alt="Screenshot 2025-04-10 114534.png" src="attachments/f856bb2b-9ad5-4bb2-9cfd-a1412da9edd1">
It has been tested and validated to work using Mixed reality portal as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/137264
Current Windows on ARM GPUs don't support
extenral memory. External memory is required
for OpenXR. So most likely OpenXR will not work
on these devices.
Most (read all) OpenXR platforms that support
vulkan also require external memory. So might
just be that those platforms won't work at all
on these devices.
In any case when not supported, the GHOST
OpenXR platform will use CPU for data transfer.
The goal is to reduce the affect of the fmod() used in the noise code,
which was initially reported in the comment:
https://projects.blender.org/blender/blender/pulls/119884#issuecomment-1258902
Basic idea is to benefit from SIMD vectorization on CPU.
Tested on Linux i9-11900K and macOS on M2 Ultra, in both cases performance
after this change is very close to what it could be with the fmod() commented
out (the call itself, `p = p + precision_correction`).
On macOS the penalty of fmod() was about 10%, on Linux it was closer to 30%
when built with GCC-13. With Linux builds from the buildbot it is more like 18%.
The optimization is only done for 3d and 4d noise. It might be possible to
gain some performance improvement for 1d and 2d cases, but the approach would
need to be different: we'd need to optimize scalar version fmodf(). Maybe
tricks with integer cast will be faster (since we are a bit optimistic in the
kernel and do not guarantee exact behavior in extreme cases such as NaN inputs).
Pull Request: https://projects.blender.org/blender/blender/pulls/137109
This PR add support to use a win32 handle to perform share render
result with the OpenXR vulkan instance. This is only possible when
the GPU matches. Otherwise a CPU roundtrip will be performed.
Pull Request: https://projects.blender.org/blender/blender/pulls/137093
Commit be63ebd961
This is causing issues with CUDA kernel compilation in some setups, even
though the builbot is ok. Since this isn't yet working for oneAPI anyway,
revert all the changes to Cycles kernel compilation for now.
Includes win32 specific extensions definitions when including
`vk_common.hh`. Inside `gpu_context.cc` vulkan needs to be
included before opengl, otherwise windows 10 builders will
report a warning.
```
[6421/7520] Building CXX object source\blender\gpu\CMakeFiles\bf_gpu.dir\intern\gpu_context.cc.obj
C:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\shared\minwindef.h(130): warning C4005: 'APIENTRY': macro redefinition
C:\Users\blender\git\blender-vexp\blender.git\lib\windows_x64\epoxy\include\epoxy/gl.h(59): note: see previous definition of 'APIENTRY'
```
Pull Request: https://projects.blender.org/blender/blender/pulls/137134
In the OpenXR/Vulkan specs it is mentioned that the swapchain layout
should be set to optimal color attachment. This wasn't the case and
could lead to validation errors.
Also fixes a memory size validation error. Not concerning as it was
abount already backed memory.
Pull Request: https://projects.blender.org/blender/blender/pulls/137143
This only worked for Ubuntu's discontinued Unity desktop.
Even though `libunity.so` can be used outside of Unity,
it's no longer actively developed.
Ref: !137128
When using SteamVR without starting SteamVR, the physical device cannot
be found. This isn't reported to the user nicely. This change will
tell the user why OpenXR couldn't be started.
Note that the physical device can be created when SteamVR has already
launched. OpenGL will start SteamVR automatically, but seems Vulkan
isn't able to do that.
Remove full-screen support from GHOST API's.
Note that this only had back-end implements for X11 and WIN32.
This was last used for the Game Engine to run games full-screen,
removing as it's unused and it doesn't seem likely to be used in the
future.
This doesn't impact making Blender full-screen from the window menu
which uses a window decoration setting.
Ref: !137050
Use VERBATIM to ensure spaces inside command line arguments don't get
escaped automatically.
On Linux and Windows the oneAPI kernel compilation still has problems.
There is an apparent bug with single quote escaping in add_custom_command
which means it's not easy to use VERBATIM.
At the moment MNEE locks up Cycles, or has rendering artifacts on
RDNA4 GPUs on WIndows.
This commit disables MNEE on that configuration until a fix
is avaliable.
Pull Request: https://projects.blender.org/blender/blender/pulls/136980
This fixes most "One Definition Rule" violations inside blender proper
resulting from duplicate structures of the same name. The fixes were
made similar to that of !135491. See also #120444 for how this has come
up in the past.
These were found by using the following compile options:
-flto=4 -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing
Note: There are still various ODR issues remaining that require
more / different fixes than what was done here.
Pull Request: https://projects.blender.org/blender/blender/pulls/136371
Implements a crash dialog for Windows.
The crash popup provides the following actions:
- Restart: reopen Blender from the last saved or auto-saved time
- Report a Bug: forward to Blender bug tracker
- View Crash Log: open the .txt file with the crash log
- Close: Closes without any further action
Pull Request: https://projects.blender.org/blender/blender/pulls/129974
Track the (per-thread) active `GHOST_Context`.
This is required to restore the active context after creating a new one
if the current context is unknown.
(Required for creating GPU contexts in the GPU module without depending
on the WM module)
Pull Request: https://projects.blender.org/blender/blender/pulls/136992
Current implementation uses a CPU roundtrip to transfer render result
to the Xr Swapchain. This PR adds support for sharing the render result
on Linux systems by using file descriptors.
To extend this solution to win32 or dx handles can be done by extending
the data transfer modes, register the correct extensions. When not
using the same GPU between Blender and OpenXR the CPU roundtrip
will still be used.
Solution has been validated with monado simulator and seems to be as
fast as OpenGL.
Performance can be improved by using GPU based synchronization.
Current API is limited as we cannot chain the different renders and
swapchains.
Pull Request: https://projects.blender.org/blender/blender/pulls/136933
Currently MetalRT interpolates transformation matrix on per-element basis
which leads to issues like #135659.
This change adds implementation of for decomposed (Scale/Rotate/Translate)
motion interpolation, matching behavior of BVH2 and other HW-RT.
This requires macOS 15 and Xcode 16 in order to use this interpolation.
On older platforms and compilers old interpolation is used.
Currently there is no changes on the user (by default) and it is only
available via CYCLES_METALRT_PCMI environment variable. This is because
there are some issues with complex motion paths that need to be looked
into. Having code available makes it easier to do further debugging.
Ref #135659
Authored by Emma Liu
Pull Request: https://projects.blender.org/blender/blender/pulls/136253
The current logic disables WITH_CYCLES_ONEAPI_BINARIES when ocloc is not
found, which is fine, but prevented building for other non-Intel SYCL
targets without (unnecessary) ocloc.
The fix here is to remove spir64_gen target when
WITH_CYCLES_ONEAPI_BINARIES is disabled, instead of forcing only spir64.
Improve the number of images that are requested in the swapchain. For
mailbox presentation mode we select tripple buffering. For V-Sync
presentation mode we select double buffering.
In future we might want to make the presentation mode and swapchain
images dynamic based on the actual action that the user is performing.
When doing action that benefit from low latency (paint cursor) we should
select mailbox, otherwise we can use fifo to reduce CPU/GPU usage and
safe some energy usage along the way. See #136923 for design task.
Pull Request: https://projects.blender.org/blender/blender/pulls/136922
