When using multiple keyboard layouts, the first layout would always
be used for internal keyboard layout queries.
This meant for e.g. with English layouts QWERTY & DVORAK both active
Control-C always used the QWERTY location for C even when DVORAK was
active.
Resolve by detecting layout changes & run xkb_state_update_mask
on all xkb_state's so internal queries always use the active layout.
Based on !115161, extended to detect layout changes & account for all
internal states.
Co-authored-by: Eugene Kuznetsov <eugene.kuznetsov@amd.com>
This change adds timeline semaphores to track submissions. The previous
implementation used a fence.
Timeline semaphores can be tracked in more detail as it is an counter.
For each submission the counter can be stored locally and when waiting
for completion the counter can be retrieved again and checked if is
known to be succeeded by a higher value.
The timeline semaphore is stored next to the queue and can also be used
to synchronize between multiple contexts.
Pull Request: https://projects.blender.org/blender/blender/pulls/115357
Currently all buffer types were stored in host memory, which is visible to the GPU as well.
This is typically slow as the data would be transferred over the PCI bus when used.
Most of the time Index and Vertex buffers are written once and read many times so it makes
more sense to locate them on the GPU. Storage buffers typically require quick access as they
are created for shading/compute purposes.
This PR will try to store vertex buffers, index buffers and storage buffers on device memory
to improve the performance.
Uniform buffers are still located on host memory as they can be uploaded during binding process.
This can (will) reset the graphics pipeline triggering draw calls using unattached resources.
In future this could be optimized further as in:
* using different pools for allocating specific buffers, with a fallback when buffers cannot be
stored on the GPU anymore.
* store uniform buffers in device memory
Pull Request: https://projects.blender.org/blender/blender/pulls/115343
This PR shows the memory footprint in the statusbar when activated.
Only memory allocated on the VRAM is counted. Memory allocated on host
memory is not counted.
Pull Request: https://projects.blender.org/blender/blender/pulls/115184
The current code ran afoul of various arithmetic overflow conditions
when attempting to either Copy out or Paste in large images that would
overflow either the naive `w * h * 4` expression or the size of what the
DibV5 header allowed (DWORD, uint32_t).
Pull Request: https://projects.blender.org/blender/blender/pulls/115018
Different from most layouts. The Turkish keyboard layout treats the `i` as the lowercase `İ` and the `ı` as the lowercase `I`.
So we have 2 different types of i: `ı` and `İ`. And two different I key positions on the keyboard.
This key with a different position is mapped as special and returns the corresponding `event->type` of the US keyboard `"` (`EVT_QUOTEKEY`).
The apparently most appropriate event for this key would be `EVT_IKEY`.
This type of change needs to be treated with care, as it may alter other shortcuts that are already common to Turkish users.
Pull Request: https://projects.blender.org/blender/blender/pulls/114917
This is never define and has no use in current blender.
If we want to keep this functionality, we should
at the very least rename it to `GHOST_WINDOW_ALPHA`.
Pull Request: https://projects.blender.org/blender/blender/pulls/114815
Anisotropy samplers are optional in Vulkan. This change will disable
anisotropy samplers when the feature isn't available on the device.
The support for anisotropy samplers is around 90% so would not expect
any compatibility issues.
Pull Request: https://projects.blender.org/blender/blender/pulls/114833
A windows pending actions wasn't cleared for new windows.
Although I'm not aware of user visible bugs, this prevents
unpredictable updates for new windows.
`shaderOutputLayer` and `shaderOutputViewportIndex` are optional in
Blender, but when used they should be activated on physical device level.
This wasn't the case and when used the validation layer reported an error.
This PR activates the features when creating the device if the features
are available.
Pull Request: https://projects.blender.org/blender/blender/pulls/114303
The last good commit was 8474716abb.
After this commits from main were pushed to blender-v4.0-release. These are
being reverted.
Commits a4880576dc from to b26f176d1a that happend afterwards were meant for
4.0, and their contents is preserved.
While the fix worked in my tests, the compositor is allowed to ignore
a requested window state change which could have entered an eternal
loop. Avoid this by limiting the while loop to 2x round-trips.
Even though the window was maximized, the non-maximized size was used.
Since the display size was used the window would be slightly larger,
clipping the status bar in GNOME.
As the window state will have been initialized, read the current window
state instead of assuming normal so changes are properly detected.
Also note that the cause of #107314 has been fixed up-stream.
When the output wasn't fractionally scaled but the compositor supports
fractional scaling, new windows were smaller than requested.
Caused by [0] which was incorrectly calculating the non-fractional scale
used by LIBDECOR (which isn't accessible via it's API).
Resolve by only using fractional scaling logic when outputs
have a fractional component.
[0]: 3eda5a114f
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.
The USE_LIBDECOR_FRACTIONAL_SCALE_HACK worked on my system but made
window size issues worse in older versions of GNOME, see: #109194.
Replace the hack with logic to set the window size using frational
scaling information from the output.
When fractional scaling is used, window sizes from LIBDECOR are still
divided by the window-decorations internal buffer scale which doesn't
match the GHOST window (always 1 in the case of fractional scale).
Also resolve glitches caused by recalculating the window size when
no size change was intended. In this case reuse LIBDECOR's internal
size so there are never any changes (caused by rounding for e.g.).
When the window manager set the window size, there were no checks
the size is a multiple of the buffer scale (a requirement for Wayland).
This meant setting the window size could exit Blender without warning
if an invalid window size was set.
