Blender had some support for using MoltenVK. However there are some key
issues why MotlenVK cannot be used. Bugs have been reported up-stream.
As it doesn't work and holds back regular developments it will be removed
from the main branch.
Any efforts on making Vulkan run on Apple (including KosmicKrisp)
is considered a community effort and can be done in a development
branch.
Pull Request: https://projects.blender.org/blender/blender/pulls/144602
This commit renames the GHOST Metal graphic context class and related
files / references from `GHOST_ContextCGL` to `GHOST_ContextMTL`. When
the Metal backend was first introduced, this context file contained
both the old OpenGL context (CGL, for macOS Core OpenGL API), and the
newer Metal context. Since #110185 all CGL related code was removed
from the class, making it Metal only, and thus rendering the old class
name outdated and potentially misleading. In addition to the rename,
unused OpenGL related forward declarations and old TODOs were also
removed.
Pull Request: https://projects.blender.org/blender/blender/pulls/142519
This PR solves running Wayland on compositors that don't support HDR/
color management. It also allows to let Blender window be drawn across
monitor boundaries and being transferred and clamped to the monitor
it is being displayed on.
From our point of view monitor configurations is a compositor/OS
responsibility. This PR provides the compositor that the provided
swapchain image will be using sRGB whitepoints and transfer
function. The compositor should then take care of performing the
final transfer to the monitor color volume.
The color management protocol doesn't provide guarantees that
every compositor does this. It is mentioned as a recommendation
and 'should do this'.
Pull Request: https://projects.blender.org/blender/blender/pulls/141598
This makes the the cursor drawing be handled by the Wayland compositor
unless the cursor shape is not in the standard cursor shape set.
For custom cursor shape, Blender still manually draws and handles these.
Removal of the X11 cursors was done because:
1. Greatly simplifies the code (and compositors not supporting the cursor
shape protocol will fallback to Blenders built in cursors).
2. On a lot of compositors the X11 cursor theme is not set per default,
this would lead to us falling back to a default theme. This would
in almost all cases not match the actual cursor theme of the user.
The fallback theme would also look quite ugly and the cursor size
would be inconsistent with the rest of the system.
Pull Request: https://projects.blender.org/blender/blender/pulls/140366
The GHOST_DisplayManager and its implementations are for the most part
unmaintained and almost completely unused in all backends. To clean
things up, and avoid any confusion about how displays are handled in
each respective GHOST backend, this PR completely removes the GHOST
Display Manager, and move the few remaining logic it still held directly
to the corresponding backends.
The backends that were modified (apart from removing the display manager
initialization call from their init) are:
- Win32: `GHOST_SystemWin32::getNumDisplays()` was calling
`m_displayManager->getNumDisplays`, the underlying system metric call
(`GetSystemMetrics(SM_CMONITORS)`) was substituted in place.
- SDL: `GHOST_SystemSDL::createWindow` was calling
`GHOST_DisplayManagerSDL::getCurrentDisplayModeSDL` which returned its
`m_mode` data member by reference. Since none of the
`GHOST_DisplayManagerSDL` member function that modified this data member
were ever called, the variable `memset` initialization call was
substituted in place from the `DisplayManagerSDL` constructor
Pull Request: https://projects.blender.org/blender/blender/pulls/138066
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
To make adding a dependeny on TBB easier.
Additional changes:
* Using LIB for libmv tests, as it now brings in includes
* Removing Eigen header listing in iTaSC
Pull Request: https://projects.blender.org/blender/blender/pulls/136865
The Blender's VkInstance cannot be shared with OpenXR VkInstance. The
reason is a chicken and egg problem where OpenXR needs to be started
before Vulkan. OpenXR can add special vulkan specific requirements
(instance&device) that are only available when the user starts an OpenXR
session.
The goal implementation is to share memory between both instances using
[VK_KHR_external_memory](https://registry.khronos.org/vulkan/specs/latest/man/html/VK_KHR_external_memory.html) and related extensions. However this seems
to be a bridge to far as a initial step. Reason: There are not that many
samples/ guides and documentation to be found to handle the workflow that
we require. We want to do a smaller step by step approach to gain the needed
knowledge.
For that reason this PR does the most stupidest thing that can be done to
share memory between instances. Download the render result to CPU RAM share
the host pointer with the OpenXR instance which copies it to the swap chain.
Also the synchronization is done using wait idle commands.
<video src="attachments/32a0d69b-c3fa-4272-aea0-d207609afaaf" title="Screencast From 2025-03-18 11-16-17.webm" controls></video>
**Gaining knowledge**
- Experiment with `VK_KHR_external_memory_host` extension for uploading vertex buffers (not related to OpenXR).
- Import host pointer with `VK_KHR_external_memory_host`. This reduces the additional
memcpy on OpenXR side.
- Export host pointer from Blender side from a mappable buffer.
- Replace host pointers with fd/dmabuf/winhandle
- Remove mappable buffer.
Ref #133718
Pull Request: https://projects.blender.org/blender/blender/pulls/133824
GPU and GHOST require to have identical checks to remove faulty drivers.
When not done GHOST can still select a device that isn't supported and
lead to freezing interfaces.
Pull Request: https://projects.blender.org/blender/blender/pulls/131241
When making a `headless` macOS build, linking would fail complaining
about missing `GHOST_ContextCGL` symbols, which are required by the Metal
backend. This commit fixes this issue by compiling the macOS CGL GHOST
Context if the Metal backend is enabled, instead of only depending on
`WITH_HEADLESS`, similarly to what's done on Linux/other *nix systems.
Pull Request: https://projects.blender.org/blender/blender/pulls/130847
This implements the proposal from #124512. For that it contains the following
changes:
* Remove the global override of `new`/`delete` when `WITH_CXX_GUARDEDALLOC` was
enabled.
* Always use `MEM_CXX_CLASS_ALLOC_FUNCS` where it is currently used. This used
to be guarded by `WITH_CXX_GUARDEDALLOC` in some but not all cases. This means
that a few classes which didn't use our guarded allocator by default before,
are now using it.
Pull Request: https://projects.blender.org/blender/blender/pulls/130181
The tablet API become stable in wayland-protocol 1.35
NOTE: this was reverted [0] because I missed adding the files to lib.
The files have been included, so use the stable API.
No functional changes expected.
[0]: c525e4db83
Since the introduction of vulkan loader in vulkan (not Blender) the
molten vk extension always leads to a failed registration. This
extension is only available when using the loader. Blender doesn't use
the vulkan loader so we should remove it.
Pull Request: https://projects.blender.org/blender/blender/pulls/128354
Disable dynamic SDL loading as well as disable SDL for release builds.
This was only used for audio output which can already use OpenAL
if there are back-ends not natively supported by Blender.
- Remove extern/sdlew/
- Remove the WITH_SDL_DYNLOAD build option.
- Remove `bpy.app.sdl.available`.
Ref !127554
The currently available `wayland-protocol` libraries in lib-linux_x64
repo do not appear to be advertised 1.36 (or 1.35) versions, since the
tablet protocol is not available among the stable ones.
This reverts commit 2a85eaaf16.
Pull Request: https://projects.blender.org/blender/blender/pulls/123774
Under GNOME resizing a window often caused the window contents could be
a different size to the window-frame, resizing was also slow.
This occurred with LIBDECOR on Wayland when a window configure event
was called from a non-main thread.
Resolve by postponing the commit-configuration call until the main event
can handle it (matching XDG behavior).
A workaround using malloc_usable_size is currently needed.
While relying on the malloc size is not so portable and worth avoiding,
it resolves noticeable glitches and allows other workarounds to be
removed.
Any application that supports threaded event handing with LIBDECOR
will need a way to postpone applying the configuration.
Even once LIBDECOR supports this properly, a workaround is necessary
until support older versions of LIBDECOR can be dropped.
Due to changes in the build environment shader_builder wasn't able to
compile on macOs. This patch reverts several recent changes to CMake files.
* dbb2844ed9
* 94817f64b9
* 1b6cd937ff
The idea is that in the near future shader_builder will run on the buildbot as
part of any regular build to ensure that changes to the CMake doesn't break
shader_builder and we only detect it after a few days.
Pull Request: https://projects.blender.org/blender/blender/pulls/115929
Tested with IBUS on GNOME 45.
Added a capabilities flag to GHOST since support for IME works on
Wayland but not on X11, so runtime detection is needed.
This was only used for accessing cursor themes which only worked
with gnome and wasn't used in official releases.
Use the default theme or the theme defined by XCURSOR_THEME.
Eventually wp_cursor_shape_manager_v1 can be supported which avoids
having to access the theme.
Ghost uses vulkan in its public headers but none of the projects that
depend on ghost had the vulkan headers in its includes nor did
bf_intern_ghost expose this vulkan dependency itself publicly yet.
bf_windowmanager also did not express its dependency on
bf_intern_ghost yet used its headers.
this change fixes both issues.
Pull Request: https://projects.blender.org/blender/blender/pulls/112259
Listing the "Blender Foundation" as copyright holder implied the Blender
Foundation holds copyright to files which may include work from many
developers.
While keeping copyright on headers makes sense for isolated libraries,
Blender's own code may be refactored or moved between files in a way
that makes the per file copyright holders less meaningful.
Copyright references to the "Blender Foundation" have been replaced with
"Blender Authors", with the exception of `./extern/` since these this
contains libraries which are more isolated, any changed to license
headers there can be handled on a case-by-case basis.
Some directories in `./intern/` have also been excluded:
- `./intern/cycles/` it's own `AUTHORS` file is planned.
- `./intern/opensubdiv/`.
An "AUTHORS" file has been added, using the chromium projects authors
file as a template.
Design task: #110784
Ref !110783.
The cleanup of blenkernel last weeks , caused the house of cards to
collapse on top of bf_gpu's shader_builder, which is off by default
but used on a daily basis by the rendering team.
Given the fixes forward in #110394 ran into a ODR violation in OSL that
was hiding there for years, I don't see another way forward without
impeding the rendering teams productivity for "quite a while" as there
is no guarantee the OSL issue would be the end of it.
the only way forward appears to be back.
this reverts :
19422044eda670b53abe0f541db97cbe516e8c813e88a2f44c4e64b772f59547e7a31707fe6c5a57
The problematic commit was 07fe6c5a57
as blenkernel links most of blender, it's a bit of a link order issue
magnet. Given all these commits stack, it's near impossible to revert
just that one without spending a significant amount of time resolving
merge conflicts. 99% of that work was automated, so easier to just
revert all of them, and re-do the work, than it is to deal with the
merge conflicts.
Pull Request: https://projects.blender.org/blender/blender/pulls/110438
There's quite a few libraries that depend on dna_type_offsets.h
but had gotten to it by just adding the folder that contains it to
their includes INC section without declaring a dependency to
bf_dna in the LIB section.
which occasionally lead to the lib building before bf_dna and the
header being missing, while this generally gets fixed in CMake by
adding bf_dna to the LIB section of the lib, however until last
week all libraries in the LIB section were linked as INTERFACE so
adding it in there did not resolve the build issue.
To make things still build, we sprinkled add_dependencies wherever
we needed it to force a build order.
This diff :
Declares public include folders for the bf_dna target so there's
no more fudging the INC section required to get to them.
Removes all dna related paths from the INC section for all
libraries.
Adds an alias target bf:dna to signify it has been updated to
modern cmake
Declares a dependency on bf::dna for all libraries that require it
Removes (almost) all calls to add_dependencies for bf_dna
Future work:
Because of the manual dependency management that was done, there is
now some "clutter" with libs depending on bf_dna that realistically
don't. Example bf_intern_opencolorio itself has no dependency on
bf_dna at all, doesn't need it, doesn't use it. However the
dna include folder had been added to it in the past since bf_blenlib
uses dna headers in some of its public headers and
bf_intern_opencolorio does use those blenlib headers.
Given bf_blenlib now correctly declares the dependency on bf_dna
as public bf_intern_opencolorio will get the dna header directory
automatically from CMake, hence some cleanup could be done for
bf_intern_opencolorio
Because 99% of the changes in this diff have been automated, this diff
does not seek to address these issues as there is no easy way to
determine why a certain dependency is in place. A developer will have
to make a pass a this at some later point in time. As I'd rather not
mix automated and manual labour.
There are a few libraries that could not be automatically processed
(ie bf_blendthumb) that also will need this manual look-over.
Pull Request: https://projects.blender.org/blender/blender/pulls/109835
