1berry/qtbase
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Skip potentially costly features in QVulkanWindow

Browse Source 
QVulkanWindow has recently been updated both in 5.15 and 6.x to start
enabling at least the 1.0 core features, because modern validation
layers are likely to complain if a feature is used without the
corresponding flag enabled upon device creation, even if the driver does
not actually care.

There is a catch here however, namely that some features may be true
opt-in flags, e.g. robustBufferAccess, and when enabled, they may incur
a performance penalty. So we will keep that one feature disabled even
when it is reported as supported.

It is unfortunate that VkPhysicalDeviceFeatures mixes together flags
that are most likely used only to query if some feature is supported by
the implementation while not serving as a real toggle (because opting
in/out is meaningless for the implementations in practice), and flags
that have significant effects when the feature is enabled, for example
when it comes to performance.

As QVulkanWindow only cares about 1.0, and 1.1+ features are to be
handled by the application via the features-modifier callback, we can
get away by just disabling robustBufferAccess and passing in everything
else supported as-is for vkCreateDevice.

Task-number: QTBUG-105158
Change-Id: I963402ab50f6e5d3fa6824680f69cff8568b669a
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
(cherry picked from commit f6dc0b4b20765175eb26aedb8c83920fc16276a1)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
This commit is contained in:
Laszlo Agocs 2022-08-02 12:16:45 +02:00 committed by Qt Cherry-pick Bot
parent f01fd007a6
commit 9258a78b22
1 changed files with 19 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

29
src/gui/vulkan/qvulkanwindow.cpp
View File

@ -175,11 +175,15 @@ Q_DECLARE_LOGGING_CATEGORY(lcGuiVk)
When it comes to device features, QVulkanWindow enables all Vulkan 1.0
features that are reported as supported from vkGetPhysicalDeviceFeatures().
This is always not sufficient, and therefore full control over the
VkPhysicalDeviceFeatures used for device creation is possible too by
registering a callback function with setEnabledFeaturesModifier(). When set,
the callback function is invoked, letting it alter the
VkPhysicalDeviceFeatures, instead of enabling only the 1.0 features.
As an exception to this rule, \c robustBufferAccess is never enabled. Use the
callback mechanism described below, if enabling that feature is desired.
Just enabling the 1.0 core features is not always sufficient, and therefore
full control over the VkPhysicalDeviceFeatures used for device creation is
possible too by registering a callback function with
setEnabledFeaturesModifier(). When set, the callback function is invoked,
letting it alter the VkPhysicalDeviceFeatures, instead of enabling only the
1.0 core features.
\sa QVulkanInstance, QWindow
*/
@ -703,8 +707,10 @@ void QVulkanWindowPrivate::init()
if (enabledFeaturesModifier) {
enabledFeaturesModifier(features);
} else {
// Enable all 1.0 features.
// Enable all supported 1.0 core features, except ones that likely
// involve a performance penalty.
f->vkGetPhysicalDeviceFeatures(physDev, &features);
features.robustBufferAccess = VK_FALSE;
}
devInfo.pEnabledFeatures = &features;
@ -1614,10 +1620,13 @@ void QVulkanWindow::setQueueCreateInfoModifier(const QueueCreateInfoModifier &mo
VkPhysicalDeviceFeatures that is passed in when creating a Vulkan device
object.
By default QVulkanWindow enables all Vulkan 1.0 features the physical
device reports as supported. That is not always sufficient when working
with Vulkan 1.1 or 1.2 features and extensions. Hence this callback
mechanism.
By default QVulkanWindow enables all Vulkan 1.0 core features that the
physical device reports as supported, with certain exceptions. In
praticular, \c robustBufferAccess is always disabled in order to avoid
unexpected performance hits.
This however is not always sufficient when working with Vulkan 1.1 or 1.2
features and extensions. Hence this callback mechanism.
The VkPhysicalDeviceFeatures reference passed in is all zeroed out at the
point when the function is invoked. It is up to the function to change