Reland after a refactor of how the extension handling work in the Vulkan
backend.
The original author is David Turner <david.turner.dev@gmail.com>.
Certain Vulkan ICDs (Intel ones notably) will compile SPIR-V
shaders with an liberal, compiler-selected, subgroup size (i.e.
either 8, 16 or 32). For more context, see [1].
This can be a problem for compute, when one shader stores data
in device memory using a subgroup-size dependent layout, to be
consumed by a another shader. Problems arise when the compiler
decides to compile both shaders with different subgroup sizes.
To work-around this, the VK_EXT_subgroup_size_control device
extension was introduced recently: it allows the device to
report the min/max subgroup sizes it provides, and allows
the Vulkan program to control the subgroup size precisely
if it wants to.
This patch adds support to the Vulkan backend to report and
enable the extension if it is available. Note that:
- This changes the definition of VulkanDeviceKnobs to
make room for the required pNext-linked chains of
extensions.
- A helper class, PNextChainBuilder is also provided in
UtilsVulkan.h to make it easy to build pNext-linked
extension struct chains at runtime, as required when
probing device propertires/features, or when
creating a new VkDevice handle.
- This modifies VulkanDeviceInfo::GatherDeviceInfo() to
use PNextChainBuilder to query extension features and properties
in a single call to vkGetPhysicalDevice{Properties,Features}2.
Apart from that, there is no change in behaviour in this CL.
I.e. a later CL might force a specific subgroup size for
consistency, or introduce a new API to let Dawn clients
select a fixed subgroup size.
[1] https://bugs.freedesktop.org/show_bug.cgi?id=108875
Bug: dawn:464
Change-Id: I01e5c28e7dac66f0a57bf35532eb192912b254fa
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/23201
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
The checks for dependencies of Device extensions were incomplete, makes
sure the transitive dependencies of the extensions we care about are all
known so they can participate in the dependency check.
Also removes a workaround for surprising Vulkan behavior with instance
extensions getting promoted as device functions. This should be handled
correctly now as DeviceExt contains the physical device extensions as
well.
Bug: dawn:457
Change-Id: I4b79729d809c9edfedcb075a0e6aa5b4dd473ab3
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/22942
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
Similarly to the CL for Instance extensions, it makes each device
extension linked to an enum class and a bitset. Logic surrounding device
extensions is changed to take advantage of this to be more programmatic
and less error prone when adding support for a new extension.
Bug: dawn:457
Change-Id: Iecf623c40b890b7e00ba972d5eac0712866692b5
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/22941
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
At the moment each instance extension needs special handling
in 6+ places when added to the Vulkan backend. This is very
error-prone and makes it difficult to do changes in how they
are extensions are handled.
This CL makes instance extensions linked with an enum class
and a bitset to know which are available (instead of individual
booleans). A table of known extensions with more information like
`versionPromoted` so that they can be handled programmatically.
Bug: dawn:457
Change-Id: I266deb730eb2b7f3ab0ee7ada1b06ff9748a60e4
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/22940
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
