Blender unconditionally requires the Vulkan multiViewport feature and
will fail to create a context on drivers that do not report it.
The feature is now optional. A new GPU_multi_viewport_support()
capability reports whether it can be used. Vulkan requires the
multiViewport feature and at least GPU_MAX_VIEWPORTS viewports;
Metal and OpenGL always report support. Apparently all devices
only support 1 or 16 viewports.
EEVEE uses the capability for shadow rendering. When it is unavailable,
the shadow module falls back to rendering each shadow view separately.
The fallback reads back the number of used views and each size,
restricts the shadow visibility shader to one view at a time and renders
at the origin of the shadow framebuffer.
When the fallback is enabled the performance would be slow, but at least
we can draw the correct shadows on these systems.
Ref: #162564
Pull Request: https://projects.blender.org/blender/blender/pulls/163697
This PR lowers the Vulkan requirements to support Vulkan 1.1 contexts.
Core features have been moved to extensions.
- VkPhysicalDeviceVulkan12Properties has been removed
- timelineSemaphores uses `VK_KHR_timeline_semaphore`.
- bufferDeviceAddress uses `VK_EXT_buffer_device_address`.
- shaderOutputLayer and shaderOutputViewportIndex uses
`VK_EXT_shader_viewport_index_layer`.
- `VK_KHR_depth_stencil_resolve` and `VK_KHR_create_renderpass2` are
dependent extensions that need to be enabled (were core in 1.2)
- Shader compiler will check for SpirV 1.3 or SpirV 1.4 support.
Performance is inline with a Vulkan 1.2 context. See PR for details
Ref: #163528
Pull Request: https://projects.blender.org/blender/blender/pulls/163531
Shader draw parameters is used to received base instance inside the
vertex shader. However some android devices do not support this
extension. Blender code has been modified to prefer the usage of
gpu_InstanceIndex above gl_InstanceID, what makes the usage of base
instance not needed anymore.
This PR doesn't contain changes to the shader tool as there is a
big refactoring going to land soon. After that the shader tool will
be adapted to remove the usage of `[[base_instance]]`.
Pull Request: https://projects.blender.org/blender/blender/pulls/163036
This commit introduces an API for watching desktop setting changes
for Linux, built around libdbus. It's designed around the initial use
case of reading the system theme (light or dark) and changes to the
value (implemented in !161872), but design to be extensible enough
to watch other settings too. The watching is done on a background
thread, so that Blender doesn't have to poll as part of a busy loop.
Instead, callback functions passed to the watcher have flexibility
over how they pass the data to Blender, e.g. sending an event.
Some Android platforms lack native support for shaderClipDistance. When
not available we fallback by dynamically patch the fragment shader to
manually loop over the clipping planes and discard fragments that fall
outside the boundary.
This would reduce the performance when using viewport clipping in the
3d editor.
Pull Request: https://projects.blender.org/blender/blender/pulls/163126
A new command line option `--debug-gpu-backend-no-fallback` is added
that skips the GPU backend support checks. This is primarily useful for
the GPU tests that should not fall back to another backend. This has the
useful side effect of skipping `vk_instance_create_for_platform_checks`,
which would otherwise create its own Vulkan instance. `vkCreateInstance`
can be an expensive function call depending on the used GPU driver (see
https://projects.blender.org/infrastructure/meta/issues/231).
Pull Request: https://projects.blender.org/blender/blender/pulls/163203
The event thread could occasionally read `events_pthread_is_active`
from `GWL_Display` after the main thread had freed it.
In practice the stale read returned the correct value so this
isn't known to have caused any failure (besides the ASAN report).
Resolve by joining the thread, woken by closing the write end
of a pipe it waits on alongside the display.
Clearing `events_pthread_is_active` alone wouldn't end the loop,
nothing wakes the thread from a blocked `poll`.
This follows the logic of QtWayland's event thread.
Ref !163187
`file_descriptor_is_io_ready` was ported from SDL2's `SDL_IOReady`,
including the `HAVE_POLL` logic.
While this made sense for SDL, `libwayland-client` includes `<poll.h>`,
so wayland requires poll anyway.
Worth noting that SDL3 has since removed building without
`<poll.h>` as it's existed in Linux since v2.1, from 1997.
Ref !163186
This PR removes the deprecated logicOp XOR drawing state from the GPU
module, replacing it with GPU_BLEND_INVERT in the Movie Clip and Image
Editor.
Switching to GPU_BLEND_INVERT achieves the exact same highly-visible
border effect while allowing us to safely strip the logicOp code from
all GPU backends.
Pull Request: https://projects.blender.org/blender/blender/pulls/162820
This PR adds Vulkan backend support to SDL, allowing Blender to run with
Vulkan. The implementation is fairly straightforward, unlike OpenGL,
Vulkan operates independently from SDL for the most part, with SDL only
providing basic setup functions (see SDL docs[^1]). This allows to
fully re-use the existing ContextVK, leaving the existing ContextSDL
for SDL/OpenGL. As a brief overview of changes:
- `GHOST_ContextVK` now takes in a `SDL_Window *sdl_window` on all
platforms, similarly to X11/Wayland specific parameters
- `GHOST_WindowSDL` now takes a preferred_device parameter/member passed
to `GHOST_ContextVK` on creation, which is analogous to
`GHOST_WindowWayland` and `GHOST_WindowX11`
- Unlike other surfaces, SDL provides its own surface extension list via
`SDL_Vulkan_GetInstanceExtensions` , bypassing
`getPlatformSpecificSurfaceExtension`
- As `SDL_Vulkan_DestroySurface` is just a wrapper for
`vkDestroySurfaceKHR` internally, implementing it has been skipped in
favor of keeping the existing generic surface destruction code
- To support all platforms, `ContextVK` ctor call is split between
Win32, macOS and *nix in multiple places with preprocessor #ifdefs,
similarly to what was already being done in GHOST_SystemHeadless.hh
Tested on Windows and used with success on the work in progress Android
branch[^2], where this patch was initially extracted from. Testing on
Linux was also conducted by Campbell during review.
See Pull Requests for screenshots.
[^1]: https://wiki.libsdl.org/SDL3/CategoryVulkan
[^2]: https://projects.blender.org/Brainzman/blender/src/branch/android/
Pull Request: https://projects.blender.org/blender/blender/pulls/162103
This extension isn't supported by platforms we want to support. This PR
makes the extension optional and patch the needed shaders with the same
workaround in use by Metal. This PR allows more Android devices to be
considered when scanning for support.
Related to: #162569
Pull Request: https://projects.blender.org/blender/blender/pulls/162633
It was only used when Blender is compiled with `WITH_DRAW_DEBUG`. When not
available, the debug layers will be skipped. It has been made optional to
allow more Android devices to be detectable.
Related task: #162563
Pull Request: https://projects.blender.org/blender/blender/pulls/162640
Make multiDrawIndirect an optional feature in the Vulkan backend. This will
allow more Android devices to be detectable. The workaround is to record
an indirect call for each item to be drawn.
Pull Request: https://projects.blender.org/blender/blender/pulls/162574
Ref: #162566
The `__has_feature` test macro is a non-standard extension and compilers
like MSVC do not implement it.
Handle it like elsewhere in the codebase by defining it if it doesn't
exist.
Pull Request: https://projects.blender.org/blender/blender/pulls/162552
The Blender Window currently stands out quite a bit on the GNOME DE for
having square corners. Rounding gives a more satisfying native look.
In the latest versions of GNOME/GTK4, the window's bottom corners are
expected to be rounded too.
Since we're responsible for drawing our own window decorations, the
title bar is simple enough, but the window bottom rounding requires us
to cut the rounded corners out as a final drawing step, so that's how
it's done here. That also gives more flexibility when we eventually make
use of the CSD to combine the title bar with the top bar.
A few things worth noting:
- We request alpha for the window surface. If that request isn't
successful, we don't draw rounded corners.
- The corners are drawn with a simple new shader. The area border shader
could be used instead with a few changes.
- Viewport transparency requires some extra consideration. The blit
shaders drawing the viewport contents currently don't write opaque
colors. This is currently solved by a `GPU_color_mask` and a texture
clear for fullscreen drawing. At the cost of some extra wiring it
could be solved by adjusting the blit instead.
- To make the corners square when the window is tiled (i.e. right/left
aligned) we need to extract that from the XDG state.
Pull Request: https://projects.blender.org/blender/blender/pulls/162335
Extend the theme-matched title bar coloring added in #123982 to the
more recently added CSD drawing. The change is simple: instead of always
retrieving the color from the 3D view header color, use the same logic
used on other OSs where the color is taken from the top-bar or the main
editor. The bug (#152138) fixed by the current code in this area remains
fixed.
Pull Request: https://projects.blender.org/blender/blender/pulls/161860
Resolves#151525
In the switch from Libdecor to our own CSD, we lost the ability to
resize the window outside of its borders, as is typical for other
applications. This necessitated an extra border _inside_ the Blender
window just to give a space to for the mouse pointer to hover for those
controls.
This commit moves the Window resizing to extra invisible surfaces
forming a border outside the main window. This feels more natural
compared to other applications and saves window space with the
removal of the border inside the Blender window.
Co-authored-by: Campbell Barton <campbell@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/161795
This PR enables the OpenXR Vive Tracker interaction profile[1], so that
Vive Trackers can be accessed through the Blender Python API. It just
adds `XR_HTCX_VIVE_TRACKER_INTERACTION_EXTENSION_NAME` to the list of
tried-to-enable extensions. I grouped it after the other HTC interaction
profiles.
This allows add-ons to use Vive Trackers in their code, but requires no
further modifications to the C++ module. I will be using it in Tracking
Toolkit[2] for native Blender XR integration, but it opens up feature
possibilities for many projects that use the XR bpy PY API (eg. scene
inspector).
[1]: https://registry.khronos.org/OpenXR/specs/1.1/html/xrspec.html#XR_HTCX_vive_tracker_interaction
[2]: https://github.com/ethanporcaro/tracking-toolkit
Pull Request: https://projects.blender.org/blender/blender/pulls/161513
Workaround problem With Vulkan on Wayland under KDE where the
cursor restore location was ignored at times (typically under load).
Resolve by applying the workaround proposed in KDE's bug tracker
(issue 520910), calling set_cursor_position_hint then waiting until
the commit is handled before destroying the "confined_pointer" object.
The method of polling for the commit to be applied follows
SDL-3.4's `Wayland_GLES_SwapWindow`.
Ref !161244
Introduced by 2dd8b4c7c5, which fixed broken macOS window drawing on
fullscreen window restoration, and also moved the makeKeyAndOrderFront
window method call to the bottom of the GHOST_WindowCocoa ctor.
While this worked for almost all setup, certain users reported vertical
draw offset on startup using specific startup.blend config files (not
reproducible on all setups). These issues were fixable on drawing size
refresh when resizing the window.
Fixed by moving the makeKeyAndOrderFront method back to *before* the
window computation/update logic (but still after the fullscreen
restoration logic to preserve the previous fullscreen fix), suggesting
this method caused certain side effects affecting window bound
calculation refresh. See discussion in #160932 for details.
Pull Request: https://projects.blender.org/blender/blender/pulls/161048
- Add GPU API for building and binding raytracing acceleration
structures.
- Implement Vulkan support through the VK_KHR_ray_query extension.
- Add BLAS caching to `MeshBatchCache`.
This PR was extracted from #158921, which also included the Workbench
RT Shadows implementation.
#158921 was a continuation of #146142
The Workbench RT shadows will be implemented in a separate PR.
Co-authored by: Jeroen Bakker
Pull Request: https://projects.blender.org/blender/blender/pulls/160674
Fixes issue #160221, at its core, the issue was caused by the
`XrPassthroughLayerCreateInfoFB` being wrongly default-initialized
instead of being value-initialized causing UB due bitwise flag setting
operation being applied to garbage values.
In addition to this, the value of `result` wasn't properly taken into
account. Instead of determining the value of `passthrough_supported`
from `result`, which was overridden by the later passthrough call,
properly error-out and early exit by wrapping both passthrough creation
calls in `CHECK_XR` macros.
This PR supersedes !158374, which from an initial review contained
AI-generated code and superfluous logic. Testing was conducted by
@Alaska and @cmdr2 which both confirmed the fix was working using a
Quest 3 and a Quest 3s (thanks again!).
Pull Request: https://projects.blender.org/blender/blender/pulls/160862
When Blender was opened with a fullscreen window, either by starting
Blender with the `--window-fullscreen` CLI option or by using a
startup.blender that was saved as fullscreen, window drawing would be
slightly broken and drawn out of bound until framebuffer drawn size was
refreshed. When using the macOS Stage Manager, the problem would be
exacerbated with the drawn Metal framebuffer content not matching the
window size, even after a size change refresh (as shown in #160570).
The issue came from the GHOST macOS WindowCocoa ctor restoring the
fullscreen TWindowState at the very end of the constructor *after* the
metalLayer drawn size was computed, leading to various issue. Fixed by
moving the fullscreen restoration logic between the drawing size
computation/update logic and the view/layer setup, and (importantly)
moving the makeKeyAndOrderFront window method call to the bottom of the
function to ensure the window is only made key when fully setup.
Pull Request: https://projects.blender.org/blender/blender/pulls/160923
This PR replaces the statically linked vulkan loader with dynamic loading
of vulkan loader. This is more in line how other software integrate vulkan
and makes it easier for vendors to help out with issues.
Volk has been placed in its own namespace (volk) this to overcome issues
as USD/Hydra still loads the vulkan loader statically. These changes had
already been applied upstream a year ago.
volk is added to extern as it requires an application specific compilation
unit for configuration.
Pull Request: https://projects.blender.org/blender/blender/pulls/139630
The in memory DIBv5 format that many Windows applications use when
posting images to the clipboard is woefully mis-implemented across the
ecosystem. Of particular interest here are the 12 bytes used for the RGB
masks (but not the Alpha mask). The v5 structure includes these masks
as fields in the header proper. But legacy versions (before v4 I think)
included such things after the end of their headers. Seems like various
applications kind of write both(?) now and we now have to account for
those applications out in the wild.
Perform a size check to see if we are exactly 12 bytes off and skip them
if so.
Pull Request: https://projects.blender.org/blender/blender/pulls/160756
Mainly just boring renaming.
For the cases where there were both C and C++ headers with the same
name, the C one was either:
- Renamed to `_c.hh`.
- Merged into the existing `.hh` header.
Pull Request: https://projects.blender.org/blender/blender/pulls/160019
For system-wide installations on Unix, FHS defines "share"
(typically "/usr/share") as "Architecture-independent".
Blender violated this by installing libraries into `/usr/share` as
part of the GLTF add-on.
Resolve by supporting a parallel "libraries" directly that mirrors
the layout of "/usr/share".
Now they install under the lib tree (mirroring share), e.g.:
- /usr/share/blender/5.2/
- /usr/lib/blender/5.2/
Changes:
- Add `bpy.utils.resource_path('SYSTEM_LIBS')`,
the version root under the install lib directory,
so add-ons can find their relocated libraries.
- Use `CMAKE_INSTALL_LIBDIR` when defined (lib/lib64/multiarch),
so linux packages can define the directory (defaulting to "lib").
Only affects non-portable Linux installs.
Portable, Python module, Windows and macOS builds still bundle
libraries next to the add-on.
Pull Request: https://projects.blender.org/blender/blender/pulls/159137
Every call was launching a "xdg-user-dir" process.
While the overhead is negligible it runs when loading factory settings
which could become noisy in GDB (prints every time a process forks).
Cache the result to avoid the noise and reduce the minor
overhead of loading factory settings.
Ref !159570
