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
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
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
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
This PR moves the ownership of vulkan memory allocator from gpu/device
to GHOST/context/device. This will allow in the future a cleaner control
flow between OpenXR and Vulkan. Currently as the ownership is in the gpu
module many objects would need to pass from GHOST to the GPU module to be
shared between the 2 allocators. Moving both (OpenXR/Context) allocator
to GHOST would reduce the complexity.
Pull Request: https://projects.blender.org/blender/blender/pulls/146819
For wide line rendering it is preferred to use polyline shaders. However
creating a custom shader is complicated and a stone to far for many
scriptors.
This PR allows using line_width_set when wide line rendering is
supported by the platform.
Pull Request: https://projects.blender.org/blender/blender/pulls/146762
Only use when Windows Automatic Color Management (ACM) is enabled.
That way we know Windows will automatically convert from extended sRGB
linear to the appropriate color space for the display.
When we previously tried this there were some issues, but I think it was due
to ACM being off. This has been confirmed to work on NVIDIA and AMD, and
Intel is not expected to support this (yet) for the same reasons there is no HDR.
Pull Request: https://projects.blender.org/blender/blender/pulls/146041
`GHOST_SwapWindowBuffers` doesn't fit well when using swapchains. In
that case an approach where swap chain images are acquired and released
would map better. This PR introduces `GHOST_SwapWindowBufferAcquire`
and `GHOST_SwapWindowBufferRelease` to be more in line with vulkan swap
chains.
Previous implementation would first record all GPU commands based on
the last used swap chain. In case a swapchain needed to be recreated
(window resize, move to other monitor) the recorded commands would
not match the swap chain and could lead to artifacts.
OpenGL only implements the release functions as they don't
have a mechanism to acquire a swap chain image. (Need to validate with
the Metal API how this is working and adapt is needed).
Currently when starting blender on a HDR capable display the first frame
would be based on an sRGB surface and presented on an extended RGB
(or other) surface. As these don't match the first frame could be incorrect and
also lead to UBs as another surface is expected.
Pull Request: https://projects.blender.org/blender/blender/pulls/145728
Qualcomm GPU doesn't support image load/store on framebuffers. We use
load store to convert to the correct color space. This PR will only
set the VK_IMAGE_USAGE_STORAGE_BIT when HDR is available. As Qualcomm
doesn't support HDR using Vulkan this is safe.
Pull Request: https://projects.blender.org/blender/blender/pulls/145775
Improving readability of GHOST_ContextVK
- Introduces GHOST_Extensions for a common interface to device/instance
extensions
- Introduces GHOST_InstanceVK for instance based API (used to be part of
GHOST_DeviceVK)
During the refactor found out that the generic queue family would always
be 0, this is most of the time the case, but could lead to issues when
setting up more complex setups.
Pull Request: https://projects.blender.org/blender/blender/pulls/145721
Up until now, when encountering an OpenXR error / exception in debug
mode, only the raw OpenXR error enum int value would be displayed, which
wasn't really descriptive nor useful. To remedy this, this commit adds
an `xrResultToString` call to additionally convert this value into its
corresponding enum string.
See PR for an example error print.
Pull Request: https://projects.blender.org/blender/blender/pulls/142582
Multiple previous changes made resource pools obsolete. Resource
pools were used to keep track of resources when the frame is rendered.
Multiple frames can be rendered at the same time and resources could
overlap.
This has been replaced (not this commit) to be part of the render graph
and when an submission has completed the resources are recycled.
Continuation of: https://projects.blender.org/blender/blender/pulls/145408
Pull Request: https://projects.blender.org/blender/blender/pulls/145511
Multiple previous changes made resource pools obsolete. Resource
pools were used to keep track of resources when the frame is rendered.
Multiple frames can be rendered at the same time and resources could
overlap.
This has been replaced (not this commit) to be part of the render graph
and when an submission has completed the resources are recycled.
Pull Request: https://projects.blender.org/blender/blender/pulls/145408
This PR disables HDR when driver doesn't support
`VK_EXT_swapchain_colorspace`. It could be that Windows detect support
(DirectX) and allow users to enable HDR. But that it isn't supported by
the Vulkan part of the driver.
In case of Windows there might be an issue with using SRGB non
linear on F16 swapchains where somewhere an additional transform is
being performed. After adding support for other color spaces we should
remove the support of this swapchain configuration.
Pull Request: https://projects.blender.org/blender/blender/pulls/145325
* Improve accuracy of warning when HDR display is not supported, taking into
account HDR mode on/off on Windows.
* When HDR mode is disabled on Windows, don't create a HDR swapchain. This
saves memory, and avoids a color difference on NVIDIA. That's because NVIDIA
is the only GPU we've tested that allows a HDR swapchain when HDR mode is
off, and we don't currently know the expected transforms for that case.
* Recreate swapchain when HDR mode on/off switch is detected.
* Update HDR info when window gains focus.
Note this means there is no wide gamut when Windows HDR is off, but it was
already not working. For that we may need to add support for something like
10bit VK_COLOR_SPACE_DISPLAY_P3_NONLINEAR_EXT, or whatever is commonly
available outside of HDR mode.
Pull Request: https://projects.blender.org/blender/blender/pulls/144959
This PR adds a slip tool in the toolbar with its own custom icon for
applying slips using the mouse. This is useful for e.g. tablets where a
keyboard is not handy and a button would be best to activate the
operator.
There is also a custom cursor that appears when hovering over valid,
slippable strips (and a "stop" icon when the strip cannot be slipped).
Alt may be used in order to ignore slipping connected strips when using
the tool, similar to selection logic. The slip tool only performs its
sole function of slipping and as such does not change the selection
state.
In the future, we can also add "slide" functionality to the same tool,
giving it multiple functions.
Pull Request: https://projects.blender.org/blender/blender/pulls/143513
This PR adds HDR support for Windows for `VK_COLOR_SPACE_EXTENDED_SRGB_LINEAR_EXT`
on `VK_FORMAT_R16G16B16A16_SFLOAT` swapchains .
For nonlinear surface formats (sRGB and extended sRGB) the back buffer is blit into the swapchain,
When VK_COLOR_SPACE_EXTENDED_SRGB_LINEAR_EXT is used as surface format a compute shader
is used to flip and invert the gamma.
SDR white level is updated from a few window event changes, but actually
none of them immediately respond to SDR white level changes in the system.
That requires using the WinRT API, which we don't do so far.
Current limitations:
- Intel GPU support
- Dual GPU support
In the future we may add controls inside Blender for absolute HDR nits,
across different platforms. But this makes behavior closer to macOS.
See !144565 for details
Co-authored-by: Brecht Van Lommel <brecht@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/144717
First advance to the next frame and use the same index for all
resources. Previous implementation used a fence of the next frame, what
added confusion why that was actually needed.
Should not make a change in functionality or performance.
Pull Request: https://projects.blender.org/blender/blender/pulls/144615
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
Add a command line argument --gpu-vsync on/off/auto.
Prefer command line arguments for GPU settings,
as it means the value is error checked and set when Blender starts.
Also refactor GHOST_Context to take a parameter argument which
includes the stereo-visual & debug arguments and includes the newly
added vsync setting. This makes it possible to add GPU context
parameters more easily in the future.
It also removes redundant parsing & setting the VSync setting for
off-screen contexts.
Changes to recent PR !143049.
Ref !144473
