Skip potentially costly features in QVulkanWindow

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
Pick-to: 6.4
Change-Id: I963402ab50f6e5d3fa6824680f69cff8568b669a
Reviewed-by: Andy Nichols <andy.nichols@qt.io>

1 files changed, 19 insertions, 10 deletions

diff --git a/src/gui/vulkan/qvulkanwindow.cpp b/src/gui/vulkan/qvulkanwindow.cpp
index 3dc7dd2200..29d6d0d5bd 100644
--- a/src/gui/vulkan/qvulkanwindow.cpp
+++ b/src/gui/vulkan/qvulkanwindow.cpp
@@ -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