vulkan: Expand cases where can_get_driver_info is true

[cmarcelo]

(UPDATED COMMIT MESSAGE)

VK_KHR_driver_properties requires VK_KHR_get_physical_device_properties2
extension. For Vulkan 1.2 both extensions are core, so nothing to do,
for Vulkan 1.1, the latter is core, so only need the former. For Vulkan
1.0 both extensions are required.

VK_KHR_driver_properties is a device extension that doesn't need to be
explicitly enabled here. As long as its supported it can be used in the
query on the physical device, before the logical device is created (i.e.
before device extensions can be enabled). See
https://registry.khronos.org/vulkan/specs/latest/html/vkspec.html#fundamentals-validusage-pNext.

VK_KHR_get_physical_device_properties2 is an instance extension,
required for the previous one. If the application hasn't enabled it,
do in its behalf. Also make sure when the extension is used, the KHR
version of the symbol is loaded.

This fixes vulkan_driver option in applications that ask for
Vulkan 1.0 (e.g. vkcube) but that the driver does support the extra
extensions.

[cmarcelo]

@DadSchoorse @flightlessmango

[DadSchoorse]

however Vulkan spec requires those to be enabled -- even if sometimes drivers work fine with just using extensions without enabling.

While correct in theory, enabling VK_KHR_driver_properties does nothing. It's a device extension, but only provides physical device level functionality. The property query on the physical device can be used long before a logical device is created. Enabling the extension anyway, while probably not harmful, is also pointless.

[cmarcelo]

Thanks for the clarification. For future reference, the spec section that allows this

Each structure included in the pNext chain must be defined at runtime by either:

- a core version which is supported
- an extension which is enabled
- a supported device extension in the case of physical-device-level functionality added by the device extension

https://registry.khronos.org/vulkan/specs/latest/html/vkspec.html#fundamentals-validusage-pNext

[DadSchoorse]

VK_KHR_get_physical_device_properties2 is a instance extension, not a device extension. So this is 100% the incorrect place to add it. The correct place to do it is vkCreateInstance. I remember issues with enabling instance extensions in layers, but they might actually be fixed now (KhronosGroup/Vulkan-Loader#547) so maybe give it a try.

[cmarcelo]

Yeah, that was 100% incorrect. Moved the handling for this extension into vkCreateInstance.

Based on the issue linked (and other ones linked from there), my local test, and the fact that Renderdoc enables instance extensions in a modified environment, I opted for enabling the extension if required.
See code around vk_device_funcs.cpp in Renderdoc.

The alternative proposed would be to modify the api_version to use 1.1, but that wouldn't work with drivers that are 1.0 only. See code around vulkan-capture.c in OBS.

[DadSchoorse]

Looks better now, just one thing that you need to pay attention to is that you actually use vkGetPhysicalDeviceProperties2KHR for Vulkan 1.0 instances, and not vkGetPhysicalDeviceProperties2. I don't think the dispatch table init here does that for you.

[cmarcelo]

Added code to handle a selected list of command aliases. Then added the vkGetPhysicalDeviceProperties2KHR name to that list.

Generated code now looks like this:

table->GetPhysicalDeviceFeatures2 = (PFN_vkGetPhysicalDeviceFeatures2) gpa(instance, "vkGetPhysicalDeviceFeatures2");
if (table->GetPhysicalDeviceFeatures2 == NULL)
    table->GetPhysicalDeviceFeatures2 = (PFN_vkGetPhysicalDeviceFeatures2) gpa(instance, "vkGetPhysicalDeviceFeatures2KHR");

[cmarcelo]

Updated again: this time don't try to extend the dispatch table, just load the right variant of vkGetPhysicalDeviceProperties2 (either non-KHR or KHR) when using it.

[DadSchoorse]

LGTM