This makes it more verbose, and a little clearer that devices prior to 8cx Gen3 are not supported in >=v4.0. It makes the error message from #113674 more prominent than just being printed to cout.
Spurred by an email I got from someone trying to run blender on a Surface Pro X, and getting the not very helpful (to old devices) error.
Pull Request: https://projects.blender.org/blender/blender/pulls/122732
Vulkan layers should not be controlled from application, but
should be enabled via `vkconfig`. There are configurations
in the layers that are mutual exclusive and hard to maintain from
within an application.
An example is that currently we are not able to use renderdoc efficient,
because there is an validation error triggered from within renderdoc.
This PR removes all vulkan layer configuration from Blender.
Pull Request: https://projects.blender.org/blender/blender/pulls/122473
When VK_EXT_maintenance4 extension is used at device creation its
extension should also be part of the device extension list.
This wasn't the case and would trigger UB in the validation layers.
Pull Request: https://projects.blender.org/blender/blender/pulls/122208
In the near future the legacy framebuffer/renderpass/pipeline drawing
will be replaced by dynamic rendering. Dynamic rendering provide a
flexible API to reuse pipelines between framebuffers if they share
the same image formats.
Dynamic rendering is provided by `VK_KHR_dynamic_rendering` extension
and is supported by all platforms we support (Intel since HD4000, NVIDIA
since 700, AMD since GCN2 and llvmpipe).
Functions provided by extensions are loaded in a struct inside
`VKDevice`.
Pull Request: https://projects.blender.org/blender/blender/pulls/121642
This is because sse2neon.h might be used to emulate SSE intrinsics
on ARM64 architecture, and it uses some preprocessor which is not
available for C language when using MSVC.
The old-style math file math_matrix.c uses this header, so needed
to become C++. Simple rename did not work since there is a new math
utility math_matrix.cc exists. Following some existing convention
the math_matrix.c is renamed to math_matrix_c.cc. Eventually all the
code should switch to use C++ style math, and the C style removed,
so it seems reasonable to not mix old and new style of API in the
same file.
There should be no functional changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/121335
This reverts commit a63e44a61f.
This lead to build failures on linux because `wl_display_get_protocol_error`
is not defined. The error happened on the buildbot too.
Check & print a message if there is an error creating the window.
In both cases Blender will fail to start, it's just better to exit
quickly with a message instead of hanging.
This change was made previously [0] but reverted as it caused the
title-bar to disappear on Ubuntu (see #121241).
Check if the value is set to GNOME delimited by `:`.
Previously checking the interfaces was used which has the down-side
that any compositor that adds `gtk_shell*` support may hang on startup
because of bugs in Blender/LIBDECOR as happened with WAYFIRE,
see reply to #76428.
[0]: 3a5389d5ab
Disable use of LIBDECOR on WAYFIRE as it causes Blender to hang
on window creation.
Detect WAYFIRE using the presence of the `zwf_shell_manager_v*`
interface, don't use LIBDECOR if this is found.
This is an alternative fix to [0] which also disabled LIBDECOR
but caused LIBDECOR not to be used in GNOME on some systems.
I'm not keen on this solution, but it seems alternatives are less
reliable. See code-comment for details.
[0]: 3a5389d5ab
This reverts commit 3a5389d5ab.
It seems XDG_CURRENT_DESKTOP isn't reliably set,
causing no titlebar on GNOME, see #121241.
The WAYFIRE workaround will need to be resolved another way.
Use XDG_CURRENT_DESKTOP to check if GNOME is running.
Previously the existence of a `gtk_shell*` interface was used however
the WAYFIRE compositor provides this interface which made GHOST require
LIBDECOR.
Initializing LIBDECOR was hanging as the initial configuration was
never seen. From a quick check it doesn't seem like a bug in Blender's
LIBDECOR use, the issue may be in either LIBDECOR or WAYFIRE.
Whatever the case, LIBDECOR isn't needed so workaround the bug by
changing how GNOME is detected.
Support detecting if the trackpad direction flag is propertly set
(currently unused).
Needed so Wayland compositors that don't support seat-version 9 or
newer (GNOME-46 & KDE5 for e.g) can have a working trackpad.
Eventually this option will be removed when the functionality is
widely supported.
Accumulate scrolling for mouse wheels that create scroll values below
a single "click".
Regression in [0], caused by bumping the seat API.
[0]: 8d86fb43a4
When turning on VR mode, if no controllers are available,
a fallback model (a sphere) is rendered in the middle of the VR area.
This change uses the OpenXR API to check if the controllers are
available, sets new properties in `GHOST_XrPose` and `wmXrController`
that store if each controller is active or not, and uses
those properties to render the controllers in the VR view only
when they are active.
NOTE: in `wmXrController`, two state properties have been included,
but only `grip_active` is currently used. `aim_active` has been
included for consistency, but it could be removed.
Pull Request: https://projects.blender.org/blender/blender/pulls/119989
On KDE, running "blender -w" (windowed with borders) created window
which was too big: the window contents matched the screen-size
causing the window decorations be outside the screen-bounds.
Un-maximizing the default startup file would also move window to the
same over-sized location.
Resolve by clamping the size of new windows to the requested bounds.
Scrolling the mouse wheel fast can generate multiple click-steps
which were ignored by window manager events.
This meant scrolling fast with a trackpad (with "Multi-touch gestures"
disabled) for e.g. would zoom less than the gesture made more slowly.
This macro makes it convenient to define a supported version range for
an interface.
Uncommenting USE_VERBOSE_OLD_IFACE_PRINT prints when newer versions
of an interface are supported by the compositor which Blender could
be updated to support.
This makes it more convenient to bump interface versions as they
become available so bumping multiple versions at once doesn't
cause unexpected changes in behavior as happened with #120587.
Resolves the issue reported in #120587, which occurred when bumping the
supported version of the seat API to 9.
Smooth scrolling values were set in without calling the discrete step
callback. Resolve by calculating discrete values from the:
wl_pointer_listener::axis_value120 handler.
The functional changes from this commit only apply once the version
of the seat API is increased - which isn't part of this commit.
This matches behavior on macOS as well as the property description.
On Wayland, smooth scrolling doesn't use the touchpad API,
so disabling multi-touch gestures doesn't change the behavior as it
does on macOS.
Resolve by converting vertical touch scrolling to mouse-wheel events.
The callback to set the relative direction wasn't running because
it required GHOST to request version 9 of the wl_seat_interface.
Natural touchpad events now work for KDE 6 and recent versions
of WLROOTS based compositors, GNOME 46 is uses wl_seat_interface
version 8 which still wont work.
MoltenVK original intent was to let developers work on a mac system developing
for the vulkan eco-system. MoltenVK doesn't support all the features that we
require and would require additional workarounds to be actually supported.
It is not expected that we will release Blender with MoltenVK for this reason.
But it still has value for shader developers to validate shaders on metal and
vulkan on a single platform.
Pull Request: https://projects.blender.org/blender/blender/pulls/117940
