Previously, each GHOST Context instantiated its own Metal device
queue. Commands are only synchronized within a queue, this was the
root cause of a number of flickering issues which had previously
been worked-around with synchronization primitives.
New solution uses a shared queue to simplify dependencies and
alleviate possibility of stalls and bugs when resources are modified
or shared across separate GPU command queues.
Authored by Apple: Michael Parkin-White
Pull Request: https://projects.blender.org/blender/blender/pulls/108223
Windows file associations using ProgID, needed because of the launcher.
This fixes "pin to taskbar" and Recent Documents lists, allow per-
version jump lists and an "Open with" list with multiple versions.
Pull Request: https://projects.blender.org/blender/blender/pulls/107013
In previous implementation the first available render surface was
selected. For NVIDIA platform this was the correct one, but for
AMD and Intel GPUs this was incorrect. This PR goes over all the
available render surfaces and selects a compatible one.
For now when no compatible render surface is found it will still select
the first available one. With the expectation that the screen is drawn
incorrectly and users would report a bug so we can investigate.
Pull Request: https://projects.blender.org/blender/blender/pulls/108169
Covers the macro ARRAY_SIZE() and STRNCPY.
The problem this change is aimed to solve it to provide cross-platform
compiler-independent safe way pf ensuring that the functions are used
correctly.
The type safety was only ensured for GCC and only for C. The C++
language and Clang compiler would not have detected issues of passing
bare pointer to neither of those macros.
Now the STRNCPY() will only accept a bounded array as the destination
argument, on any compiler.
The ARRAY_SIZE as well, but there are a bit more complications to it
in terms of transparency of the change.
In one place the ARRAY_SIZE was used on float3 type. This worked in the
old code because the type implements subscript operator, and the type
consists of 3 floats. One would argue this is somewhat hidden/implicit
behavior, which better be avoided. So an in-lined value of 3 is used now
there.
Another place is the ARRAY_SIZE used to define a bounded array of the
size which matches bounded array which is a member of a struct. While
the ARRAY_SIZE provides proper size in this case, the compiler does not
believe that the value is known at compile time and errors out with a
message that construction of variable-size arrays is not supported.
Solved by converting the field to std::array<> and adding dedicated
utility to get size of std::array at compile time. There might be a
better way of achieving the same result, or maybe the approach is
fine and just need to find a better place for such utility.
Surely, more macro from the BLI_string.h can be covered with the C++
inlined functions, but need to start somewhere.
There are also quite some changes to ensure the C linkage is not
enforced by code which includes the headers.
Pull Request: https://projects.blender.org/blender/blender/pulls/108041
xdg_surface_ack_configure must run once the events have been handled
which is not the case configure runs from the event handling thread.
In practice this could lead to glitches resizing windows, although some
flickering on startup remains on KDE which would be good to resolve.
Exiting with multiple overlapping windows (a file selector for e.g.)
reliably crashes.
Closing the windows on exit caused the the keyboard enter handler to be
called with a NULL window surface (wl_surface).
While this doesn't look to be documented anywhere, SDL's code-comments
note this happens when windows have just been closed.
GTK also check surfaces for NULL.
The goal is to make it more explicit and centralized operation to
assign and steal buffer data, with proper ownership tracking.
The buffers and ownership flags are wrapped into their dedicated
structures now.
There should be no functional changes currently, it is a preparation
for allowing implicit sharing of the ImBuf buffers. Additionally, in
the future it is possible to more buffer-specific information (such
as color space) next to the buffer data itself. It is also possible
to clean up the allocation flags (IB_rect, ...) to give them more
clear naming and not have stored in the ImBuf->flags as they are only
needed for allocation.
The most dangerous part of this change is the change of byte buffer
data from `int*` to `uint8_t*`. In a lot of cases the byte buffer was
cast to `uchar*`, so those casts are now gone. But some code is
operating on `int*` so now there are casts in there. In practice this
should be fine, since we only support 64bit platforms, so allocations
are aligned. The real things to watch out for here is the fact that
allocation and offsetting from the byte buffer now need an explicit 4
channel multiplier.
Once everything is C++ it will be possible to simplify public
functions even further.
Pull Request: https://projects.blender.org/blender/blender/pulls/107609
Only make libdecor a hard-requirement for using Wayland in gnome-shell
when X11 is available, as it's possible to disable Xwayland.
This also fixes window-borders not being used in gnome-shell when
WITH_GHOST_X11 is off.
Now it's possible to test Blender under gnome without libdecor by
uninstalling libdecor & running with DISPLAY environment variable
set to an empty string - useful for troubleshooting issues which
could be caused by libdecor.
This PR enabled the swapchain to be used with AMD GPUs.
The issue is that we had to separate the swapchain into
2 functions and therefore the rendering is also not
controlled at the same time.
Semaphores were finished, before being used and the
driver stalled when waiting for those Semaphores.
This doesn't solve the issue that renderdoc can still
crash the graphics driver.
Pull Request: https://projects.blender.org/blender/blender/pulls/107840
This PR replaces the previous implementation of the swap chain.
The previous implementation was based on a gaming loop where
inside a single function an image is requested, the drawing occurs
and the requested image is presented on screen.
In blender the drawing isn't controlled in a single function and
this approach lead to freezes, missing frames and other
artifacts.
This approach is not be the final approach but a step into a
direction where the acquiring of the next image in the swap chain
is separated from the swapping.
Pull Request: https://projects.blender.org/blender/blender/pulls/107740
Previous GHOST_ContextVK would create a logical device for each
context. Blender uses multiple contexts at the same time and wasn't able
to share resources between them as the logical device where different.
This patch will create a single logical device and share them between
multiple contexts. This allows sharing memory/shaders between contexts
and make sure that all memory allocations are freed from the device it
was allocated from.
Some allocations in Blender are freed when there isn't a context, this
was failing in the previous implementation. We didn't noticed it before
as we didn't test multiple contexts.
This patch also moves device specific data structures from VKContext to
VKDevice like the descriptor pools, debug layers etc.
Pull Request: https://projects.blender.org/blender/blender/pulls/107606
In some cases comments at the end of control statements were wrapped
onto new lines which made it read as if they applied to the next line
instead of the (now) previous line.
Relocate comments to the previous line or in some cases the end of the
line (before the brace) to avoid confusion.
Note that in quite a few cases these blocks didn't read well
even before MultiLine was used as comments after the brace caused
wrapping across multiple lines in a way that didn't follow
formatting used everywhere else.
Detecting when to show warnings about GHOST/XKB modifier
mismatches was rather involved, remove the check as it's
unnecessary for Gnome-Shell >= v43.
Older versions of Gnome-Shell will show warnings on window activation
with modifier keys held.
Reading modifiers from XKB caused a complications in getModifierKeys(..)
when called on a window that was activated, before the keyboard enter
handler had run - because the keys held by GHOST had not yet been
updated by XKB. This caused a problem which Gnome-shell which runs
the keyboard-enter handler after window activation.
This change would have fixed the Super key being stuck, see: #107314.
Keep the previous fix since in the unlikely case GHOST & XKB get out of
sync, stuck modifier keys should still be prevented.
This change means the warning for GHOST & XKB getting out of sync
can be enabled for Gnome-shell again, as it was previously suppressed
as it happened frequently on window activation.
Tapping the OS key to switch windows could cause the OS key to stick.
On window deactivation the OS key was considered held, activating the
window later read the XKB modifier state before the keyboard_enter &
keyboard_modifier callbacks had run.
When they ran later, the mis-match between XKB and GHOST was not taken
into account, causing the OS key to stick.
Apparently we always constructed a Vulkan 1.0 Context, although we
are targetting Vulkan 1.2. This also lead to incorrect expectations
when using the Vulkan Memory allocator.
Pull Request: https://projects.blender.org/blender/blender/pulls/107300
This PR uses the VK_EXT_debug_utils extension, but it's only for labeling, so it doesn't rely on the VK_LAYER_KHRONOS_validation functionality.
The functions that do these things are loaded into the runtime as vulkan extensions.
Declare the function pointers in a struct and make them members of vk_context.
Pull Request: https://projects.blender.org/blender/blender/pulls/106098
While this didn't cause bugs, initialize members to avoid problems
in the future.
GHOST::SystemX11
- m_keyboard_vector
- m_keycode_last_repeat_key
GHOST::Window
- m_cursorGrabInitPos
- m_userData
Completes the TODO in GHOST_SystemPathsCocoa::addToSystemRecentFiles
Also renames the filename parameter to the more appropriate filepath.
The recently opened/saved file will now also show up in:
- Blender Dock icon > Right click.
- Three finger swipe down in Open Blender i.e., App Expose
Based on a earlier contribution by @jenkm.
Pull Request: https://projects.blender.org/blender/blender/pulls/107174
During createOffscreenContext with VK backend enabled wl_surface
was not stored in the context's user data. This resulted in nullptr
dereference later on during disposeContext. Added a line that sets
user data and additionally added nullptr checks in disposeContext.
Ref !107057.
Expand on why front-buffer support is always disabled on Wayland &
why viewport orbit around selection offset correction isn't used for
perspective views.
- Use off-screen drawing when reading from the front-buffer isn't
supported.
- Add a capabilities flag for reading the front-buffer which is always
disabled on WAYLAND.
- Add GPU_offscreen_read_pixels_region, used for reading a sub-region of
an off-screen buffer - use for color-picking a single pixel.
After double clicking a file, user can click on a different app and
Blender will lose focus. Then it stays on splash screen. So fetch any
window instead of relying on active one to open the file.
pull request #106769
This reverts commit 4fe2685615.
Always use the preferred_scale requested by the compositor as this
did not work so well in the intended use case (where the low resolution
monitor text was scaled down and difficult to see).
After discussion with @ZedDB, revert this change since there are cases
where either functionality might be preferred - to ensure Blender's UI
is visible on a low resolution mirrored projector for e.g.
Changing the behavior of the preferred scale makes most sense in the
compositor, instead of controlling it on a per-application basis.
Defer acting on the tag to update scale as it caused the window
to use the wrong scale on startup & exit.
GTK/KDE applications seem to postpone updating scale so use this by
default as glitches with scale tend to be caused by updating the scale
too frequently instead of not quickly enough.
There is no need to postpone these operations when configuring the frame
only postpone committing the surface change.
Deferring these operations caused flickering when moving windows
between monitors of different scale on both GNOME & KDE.
Freeing ContextEGL would attempt to free the context's EGLSurface,
which was already freed by the native-window, causing 2x bad-surface
errors on exit.
Suppress the warning by clearing the surface from releaseNativeHandles
when the surface was created by a native window.
Updating the buffer scale increased the window size based on the
previous window scale. Since the previous scale (DPI) newly created
windows restored from a `.blend` file isn't known, don't scale the
window size when updating the window's scale for the first time.
When a window overlaps multiple outputs, always use the resolution
on the output with the highest resolution. This means Blender never
shows low resolution content up-scaled.
Share logic between fractional & non-fractional window scaling.
This also enables fractional-scaling without scaling fixed sized buffers
for compositors without support for fractional_scale_manager_v1.
