A bit simpler and more consistent because currently VK_USE_64_BIT_PTR_DEFINES
can be 1 but non dipatchable handles are always unit64_t.
Signed-off-by: Georg Lehmann <dadschoorse@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
There is no ABI ambiguity, so we may just use public names.
Signed-off-by: Jacek Caban <jacek@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This fixes a mismatch that occurred when the default type of VK_NULL_HANDLE and
VK_DEFINE_NON_DISPATCHABLE_HANDLE had changed in the upstream XML. Because WineVulkan overrides the
definition of VK_DEFINE_NON_DISPATCHABLE_HANDLE we must do the same for VK_NULL_HANDLE so that the
types match.
Signed-off-by: Liam Middlebrook <lmiddlebrook@nvidia.com>
Signed-off-by: Daniel Koch <dkoch@nvidia.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The Vulkan spec says:
The queueFamilyIndex member of each element of pQueueCreateInfos must be unique
within pQueueCreateInfos, except that two members can share the same
queueFamilyIndex if one is a protected-capable queue and one is not a
protected-capable queue.
Signed-off-by: Georg Lehmann <dadschoorse@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
It was needed for use cases like DXVK winelib builds. It was never
really adopted and it's problematic for PE builds.
Signed-off-by: Jacek Caban <jacek@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Previously
"thunk" : True, "private_thunk" : True
and
"thunk" : False, "private_thunk" : True
had the same effect and make_vulkan used both variant.
Replacing the two bools with an enum should reduce confusion.
Signed-off-by: Georg Lehmann <dadschoorse@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
When using the windows vulkan loader vk_icdGetPhysicalDeviceProcAddr
is used for unknown physical device functions.
Fixes Red Dead Redemption 2 with vkd3d-proton. The game replaces wine's
vulkan-1.dll with a windows version that doesn't know functions used by
vkd3d-proton.
Signed-off-by: Georg Lehmann <dadschoorse@gmail.com>
Signed-off-by: Joshua Ashton <joshua@froggi.es>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Currently, this function is passed through winevulkan to the system's
Vulkan loader, which causes the loader to write the system's device
layers properties in pProperties.
Unreal Engine 4 then calls vkEnumerateDeviceExtensionProperties, using
VkLayerProperties::layerName as the pLayerName.
winevulkan's implementation of vkEnumerateDeviceExtensionProperties then
returns VK_ERROR_LAYER_NOT_PRESENT, crashing UE4.
This issue was found while debugging Project Wingman (Steam appid
895870), but it should also happen to any UE4 application using the
Vulkan RHI.
Signed-off-by: Victor Hermann Chiletto <v@hnn.net.br>
Signed-off-by: Joshua Ashton <joshua@froggi.es>
Signed-off-by: Liam Middlebrook <lmiddlebrook@nvidia.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The section for vkEnumerateInstanceLayerProperties states [1]:
On success, this command returns
* VK_SUCCESS
* VK_INCOMPLETE
On failure, this command returns
* VK_ERROR_OUT_OF_HOST_MEMORY
* VK_ERROR_OUT_OF_DEVICE_MEMORY
Always setting the layer count to zero and returning VK_SUCCESS is
valid, as even if the function is given an array in pProperties, it's
filled with zero layers
[1]: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/vkEnumerateInstanceLayerProperties.html
Signed-off-by: Victor Hermann Chiletto <v@hnn.net.br>
Signed-off-by: Joshua Ashton <joshua@froggi.es>
Signed-off-by: Liam Middlebrook <lmiddlebrook@nvidia.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Fixes one of the issue related to the changes for VK_KHR_synchronization2.
Signed-off-by: Georg Lehmann <dadschoorse@gmail.com>
Signed-off-by: Liam Middlebrook <lmiddlebrook@nvidia.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Georg Lehmann