[Bug 51360] New: vkGetDeviceProcAddr invalid behavior for functions from extensions unsupported by host Vulkan instance

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=51360

Bug ID: 51360
           Summary: vkGetDeviceProcAddr invalid behavior for functions
                    from extensions unsupported by host Vulkan instance
           Product: Wine
           Version: unspecified
          Hardware: x86-64
                OS: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: winevulkan
          Assignee: [e-mail]
          Reporter: [e-mail]
      Distribution: ---

I believe the below may also be true for vkGetInstanceProcAddr, but I haven't
confirmed this locally.

The Vulkan 1.2.182 specification states the following about the behavior of
vkGetDeviceProcAddr:
> The table below defines the various use cases for vkGetDeviceProcAddr and
> expected return value for each case.
>
> The returned function pointer is of type PFN_vkVoidFunction, and must be cast to
> the type of the command being queried before use. The function pointer must only
> be called with a dispatchable object (the first parameter) that is device or a
> child of device.
>
> Table 2. vkGetDeviceProcAddr behavior
> device          |   pName                                           |    return value
> NULL            |   *[1]                                            |    undefined
> invalid device  |   *[1]                                            |    undefined
> device          |   NULL                                            |    undefined
> device          |   core device-level Vulkan command [2]            |    fp[3]
> device          |   enabled extension device-level commands [2]     |    fp[3]
>         any other case, not covered above                       |    NULL
>
> [1] - "*" means any representable value for the parameter (including valid
>       values, invalid values, and NULL).
>
> [2] - In this function, device-level excludes all physical-device-level
>       commands.
>
> [3] - The returned function pointer must only be called with a dispatchable
>       object (the first parameter) that is device or a child of device e.g.
>       VkDevice, VkQueue, or VkCommandBuffer.

Winevulkan's behavior differs from this slightly. Note the fifth row of the
table uses the language "enabled extension device-level commands", this means
that if a command is queried via vkGetDeviceProcAddr and isn't part of core,
the extension which introduces it must be enabled for the given VkDevice object
in order for vkGetDeviceProcAddr to return a valid function pointer, and
otherwise it should return NULL.

In order to properly conform to the Vulkan specification Winevulkan should only
expose device-level commands whose extensions have been enabled.

Note that applications should not be querying for Vulkan commands via
vkGetDeviceProcAddr if they know the extension is not supported by the
underlying implementation. However in the case of an application which does
rely on this bad behavior, Winevulkan will return a function pointer to one of
its thunks and then proceed to deference a null function pointer when it tries
to call into the underlying host Vulkan implementation.