[PATCH v7 1/4] winevulkan: Support use of extensions which mustn't be exposed.
Signed-off-by: Derek Lesho <dlesho(a)codeweavers.com> --- v7: Fixed typo whereupon the presence the of the is_required method was checked, rather than the return value. --- dlls/winevulkan/make_vulkan | 35 ++++++++++++++++++++++++----------- 1 file changed, 24 insertions(+), 11 deletions(-) diff --git a/dlls/winevulkan/make_vulkan b/dlls/winevulkan/make_vulkan index 7f76d328fc8..34dd9fc432f 100755 --- a/dlls/winevulkan/make_vulkan +++ b/dlls/winevulkan/make_vulkan @@ -120,6 +120,11 @@ UNSUPPORTED_EXTENSIONS = [ "VK_NV_external_memory_win32", ] +# Either internal extensions which aren't present on the win32 platform which +# winevulkan may nonetheless use, or extensions we want to generate headers for +# but not expose to applications (useful for test commits) +UNEXPOSED_EXTENSIONS = {} + # The Vulkan loader provides entry-points for core functionality and important # extensions. Based on vulkan-1.def this amounts to WSI extensions on 1.0.51. CORE_EXTENSIONS = [ @@ -521,8 +526,8 @@ class VkEnumValue(object): class VkFunction(object): - def __init__(self, _type=None, name=None, params=[], extensions=[], alias=None): - self.extensions = [] + def __init__(self, _type=None, name=None, params=[], alias=None): + self.extensions = set() self.name = name self.type = _type self.params = params @@ -665,6 +670,10 @@ class VkFunction(object): def needs_private_thunk(self): return self.thunk_type == ThunkType.PRIVATE + def needs_exposing(self): + # The function needs exposed if at-least one extension isn't both UNSUPPORTED and UNEXPOSED + return self.is_required() and (not self.extensions or not self.extensions.issubset(UNEXPOSED_EXTENSIONS)) + def pfn(self, prefix="p", call_conv=None, conv=False): """ Create function pointer. """ @@ -2653,7 +2662,7 @@ class VkGenerator(object): # Create thunks for instance and device functions. # Global functions don't go through the thunks. for vk_func in self.registry.funcs.values(): - if not vk_func.is_required(): + if not vk_func.needs_exposing(): continue if vk_func.is_global_func(): @@ -2676,6 +2685,8 @@ class VkGenerator(object): for ext in self.registry.extensions: if ext["type"] != "device": continue + if ext["name"] in UNEXPOSED_EXTENSIONS: + continue f.write(" \"{0}\",\n".format(ext["name"])) f.write("};\n\n") @@ -2685,6 +2696,8 @@ class VkGenerator(object): for ext in self.registry.extensions: if ext["type"] != "instance": continue + if ext["name"] in UNEXPOSED_EXTENSIONS: + continue f.write(" \"{0}\",\n".format(ext["name"])) f.write("};\n\n") @@ -2744,7 +2757,7 @@ class VkGenerator(object): f.write("const struct unix_funcs loader_funcs =\n") f.write("{\n") for vk_func in self.registry.funcs.values(): - if not vk_func.is_required(): + if not vk_func.needs_exposing(): continue if vk_func.loader_thunk_type == ThunkType.NONE: continue @@ -2763,7 +2776,7 @@ class VkGenerator(object): # Generate prototypes for device and instance functions requiring a custom implementation. f.write("/* Functions for which we have custom implementations outside of the thunks. */\n") for vk_func in self.registry.funcs.values(): - if not vk_func.is_required(): + if not vk_func.needs_exposing(): continue if vk_func.needs_thunk() and not vk_func.needs_private_thunk(): continue @@ -2872,7 +2885,7 @@ class VkGenerator(object): f.write("WINE_DEFAULT_DEBUG_CHANNEL(vulkan);\n\n") for vk_func in self.registry.funcs.values(): - if not vk_func.is_required(): + if not vk_func.needs_exposing(): continue if vk_func.loader_thunk_type != ThunkType.PUBLIC: continue @@ -2881,7 +2894,7 @@ class VkGenerator(object): f.write("static const struct vulkan_func vk_device_dispatch_table[] =\n{\n") for vk_func in self.registry.device_funcs: - if not vk_func.is_required(): + if not vk_func.needs_exposing(): continue f.write(" {{\"{0}\", &{0}}},\n".format(vk_func.name)) @@ -2889,7 +2902,7 @@ class VkGenerator(object): f.write("static const struct vulkan_func vk_phys_dev_dispatch_table[] =\n{\n") for vk_func in self.registry.phys_dev_funcs: - if not vk_func.is_required(): + if not vk_func.needs_exposing(): continue f.write(" {{\"{0}\", &{0}}},\n".format(vk_func.name)) @@ -2897,7 +2910,7 @@ class VkGenerator(object): f.write("static const struct vulkan_func vk_instance_dispatch_table[] =\n{\n") for vk_func in self.registry.instance_funcs: - if not vk_func.is_required(): + if not vk_func.needs_exposing(): continue f.write(" {{\"{0}\", &{0}}},\n".format(vk_func.name)) @@ -2954,7 +2967,7 @@ class VkGenerator(object): f.write("struct unix_funcs\n") f.write("{\n") for vk_func in self.registry.funcs.values(): - if not vk_func.is_required(): + if not vk_func.needs_exposing(): continue if vk_func.loader_thunk_type == ThunkType.NONE: continue @@ -3447,7 +3460,7 @@ class VkRegistry(object): # the XML file to handle this, but because of the manner in which we parse the XML # file we pre-populate from <commands> before we check if a command is enabled. if cmd_name in self.funcs: - self.funcs[cmd_name].extensions.append(ext_name) + self.funcs[cmd_name].extensions.add(ext_name) # Some extensions are not ready or have numbers reserved as a place holder. if ext.attrib["supported"] == "disabled": -- 2.31.1
Signed-off-by: Derek Lesho <dlesho(a)codeweavers.com> --- dlls/vulkan-1/tests/vulkan.c | 218 +++++++++++++++++++++++++++++++++++ dlls/winevulkan/make_vulkan | 5 +- 2 files changed, 221 insertions(+), 2 deletions(-) diff --git a/dlls/vulkan-1/tests/vulkan.c b/dlls/vulkan-1/tests/vulkan.c index 1d23c4112cf..64dcead3476 100644 --- a/dlls/vulkan-1/tests/vulkan.c +++ b/dlls/vulkan-1/tests/vulkan.c @@ -546,6 +546,223 @@ static void test_null_hwnd(VkInstance vk_instance, VkPhysicalDevice vk_physical_ vkDestroySurfaceKHR(vk_instance, surface, NULL); } +uint32_t find_memory_type(VkPhysicalDevice vk_physical_device, VkMemoryPropertyFlagBits flags, uint32_t mask) +{ + VkPhysicalDeviceMemoryProperties properties = {0}; + unsigned int i; + + vkGetPhysicalDeviceMemoryProperties(vk_physical_device, &properties); + + for(i = 0; i < properties.memoryTypeCount; i++) + { + if ((1u << i) & mask && properties.memoryTypes[i].propertyFlags & flags) + return i; + } + return -1; +} + +static const char *test_external_memory_extensions[] = +{ + "VK_KHR_external_memory_capabilities", +}; + +static void test_external_memory(VkInstance vk_instance, VkPhysicalDevice vk_physical_device) +{ + PFN_vkGetPhysicalDeviceExternalBufferPropertiesKHR pfn_vkGetPhysicalDeviceExternalBufferPropertiesKHR; + PFN_vkGetMemoryWin32HandleKHR pfn_vkGetMemoryWin32HandleKHR; + VkPhysicalDeviceExternalBufferInfoKHR external_buffer_info; + VkExternalBufferPropertiesKHR external_buffer_properties; + VkMemoryDedicatedAllocateInfoKHR dedicated_alloc_info; + VkExportMemoryWin32HandleInfoKHR export_handle_info; + VkImportMemoryWin32HandleInfoKHR import_handle_info; + VkExportMemoryAllocateInfoKHR export_memory_info; + VkMemoryGetWin32HandleInfoKHR get_handle_info; + VkDeviceMemory vk_memory, vk_memory_import; + VkMemoryRequirements memory_requirements; + VkBufferCreateInfo buffer_create_info; + VkMemoryAllocateInfo alloc_info; + HANDLE nt_handle, kmt_handle; + uint32_t queue_family_index; + VkBuffer vk_buffer; + VkDevice vk_device; + VkResult vr; + + static const char *extensions[] = + { + "VK_KHR_dedicated_allocation", + "VK_KHR_external_memory", + "VK_KHR_external_memory_win32", + }; + + pfn_vkGetPhysicalDeviceExternalBufferPropertiesKHR = + (void*) vkGetInstanceProcAddr(vk_instance, "vkGetPhysicalDeviceExternalBufferPropertiesKHR"); + + if ((vr = create_device(vk_physical_device, ARRAY_SIZE(extensions), extensions, NULL, &vk_device))) + { + skip("Failed to create device with external memory extensions, VkResult %d.\n", vr); + return; + } + + pfn_vkGetMemoryWin32HandleKHR = (void *) vkGetDeviceProcAddr(vk_device, "vkGetMemoryWin32HandleKHR"); + + find_queue_family(vk_physical_device, VK_QUEUE_GRAPHICS_BIT, &queue_family_index); + + /* Most implementations only support exporting dedicated allocations */ + + buffer_create_info.sType = VK_STRUCTURE_TYPE_BUFFER_CREATE_INFO; + buffer_create_info.pNext = NULL; + buffer_create_info.flags = 0; + buffer_create_info.size = 1; + buffer_create_info.usage = VK_BUFFER_USAGE_TRANSFER_SRC_BIT | VK_BUFFER_USAGE_TRANSFER_DST_BIT; + buffer_create_info.sharingMode = VK_SHARING_MODE_CONCURRENT; + buffer_create_info.queueFamilyIndexCount = 1; + buffer_create_info.pQueueFamilyIndices = &queue_family_index; + if ((vr = vkCreateBuffer(vk_device, &buffer_create_info, NULL, &vk_buffer))) + { + skip("Failed to create generic buffer, VkResult %d.\n", vr); + vkDestroyDevice(vk_device, NULL); + return; + } + + dedicated_alloc_info.sType = VK_STRUCTURE_TYPE_MEMORY_DEDICATED_ALLOCATE_INFO_KHR; + dedicated_alloc_info.pNext = NULL; + dedicated_alloc_info.image = VK_NULL_HANDLE; + dedicated_alloc_info.buffer = vk_buffer; + + external_buffer_info.sType = VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTERNAL_BUFFER_INFO_KHR; + external_buffer_info.pNext = NULL; + external_buffer_info.flags = 0; + external_buffer_info.usage = VK_BUFFER_USAGE_TRANSFER_SRC_BIT | VK_BUFFER_USAGE_TRANSFER_DST_BIT; + external_buffer_info.handleType = VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_BIT_KHR; + + memset(&external_buffer_properties, 0, sizeof(external_buffer_properties)); + external_buffer_properties.sType = VK_STRUCTURE_TYPE_EXTERNAL_BUFFER_PROPERTIES_KHR; + + pfn_vkGetPhysicalDeviceExternalBufferPropertiesKHR(vk_physical_device, &external_buffer_info, &external_buffer_properties); + + vkGetBufferMemoryRequirements(vk_device, vk_buffer, &memory_requirements); + + if (!(external_buffer_properties.externalMemoryProperties.externalMemoryFeatures & + (VK_EXTERNAL_MEMORY_FEATURE_EXPORTABLE_BIT_KHR|VK_EXTERNAL_MEMORY_FEATURE_IMPORTABLE_BIT_KHR))) + skip("With desired parameters, buffers are not exportable to and importable from an NT handle.\n"); + else + { + ok(external_buffer_properties.externalMemoryProperties.compatibleHandleTypes & VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_BIT_KHR, + "Unexpected compatibleHandleTypes %#x.\n", external_buffer_properties.externalMemoryProperties.compatibleHandleTypes); + + export_memory_info.sType = VK_STRUCTURE_TYPE_EXPORT_MEMORY_ALLOCATE_INFO_KHR; + export_memory_info.pNext = &dedicated_alloc_info; + export_memory_info.handleTypes = VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_BIT_KHR; + + export_handle_info.sType = VK_STRUCTURE_TYPE_EXPORT_MEMORY_WIN32_HANDLE_INFO_KHR; + export_handle_info.pNext = &export_memory_info; + export_handle_info.name = L"wine_test_buffer_export_name"; + export_handle_info.dwAccess = GENERIC_ALL; + export_handle_info.pAttributes = NULL; + + alloc_info.sType = VK_STRUCTURE_TYPE_MEMORY_ALLOCATE_INFO; + alloc_info.pNext = &export_handle_info; + alloc_info.allocationSize = memory_requirements.size; + alloc_info.memoryTypeIndex = find_memory_type(vk_physical_device, VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT, memory_requirements.memoryTypeBits); + + ok(alloc_info.memoryTypeIndex != -1, "Device local memory type index was not found.\n"); + + vr = vkAllocateMemory(vk_device, &alloc_info, NULL, &vk_memory); + ok(vr == VK_SUCCESS, "vkAllocateMemory failed, VkResult %d.\n", vr); + + get_handle_info.sType = VK_STRUCTURE_TYPE_MEMORY_GET_WIN32_HANDLE_INFO_KHR; + get_handle_info.pNext = NULL; + get_handle_info.memory = vk_memory; + get_handle_info.handleType = VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_BIT_KHR; + + vr = pfn_vkGetMemoryWin32HandleKHR(vk_device, &get_handle_info, &nt_handle); + ok(vr == VK_SUCCESS, "vkGetMemoryWin32HandleKHR failed, VkResult %d.\n", vr); + + import_handle_info.sType = VK_STRUCTURE_TYPE_IMPORT_MEMORY_WIN32_HANDLE_INFO_KHR; + import_handle_info.pNext = &dedicated_alloc_info; + import_handle_info.handleType = VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_BIT_KHR; + import_handle_info.handle = nt_handle; + import_handle_info.name = NULL; + + alloc_info.pNext = &import_handle_info; + + vr = vkAllocateMemory(vk_device, &alloc_info, NULL, &vk_memory_import); + ok(vr == VK_SUCCESS, "vkAllocateMemory failed, VkResult %d.\n", vr); + ok(vk_memory_import != vk_memory, "Expected new memory object.\n"); + + vkFreeMemory(vk_device, vk_memory_import, NULL); + + import_handle_info.handle = NULL; + import_handle_info.name = L"wine_test_buffer_export_name"; + + vr = vkAllocateMemory(vk_device, &alloc_info, NULL, &vk_memory_import); + ok(vr == VK_SUCCESS, "vkAllocateMemory failed, VkResult %d.\n", vr); + if (vr == VK_SUCCESS) + { + ok(vk_memory_import != vk_memory, "Expected new memory object.\n"); + vkFreeMemory(vk_device, vk_memory_import, NULL); + } + vkFreeMemory(vk_device, vk_memory, NULL); + CloseHandle(nt_handle); + } + + external_buffer_info.handleType = VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_KMT_BIT_KHR; + + memset(&external_buffer_properties, 0, sizeof(external_buffer_properties)); + external_buffer_properties.sType = VK_STRUCTURE_TYPE_EXTERNAL_BUFFER_PROPERTIES_KHR; + + pfn_vkGetPhysicalDeviceExternalBufferPropertiesKHR(vk_physical_device, &external_buffer_info, &external_buffer_properties); + + if (!(external_buffer_properties.externalMemoryProperties.externalMemoryFeatures & + (VK_EXTERNAL_MEMORY_FEATURE_EXPORTABLE_BIT_KHR|VK_EXTERNAL_MEMORY_FEATURE_IMPORTABLE_BIT_KHR))) + skip("With desired parameters, buffers are not exportable to and importable from a KMT handle.\n"); + else + { + ok(external_buffer_properties.externalMemoryProperties.compatibleHandleTypes & VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_KMT_BIT_KHR, + "Unexpected compatibleHandleTypes %#x.\n", external_buffer_properties.externalMemoryProperties.compatibleHandleTypes); + + export_memory_info.sType = VK_STRUCTURE_TYPE_EXPORT_MEMORY_ALLOCATE_INFO_KHR; + export_memory_info.pNext = &dedicated_alloc_info; + export_memory_info.handleTypes = VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_KMT_BIT_KHR; + + alloc_info.sType = VK_STRUCTURE_TYPE_MEMORY_ALLOCATE_INFO; + alloc_info.pNext = &export_memory_info; + alloc_info.allocationSize = memory_requirements.size; + alloc_info.memoryTypeIndex = find_memory_type(vk_physical_device, VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT, memory_requirements.memoryTypeBits); + + ok(alloc_info.memoryTypeIndex != -1, "Device local memory type index was not found.\n"); + + vr = vkAllocateMemory(vk_device, &alloc_info, NULL, &vk_memory); + ok(vr == VK_SUCCESS, "vkAllocateMemory failed, VkResult %d.\n", vr); + + get_handle_info.sType = VK_STRUCTURE_TYPE_MEMORY_GET_WIN32_HANDLE_INFO_KHR; + get_handle_info.pNext = NULL; + get_handle_info.memory = vk_memory; + get_handle_info.handleType = VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_KMT_BIT_KHR; + + vr = pfn_vkGetMemoryWin32HandleKHR(vk_device, &get_handle_info, &kmt_handle); + ok(vr == VK_SUCCESS, "vkGetMemoryWin32HandleKHR failed, VkResult %d.\n", vr); + + import_handle_info.sType = VK_STRUCTURE_TYPE_IMPORT_MEMORY_WIN32_HANDLE_INFO_KHR; + import_handle_info.pNext = &dedicated_alloc_info; + import_handle_info.handleType = VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_KMT_BIT_KHR; + import_handle_info.handle = kmt_handle; + import_handle_info.name = NULL; + + alloc_info.pNext = &import_handle_info; + + vr = vkAllocateMemory(vk_device, &alloc_info, NULL, &vk_memory_import); + ok(vr == VK_SUCCESS, "vkAllocateMemory failed, VkResult %d.\n", vr); + ok(vk_memory_import != vk_memory, "Expected new memory object.\n"); + + vkFreeMemory(vk_device, vk_memory_import, NULL); + vkFreeMemory(vk_device, vk_memory, NULL); + } + + vkDestroyBuffer(vk_device, vk_buffer, NULL); + vkDestroyDevice(vk_device, NULL); +} + static void for_each_device_instance(uint32_t extension_count, const char * const *enabled_extensions, void (*test_func_instance)(VkInstance, VkPhysicalDevice), void (*test_func)(VkPhysicalDevice)) { @@ -602,4 +819,5 @@ START_TEST(vulkan) for_each_device(test_unsupported_device_extensions); for_each_device(test_private_data); for_each_device_instance(ARRAY_SIZE(test_null_hwnd_extensions), test_null_hwnd_extensions, test_null_hwnd, NULL); + for_each_device_instance(ARRAY_SIZE(test_external_memory_extensions), test_external_memory_extensions, test_external_memory, NULL); } diff --git a/dlls/winevulkan/make_vulkan b/dlls/winevulkan/make_vulkan index 34dd9fc432f..31219ad0469 100755 --- a/dlls/winevulkan/make_vulkan +++ b/dlls/winevulkan/make_vulkan @@ -99,7 +99,6 @@ UNSUPPORTED_EXTENSIONS = [ "VK_EXT_pipeline_creation_feedback", "VK_GOOGLE_display_timing", "VK_KHR_external_fence_win32", - "VK_KHR_external_memory_win32", "VK_KHR_external_semaphore_win32", # Relates to external_semaphore and needs type conversions in bitflags. "VK_KHR_shared_presentable_image", # Needs WSI work. @@ -123,7 +122,9 @@ UNSUPPORTED_EXTENSIONS = [ # Either internal extensions which aren't present on the win32 platform which # winevulkan may nonetheless use, or extensions we want to generate headers for # but not expose to applications (useful for test commits) -UNEXPOSED_EXTENSIONS = {} +UNEXPOSED_EXTENSIONS = { + "VK_KHR_external_memory_win32", +} # The Vulkan loader provides entry-points for core functionality and important # extensions. Based on vulkan-1.def this amounts to WSI extensions on 1.0.51. -- 2.31.1
Signed-off-by: Georg Lehmann <dadschoorse(a)gmail.com>
Signed-off-by: Derek Lesho <dlesho(a)codeweavers.com> --- v7: Fixed various oversights stemming from me not testing v6. --- dlls/vulkan-1/tests/vulkan.c | 1 + dlls/winevulkan/make_vulkan | 20 +- dlls/winevulkan/vulkan.c | 351 ++++++++++++++++++++++++++++++- dlls/winevulkan/vulkan_private.h | 24 +++ 4 files changed, 389 insertions(+), 7 deletions(-) diff --git a/dlls/vulkan-1/tests/vulkan.c b/dlls/vulkan-1/tests/vulkan.c index 64dcead3476..935ded0c3bf 100644 --- a/dlls/vulkan-1/tests/vulkan.c +++ b/dlls/vulkan-1/tests/vulkan.c @@ -696,6 +696,7 @@ static void test_external_memory(VkInstance vk_instance, VkPhysicalDevice vk_phy import_handle_info.name = L"wine_test_buffer_export_name"; vr = vkAllocateMemory(vk_device, &alloc_info, NULL, &vk_memory_import); + todo_wine ok(vr == VK_SUCCESS, "vkAllocateMemory failed, VkResult %d.\n", vr); if (vr == VK_SUCCESS) { diff --git a/dlls/winevulkan/make_vulkan b/dlls/winevulkan/make_vulkan index 31219ad0469..618ce121862 100755 --- a/dlls/winevulkan/make_vulkan +++ b/dlls/winevulkan/make_vulkan @@ -108,7 +108,6 @@ UNSUPPORTED_EXTENSIONS = [ "VK_EXT_external_memory_dma_buf", "VK_EXT_image_drm_format_modifier", "VK_KHR_external_fence_fd", - "VK_KHR_external_memory_fd", "VK_KHR_external_semaphore_fd", # Extensions which require callback handling @@ -123,7 +122,7 @@ UNSUPPORTED_EXTENSIONS = [ # winevulkan may nonetheless use, or extensions we want to generate headers for # but not expose to applications (useful for test commits) UNEXPOSED_EXTENSIONS = { - "VK_KHR_external_memory_win32", + "VK_KHR_external_memory_fd", } # The Vulkan loader provides entry-points for core functionality and important @@ -182,7 +181,7 @@ FUNCTION_OVERRIDES = { "vkEnumerateDeviceLayerProperties": {"dispatch": True, "driver": False, "thunk": ThunkType.NONE}, "vkEnumeratePhysicalDeviceGroups" : {"dispatch" : True, "driver" : False, "thunk" : ThunkType.NONE}, "vkEnumeratePhysicalDevices" : {"dispatch" : True, "driver" : False, "thunk" : ThunkType.NONE}, - "vkGetPhysicalDeviceExternalBufferProperties" : {"dispatch" : False, "driver" : False, "thunk" : ThunkType.NONE}, + "vkGetPhysicalDeviceExternalBufferProperties" : {"dispatch" : True, "driver" : False, "thunk" : ThunkType.NONE}, "vkGetPhysicalDeviceExternalFenceProperties" : {"dispatch" : False, "driver" : False, "thunk" : ThunkType.NONE}, "vkGetPhysicalDeviceExternalSemaphoreProperties" : {"dispatch" : False, "driver" : False, "thunk" : ThunkType.NONE}, "vkGetPhysicalDeviceImageFormatProperties2" : {"dispatch" : True, "driver" : False, "thunk" : ThunkType.PRIVATE}, @@ -191,10 +190,13 @@ FUNCTION_OVERRIDES = { # Device functions "vkAllocateCommandBuffers" : {"dispatch" : True, "driver" : False, "thunk" : ThunkType.NONE}, + "vkAllocateMemory" : {"dispatch" : True, "driver" : False, "thunk" : ThunkType.NONE}, + "vkCreateBuffer" : {"dispatch" : True, "driver" : False, "thunk" : ThunkType.NONE}, "vkCreateCommandPool" : {"dispatch": True, "driver" : False, "thunk" : ThunkType.NONE}, "vkDestroyCommandPool" : {"dispatch": True, "driver" : False, "thunk" : ThunkType.NONE}, "vkDestroyDevice" : {"dispatch" : True, "driver" : False, "thunk" : ThunkType.NONE}, "vkFreeCommandBuffers" : {"dispatch" : True, "driver" : False, "thunk" : ThunkType.NONE}, + "vkFreeMemory" : {"dispatch" : True, "driver" : False, "thunk" : ThunkType.NONE}, "vkGetDeviceProcAddr" : {"dispatch" : False, "driver" : True, "thunk" : ThunkType.NONE, "loader_thunk" : ThunkType.NONE}, "vkGetDeviceQueue" : {"dispatch": True, "driver" : False, "thunk" : ThunkType.NONE}, "vkGetDeviceQueue2" : {"dispatch": True, "driver" : False, "thunk" : ThunkType.NONE}, @@ -224,7 +226,7 @@ FUNCTION_OVERRIDES = { "vkGetPhysicalDeviceExternalFencePropertiesKHR" : {"dispatch" : False, "driver" : False, "thunk" : ThunkType.NONE}, # VK_KHR_external_memory_capabilities - "vkGetPhysicalDeviceExternalBufferPropertiesKHR" : {"dispatch" : False, "driver" : False, "thunk" : ThunkType.NONE}, + "vkGetPhysicalDeviceExternalBufferPropertiesKHR" : {"dispatch" : True, "driver" : False, "thunk" : ThunkType.NONE}, "vkGetPhysicalDeviceImageFormatProperties2KHR" : {"dispatch" : True, "driver" : False, "thunk" : ThunkType.PRIVATE}, # VK_KHR_external_semaphore_capabilities @@ -260,12 +262,20 @@ FUNCTION_OVERRIDES = { # VK_EXT_debug_marker "vkDebugMarkerSetObjectNameEXT" : {"dispatch": True, "driver" : False, "thunk" : ThunkType.PRIVATE}, "vkDebugMarkerSetObjectTagEXT" : {"dispatch": True, "driver" : False, "thunk" : ThunkType.PRIVATE}, + + # VK_KHR_external_memory_win32 + "vkGetMemoryWin32HandleKHR" : {"dispatch" : True, "driver" : False, "thunk" : ThunkType.NONE}, + "vkGetMemoryWin32HandlePropertiesKHR" : {"dispatch" : True, "driver" : False, "thunk" : ThunkType.NONE}, } STRUCT_CHAIN_CONVERSIONS = { # Ignore to not confuse host loader. "VkDeviceCreateInfo": ["VK_STRUCTURE_TYPE_LOADER_DEVICE_CREATE_INFO"], "VkInstanceCreateInfo": ["VK_STRUCTURE_TYPE_LOADER_INSTANCE_CREATE_INFO"], + + # Structs which require pNext chain modification + "VkBufferCreateInfo": [], + "VkMemoryAllocateInfo": ["VK_STRUCTURE_TYPE_EXPORT_MEMORY_WIN32_HANDLE_INFO_KHR", "VK_STRUCTURE_TYPE_IMPORT_MEMORY_WIN32_HANDLE_INFO_KHR"], } @@ -1056,6 +1066,8 @@ class VkHandle(object): return "wine_debug_report_callback_from_handle({0})->debug_callback".format(name) if self.name == "VkSurfaceKHR": return "wine_surface_from_handle({0})->surface".format(name) + if self.name == "VkDeviceMemory": + return "wine_dev_mem_from_handle({0})->dev_mem".format(name) native_handle_name = None diff --git a/dlls/winevulkan/vulkan.c b/dlls/winevulkan/vulkan.c index 9f181d92bc5..327113289a7 100644 --- a/dlls/winevulkan/vulkan.c +++ b/dlls/winevulkan/vulkan.c @@ -25,6 +25,7 @@ #include <time.h> #include <stdarg.h> #include <stdlib.h> +#include <unistd.h> #include "ntstatus.h" #define WIN32_NO_STATUS @@ -34,6 +35,8 @@ #include "winuser.h" #include "winternl.h" +#include "wine/server.h" + #include "vulkan_private.h" WINE_DEFAULT_DEBUG_CHANNEL(vulkan); @@ -263,6 +266,15 @@ static struct VkPhysicalDevice_T *wine_vk_physical_device_alloc(struct VkInstanc */ for (i = 0; i < num_host_properties; i++) { + if (!strcmp(host_properties[i].extensionName, "VK_KHR_external_memory_fd")) + { + TRACE("Substituting VK_KHR_external_memory_fd for VK_KHR_external_memory_win32\n"); + + snprintf(host_properties[i].extensionName, sizeof(host_properties[i].extensionName), + VK_KHR_EXTERNAL_MEMORY_WIN32_EXTENSION_NAME); + host_properties[i].specVersion = VK_KHR_EXTERNAL_MEMORY_WIN32_SPEC_VERSION; + } + if (wine_vk_device_extension_supported(host_properties[i].extensionName)) { TRACE("Enabling extension '%s' for physical device %p\n", host_properties[i].extensionName, object); @@ -361,11 +373,15 @@ static void wine_vk_device_get_queues(struct VkDevice_T *device, static void wine_vk_device_free_create_info(VkDeviceCreateInfo *create_info) { free_VkDeviceCreateInfo_struct_chain(create_info); + + if (create_info->enabledExtensionCount) + free((void *)create_info->ppEnabledExtensionNames); } static VkResult wine_vk_device_convert_create_info(const VkDeviceCreateInfo *src, VkDeviceCreateInfo *dst) { + const char **enabled_extensions; unsigned int i; VkResult res; @@ -389,11 +405,34 @@ static VkResult wine_vk_device_convert_create_info(const VkDeviceCreateInfo *src if (!wine_vk_device_extension_supported(extension_name)) { WARN("Extension %s is not supported.\n", debugstr_a(extension_name)); - wine_vk_device_free_create_info(dst); + free_VkDeviceCreateInfo_struct_chain(dst); return VK_ERROR_EXTENSION_NOT_PRESENT; } } + if (src->enabledExtensionCount > 0) + { + enabled_extensions = calloc(src->enabledExtensionCount, sizeof(*src->ppEnabledExtensionNames)); + if (!enabled_extensions) + { + free_VkDeviceCreateInfo_struct_chain(dst); + return VK_ERROR_OUT_OF_HOST_MEMORY; + } + + for (i = 0; i < src->enabledExtensionCount; i++) + { + if (!strcmp(src->ppEnabledExtensionNames[i], "VK_KHR_external_memory_win32")) + { + enabled_extensions[i] = "VK_KHR_external_memory_fd"; + } + else + { + enabled_extensions[i] = src->ppEnabledExtensionNames[i]; + } + } + dst->ppEnabledExtensionNames = enabled_extensions; + } + return VK_SUCCESS; } @@ -1187,18 +1226,71 @@ void WINAPI wine_vkGetPhysicalDeviceExternalFencePropertiesKHR(VkPhysicalDevice properties->externalFenceFeatures = 0; } +static inline void wine_vk_normalize_handle_types_win(VkExternalMemoryHandleTypeFlags *types) +{ + *types &= + VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_BIT | + VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_KMT_BIT | + VK_EXTERNAL_MEMORY_HANDLE_TYPE_D3D11_TEXTURE_BIT | + VK_EXTERNAL_MEMORY_HANDLE_TYPE_D3D11_TEXTURE_KMT_BIT | + VK_EXTERNAL_MEMORY_HANDLE_TYPE_D3D12_HEAP_BIT | + VK_EXTERNAL_MEMORY_HANDLE_TYPE_D3D12_RESOURCE_BIT | + VK_EXTERNAL_MEMORY_HANDLE_TYPE_HOST_ALLOCATION_BIT_EXT | + VK_EXTERNAL_MEMORY_HANDLE_TYPE_HOST_MAPPED_FOREIGN_MEMORY_BIT_EXT; +} + +static inline void wine_vk_normalize_handle_types_host(VkExternalMemoryHandleTypeFlags *types) +{ + *types &= + VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT | + VK_EXTERNAL_MEMORY_HANDLE_TYPE_HOST_ALLOCATION_BIT_EXT | +/* predicated on VK_KHR_external_memory_dma_buf + VK_EXTERNAL_MEMORY_HANDLE_TYPE_DMA_BUF_BIT_EXT | */ + VK_EXTERNAL_MEMORY_HANDLE_TYPE_HOST_MAPPED_FOREIGN_MEMORY_BIT_EXT; +} + +static void wine_vk_get_physical_device_external_buffer_properties(VkPhysicalDevice phys_dev, + void (*p_vkGetPhysicalDeviceExternalBufferProperties)(VkPhysicalDevice, const VkPhysicalDeviceExternalBufferInfo *, VkExternalBufferProperties *), + const VkPhysicalDeviceExternalBufferInfo *buffer_info, VkExternalBufferProperties *properties) +{ + VkPhysicalDeviceExternalBufferInfo buffer_info_dup = *buffer_info; + + wine_vk_normalize_handle_types_win(&buffer_info_dup.handleType); + if (buffer_info_dup.handleType == VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_BIT) + buffer_info_dup.handleType = VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT; + wine_vk_normalize_handle_types_host(&buffer_info_dup.handleType); + + if (buffer_info->handleType && !buffer_info_dup.handleType) + { + memset(&properties->externalMemoryProperties, 0, sizeof(properties->externalMemoryProperties)); + return; + } + + p_vkGetPhysicalDeviceExternalBufferProperties(phys_dev->phys_dev, &buffer_info_dup, properties); + + if (properties->externalMemoryProperties.exportFromImportedHandleTypes & VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT) + properties->externalMemoryProperties.exportFromImportedHandleTypes |= VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_BIT; + wine_vk_normalize_handle_types_win(&properties->externalMemoryProperties.exportFromImportedHandleTypes); + + if (properties->externalMemoryProperties.compatibleHandleTypes & VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT) + properties->externalMemoryProperties.compatibleHandleTypes |= VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_BIT; + wine_vk_normalize_handle_types_win(&properties->externalMemoryProperties.compatibleHandleTypes); +} + void WINAPI wine_vkGetPhysicalDeviceExternalBufferProperties(VkPhysicalDevice phys_dev, const VkPhysicalDeviceExternalBufferInfo *buffer_info, VkExternalBufferProperties *properties) { TRACE("%p, %p, %p\n", phys_dev, buffer_info, properties); - memset(&properties->externalMemoryProperties, 0, sizeof(properties->externalMemoryProperties)); + + wine_vk_get_physical_device_external_buffer_properties(phys_dev, phys_dev->instance->funcs.p_vkGetPhysicalDeviceExternalBufferProperties, buffer_info, properties); } void WINAPI wine_vkGetPhysicalDeviceExternalBufferPropertiesKHR(VkPhysicalDevice phys_dev, const VkPhysicalDeviceExternalBufferInfo *buffer_info, VkExternalBufferProperties *properties) { TRACE("%p, %p, %p\n", phys_dev, buffer_info, properties); - memset(&properties->externalMemoryProperties, 0, sizeof(properties->externalMemoryProperties)); + + wine_vk_get_physical_device_external_buffer_properties(phys_dev, phys_dev->instance->funcs.p_vkGetPhysicalDeviceExternalBufferPropertiesKHR, buffer_info, properties); } VkResult WINAPI wine_vkGetPhysicalDeviceImageFormatProperties2(VkPhysicalDevice phys_dev, @@ -1720,3 +1812,256 @@ VkResult WINAPI wine_vkDebugMarkerSetObjectNameEXT(VkDevice device, const VkDebu return thunk_vkDebugMarkerSetObjectNameEXT(device, &wine_name_info); } + +static HANDLE create_gpu_resource(int fd, LPCWSTR name) +{ + HANDLE ret = INVALID_HANDLE_VALUE; + + if (name) + FIXME("Naming gpu resources not supported.\n"); + + wine_server_fd_to_handle(fd, GENERIC_ALL, 0, &ret); + + return ret; +} + +VkResult WINAPI wine_vkAllocateMemory(VkDevice device, const VkMemoryAllocateInfo *allocate_info, + const VkAllocationCallbacks *allocator, VkDeviceMemory *memory) +{ + const VkImportMemoryWin32HandleInfoKHR *handle_import_info; + const VkExportMemoryWin32HandleInfoKHR *handle_export_info; + VkMemoryAllocateInfo allocate_info_dup = *allocate_info; + VkExportMemoryAllocateInfo *export_info; + VkImportMemoryFdInfoKHR fd_import_info; + struct wine_dev_mem *object; + VkResult res; + int fd; + +#if defined(USE_STRUCT_CONVERSION) + VkMemoryAllocateInfo_host allocate_info_host; + VkMemoryGetFdInfoKHR_host get_fd_info; +#else + VkMemoryAllocateInfo allocate_info_host; + VkMemoryGetFdInfoKHR get_fd_info; +#endif + + TRACE("%p %p %p %p\n", device, allocate_info, allocator, memory); + + if (allocator) + FIXME("Support for allocation callbacks not implemented yet\n"); + + if ((res = convert_VkMemoryAllocateInfo_struct_chain(allocate_info->pNext, &allocate_info_dup)) < 0) + { + WARN("Failed to convert VkMemoryAllocateInfo pNext chain, res=%d.\n", res); + return res; + } + + if (!(object = calloc(1, sizeof(*object)))) + { + free_VkMemoryAllocateInfo_struct_chain(&allocate_info_dup); + return VK_ERROR_OUT_OF_HOST_MEMORY; + } + + object->dev_mem = VK_NULL_HANDLE; + object->handle = INVALID_HANDLE_VALUE; + fd_import_info.fd = -1; + fd_import_info.pNext = NULL; + + /* find and process handle import/export info and grab it */ + handle_import_info = wine_vk_find_struct(allocate_info, IMPORT_MEMORY_WIN32_HANDLE_INFO_KHR); + handle_export_info = wine_vk_find_struct(allocate_info, EXPORT_MEMORY_WIN32_HANDLE_INFO_KHR); + if (handle_export_info && handle_export_info->pAttributes && handle_export_info->pAttributes->lpSecurityDescriptor) + FIXME("Support for custom security descriptor not implemented.\n"); + + if ((export_info = wine_vk_find_struct(&allocate_info_dup, EXPORT_MEMORY_ALLOCATE_INFO))) + { + object->handle_types = export_info->handleTypes; + if (export_info->handleTypes & VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_BIT) + export_info->handleTypes |= VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT; + wine_vk_normalize_handle_types_host(&export_info->handleTypes); + } + + /* Vulkan consumes imported FDs, but not imported HANDLEs */ + if (handle_import_info) + { + fd_import_info.sType = VK_STRUCTURE_TYPE_IMPORT_MEMORY_FD_INFO_KHR; + fd_import_info.pNext = allocate_info_dup.pNext; + fd_import_info.handleType = VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT; + + switch (handle_import_info->handleType) + { + case VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_BIT: + if (handle_import_info->handle) + NtDuplicateObject( NtCurrentProcess(), handle_import_info->handle, NtCurrentProcess(), &object->handle, 0, 0, DUPLICATE_SAME_ACCESS ); + else if (handle_import_info->name) + FIXME("Importing device memory by resource name not supported.\n"); + break; + default: + WARN("Invalid handle type %08x passed in.\n", handle_import_info->handleType); + res = VK_ERROR_INVALID_EXTERNAL_HANDLE; + goto done; + } + + if (object->handle != INVALID_HANDLE_VALUE) + wine_server_handle_to_fd(object->handle, FILE_READ_DATA, &fd_import_info.fd, NULL); + + if (fd_import_info.fd == -1) + { + TRACE("Couldn't access resource handle or name. type=%08x handle=%p name=%s\n", handle_import_info->handleType, handle_import_info->handle, + handle_import_info->name ? debugstr_w(handle_import_info->name) : ""); + res = VK_ERROR_INVALID_EXTERNAL_HANDLE; + goto done; + } + } + + allocate_info_host.sType = allocate_info_dup.sType; + allocate_info_host.pNext = fd_import_info.fd == -1 ? allocate_info_dup.pNext : &fd_import_info; + allocate_info_host.allocationSize = allocate_info_dup.allocationSize; + allocate_info_host.memoryTypeIndex = allocate_info_dup.memoryTypeIndex; + + if ((res = device->funcs.p_vkAllocateMemory(device->device, &allocate_info_host, NULL, &object->dev_mem)) == VK_SUCCESS) + { + if (object->handle == INVALID_HANDLE_VALUE && export_info && export_info->handleTypes & VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT) + { + get_fd_info.sType = VK_STRUCTURE_TYPE_MEMORY_GET_FD_INFO_KHR; + get_fd_info.pNext = NULL; + get_fd_info.memory = object->dev_mem; + get_fd_info.handleType = VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT; + + if (device->funcs.p_vkGetMemoryFdKHR(device->device, &get_fd_info, &fd) == VK_SUCCESS) + { + object->handle = create_gpu_resource(fd, handle_export_info ? handle_export_info->name : NULL); + object->access = handle_export_info ? handle_export_info->dwAccess : GENERIC_ALL; + if (handle_export_info && handle_export_info->pAttributes) + object->inherit = handle_export_info->pAttributes->bInheritHandle; + else + object->inherit = FALSE; + close(fd); + } + + if (object->handle == INVALID_HANDLE_VALUE) + { + res = VK_ERROR_OUT_OF_HOST_MEMORY; + goto done; + } + } + + WINE_VK_ADD_NON_DISPATCHABLE_MAPPING(device->phys_dev->instance, object, object->dev_mem); + *memory = wine_dev_mem_to_handle(object); + } + + done: + + if (res != VK_SUCCESS) + { + device->funcs.p_vkFreeMemory(device->device, object->dev_mem, NULL); + if (fd_import_info.fd != -1) + close(fd_import_info.fd); + if (object->handle != INVALID_HANDLE_VALUE) + NtClose(object->handle); + free(object); + } + + free_VkMemoryAllocateInfo_struct_chain(&allocate_info_dup); + + return res; +} + +VkResult WINAPI wine_vkGetMemoryWin32HandleKHR(VkDevice device, + const VkMemoryGetWin32HandleInfoKHR *handle_info, HANDLE *handle) +{ + struct wine_dev_mem *dev_mem = wine_dev_mem_from_handle(handle_info->memory); + const VkBaseInStructure *chain; + + TRACE("%p, %p %p\n", device, handle_info, handle); + + if (!(dev_mem->handle_types & handle_info->handleType)) + return VK_ERROR_UNKNOWN; + + if ((chain = handle_info->pNext)) + FIXME("Ignoring a linked structure of type %u.\n", chain->sType); + + switch(handle_info->handleType) + { + case VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_BIT: + return !NtDuplicateObject( NtCurrentProcess(), dev_mem->handle, NtCurrentProcess(), handle, dev_mem->access, dev_mem->inherit ? OBJ_INHERIT : 0, 0) ? + VK_SUCCESS : VK_ERROR_OUT_OF_HOST_MEMORY; + default: + FIXME("Unable to get handle of type %x, did the application ignore the capabilities?\n", handle_info->handleType); + return VK_ERROR_UNKNOWN; + } +} + +void WINAPI wine_vkFreeMemory(VkDevice device, VkDeviceMemory handle, const VkAllocationCallbacks *allocator) +{ + struct wine_dev_mem *dev_mem = wine_dev_mem_from_handle(handle); + + TRACE("%p 0x%s, %p\n", device, wine_dbgstr_longlong(handle), allocator); + + if (allocator) + FIXME("Support for allocation callbacks not implemented yet\n"); + + if (!handle) + return; + + WINE_VK_REMOVE_HANDLE_MAPPING(device->phys_dev->instance, dev_mem); + device->funcs.p_vkFreeMemory(device->device, dev_mem->dev_mem, NULL); + if (dev_mem->handle != INVALID_HANDLE_VALUE) + NtClose(dev_mem->handle); + free(dev_mem); +} + +VkResult WINAPI wine_vkGetMemoryWin32HandlePropertiesKHR(VkDevice device, + VkExternalMemoryHandleTypeFlagBits type, HANDLE handle, VkMemoryWin32HandlePropertiesKHR *properties) +{ + TRACE("%p %u %p %p\n", device, type, handle, properties); + + /* VUID-vkGetMemoryWin32HandlePropertiesKHR-handleType-00666 + handleType must not be one of the handle types defined as opaque */ + return VK_ERROR_INVALID_EXTERNAL_HANDLE; +} + +VkResult WINAPI wine_vkCreateBuffer(VkDevice device, const VkBufferCreateInfo *create_info, + const VkAllocationCallbacks *allocator, VkBuffer *buffer) +{ + VkExternalMemoryBufferCreateInfo *external_memory_info; + VkResult res; + +#if defined(USE_STRUCT_CONVERSION) + VkBufferCreateInfo_host create_info_host; +#else + VkBufferCreateInfo create_info_host; +#endif + + TRACE("%p %p %p %p\n", device, create_info, allocator, buffer); + + if (allocator) + FIXME("Support for allocation callbacks not implemented yet\n"); + + if ((res = convert_VkBufferCreateInfo_struct_chain(create_info->pNext, (VkBufferCreateInfo *) &create_info_host))) + { + WARN("Failed to convert VkBufferCreateInfo pNext chain, res=%d.\n", res); + return res; + } + + if ((external_memory_info = wine_vk_find_struct((VkBufferCreateInfo *) &create_info_host, EXTERNAL_MEMORY_BUFFER_CREATE_INFO))) + { + if (external_memory_info->handleTypes & VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_BIT) + external_memory_info->handleTypes |= VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT; + wine_vk_normalize_handle_types_host(&external_memory_info->handleTypes); + } + + create_info_host.sType = create_info->sType; + create_info_host.flags = create_info->flags; + create_info_host.size = create_info->size; + create_info_host.usage = create_info->usage; + create_info_host.sharingMode = create_info->sharingMode; + create_info_host.queueFamilyIndexCount = create_info->queueFamilyIndexCount; + create_info_host.pQueueFamilyIndices = create_info->pQueueFamilyIndices; + + res = device->funcs.p_vkCreateBuffer(device->device, &create_info_host, NULL, buffer); + + free_VkBufferCreateInfo_struct_chain((VkBufferCreateInfo *) &create_info_host); + + return res; +} diff --git a/dlls/winevulkan/vulkan_private.h b/dlls/winevulkan/vulkan_private.h index 83dc90ca15e..4a20702d43b 100644 --- a/dlls/winevulkan/vulkan_private.h +++ b/dlls/winevulkan/vulkan_private.h @@ -204,6 +204,30 @@ static inline VkSurfaceKHR wine_surface_to_handle(struct wine_surface *surface) return (VkSurfaceKHR)(uintptr_t)surface; } +struct wine_dev_mem +{ + VkDeviceMemory dev_mem; + + VkExternalMemoryHandleTypeFlagBits handle_types; + + BOOL inherit; + DWORD access; + + HANDLE handle; + + struct wine_vk_mapping mapping; +}; + +static inline struct wine_dev_mem *wine_dev_mem_from_handle(VkDeviceMemory handle) +{ + return (struct wine_dev_mem *)(uintptr_t)handle; +} + +static inline VkDeviceMemory wine_dev_mem_to_handle(struct wine_dev_mem *dev_mem) +{ + return (VkDeviceMemory)(uintptr_t)dev_mem; +} + BOOL wine_vk_device_extension_supported(const char *name) DECLSPEC_HIDDEN; BOOL wine_vk_instance_extension_supported(const char *name) DECLSPEC_HIDDEN; -- 2.31.1
Signed-off-by: Derek Lesho <dlesho(a)codeweavers.com> --- v7: Fixed various oversights stemming from me not testing v6. --- dlls/winevulkan/make_vulkan | 3 ++ dlls/winevulkan/vulkan.c | 96 +++++++++++++++++++++++++++++-------- 2 files changed, 80 insertions(+), 19 deletions(-) diff --git a/dlls/winevulkan/make_vulkan b/dlls/winevulkan/make_vulkan index 618ce121862..5078c44deec 100755 --- a/dlls/winevulkan/make_vulkan +++ b/dlls/winevulkan/make_vulkan @@ -193,6 +193,7 @@ FUNCTION_OVERRIDES = { "vkAllocateMemory" : {"dispatch" : True, "driver" : False, "thunk" : ThunkType.NONE}, "vkCreateBuffer" : {"dispatch" : True, "driver" : False, "thunk" : ThunkType.NONE}, "vkCreateCommandPool" : {"dispatch": True, "driver" : False, "thunk" : ThunkType.NONE}, + "vkCreateImage" : {"dispatch" : True, "driver" : False, "thunk" : ThunkType.NONE}, "vkDestroyCommandPool" : {"dispatch": True, "driver" : False, "thunk" : ThunkType.NONE}, "vkDestroyDevice" : {"dispatch" : True, "driver" : False, "thunk" : ThunkType.NONE}, "vkFreeCommandBuffers" : {"dispatch" : True, "driver" : False, "thunk" : ThunkType.NONE}, @@ -275,7 +276,9 @@ STRUCT_CHAIN_CONVERSIONS = { # Structs which require pNext chain modification "VkBufferCreateInfo": [], + "VkImageCreateInfo": [], "VkMemoryAllocateInfo": ["VK_STRUCTURE_TYPE_EXPORT_MEMORY_WIN32_HANDLE_INFO_KHR", "VK_STRUCTURE_TYPE_IMPORT_MEMORY_WIN32_HANDLE_INFO_KHR"], + "VkPhysicalDeviceImageFormatInfo2": [], } diff --git a/dlls/winevulkan/vulkan.c b/dlls/winevulkan/vulkan.c index 327113289a7..8da4396b720 100644 --- a/dlls/winevulkan/vulkan.c +++ b/dlls/winevulkan/vulkan.c @@ -1293,46 +1293,72 @@ void WINAPI wine_vkGetPhysicalDeviceExternalBufferPropertiesKHR(VkPhysicalDevice wine_vk_get_physical_device_external_buffer_properties(phys_dev, phys_dev->instance->funcs.p_vkGetPhysicalDeviceExternalBufferPropertiesKHR, buffer_info, properties); } -VkResult WINAPI wine_vkGetPhysicalDeviceImageFormatProperties2(VkPhysicalDevice phys_dev, +static VkResult wine_vk_get_physical_device_image_format_properties_2(VkPhysicalDevice phys_dev, + VkResult (*p_vkGetPhysicalDeviceImageFormatProperties2)(VkPhysicalDevice, const VkPhysicalDeviceImageFormatInfo2 *, VkImageFormatProperties2 *), const VkPhysicalDeviceImageFormatInfo2 *format_info, VkImageFormatProperties2 *properties) { + VkPhysicalDeviceExternalImageFormatInfo *external_image_info_dup = NULL; + const VkPhysicalDeviceExternalImageFormatInfo *external_image_info; + VkPhysicalDeviceImageFormatInfo2 format_info_host = *format_info; VkExternalImageFormatProperties *external_image_properties; VkResult res; - TRACE("%p, %p, %p\n", phys_dev, format_info, properties); + if ((external_image_info = wine_vk_find_struct(format_info, PHYSICAL_DEVICE_EXTERNAL_IMAGE_FORMAT_INFO)) && external_image_info->handleType) + { + if ((res = convert_VkPhysicalDeviceImageFormatInfo2_struct_chain(format_info->pNext, &format_info_host)) < 0) + { + WARN("Failed to convert VkPhysicalDeviceImageFormatInfo2 pNext chain, res=%d.\n", res); + return res; + } + external_image_info_dup = wine_vk_find_struct(&format_info_host, PHYSICAL_DEVICE_EXTERNAL_IMAGE_FORMAT_INFO); + + wine_vk_normalize_handle_types_win(&external_image_info_dup->handleType); + + if (external_image_info_dup->handleType == VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_BIT) + external_image_info_dup->handleType = VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT; + + wine_vk_normalize_handle_types_host(&external_image_info_dup->handleType); + if (!external_image_info_dup->handleType) + { + WARN("Unsupported handle type %#x.\n", external_image_info->handleType); + return VK_ERROR_FORMAT_NOT_SUPPORTED; + } + } + + res = p_vkGetPhysicalDeviceImageFormatProperties2(phys_dev, &format_info_host, properties); - res = thunk_vkGetPhysicalDeviceImageFormatProperties2(phys_dev, format_info, properties); + if (external_image_info_dup) + free_VkPhysicalDeviceImageFormatInfo2_struct_chain(&format_info_host); if ((external_image_properties = wine_vk_find_struct(properties, EXTERNAL_IMAGE_FORMAT_PROPERTIES))) { VkExternalMemoryProperties *p = &external_image_properties->externalMemoryProperties; - p->externalMemoryFeatures = 0; - p->exportFromImportedHandleTypes = 0; - p->compatibleHandleTypes = 0; + if (p->exportFromImportedHandleTypes & VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT) + p->exportFromImportedHandleTypes |= VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_BIT; + wine_vk_normalize_handle_types_win(&p->exportFromImportedHandleTypes); + + if (p->compatibleHandleTypes & VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT) + p->compatibleHandleTypes |= VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_BIT; + wine_vk_normalize_handle_types_win(&p->compatibleHandleTypes); } return res; } -VkResult WINAPI wine_vkGetPhysicalDeviceImageFormatProperties2KHR(VkPhysicalDevice phys_dev, +VkResult WINAPI wine_vkGetPhysicalDeviceImageFormatProperties2(VkPhysicalDevice phys_dev, const VkPhysicalDeviceImageFormatInfo2 *format_info, VkImageFormatProperties2 *properties) { - VkExternalImageFormatProperties *external_image_properties; - VkResult res; - TRACE("%p, %p, %p\n", phys_dev, format_info, properties); - res = thunk_vkGetPhysicalDeviceImageFormatProperties2KHR(phys_dev, format_info, properties); + return wine_vk_get_physical_device_image_format_properties_2(phys_dev, thunk_vkGetPhysicalDeviceImageFormatProperties2, format_info, properties); +} - if ((external_image_properties = wine_vk_find_struct(properties, EXTERNAL_IMAGE_FORMAT_PROPERTIES))) - { - VkExternalMemoryProperties *p = &external_image_properties->externalMemoryProperties; - p->externalMemoryFeatures = 0; - p->exportFromImportedHandleTypes = 0; - p->compatibleHandleTypes = 0; - } +VkResult WINAPI wine_vkGetPhysicalDeviceImageFormatProperties2KHR(VkPhysicalDevice phys_dev, + const VkPhysicalDeviceImageFormatInfo2 *format_info, VkImageFormatProperties2 *properties) +{ + TRACE("%p, %p, %p\n", phys_dev, format_info, properties); - return res; + return wine_vk_get_physical_device_image_format_properties_2(phys_dev, thunk_vkGetPhysicalDeviceImageFormatProperties2KHR, format_info, properties); } /* From ntdll/unix/sync.c */ @@ -2065,3 +2091,35 @@ VkResult WINAPI wine_vkCreateBuffer(VkDevice device, const VkBufferCreateInfo *c return res; } + +VkResult WINAPI wine_vkCreateImage(VkDevice device, const VkImageCreateInfo *create_info, + const VkAllocationCallbacks *allocator, VkBuffer *image) +{ + VkExternalMemoryImageCreateInfo *external_memory_info; + VkImageCreateInfo create_info_host = *create_info; + VkResult res; + + TRACE("%p %p %p %p\n", device, create_info, allocator, image); + + if (allocator) + FIXME("Support for allocation callbacks not implemented yet\n"); + + if ((res = convert_VkImageCreateInfo_struct_chain(create_info->pNext, &create_info_host))) + { + WARN("Failed to convert VkImageCreateInfo pNext chain, res=%d.\n", res); + return res; + } + + if ((external_memory_info = wine_vk_find_struct(&create_info_host, EXTERNAL_MEMORY_IMAGE_CREATE_INFO))) + { + if (external_memory_info->handleTypes & VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_BIT_KHR) + external_memory_info->handleTypes |= VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT_KHR; + wine_vk_normalize_handle_types_host(&external_memory_info->handleTypes); + } + + res = device->funcs.p_vkCreateImage(device->device, &create_info_host, NULL, image); + + free_VkImageCreateInfo_struct_chain(&create_info_host); + + return res; +} -- 2.31.1
Signed-off-by: Georg Lehmann <dadschoorse(a)gmail.com>
How do you plan to implement the following features: * named NT paths * security descriptors * KMT handles * CL_KHR_d3d11_sharing * CL_KHR_gl_sharing * Shared resources in d3d9-11, when using the OpenGL backend * Shared resources in d3d9-11, when using the Vulkan backend * Shared resources in d3d12 * Shared resources between d3d9-12 devices, when using wined3d or libvkd3d on Windows * Shared resources between d3d9-12 devices and OpenGL or Vulkan, when using wined3d or libvkd3d on Windows Please give detailed walkthroughs, including code if possible, or detailed explanations of why any of these can't be done. I note your tests also don't seem very interesting; they only share objects within the same device. Sharing objects across multiple devices, and across multiple processes, strikes me as more interesting.
On 5/25/21 11:52 AM, Zebediah Figura (she/her) wrote:
How do you plan to implement the following features: For what it's worth, all of the ideas I express in this email don't apply this patch, but rather planned follow-up patches. As it relates to Vulkan, I don't think there's any approach we take this path makes more of a headache. For example, if we do decide to instead create custom object types for resources, all we have to do is extend the create_gpu_resource function in that direction.
* named NT paths
* security descriptors
* KMT handles
I intend to take the approach of wrapping the FD object behind a device object, like you suggested in your previous mail. Device objects can be named, and while support for access rights on device file objects doesn't seem to be implemented right now, it shouldn't be too hard to add this functionality. https://source.winehq.org/git/wine.git/blob/HEAD:/dlls/ntoskrnl.exe/ntoskrnl... The device objects will be created via IOCTLs to a master "Utility" device object, which will handle KMT lookup and user data storage. For unnamed device objects I'm thinking about using FILE_AUTOGENERATED_DEVICE_NAME, retrieving the name of the device object IoCreateDevice returns, then proceeding as normal and opening/returning the handle.
* CL_KHR_d3d11_sharing
OpenCL lacks any equivalent to GL's EXT_external_objects, which is "modern" approach to shared resources, meaning it is unable to directly share resources with Vulkan. If needed in the future, I imagine it wouldn't be too hard to convince the OpenCL spec people to draft an equivalent extension. To use the extension as it exists in OpenGL right now, we can just use the publicly exposed D3D API (GetSharedHandle/CreateSharedHandle for D3D11) to get a HANDLE to the device object, then run an IOCTL fetching the FD we feed into the extension. Theoretically we could even use EXT_external_objects as an implementation detail for openCL, sharing the resource through two steps (first through EXT_external_objects then through CL_KHR_gl_sharing), but I imagine there would be some hitch we run into there, plus nothing uses OpenCL so why bother.
* CL_KHR_gl_sharing
This doesn't involve what I am working on, both openGL and openCL are both host libraries, and should be able to share without any help from wine.
* Shared resources in d3d9-11, when using the OpenGL backend
As mentioned, the EXT_external_objects extension exists, ( https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_external_objects.... ), which accepts and produces file descriptors compatible with the ones Vulkan produces and accepts. The interactions here seem to be well defined.
* Shared resources in d3d9-11, when using the Vulkan backend
The only additional challenge that faces both D3D implementations of any backend is that along with referencing the raw GPU payload, certain metadata is also stored in the resource objects. However, this metadata is not stored by the host implementation (either GL or Vulkan), meaning it has to be tracked by us somehow. For this, inside the device objects there will be user data that translation layers can access through IOCTLs. As to not artificially hamstring certain implementations, I plan to leave the structure of this user data translation-layer defined. To this end, I think it would be useful to store a GUID key needed to set/get the user data, so that translation layers doesn't try to parse user data with an unknown format. This still leaves open the possibility of converging onto a single key if possible.
* Shared resources in d3d12
Nothing special here, as the D3D12 model for sharing seems to be quite similar to the Vulkan one in that you share heaps, not resources. It looks like it's a 1:1 mapping from a D3D12 heap to a Vulkan Device Memory object.
* Shared resources between d3d9-12 devices, when using wined3d or libvkd3d on Windows
Putting aside how rare and questionable of a use-case this must be, I don't think this concerns any of my patches. My future patches would provide a way for translation layers on wine to store metadata alongside the host handlers, it doesn't have any correspondence to Windows. If you really wanted to (why?), you could probably create your own backing storage in a shared memory object and accept the caveats that come along with that.
* Shared resources between d3d9-12 devices and OpenGL or Vulkan, when using wined3d or libvkd3d on Windows
Again, a questionable and rare use-case not related to the patches I intend to send, but I'll try to brainstorm something. If you don't control the code trying to import your D3D resources into Vulkan or GL, you'll have to either 1) Figure out how to register the resources in your translation layer with Windows in such a way that it thinks the resources belong to the APIs you are implementing (as the Windows driver for Vulkan or GL will have to recognize it as such), or instead 2) Try to create an implicit Vulkan layer (for GL it would be much harder) that intercepts calls trying to import D3D objects, and instead imports the NT/KMT handles your translation layer can retrieve from Vulkan.
Please give detailed walkthroughs, including code if possible, or detailed explanations of why any of these can't be done.
I note your tests also don't seem very interesting; they only share objects within the same device. Sharing objects across multiple devices, and across multiple processes, strikes me as more interesting.
In my opinion, given that the semantics for VK_KHR_external_memory_fd and VK_KHR_external_memory_win32 are so similar, I wonder how relevant such tests would be, it seems like the kind of thing the Vulkan CTS should add for testing drivers. I think the tests should be more for testing the properties of the HANDLEs we get, as this is what we are implementing ourselves. Maybe I should add more tests looking at the locations of the named objects in the NT directory, or tests relating to types of the objects and their access permissions.
On 5/25/21 1:11 PM, Derek Lesho wrote:
On 5/25/21 11:52 AM, Zebediah Figura (she/her) wrote:
How do you plan to implement the following features: For what it's worth, all of the ideas I express in this email don't apply this patch, but rather planned follow-up patches. As it relates to Vulkan, I don't think there's any approach we take this path makes more of a headache. For example, if we do decide to instead create custom object types for resources, all we have to do is extend the create_gpu_resource function in that direction.
* named NT paths
* security descriptors
* KMT handles
I intend to take the approach of wrapping the FD object behind a device object, like you suggested in your previous mail. Device objects can be named, and while support for access rights on device file objects doesn't seem to be implemented right now, it shouldn't be too hard to add this functionality.
https://source.winehq.org/git/wine.git/blob/HEAD:/dlls/ntoskrnl.exe/ntoskrnl...
The device objects will be created via IOCTLs to a master "Utility" device object, which will handle KMT lookup and user data storage. For unnamed device objects I'm thinking about using FILE_AUTOGENERATED_DEVICE_NAME, retrieving the name of the device object IoCreateDevice returns, then proceeding as normal and opening/returning the handle.
* CL_KHR_d3d11_sharing
OpenCL lacks any equivalent to GL's EXT_external_objects, which is "modern" approach to shared resources, meaning it is unable to directly share resources with Vulkan. If needed in the future, I imagine it wouldn't be too hard to convince the OpenCL spec people to draft an equivalent extension.
To use the extension as it exists in OpenGL right now, we can just use the publicly exposed D3D API (GetSharedHandle/CreateSharedHandle for D3D11) to get a HANDLE to the device object, then run an IOCTL fetching the FD we feed into the extension. Theoretically we could even use EXT_external_objects as an implementation detail for openCL, sharing the resource through two steps (first through EXT_external_objects then through CL_KHR_gl_sharing), but I imagine there would be some hitch we run into there, plus nothing uses OpenCL so why bother.
* CL_KHR_gl_sharing
This doesn't involve what I am working on, both openGL and openCL are both host libraries, and should be able to share without any help from wine.
* Shared resources in d3d9-11, when using the OpenGL backend
As mentioned, the EXT_external_objects extension exists, ( https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_external_objects.... ), which accepts and produces file descriptors compatible with the ones Vulkan produces and accepts. The interactions here seem to be well defined.
According to my reading, neither GL_EXT_external_objects nor GL_EXT_external_objects_fd provide for export of an object from an OpenGL context; they only allow importing objects created by Vulkan.
* Shared resources in d3d9-11, when using the Vulkan backend
The only additional challenge that faces both D3D implementations of any backend is that along with referencing the raw GPU payload, certain metadata is also stored in the resource objects. However, this metadata is not stored by the host implementation (either GL or Vulkan), meaning it has to be tracked by us somehow. For this, inside the device objects there will be user data that translation layers can access through IOCTLs.
As to not artificially hamstring certain implementations, I plan to leave the structure of this user data translation-layer defined. To this end, I think it would be useful to store a GUID key needed to set/get the user data, so that translation layers doesn't try to parse user data with an unknown format. This still leaves open the possibility of converging onto a single key if possible.
* Shared resources in d3d12
Nothing special here, as the D3D12 model for sharing seems to be quite similar to the Vulkan one in that you share heaps, not resources. It looks like it's a 1:1 mapping from a D3D12 heap to a Vulkan Device Memory object.
* Shared resources between d3d9-12 devices, when using wined3d or libvkd3d on Windows
Putting aside how rare and questionable of a use-case this must be, I don't think this concerns any of my patches. My future patches would provide a way for translation layers on wine to store metadata alongside the host handlers, it doesn't have any correspondence to Windows. If you really wanted to (why?), you could probably create your own backing storage in a shared memory object and accept the caveats that come along with that.
I suspect those of us who have worked with Direct3D for multiple decades would take issue with "rare and questionable", but regardless, part of the point here is to ask: *is* it possible to use a native set of APIs, like perhaps the D3DKMT*() functions from gdi32, to share resources? I.e. should the implementation live in gdi32 instead of winevulkan/opengl32/wined3d? Just from a quick scan I see several which look like the ones we want, and they're even documented.
* Shared resources between d3d9-12 devices and OpenGL or Vulkan, when using wined3d or libvkd3d on Windows
Again, a questionable and rare use-case not related to the patches I intend to send, but I'll try to brainstorm something.
If you don't control the code trying to import your D3D resources into Vulkan or GL, you'll have to either
1) Figure out how to register the resources in your translation layer with Windows in such a way that it thinks the resources belong to the APIs you are implementing (as the Windows driver for Vulkan or GL will have to recognize it as such), or instead
2) Try to create an implicit Vulkan layer (for GL it would be much harder) that intercepts calls trying to import D3D objects, and instead imports the NT/KMT handles your translation layer can retrieve from Vulkan.
Please give detailed walkthroughs, including code if possible, or detailed explanations of why any of these can't be done.
I note your tests also don't seem very interesting; they only share objects within the same device. Sharing objects across multiple devices, and across multiple processes, strikes me as more interesting.
In my opinion, given that the semantics for VK_KHR_external_memory_fd and VK_KHR_external_memory_win32 are so similar, I wonder how relevant such tests would be, it seems like the kind of thing the Vulkan CTS should add for testing drivers.
I think the tests should be more for testing the properties of the HANDLEs we get, as this is what we are implementing ourselves. Maybe I should add more tests looking at the locations of the named objects in the NT directory, or tests relating to types of the objects and their access permissions.
The point is more of a smoke test, because it's easy to get it wrong, and not too hard to verify that we got it right. It'd also be nice to demonstrate what the behaviour of KMT handles is across processes.
On 5/26/21 3:07 AM, Zebediah Figura (she/her) wrote:
On 5/25/21 1:11 PM, Derek Lesho wrote:
On 5/25/21 11:52 AM, Zebediah Figura (she/her) wrote:
How do you plan to implement the following features: For what it's worth, all of the ideas I express in this email don't apply this patch, but rather planned follow-up patches. As it relates to Vulkan, I don't think there's any approach we take this path makes more of a headache. For example, if we do decide to instead create custom object types for resources, all we have to do is extend the create_gpu_resource function in that direction.
* named NT paths
* security descriptors
* KMT handles
I intend to take the approach of wrapping the FD object behind a device object, like you suggested in your previous mail. Device objects can be named, and while support for access rights on device file objects doesn't seem to be implemented right now, it shouldn't be too hard to add this functionality.
https://source.winehq.org/git/wine.git/blob/HEAD:/dlls/ntoskrnl.exe/ntoskrnl...
The device objects will be created via IOCTLs to a master "Utility" device object, which will handle KMT lookup and user data storage. For unnamed device objects I'm thinking about using FILE_AUTOGENERATED_DEVICE_NAME, retrieving the name of the device object IoCreateDevice returns, then proceeding as normal and opening/returning the handle.
* CL_KHR_d3d11_sharing
OpenCL lacks any equivalent to GL's EXT_external_objects, which is "modern" approach to shared resources, meaning it is unable to directly share resources with Vulkan. If needed in the future, I imagine it wouldn't be too hard to convince the OpenCL spec people to draft an equivalent extension.
To use the extension as it exists in OpenGL right now, we can just use the publicly exposed D3D API (GetSharedHandle/CreateSharedHandle for D3D11) to get a HANDLE to the device object, then run an IOCTL fetching the FD we feed into the extension. Theoretically we could even use EXT_external_objects as an implementation detail for openCL, sharing the resource through two steps (first through EXT_external_objects then through CL_KHR_gl_sharing), but I imagine there would be some hitch we run into there, plus nothing uses OpenCL so why bother.
* CL_KHR_gl_sharing
This doesn't involve what I am working on, both openGL and openCL are both host libraries, and should be able to share without any help from wine.
* Shared resources in d3d9-11, when using the OpenGL backend
As mentioned, the EXT_external_objects extension exists, ( https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_external_objects....
), which accepts and produces file descriptors compatible with the ones Vulkan produces and accepts. The interactions here seem to be well defined.
According to my reading, neither GL_EXT_external_objects nor GL_EXT_external_objects_fd provide for export of an object from an OpenGL context; they only allow importing objects created by Vulkan.
* Shared resources in d3d9-11, when using the Vulkan backend
The only additional challenge that faces both D3D implementations of any backend is that along with referencing the raw GPU payload, certain metadata is also stored in the resource objects. However, this metadata is not stored by the host implementation (either GL or Vulkan), meaning it has to be tracked by us somehow. For this, inside the device objects there will be user data that translation layers can access through IOCTLs.
As to not artificially hamstring certain implementations, I plan to leave the structure of this user data translation-layer defined. To this end, I think it would be useful to store a GUID key needed to set/get the user data, so that translation layers doesn't try to parse user data with an unknown format. This still leaves open the possibility of converging onto a single key if possible.
* Shared resources in d3d12
Nothing special here, as the D3D12 model for sharing seems to be quite similar to the Vulkan one in that you share heaps, not resources. It looks like it's a 1:1 mapping from a D3D12 heap to a Vulkan Device Memory object.
* Shared resources between d3d9-12 devices, when using wined3d or libvkd3d on Windows
Putting aside how rare and questionable of a use-case this must be, I don't think this concerns any of my patches. My future patches would provide a way for translation layers on wine to store metadata alongside the host handlers, it doesn't have any correspondence to Windows. If you really wanted to (why?), you could probably create your own backing storage in a shared memory object and accept the caveats that come along with that.
I suspect those of us who have worked with Direct3D for multiple decades would take issue with "rare and questionable", but regardless, part of the point here is to ask: *is* it possible to use a native set of APIs, like perhaps the D3DKMT*() functions from gdi32, to share resources? I.e. should the implementation live in gdi32 instead of winevulkan/opengl32/wined3d? Just from a quick scan I see several which look like the ones we want, and they're even documented.
It would be nice to use those, but we have no way of getting the associated D3DKMT handles for hDevice or any other parts of it. https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/d3dkmthk/nf-d3... I think that path is a bit of a dead end... ___ On our end in D3D land, we just need some way of getting metadata about an image/buffer in/out to make the Vulkan image/buffer with, etc. Down the line, this could be made to work on Windows if there was an extension to retrieve the information we need to make an image/buffer with the right info. Having something implemented to show that we can do this, and exactly what we would need would be a prerequisite for me spending any time pushing for that. ___ What's in this patchset is simply about the Vulkan/GL side of things (which is a prerequisite), and is memory only, so this is all a non-issue. We should get Vulkan <-> Vulkan working, then go from there, find out exactly what we need for D3D <-> D3D interop, get that working with an implementation, then maybe finish it off in a nicer way. - Joshie 🐸✨
* Shared resources between d3d9-12 devices and OpenGL or Vulkan, when using wined3d or libvkd3d on Windows
Again, a questionable and rare use-case not related to the patches I intend to send, but I'll try to brainstorm something.
If you don't control the code trying to import your D3D resources into Vulkan or GL, you'll have to either
1) Figure out how to register the resources in your translation layer with Windows in such a way that it thinks the resources belong to the APIs you are implementing (as the Windows driver for Vulkan or GL will have to recognize it as such), or instead
2) Try to create an implicit Vulkan layer (for GL it would be much harder) that intercepts calls trying to import D3D objects, and instead imports the NT/KMT handles your translation layer can retrieve from Vulkan.
Please give detailed walkthroughs, including code if possible, or detailed explanations of why any of these can't be done.
I note your tests also don't seem very interesting; they only share objects within the same device. Sharing objects across multiple devices, and across multiple processes, strikes me as more interesting.
In my opinion, given that the semantics for VK_KHR_external_memory_fd and VK_KHR_external_memory_win32 are so similar, I wonder how relevant such tests would be, it seems like the kind of thing the Vulkan CTS should add for testing drivers.
I think the tests should be more for testing the properties of the HANDLEs we get, as this is what we are implementing ourselves. Maybe I should add more tests looking at the locations of the named objects in the NT directory, or tests relating to types of the objects and their access permissions.
The point is more of a smoke test, because it's easy to get it wrong, and not too hard to verify that we got it right.
It'd also be nice to demonstrate what the behaviour of KMT handles is across processes.
On 5/25/21 10:07 PM, Zebediah Figura (she/her) wrote:
* Shared resources in d3d9-11, when using the OpenGL backend
As mentioned, the EXT_external_objects extension exists, ( https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_external_objects....
), which accepts and produces file descriptors compatible with the ones Vulkan produces and accepts. The interactions here seem to be well defined.
According to my reading, neither GL_EXT_external_objects nor GL_EXT_external_objects_fd provide for export of an object from an OpenGL context; they only allow importing objects created by Vulkan.
Yeah, from what I can see, openGL has no standard way to share memory across processes without the use of this extension and Vulkan. I suspect this would be difficult due to all the user mode driver code protecting against invalid use of resources. I think the most reasonable path forward is to create a Vulkan dummy object in wined3d, then import it into GL. Of course, this would make shared resources unsupported for old GPUs and systems that don't support Vulkan, but the API is half a decade old at this point, and only GPUs from almost a decade ago don't support it. Alternatively we could get try to use platform-specific buffer sharing APIs like EGLStreams or GBM, or just support in-process shared resources through the eglCreateContext API, which allows the creation of "shared contexts", in which the GPU resources are shared.
* Shared resources between d3d9-12 devices, when using wined3d or libvkd3d on Windows
Putting aside how rare and questionable of a use-case this must be, I don't think this concerns any of my patches. My future patches would provide a way for translation layers on wine to store metadata alongside the host handlers, it doesn't have any correspondence to Windows. If you really wanted to (why?), you could probably create your own backing storage in a shared memory object and accept the caveats that come along with that.
I suspect those of us who have worked with Direct3D for multiple decades would take issue with "rare and questionable", but regardless, part of the point here is to ask: *is* it possible to use a native set of APIs, like perhaps the D3DKMT*() functions from gdi32, to share resources? I.e. should the implementation live in gdi32 instead of winevulkan/opengl32/wined3d? Just from a quick scan I see several which look like the ones we want, and they're even documented.
Could you link these APIs so I can look further into them? I conferred with Josh and he didn't find anything. Also, if there are APIs which allow registering resources retrieved from Vulkan with certain metadata, winevulkan would still have roughly the same role. The only difference would be in the translation layers, where instead of using IOCTLs on the HANDLEs to shared resources they have to get/set metadata, they would use some D3DKMT API you've found.
I note your tests also don't seem very interesting; they only share objects within the same device. Sharing objects across multiple devices, and across multiple processes, strikes me as more interesting.
In my opinion, given that the semantics for VK_KHR_external_memory_fd and VK_KHR_external_memory_win32 are so similar, I wonder how relevant such tests would be, it seems like the kind of thing the Vulkan CTS should add for testing drivers.
I think the tests should be more for testing the properties of the HANDLEs we get, as this is what we are implementing ourselves. Maybe I should add more tests looking at the locations of the named objects in the NT directory, or tests relating to types of the objects and their access permissions.
The point is more of a smoke test, because it's easy to get it wrong, and not too hard to verify that we got it right.
It'd also be nice to demonstrate what the behaviour of KMT handles is across processes.
An in-process intra-device test tests the same amount of winevulkan behavior as a cross-process inter-device test. All the implementation details of cross-process and cross-device sharing are handled on the host and through wineserver's well established HANDLE<->FD mapping.
On 5/26/21 9:21 AM, Derek Lesho wrote:
On 5/25/21 10:07 PM, Zebediah Figura (she/her) wrote:
* Shared resources in d3d9-11, when using the OpenGL backend
As mentioned, the EXT_external_objects extension exists, ( https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_external_objects....
), which accepts and produces file descriptors compatible with the ones Vulkan produces and accepts. The interactions here seem to be well defined.
According to my reading, neither GL_EXT_external_objects nor GL_EXT_external_objects_fd provide for export of an object from an OpenGL context; they only allow importing objects created by Vulkan.
Yeah, from what I can see, openGL has no standard way to share memory across processes without the use of this extension and Vulkan. I suspect this would be difficult due to all the user mode driver code protecting against invalid use of resources. I think the most reasonable path forward is to create a Vulkan dummy object in wined3d, then import it into GL. Of course, this would make shared resources unsupported for old GPUs and systems that don't support Vulkan, but the API is half a decade old at this point, and only GPUs from almost a decade ago don't support it.
There is no free software NVidia Vulkan driver, which is a rather glaring hole. There also exist cards released as recently as 2014 that don't support Vulkan. And in general, although it's sometimes convenient for the implementer to require the latest hardware, it's a rather mean thing to do to users. Keep in mind that we need Direct3D shared resources for bug 44985, which affects a very long list of applications. Now, with that in mind, two options I immediately see are: * Create all contexts as shared. It's not clear to me whether this has negative consequences, however. It's also not clear to me whether this can be done across processes. * Try to introduce an OpenGL extension that allows exporting file descriptors.
Alternatively we could get try to use platform-specific buffer sharing APIs like EGLStreams or GBM, or just support in-process shared resources through the eglCreateContext API, which allows the creation of "shared contexts", in which the GPU resources are shared.
* Shared resources between d3d9-12 devices, when using wined3d or libvkd3d on Windows
Putting aside how rare and questionable of a use-case this must be, I don't think this concerns any of my patches. My future patches would provide a way for translation layers on wine to store metadata alongside the host handlers, it doesn't have any correspondence to Windows. If you really wanted to (why?), you could probably create your own backing storage in a shared memory object and accept the caveats that come along with that.
I suspect those of us who have worked with Direct3D for multiple decades would take issue with "rare and questionable", but regardless, part of the point here is to ask: *is* it possible to use a native set of APIs, like perhaps the D3DKMT*() functions from gdi32, to share resources? I.e. should the implementation live in gdi32 instead of winevulkan/opengl32/wined3d? Just from a quick scan I see several which look like the ones we want, and they're even documented.
Could you link these APIs so I can look further into them? I conferred with Josh and he didn't find anything.
Sure, here are some APIs that look promising, and are documented: * D3DKMTCreateAllocation() * D3DKMTOpenResource() * D3DKMTOpenResourceFromNtHandle() * D3DKMTQueryResourceInfo() * D3DKMTQueryResourceInfoFromNtHandle()
Also, if there are APIs which allow registering resources retrieved from Vulkan with certain metadata, winevulkan would still have roughly the same role. The only difference would be in the translation layers, where instead of using IOCTLs on the HANDLEs to shared resources they have to get/set metadata, they would use some D3DKMT API you've found.
Well, broadly, yes, but it changes the way that this patch series should be structured and sent.
I note your tests also don't seem very interesting; they only share objects within the same device. Sharing objects across multiple devices, and across multiple processes, strikes me as more interesting.
In my opinion, given that the semantics for VK_KHR_external_memory_fd and VK_KHR_external_memory_win32 are so similar, I wonder how relevant such tests would be, it seems like the kind of thing the Vulkan CTS should add for testing drivers.
I think the tests should be more for testing the properties of the HANDLEs we get, as this is what we are implementing ourselves. Maybe I should add more tests looking at the locations of the named objects in the NT directory, or tests relating to types of the objects and their access permissions.
The point is more of a smoke test, because it's easy to get it wrong, and not too hard to verify that we got it right.
It'd also be nice to demonstrate what the behaviour of KMT handles is across processes.
An in-process intra-device test tests the same amount of winevulkan behavior as a cross-process inter-device test. All the implementation details of cross-process and cross-device sharing are handled on the host and through wineserver's well established HANDLE<->FD mapping.
Is it really that hard just to add a test?
On 5/31/21 10:43 AM, Zebediah Figura (she/her) wrote:
On 5/26/21 9:21 AM, Derek Lesho wrote:
On 5/25/21 10:07 PM, Zebediah Figura (she/her) wrote:
* Shared resources in d3d9-11, when using the OpenGL backend
As mentioned, the EXT_external_objects extension exists, ( https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_external_objects....
), which accepts and produces file descriptors compatible with the ones Vulkan produces and accepts. The interactions here seem to be well defined.
According to my reading, neither GL_EXT_external_objects nor GL_EXT_external_objects_fd provide for export of an object from an OpenGL context; they only allow importing objects created by Vulkan.
Yeah, from what I can see, openGL has no standard way to share memory across processes without the use of this extension and Vulkan. I suspect this would be difficult due to all the user mode driver code protecting against invalid use of resources. I think the most reasonable path forward is to create a Vulkan dummy object in wined3d, then import it into GL. Of course, this would make shared resources unsupported for old GPUs and systems that don't support Vulkan, but the API is half a decade old at this point, and only GPUs from almost a decade ago don't support it.
There is no free software NVidia Vulkan driver, which is a rather glaring hole. There also exist cards released as recently as 2014 that don't support Vulkan. And in general, although it's sometimes convenient for the implementer to require the latest hardware, it's a rather mean thing to do to users.
Keep in mind that we need Direct3D shared resources for bug 44985, which affects a very long list of applications.
Now, with that in mind, two options I immediately see are:
* Create all contexts as shared. It's not clear to me whether this has negative consequences, however. It's also not clear to me whether this can be done across processes.
* Try to introduce an OpenGL extension that allows exporting file descriptors.
The second option definitely sounds better, as with the first you're still limited to in-process sharing, if my understanding is correct. Additionally, the case where you're using wined3d's d3d9 for example, create a shared resource, then try importing it into DXVK for d3d10/11, would only work with the second solution from what I can see. I imagine that we could cover the vast majority of users by implementing the "vulkan helper" path that I suggested before, and quite easily transition into using an extension if/when needed.
Alternatively we could get try to use platform-specific buffer sharing APIs like EGLStreams or GBM, or just support in-process shared resources through the eglCreateContext API, which allows the creation of "shared contexts", in which the GPU resources are shared.
* Shared resources between d3d9-12 devices, when using wined3d or libvkd3d on Windows
Putting aside how rare and questionable of a use-case this must be, I don't think this concerns any of my patches. My future patches would provide a way for translation layers on wine to store metadata alongside the host handlers, it doesn't have any correspondence to Windows. If you really wanted to (why?), you could probably create your own backing storage in a shared memory object and accept the caveats that come along with that.
I suspect those of us who have worked with Direct3D for multiple decades would take issue with "rare and questionable", but regardless, part of the point here is to ask: *is* it possible to use a native set of APIs, like perhaps the D3DKMT*() functions from gdi32, to share resources? I.e. should the implementation live in gdi32 instead of winevulkan/opengl32/wined3d? Just from a quick scan I see several which look like the ones we want, and they're even documented.
Could you link these APIs so I can look further into them? I conferred with Josh and he didn't find anything.
Sure, here are some APIs that look promising, and are documented:
* D3DKMTCreateAllocation() * D3DKMTOpenResource() * D3DKMTOpenResourceFromNtHandle() * D3DKMTQueryResourceInfo() * D3DKMTQueryResourceInfoFromNtHandle()
So I discussed this with Josh and Georg, and the problems with these APIs for our usecases are 1) In order to interface with any of these APIs, you need a KMT device handle. This roughly corresponds to a Vulkan device object or OpenGL context, but according to Josh they don't have to map 1:1. 2) There's no way to update the private runtime data once the resource is created. In the current and simpler flow, the host graphics API will create the object, and the translation layer will then attach the needed private data. For this to work on windows, the translation layers would have to agree on some way to get Vulkan to set the desired private data, and that's assuming that no Windows drivers already use this for their own purposes.
Also, if there are APIs which allow registering resources retrieved from Vulkan with certain metadata, winevulkan would still have roughly the same role. The only difference would be in the translation layers, where instead of using IOCTLs on the HANDLEs to shared resources they have to get/set metadata, they would use some D3DKMT API you've found.
Well, broadly, yes, but it changes the way that this patch series should be structured and sent.
This patch's main focus is just setting up the winevulkan infrastructure for shared resources. If we decide to still use D3DKMT for one reason or another, the only change to the current patchset would be to the tiny function create_gpu_resource to get the HANDLE through KMT APIs instead of wine_server_fd_to_handle.
I note your tests also don't seem very interesting; they only share objects within the same device. Sharing objects across multiple devices, and across multiple processes, strikes me as more interesting.
In my opinion, given that the semantics for VK_KHR_external_memory_fd and VK_KHR_external_memory_win32 are so similar, I wonder how relevant such tests would be, it seems like the kind of thing the Vulkan CTS should add for testing drivers.
I think the tests should be more for testing the properties of the HANDLEs we get, as this is what we are implementing ourselves. Maybe I should add more tests looking at the locations of the named objects in the NT directory, or tests relating to types of the objects and their access permissions.
The point is more of a smoke test, because it's easy to get it wrong, and not too hard to verify that we got it right.
It'd also be nice to demonstrate what the behaviour of KMT handles is across processes.
An in-process intra-device test tests the same amount of winevulkan behavior as a cross-process inter-device test. All the implementation details of cross-process and cross-device sharing are handled on the host and through wineserver's well established HANDLE<->FD mapping.
Is it really that hard just to add a test?
No, but I just think it would be a waste of time and lines of code, especially for testing cross-process when it makes no difference which processes the two devices are made on. Given that you said "a test", do you mean you think it would be fine if I were to just add a test testing shared resources across devices in the same process?
On 6/1/21 10:17 AM, Derek Lesho wrote:
On 5/31/21 10:43 AM, Zebediah Figura (she/her) wrote:
On 5/26/21 9:21 AM, Derek Lesho wrote:
On 5/25/21 10:07 PM, Zebediah Figura (she/her) wrote:
* Shared resources in d3d9-11, when using the OpenGL backend
As mentioned, the EXT_external_objects extension exists, ( https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_external_objects....
), which accepts and produces file descriptors compatible with the ones Vulkan produces and accepts. The interactions here seem to be well defined.
According to my reading, neither GL_EXT_external_objects nor GL_EXT_external_objects_fd provide for export of an object from an OpenGL context; they only allow importing objects created by Vulkan.
Yeah, from what I can see, openGL has no standard way to share memory across processes without the use of this extension and Vulkan. I suspect this would be difficult due to all the user mode driver code protecting against invalid use of resources. I think the most reasonable path forward is to create a Vulkan dummy object in wined3d, then import it into GL. Of course, this would make shared resources unsupported for old GPUs and systems that don't support Vulkan, but the API is half a decade old at this point, and only GPUs from almost a decade ago don't support it.
There is no free software NVidia Vulkan driver, which is a rather glaring hole. There also exist cards released as recently as 2014 that don't support Vulkan. And in general, although it's sometimes convenient for the implementer to require the latest hardware, it's a rather mean thing to do to users.
Keep in mind that we need Direct3D shared resources for bug 44985, which affects a very long list of applications.
Now, with that in mind, two options I immediately see are:
* Create all contexts as shared. It's not clear to me whether this has negative consequences, however. It's also not clear to me whether this can be done across processes.
* Try to introduce an OpenGL extension that allows exporting file descriptors.
The second option definitely sounds better, as with the first you're still limited to in-process sharing, if my understanding is correct. Additionally, the case where you're using wined3d's d3d9 for example, create a shared resource, then try importing it into DXVK for d3d10/11, would only work with the second solution from what I can see. I imagine that we could cover the vast majority of users by implementing the "vulkan helper" path that I suggested before, and quite easily transition into using an extension if/when needed.
Alternatively we could get try to use platform-specific buffer sharing APIs like EGLStreams or GBM, or just support in-process shared resources through the eglCreateContext API, which allows the creation of "shared contexts", in which the GPU resources are shared.
* Shared resources between d3d9-12 devices, when using wined3d or libvkd3d on Windows
Putting aside how rare and questionable of a use-case this must be, I don't think this concerns any of my patches. My future patches would provide a way for translation layers on wine to store metadata alongside the host handlers, it doesn't have any correspondence to Windows. If you really wanted to (why?), you could probably create your own backing storage in a shared memory object and accept the caveats that come along with that.
I suspect those of us who have worked with Direct3D for multiple decades would take issue with "rare and questionable", but regardless, part of the point here is to ask: *is* it possible to use a native set of APIs, like perhaps the D3DKMT*() functions from gdi32, to share resources? I.e. should the implementation live in gdi32 instead of winevulkan/opengl32/wined3d? Just from a quick scan I see several which look like the ones we want, and they're even documented.
Could you link these APIs so I can look further into them? I conferred with Josh and he didn't find anything.
Sure, here are some APIs that look promising, and are documented:
* D3DKMTCreateAllocation() * D3DKMTOpenResource() * D3DKMTOpenResourceFromNtHandle() * D3DKMTQueryResourceInfo() * D3DKMTQueryResourceInfoFromNtHandle()
So I discussed this with Josh and Georg, and the problems with these APIs for our usecases are
1) In order to interface with any of these APIs, you need a KMT device handle. This roughly corresponds to a Vulkan device object or OpenGL context, but according to Josh they don't have to map 1:1.
It's a bit unfortunate that this discussion still isn't happening in a public place, but anyway, we already use KMT device handles; see e.g. wined3d_output_init().
2) There's no way to update the private runtime data once the resource is created. In the current and simpler flow, the host graphics API will create the object, and the translation layer will then attach the needed private data. For this to work on windows, the translation layers would have to agree on some way to get Vulkan to set the desired private data, and that's assuming that no Windows drivers already use this for their own purposes.
Part of my point here is that, ideally, we shouldn't need to. Presumably if a Win32 application creates a Vulkan resource and tries to import it into Direct3D, the Microsoft Direct3D runtime will call such functions to get information from it. It seems at least plausible that we could do the same. There may be any number of foreseen and unforeseen pitfalls along the way, which could prevent this approach from working at all, but my point is, it's worth testing—and I mean actually testing, not just theorizing about what we can and can't do. And even if it doesn't work on Windows, it still bears asking whether we should use these APIs for Wine. And, if the answer ends up being yes, we should start there when implementing them. It's far better to plan out the final architecture and implement things accordingly, when possible, rather than to start implementing things one way and then have to reorganize them later.
Also, if there are APIs which allow registering resources retrieved from Vulkan with certain metadata, winevulkan would still have roughly the same role. The only difference would be in the translation layers, where instead of using IOCTLs on the HANDLEs to shared resources they have to get/set metadata, they would use some D3DKMT API you've found.
Well, broadly, yes, but it changes the way that this patch series should be structured and sent.
This patch's main focus is just setting up the winevulkan infrastructure for shared resources. If we decide to still use D3DKMT for one reason or another, the only change to the current patchset would be to the tiny function create_gpu_resource to get the HANDLE through KMT APIs instead of wine_server_fd_to_handle.
I note your tests also don't seem very interesting; they only share objects within the same device. Sharing objects across multiple devices, and across multiple processes, strikes me as more interesting.
In my opinion, given that the semantics for VK_KHR_external_memory_fd and VK_KHR_external_memory_win32 are so similar, I wonder how relevant such tests would be, it seems like the kind of thing the Vulkan CTS should add for testing drivers.
I think the tests should be more for testing the properties of the HANDLEs we get, as this is what we are implementing ourselves. Maybe I should add more tests looking at the locations of the named objects in the NT directory, or tests relating to types of the objects and their access permissions.
The point is more of a smoke test, because it's easy to get it wrong, and not too hard to verify that we got it right.
It'd also be nice to demonstrate what the behaviour of KMT handles is across processes.
An in-process intra-device test tests the same amount of winevulkan behavior as a cross-process inter-device test. All the implementation details of cross-process and cross-device sharing are handled on the host and through wineserver's well established HANDLE<->FD mapping.
Is it really that hard just to add a test?
No, but I just think it would be a waste of time and lines of code, especially for testing cross-process when it makes no difference which processes the two devices are made on. Given that you said "a test", do you mean you think it would be fine if I were to just add a test testing shared resources across devices in the same process?
It's not that hard to write a cross-process test; see kernel32:pipe for an example. We have infrastructure for it. For a rationale: even if the code path isn't significantly different now, it might be in the future, especially when this patch series seems far from maturity. And, like I said, we have no tests for KMT handles across processes.
On 05.06.21 01:23, Zebediah Figura (she/her) wrote:
On 6/1/21 10:17 AM, Derek Lesho wrote:
On 5/31/21 10:43 AM, Zebediah Figura (she/her) wrote:
On 5/26/21 9:21 AM, Derek Lesho wrote:
On 5/25/21 10:07 PM, Zebediah Figura (she/her) wrote:
> > * Shared resources in d3d9-11, when using the OpenGL backend
As mentioned, the EXT_external_objects extension exists, ( https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_external_objects....
), which accepts and produces file descriptors compatible with the ones Vulkan produces and accepts. The interactions here seem to be well defined.
According to my reading, neither GL_EXT_external_objects nor GL_EXT_external_objects_fd provide for export of an object from an OpenGL context; they only allow importing objects created by Vulkan.
Yeah, from what I can see, openGL has no standard way to share memory across processes without the use of this extension and Vulkan. I suspect this would be difficult due to all the user mode driver code protecting against invalid use of resources. I think the most reasonable path forward is to create a Vulkan dummy object in wined3d, then import it into GL. Of course, this would make shared resources unsupported for old GPUs and systems that don't support Vulkan, but the API is half a decade old at this point, and only GPUs from almost a decade ago don't support it.
There is no free software NVidia Vulkan driver, which is a rather glaring hole. There also exist cards released as recently as 2014 that don't support Vulkan. And in general, although it's sometimes convenient for the implementer to require the latest hardware, it's a rather mean thing to do to users.
Keep in mind that we need Direct3D shared resources for bug 44985, which affects a very long list of applications.
Now, with that in mind, two options I immediately see are:
* Create all contexts as shared. It's not clear to me whether this has negative consequences, however. It's also not clear to me whether this can be done across processes.
* Try to introduce an OpenGL extension that allows exporting file descriptors.
The second option definitely sounds better, as with the first you're still limited to in-process sharing, if my understanding is correct. Additionally, the case where you're using wined3d's d3d9 for example, create a shared resource, then try importing it into DXVK for d3d10/11, would only work with the second solution from what I can see. I imagine that we could cover the vast majority of users by implementing the "vulkan helper" path that I suggested before, and quite easily transition into using an extension if/when needed.
Alternatively we could get try to use platform-specific buffer sharing APIs like EGLStreams or GBM, or just support in-process shared resources through the eglCreateContext API, which allows the creation of "shared contexts", in which the GPU resources are shared.
> > * Shared resources between d3d9-12 devices, when using wined3d or > libvkd3d on Windows Putting aside how rare and questionable of a use-case this must be, I don't think this concerns any of my patches. My future patches would provide a way for translation layers on wine to store metadata alongside the host handlers, it doesn't have any correspondence to Windows. If you really wanted to (why?), you could probably create your own backing storage in a shared memory object and accept the caveats that come along with that.
I suspect those of us who have worked with Direct3D for multiple decades would take issue with "rare and questionable", but regardless, part of the point here is to ask: *is* it possible to use a native set of APIs, like perhaps the D3DKMT*() functions from gdi32, to share resources? I.e. should the implementation live in gdi32 instead of winevulkan/opengl32/wined3d? Just from a quick scan I see several which look like the ones we want, and they're even documented.
Could you link these APIs so I can look further into them? I conferred with Josh and he didn't find anything.
Sure, here are some APIs that look promising, and are documented:
* D3DKMTCreateAllocation() * D3DKMTOpenResource() * D3DKMTOpenResourceFromNtHandle() * D3DKMTQueryResourceInfo() * D3DKMTQueryResourceInfoFromNtHandle()
So I discussed this with Josh and Georg, and the problems with these APIs for our usecases are
1) In order to interface with any of these APIs, you need a KMT device handle. This roughly corresponds to a Vulkan device object or OpenGL context, but according to Josh they don't have to map 1:1.
It's a bit unfortunate that this discussion still isn't happening in a public place,
I'm sorry, but I get very annoyed by comments like these when at the same time most of wine's development happens behind closed doors inside codeweavers. It's not like wine-devel is used for architecture discussion or anything like that, no it's just patches and sometimes reviews. And somehow you now criticize me (well, us, but I can only speak for myself) for not communicating only via wine-devel? I send patches via wine-devel and I review patches on wine-devel, just like everyone else. Anyway, back to the actual discussion.
but anyway, we already use KMT device handles; see e.g. wined3d_output_init().
2) There's no way to update the private runtime data once the resource is created. In the current and simpler flow, the host graphics API will create the object, and the translation layer will then attach the needed private data. For this to work on windows, the translation layers would have to agree on some way to get Vulkan to set the desired private data, and that's assuming that no Windows drivers already use this for their own purposes.
Part of my point here is that, ideally, we shouldn't need to. Presumably if a Win32 application creates a Vulkan resource and tries to import it into Direct3D, the Microsoft Direct3D runtime will call such functions to get information from it. It seems at least plausible that we could do the same.
You can *not* import a Vulkan resource into Direct3D. The vulkan specification [1] says: VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_BIT specifies an NT handle that has only limited valid usage outside of Vulkan and other compatible APIs. It must be compatible with the functions DuplicateHandle, CloseHandle, CompareObjectHandles, GetHandleInformation, and SetHandleInformation. VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_KMT_BIT specifies a global share handle that has only limited valid usage outside of Vulkan and other compatible APIs. It is not compatible with any native APIs. Note the "outside of Vulkan and other compatible APIs" part, which to my knowledge means Vulkan and the OpenGL import extension. These handles also can *not* include the info needed for e.g. D3D11 because they are memory objects, not image/buffer objects. If you bind e.g. a 2D image to the memory, you don't know the width, the height or the format on import because it's *just* memory. [1] https://www.khronos.org/registry/vulkan/specs/1.2-extensions/html/vkspec.htm...
There may be any number of foreseen and unforeseen pitfalls along the way, which could prevent this approach from working at all, but my point is, it's worth testing—and I mean actually testing, not just theorizing about what we can and can't do. And even if it doesn't work on Windows, it still bears asking whether we should use these APIs for Wine.
Sorry, I just fail to see what's the point of using D3DKMT is. Unless I miss some detail, this won't make any of this work on windows, and if you somehow found a way to do make it work (which I think does not exists), you would violate the vulkan specification and rely on undefined behavior. And then that makes me ask the question: Why should we use this API in Wine, what's the benefit?
And, if the answer ends up being yes, we should start there when implementing them. It's far better to plan out the final architecture and implement things accordingly, when possible, rather than to start implementing things one way and then have to reorganize them later.
This patch set is 99% setting up winevulkan for translation of the Win32 external memory extension to the Unix fd external memory extension. You have to do that either way, and it won't change regardless of how ultimately get your NT handle for a Unix fd. It's also just vulkan <-> vulkan sharing (and I guess OpenGl if someone wants to implement the import extension in Wine), it does *not* relate to Direct3D at all.
Also, if there are APIs which allow registering resources retrieved from Vulkan with certain metadata, winevulkan would still have roughly the same role. The only difference would be in the translation layers, where instead of using IOCTLs on the HANDLEs to shared resources they have to get/set metadata, they would use some D3DKMT API you've found.
Well, broadly, yes, but it changes the way that this patch series should be structured and sent.
This patch's main focus is just setting up the winevulkan infrastructure for shared resources. If we decide to still use D3DKMT for one reason or another, the only change to the current patchset would be to the tiny function create_gpu_resource to get the HANDLE through KMT APIs instead of wine_server_fd_to_handle.
> > I note your tests also don't seem very interesting; they only share > objects within the same device. Sharing objects across multiple > devices, and across multiple processes, strikes me as more > interesting.
In my opinion, given that the semantics for VK_KHR_external_memory_fd and VK_KHR_external_memory_win32 are so similar, I wonder how relevant such tests would be, it seems like the kind of thing the Vulkan CTS should add for testing drivers.
I think the tests should be more for testing the properties of the HANDLEs we get, as this is what we are implementing ourselves. Maybe I should add more tests looking at the locations of the named objects in the NT directory, or tests relating to types of the objects and their access permissions.
The point is more of a smoke test, because it's easy to get it wrong, and not too hard to verify that we got it right.
It'd also be nice to demonstrate what the behaviour of KMT handles is across processes.
An in-process intra-device test tests the same amount of winevulkan behavior as a cross-process inter-device test. All the implementation details of cross-process and cross-device sharing are handled on the host and through wineserver's well established HANDLE<->FD mapping.
Is it really that hard just to add a test?
No, but I just think it would be a waste of time and lines of code, especially for testing cross-process when it makes no difference which processes the two devices are made on. Given that you said "a test", do you mean you think it would be fine if I were to just add a test testing shared resources across devices in the same process?
It's not that hard to write a cross-process test; see kernel32:pipe for an example. We have infrastructure for it.
For a rationale: even if the code path isn't significantly different now, it might be in the future, especially when this patch series seems far from maturity. And, like I said, we have no tests for KMT handles across processes.
FWIW since this patch set only implements NT handles, it might be better to just not add any KMT handle tests in this patch set at all.
On 6/5/21 10:53 AM, Georg Lehmann wrote:
On 05.06.21 01:23, Zebediah Figura (she/her) wrote:
On 6/1/21 10:17 AM, Derek Lesho wrote:
On 5/31/21 10:43 AM, Zebediah Figura (she/her) wrote:
On 5/26/21 9:21 AM, Derek Lesho wrote:
On 5/25/21 10:07 PM, Zebediah Figura (she/her) wrote:
>> >> * Shared resources in d3d9-11, when using the OpenGL backend > > As mentioned, the EXT_external_objects extension exists, ( > https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_external_objects.... > > > > ), which accepts and produces file descriptors compatible with the > ones > Vulkan produces and accepts. The interactions here seem to be well > defined.
According to my reading, neither GL_EXT_external_objects nor GL_EXT_external_objects_fd provide for export of an object from an OpenGL context; they only allow importing objects created by Vulkan.
Yeah, from what I can see, openGL has no standard way to share memory across processes without the use of this extension and Vulkan. I suspect this would be difficult due to all the user mode driver code protecting against invalid use of resources. I think the most reasonable path forward is to create a Vulkan dummy object in wined3d, then import it into GL. Of course, this would make shared resources unsupported for old GPUs and systems that don't support Vulkan, but the API is half a decade old at this point, and only GPUs from almost a decade ago don't support it.
There is no free software NVidia Vulkan driver, which is a rather glaring hole. There also exist cards released as recently as 2014 that don't support Vulkan. And in general, although it's sometimes convenient for the implementer to require the latest hardware, it's a rather mean thing to do to users.
Keep in mind that we need Direct3D shared resources for bug 44985, which affects a very long list of applications.
Now, with that in mind, two options I immediately see are:
* Create all contexts as shared. It's not clear to me whether this has negative consequences, however. It's also not clear to me whether this can be done across processes.
* Try to introduce an OpenGL extension that allows exporting file descriptors.
The second option definitely sounds better, as with the first you're still limited to in-process sharing, if my understanding is correct. Additionally, the case where you're using wined3d's d3d9 for example, create a shared resource, then try importing it into DXVK for d3d10/11, would only work with the second solution from what I can see. I imagine that we could cover the vast majority of users by implementing the "vulkan helper" path that I suggested before, and quite easily transition into using an extension if/when needed.
Alternatively we could get try to use platform-specific buffer sharing APIs like EGLStreams or GBM, or just support in-process shared resources through the eglCreateContext API, which allows the creation of "shared contexts", in which the GPU resources are shared.
>> >> * Shared resources between d3d9-12 devices, when using wined3d or >> libvkd3d on Windows > Putting aside how rare and questionable of a use-case this must be, I > don't think this concerns any of my patches. My future patches would > provide a way for translation layers on wine to store metadata > alongside > the host handlers, it doesn't have any correspondence to Windows. If > you really wanted to (why?), you could probably create your own > backing > storage in a shared memory object and accept the caveats that come > along > with that.
I suspect those of us who have worked with Direct3D for multiple decades would take issue with "rare and questionable", but regardless, part of the point here is to ask: *is* it possible to use a native set of APIs, like perhaps the D3DKMT*() functions from gdi32, to share resources? I.e. should the implementation live in gdi32 instead of winevulkan/opengl32/wined3d? Just from a quick scan I see several which look like the ones we want, and they're even documented.
Could you link these APIs so I can look further into them? I conferred with Josh and he didn't find anything.
Sure, here are some APIs that look promising, and are documented:
* D3DKMTCreateAllocation() * D3DKMTOpenResource() * D3DKMTOpenResourceFromNtHandle() * D3DKMTQueryResourceInfo() * D3DKMTQueryResourceInfoFromNtHandle()
So I discussed this with Josh and Georg, and the problems with these APIs for our usecases are
1) In order to interface with any of these APIs, you need a KMT device handle. This roughly corresponds to a Vulkan device object or OpenGL context, but according to Josh they don't have to map 1:1.
It's a bit unfortunate that this discussion still isn't happening in a public place,
I'm sorry, but I get very annoyed by comments like these when at the same time most of wine's development happens behind closed doors inside codeweavers. It's not like wine-devel is used for architecture discussion or anything like that, no it's just patches and sometimes reviews. And somehow you now criticize me (well, us, but I can only speak for myself) for not communicating only via wine-devel? I send patches via wine-devel and I review patches on wine-devel, just like everyone else.
So for what it's worth—and I'm not speaking for CodeWeavers here—I don't think "most of wine's development" happens anywhere at all. Large-scale architectural decisions aren't really discussed often. But if they are, they're usually discussed on wine-devel, Bugzilla, #winehackers, WineConf, or privately via e-mail. The last is a bit unfortunate, but it's also not specific to CodeWeavers—I can think of two people with whom I'm currently engaged in architectural discussion, and only one of those is a CodeWeavers employee. And I get the impression that CodeWeavers, or at least its employees, try to encourage discussing things openly where possible (not constrained by NDA, etc.) And when it comes to patches, we *are* encouraged and even expected to explain ourselves from the point of view of an outsider; see [2] for example. By contrast, when I tried to get the VKx community to discuss things openly, it was made quickly clear to me that they were not interested in using official Wine channels or coöperating with upstream Wine developers, but rather wanted Wine developers to use their channels (and their development practices, and their forks, etc...) So I'm being more than a little passive-aggressive, and I'm sorry for that. But I also really do want to point out that the people most involved in Direct3D/GPU work in Wine have not been involved in this discussion at all, and before some point in this reply chain they/we had no idea it was even happening. And as a result when a submitter acts like some fact is obvious, to the point of not explaining it at all, just because they discussed it privately with someone else, it's more than a little frustrating. The bottom line is: it's really not clear that this patch set is taking the right approach. Not "it's taking the wrong approach", but it's really not clear that it's taking the right one. And most of that unclarity comes from a lack of public discussion, or even private discussion with the Wine contributors involved in Direct3D/GPU APIs. [2] https://www.winehq.org/pipermail/wine-devel/2019-June/147452.html
Anyway, back to the actual discussion.
but anyway, we already use KMT device handles; see e.g. wined3d_output_init().
2) There's no way to update the private runtime data once the resource is created. In the current and simpler flow, the host graphics API will create the object, and the translation layer will then attach the needed private data. For this to work on windows, the translation layers would have to agree on some way to get Vulkan to set the desired private data, and that's assuming that no Windows drivers already use this for their own purposes.
Part of my point here is that, ideally, we shouldn't need to. Presumably if a Win32 application creates a Vulkan resource and tries to import it into Direct3D, the Microsoft Direct3D runtime will call such functions to get information from it. It seems at least plausible that we could do the same.
You can *not* import a Vulkan resource into Direct3D. The vulkan specification [1] says:
VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_BIT specifies an NT handle that has only limited valid usage outside of Vulkan and other compatible APIs. It must be compatible with the functions DuplicateHandle, CloseHandle, CompareObjectHandles, GetHandleInformation, and SetHandleInformation.
VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_KMT_BIT specifies a global share handle that has only limited valid usage outside of Vulkan and other compatible APIs. It is not compatible with any native APIs.
Note the "outside of Vulkan and other compatible APIs" part, which to my knowledge means Vulkan and the OpenGL import extension.
These handles also can *not* include the info needed for e.g. D3D11 because they are memory objects, not image/buffer objects. If you bind e.g. a 2D image to the memory, you don't know the width, the height or the format on import because it's *just* memory.
[1] https://www.khronos.org/registry/vulkan/specs/1.2-extensions/html/vkspec.htm...
That may be true for the OPAQUE bit, but that's not the only bit. E.g. as far as I can tell from my reading of the Vulkan specification, VK_EXTERNAL_MEMORY_HANDLE_TYPE_D3D11_TEXTURE_BIT isn't forbidden from being specified in VkExportMemoryAllocateInfo, and the language even seems to "explicitly imply", as it were, that it's allowed. See the Vulkan 1.2 specification § 11.2.4 in particular. Granted, the documentation for VK_EXTERNAL_MEMORY_HANDLE_TYPE_D3D11_TEXTURE_BIT itself (no section number, I guess?) says "VK_EXTERNAL_MEMORY_HANDLE_TYPE_D3D11_TEXTURE_BIT specifies an NT handle returned by IDXGIResource1::CreateSharedHandle referring to a Direct3D 10 or 11 texture resource," which is a bit unclear. I haven't actually tested whether it works in practice, either, although of course even if it doesn't now it might in the future.
There may be any number of foreseen and unforeseen pitfalls along the way, which could prevent this approach from working at all, but my point is, it's worth testing—and I mean actually testing, not just theorizing about what we can and can't do. And even if it doesn't work on Windows, it still bears asking whether we should use these APIs for Wine.
Sorry, I just fail to see what's the point of using D3DKMT is. Unless I miss some detail, this won't make any of this work on windows, and if you somehow found a way to do make it work (which I think does not exists), you would violate the vulkan specification and rely on undefined behavior.
And then that makes me ask the question: Why should we use this API in Wine, what's the benefit?
And, if the answer ends up being yes, we should start there when implementing them. It's far better to plan out the final architecture and implement things accordingly, when possible, rather than to start implementing things one way and then have to reorganize them later.
This patch set is 99% setting up winevulkan for translation of the Win32 external memory extension to the Unix fd external memory extension. You have to do that either way, and it won't change regardless of how ultimately get your NT handle for a Unix fd. It's also just vulkan <-> vulkan sharing (and I guess OpenGl if someone wants to implement the import extension in Wine), it does *not* relate to Direct3D at all.
I was hoping this would be evident by now, but Vulkan does not exist in a vacuum, as far as Wine is concerned. Neither does VK_KHR_external_memory_win32. Vulkan can at the very least import resources from Direct3D, and export resources to OpenGL. Those in turn have more interop and intra-op (as it were) capabilities. And even if there were no interop, it's not unlikely that we'd want to consider how to make intra-op work in a generic way. Even the initial version of this patch set was submitted with that in mind. Yes, it's a hard problem, and a lot of the hard things about it come from making *all* of the interop and intra-op work at once. It would be much easier if we could just submit this patch series and claim we're done, if only for now. But Wine doesn't really follow this development model: we much prefer to get the design right from the beginning, no matter how long it takes, so that we don't have to fix it much later, when it'll be much more painful.
Also, if there are APIs which allow registering resources retrieved from Vulkan with certain metadata, winevulkan would still have roughly the same role. The only difference would be in the translation layers, where instead of using IOCTLs on the HANDLEs to shared resources they have to get/set metadata, they would use some D3DKMT API you've found.
Well, broadly, yes, but it changes the way that this patch series should be structured and sent.
This patch's main focus is just setting up the winevulkan infrastructure for shared resources. If we decide to still use D3DKMT for one reason or another, the only change to the current patchset would be to the tiny function create_gpu_resource to get the HANDLE through KMT APIs instead of wine_server_fd_to_handle.
>> >> I note your tests also don't seem very interesting; they only share >> objects within the same device. Sharing objects across multiple >> devices, and across multiple processes, strikes me as more >> interesting. > > In my opinion, given that the semantics for VK_KHR_external_memory_fd > and VK_KHR_external_memory_win32 are so similar, I wonder how > relevant > such tests would be, it seems like the kind of thing the Vulkan CTS > should add for testing drivers. > > I think the tests should be more for testing the properties of the > HANDLEs we get, as this is what we are implementing ourselves. > Maybe I > should add more tests looking at the locations of the named > objects in > the NT directory, or tests relating to types of the objects and their > access permissions. > >
The point is more of a smoke test, because it's easy to get it wrong, and not too hard to verify that we got it right.
It'd also be nice to demonstrate what the behaviour of KMT handles is across processes.
An in-process intra-device test tests the same amount of winevulkan behavior as a cross-process inter-device test. All the implementation details of cross-process and cross-device sharing are handled on the host and through wineserver's well established HANDLE<->FD mapping.
Is it really that hard just to add a test?
No, but I just think it would be a waste of time and lines of code, especially for testing cross-process when it makes no difference which processes the two devices are made on. Given that you said "a test", do you mean you think it would be fine if I were to just add a test testing shared resources across devices in the same process?
It's not that hard to write a cross-process test; see kernel32:pipe for an example. We have infrastructure for it.
For a rationale: even if the code path isn't significantly different now, it might be in the future, especially when this patch series seems far from maturity. And, like I said, we have no tests for KMT handles across processes.
FWIW since this patch set only implements NT handles, it might be better to just not add any KMT handle tests in this patch set at all.
On 6/9/21 9:56 PM, Zebediah Figura (she/her) wrote:
On 6/5/21 10:53 AM, Georg Lehmann wrote:
On 05.06.21 01:23, Zebediah Figura (she/her) wrote:
On 6/1/21 10:17 AM, Derek Lesho wrote:
On 5/31/21 10:43 AM, Zebediah Figura (she/her) wrote:
On 5/26/21 9:21 AM, Derek Lesho wrote:
On 5/25/21 10:07 PM, Zebediah Figura (she/her) wrote:
> >>> >>> * Shared resources in d3d9-11, when using the OpenGL backend >> >> As mentioned, the EXT_external_objects extension exists, ( >> https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_external_objects.... >> >> >> >> >> ), which accepts and produces file descriptors compatible with the >> ones >> Vulkan produces and accepts. The interactions here seem to be >> well >> defined. > > According to my reading, neither GL_EXT_external_objects nor > GL_EXT_external_objects_fd provide for export of an object from an > OpenGL context; they only allow importing objects created by > Vulkan.
Yeah, from what I can see, openGL has no standard way to share memory across processes without the use of this extension and Vulkan. I suspect this would be difficult due to all the user mode driver code protecting against invalid use of resources. I think the most reasonable path forward is to create a Vulkan dummy object in wined3d, then import it into GL. Of course, this would make shared resources unsupported for old GPUs and systems that don't support Vulkan, but the API is half a decade old at this point, and only GPUs from almost a decade ago don't support it.
There is no free software NVidia Vulkan driver, which is a rather glaring hole. There also exist cards released as recently as 2014 that don't support Vulkan. And in general, although it's sometimes convenient for the implementer to require the latest hardware, it's a rather mean thing to do to users.
Keep in mind that we need Direct3D shared resources for bug 44985, which affects a very long list of applications.
Now, with that in mind, two options I immediately see are:
* Create all contexts as shared. It's not clear to me whether this has negative consequences, however. It's also not clear to me whether this can be done across processes.
* Try to introduce an OpenGL extension that allows exporting file descriptors.
The second option definitely sounds better, as with the first you're still limited to in-process sharing, if my understanding is correct. Additionally, the case where you're using wined3d's d3d9 for example, create a shared resource, then try importing it into DXVK for d3d10/11, would only work with the second solution from what I can see. I imagine that we could cover the vast majority of users by implementing the "vulkan helper" path that I suggested before, and quite easily transition into using an extension if/when needed.
Alternatively we could get try to use platform-specific buffer sharing APIs like EGLStreams or GBM, or just support in-process shared resources through the eglCreateContext API, which allows the creation of "shared contexts", in which the GPU resources are shared.
>>> >>> * Shared resources between d3d9-12 devices, when using wined3d or >>> libvkd3d on Windows >> Putting aside how rare and questionable of a use-case this must >> be, I >> don't think this concerns any of my patches. My future patches >> would >> provide a way for translation layers on wine to store metadata >> alongside >> the host handlers, it doesn't have any correspondence to >> Windows. If >> you really wanted to (why?), you could probably create your own >> backing >> storage in a shared memory object and accept the caveats that come >> along >> with that. > > I suspect those of us who have worked with Direct3D for multiple > decades would take issue with "rare and questionable", but > regardless, > part of the point here is to ask: *is* it possible to use a > native set > of APIs, like perhaps the D3DKMT*() functions from gdi32, to share > resources? I.e. should the implementation live in gdi32 instead of > winevulkan/opengl32/wined3d? Just from a quick scan I see several > which look like the ones we want, and they're even documented.
Could you link these APIs so I can look further into them? I conferred with Josh and he didn't find anything.
Sure, here are some APIs that look promising, and are documented:
* D3DKMTCreateAllocation() * D3DKMTOpenResource() * D3DKMTOpenResourceFromNtHandle() * D3DKMTQueryResourceInfo() * D3DKMTQueryResourceInfoFromNtHandle()
So I discussed this with Josh and Georg, and the problems with these APIs for our usecases are
1) In order to interface with any of these APIs, you need a KMT device handle. This roughly corresponds to a Vulkan device object or OpenGL context, but according to Josh they don't have to map 1:1.
It's a bit unfortunate that this discussion still isn't happening in a public place,
I'm sorry, but I get very annoyed by comments like these when at the same time most of wine's development happens behind closed doors inside codeweavers. It's not like wine-devel is used for architecture discussion or anything like that, no it's just patches and sometimes reviews. And somehow you now criticize me (well, us, but I can only speak for myself) for not communicating only via wine-devel? I send patches via wine-devel and I review patches on wine-devel, just like everyone else.
So for what it's worth—and I'm not speaking for CodeWeavers here—I don't think "most of wine's development" happens anywhere at all. Large-scale architectural decisions aren't really discussed often. But if they are, they're usually discussed on wine-devel, Bugzilla, #winehackers, WineConf, or privately via e-mail.
The last is a bit unfortunate, but it's also not specific to CodeWeavers—I can think of two people with whom I'm currently engaged in architectural discussion, and only one of those is a CodeWeavers employee.
And I get the impression that CodeWeavers, or at least its employees, try to encourage discussing things openly where possible (not constrained by NDA, etc.) And when it comes to patches, we *are* encouraged and even expected to explain ourselves from the point of view of an outsider; see [2] for example.
By contrast, when I tried to get the VKx community to discuss things openly, it was made quickly clear to me that they were not interested in using official Wine channels or coöperating with upstream Wine developers, but rather wanted Wine developers to use their channels (and their development practices, and their forks, etc...)
So I'm being more than a little passive-aggressive, and I'm sorry for that. But I also really do want to point out that the people most involved in Direct3D/GPU work in Wine have not been involved in this discussion at all, and before some point in this reply chain they/we had no idea it was even happening. And as a result when a submitter acts like some fact is obvious, to the point of not explaining it at all, just because they discussed it privately with someone else, it's more than a little frustrating. The only thing I have to say here is that my experiences working for codeweavers give me a different impression. We regularly get updated on what everyone is working on, and have been shared much more information about the ongoing PE/unix architectural rework than the outside community.
The bottom line is: it's really not clear that this patch set is taking the right approach. Not "it's taking the wrong approach", but it's really not clear that it's taking the right one. And most of that unclarity comes from a lack of public discussion, or even private discussion with the Wine contributors involved in Direct3D/GPU APIs. I'd like to reiterate here that this current patchset is not opinionated on the approach we end up taking for D3D resources. It simply implements 1:1 an exclusively Vulkan/GL feature with the almost identical corresponding Unix API. The discussions we are having about what to do in those cases are important, but they don't affect whether or not this current patch series should be merged. If you disagree with that statement, please refer to the code that would have to be substantially changed in any thus-far proposed approach to the greater problem, so that we can address it separately from the broader discussion of how we want to handle resources and interop with D3D.
[2] https://www.winehq.org/pipermail/wine-devel/2019-June/147452.html
Anyway, back to the actual discussion.
but anyway, we already use KMT device handles; see e.g. wined3d_output_init().
2) There's no way to update the private runtime data once the resource is created. In the current and simpler flow, the host graphics API will create the object, and the translation layer will then attach the needed private data. For this to work on windows, the translation layers would have to agree on some way to get Vulkan to set the desired private data, and that's assuming that no Windows drivers already use this for their own purposes.
Part of my point here is that, ideally, we shouldn't need to. Presumably if a Win32 application creates a Vulkan resource and tries to import it into Direct3D, the Microsoft Direct3D runtime will call such functions to get information from it. It seems at least plausible that we could do the same.
You can *not* import a Vulkan resource into Direct3D. The vulkan specification [1] says:
VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_BIT specifies an NT handle that has only limited valid usage outside of Vulkan and other compatible APIs. It must be compatible with the functions DuplicateHandle, CloseHandle, CompareObjectHandles, GetHandleInformation, and SetHandleInformation.
VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_KMT_BIT specifies a global share handle that has only limited valid usage outside of Vulkan and other compatible APIs. It is not compatible with any native APIs.
Note the "outside of Vulkan and other compatible APIs" part, which to my knowledge means Vulkan and the OpenGL import extension.
These handles also can *not* include the info needed for e.g. D3D11 because they are memory objects, not image/buffer objects. If you bind e.g. a 2D image to the memory, you don't know the width, the height or the format on import because it's *just* memory.
[1] https://www.khronos.org/registry/vulkan/specs/1.2-extensions/html/vkspec.htm...
That may be true for the OPAQUE bit, but that's not the only bit. E.g. as far as I can tell from my reading of the Vulkan specification, VK_EXTERNAL_MEMORY_HANDLE_TYPE_D3D11_TEXTURE_BIT isn't forbidden from being specified in VkExportMemoryAllocateInfo, and the language even seems to "explicitly imply", as it were, that it's allowed. See the Vulkan 1.2 specification § 11.2.4 in particular.
Granted, the documentation for VK_EXTERNAL_MEMORY_HANDLE_TYPE_D3D11_TEXTURE_BIT itself (no section number, I guess?) says "VK_EXTERNAL_MEMORY_HANDLE_TYPE_D3D11_TEXTURE_BIT specifies an NT handle returned by IDXGIResource1::CreateSharedHandle referring to a Direct3D 10 or 11 texture resource," which is a bit unclear. I haven't actually tested whether it works in practice, either, although of course even if it doesn't now it might in the future.
Good catch, I think we overlooked this possibility before. I wrote some tests to see whether any drivers support this on windows, and it seems they don't. (When querying the properties of sharing an image through VK_EXTERNAL_MEMORY_HANDLE_TYPE_D3D11_TEXTURE_BIT, both the NVIDIA and AMD windows drivers report only VK_EXTERNAL_MEMORY_FEATURE_DEDICATED_ONLY_BIT|VK_EXTERNAL_MEMORY_FEATURE_IMPORTABLE_BIT). It seems that we could however expose this functionality in wine, and then write the relevant translation layer code that would work on windows if this were ever to be supported by a windows driver. Nevertheless, I'm still leaning against using this approach, as 1) It requires us to reverse engineer the undocumented runtime data format, which has a good chance of changing from windows version to windows version. I doubt that any windows applications have any reason to use these APIs when they can just go through D3D11 to get the information they want in a well-defined manner, meaning Microsoft probably doesn't have to worry about changing this. 2) This approach would require us to wrap the VkImage structure in winevulkan, since it is inferred that the runtime data we need is derived from VkImage used in the dedicated+shared allocation. (The spec doesn't specify this, but it's the only possible way this data is shared with the call creating the shared resource). According the Georg, doing this would slow down some critical hotpath functions, namely the descriptor update functions.
There may be any number of foreseen and unforeseen pitfalls along the way, which could prevent this approach from working at all, but my point is, it's worth testing—and I mean actually testing, not just theorizing about what we can and can't do. And even if it doesn't work on Windows, it still bears asking whether we should use these APIs for Wine.
Sorry, I just fail to see what's the point of using D3DKMT is. Unless I miss some detail, this won't make any of this work on windows, and if you somehow found a way to do make it work (which I think does not exists), you would violate the vulkan specification and rely on undefined behavior.
And then that makes me ask the question: Why should we use this API in Wine, what's the benefit?
And, if the answer ends up being yes, we should start there when implementing them. It's far better to plan out the final architecture and implement things accordingly, when possible, rather than to start implementing things one way and then have to reorganize them later.
This patch set is 99% setting up winevulkan for translation of the Win32 external memory extension to the Unix fd external memory extension. You have to do that either way, and it won't change regardless of how ultimately get your NT handle for a Unix fd. It's also just vulkan <-> vulkan sharing (and I guess OpenGl if someone wants to implement the import extension in Wine), it does *not* relate to Direct3D at all.
I was hoping this would be evident by now, but Vulkan does not exist in a vacuum, as far as Wine is concerned. Neither does VK_KHR_external_memory_win32. Vulkan can at the very least import resources from Direct3D, and export resources to OpenGL. Those in turn have more interop and intra-op (as it were) capabilities. And even if there were no interop, it's not unlikely that we'd want to consider how to make intra-op work in a generic way. Even the initial version of this patch set was submitted with that in mind.
The shared resource primitives implemented in this patchset do exist in vacuum, together with the GL extension.
Yes, it's a hard problem, and a lot of the hard things about it come from making *all* of the interop and intra-op work at once. It would be much easier if we could just submit this patch series and claim we're done, if only for now. But Wine doesn't really follow this development model: we much prefer to get the design right from the beginning, no matter how long it takes, so that we don't have to fix it much later, when it'll be much more painful.
Also, if there are APIs which allow registering resources retrieved from Vulkan with certain metadata, winevulkan would still have roughly the same role. The only difference would be in the translation layers, where instead of using IOCTLs on the HANDLEs to shared resources they have to get/set metadata, they would use some D3DKMT API you've found.
Well, broadly, yes, but it changes the way that this patch series should be structured and sent.
This patch's main focus is just setting up the winevulkan infrastructure for shared resources. If we decide to still use D3DKMT for one reason or another, the only change to the current patchset would be to the tiny function create_gpu_resource to get the HANDLE through KMT APIs instead of wine_server_fd_to_handle.
> >>> >>> I note your tests also don't seem very interesting; they only >>> share >>> objects within the same device. Sharing objects across multiple >>> devices, and across multiple processes, strikes me as more >>> interesting. >> >> In my opinion, given that the semantics for >> VK_KHR_external_memory_fd >> and VK_KHR_external_memory_win32 are so similar, I wonder how >> relevant >> such tests would be, it seems like the kind of thing the Vulkan >> CTS >> should add for testing drivers. >> >> I think the tests should be more for testing the properties of the >> HANDLEs we get, as this is what we are implementing ourselves. >> Maybe I >> should add more tests looking at the locations of the named >> objects in >> the NT directory, or tests relating to types of the objects and >> their >> access permissions. >> >> > > The point is more of a smoke test, because it's easy to get it > wrong, > and not too hard to verify that we got it right. > > It'd also be nice to demonstrate what the behaviour of KMT > handles is > across processes. > An in-process intra-device test tests the same amount of winevulkan behavior as a cross-process inter-device test. All the implementation details of cross-process and cross-device sharing are handled on the host and through wineserver's well established HANDLE<->FD mapping.
Is it really that hard just to add a test?
No, but I just think it would be a waste of time and lines of code, especially for testing cross-process when it makes no difference which processes the two devices are made on. Given that you said "a test", do you mean you think it would be fine if I were to just add a test testing shared resources across devices in the same process?
It's not that hard to write a cross-process test; see kernel32:pipe for an example. We have infrastructure for it.
For a rationale: even if the code path isn't significantly different now, it might be in the future, especially when this patch series seems far from maturity. And, like I said, we have no tests for KMT handles across processes.
FWIW since this patch set only implements NT handles, it might be better to just not add any KMT handle tests in this patch set at all.
On 10.06.21 21:18, Derek Lesho wrote:
On 6/9/21 9:56 PM, Zebediah Figura (she/her) wrote:
On 6/5/21 10:53 AM, Georg Lehmann wrote:
On 05.06.21 01:23, Zebediah Figura (she/her) wrote:
On 6/1/21 10:17 AM, Derek Lesho wrote:
On 5/31/21 10:43 AM, Zebediah Figura (she/her) wrote:
On 5/26/21 9:21 AM, Derek Lesho wrote: > On 5/25/21 10:07 PM, Zebediah Figura (she/her) wrote: > >> >>>> >>>> * Shared resources in d3d9-11, when using the OpenGL backend >>> >>> As mentioned, the EXT_external_objects extension exists, ( >>> https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_external_objects.... >>> >>> >>> >>> >>> ), which accepts and produces file descriptors compatible with the >>> ones >>> Vulkan produces and accepts. The interactions here seem to be >>> well >>> defined. >> >> According to my reading, neither GL_EXT_external_objects nor >> GL_EXT_external_objects_fd provide for export of an object from an >> OpenGL context; they only allow importing objects created by >> Vulkan. > > Yeah, from what I can see, openGL has no standard way to share > memory > across processes without the use of this extension and Vulkan. I > suspect this would be difficult due to all the user mode driver code > protecting against invalid use of resources. I think the most > reasonable path forward is to create a Vulkan dummy object in > wined3d, > then import it into GL. Of course, this would make shared resources > unsupported for old GPUs and systems that don't support Vulkan, > but the > API is half a decade old at this point, and only GPUs from almost a > decade ago don't support it.
There is no free software NVidia Vulkan driver, which is a rather glaring hole. There also exist cards released as recently as 2014 that don't support Vulkan. And in general, although it's sometimes convenient for the implementer to require the latest hardware, it's a rather mean thing to do to users.
Keep in mind that we need Direct3D shared resources for bug 44985, which affects a very long list of applications.
Now, with that in mind, two options I immediately see are:
* Create all contexts as shared. It's not clear to me whether this has negative consequences, however. It's also not clear to me whether this can be done across processes.
* Try to introduce an OpenGL extension that allows exporting file descriptors.
The second option definitely sounds better, as with the first you're still limited to in-process sharing, if my understanding is correct. Additionally, the case where you're using wined3d's d3d9 for example, create a shared resource, then try importing it into DXVK for d3d10/11, would only work with the second solution from what I can see. I imagine that we could cover the vast majority of users by implementing the "vulkan helper" path that I suggested before, and quite easily transition into using an extension if/when needed.
> > Alternatively we could get try to use platform-specific buffer > sharing > APIs like EGLStreams or GBM, or just support in-process shared > resources > through the eglCreateContext API, which allows the creation of > "shared > contexts", in which the GPU resources are shared. > >>>> >>>> * Shared resources between d3d9-12 devices, when using wined3d or >>>> libvkd3d on Windows >>> Putting aside how rare and questionable of a use-case this must >>> be, I >>> don't think this concerns any of my patches. My future patches >>> would >>> provide a way for translation layers on wine to store metadata >>> alongside >>> the host handlers, it doesn't have any correspondence to >>> Windows. If >>> you really wanted to (why?), you could probably create your own >>> backing >>> storage in a shared memory object and accept the caveats that come >>> along >>> with that. >> >> I suspect those of us who have worked with Direct3D for multiple >> decades would take issue with "rare and questionable", but >> regardless, >> part of the point here is to ask: *is* it possible to use a >> native set >> of APIs, like perhaps the D3DKMT*() functions from gdi32, to share >> resources? I.e. should the implementation live in gdi32 instead of >> winevulkan/opengl32/wined3d? Just from a quick scan I see several >> which look like the ones we want, and they're even documented. > > Could you link these APIs so I can look further into them? I > conferred > with Josh and he didn't find anything.
Sure, here are some APIs that look promising, and are documented:
* D3DKMTCreateAllocation() * D3DKMTOpenResource() * D3DKMTOpenResourceFromNtHandle() * D3DKMTQueryResourceInfo() * D3DKMTQueryResourceInfoFromNtHandle()
So I discussed this with Josh and Georg, and the problems with these APIs for our usecases are
1) In order to interface with any of these APIs, you need a KMT device handle. This roughly corresponds to a Vulkan device object or OpenGL context, but according to Josh they don't have to map 1:1.
It's a bit unfortunate that this discussion still isn't happening in a public place,
I'm sorry, but I get very annoyed by comments like these when at the same time most of wine's development happens behind closed doors inside codeweavers. It's not like wine-devel is used for architecture discussion or anything like that, no it's just patches and sometimes reviews. And somehow you now criticize me (well, us, but I can only speak for myself) for not communicating only via wine-devel? I send patches via wine-devel and I review patches on wine-devel, just like everyone else.
So for what it's worth—and I'm not speaking for CodeWeavers here—I don't think "most of wine's development" happens anywhere at all. Large-scale architectural decisions aren't really discussed often. But if they are, they're usually discussed on wine-devel, Bugzilla, #winehackers, WineConf, or privately via e-mail.
The last is a bit unfortunate, but it's also not specific to CodeWeavers—I can think of two people with whom I'm currently engaged in architectural discussion, and only one of those is a CodeWeavers employee.
And I get the impression that CodeWeavers, or at least its employees, try to encourage discussing things openly where possible (not constrained by NDA, etc.) And when it comes to patches, we *are* encouraged and even expected to explain ourselves from the point of view of an outsider; see [2] for example.
By contrast, when I tried to get the VKx community to discuss things openly, it was made quickly clear to me that they were not interested in using official Wine channels or coöperating with upstream Wine developers, but rather wanted Wine developers to use their channels (and their development practices, and their forks, etc...)
So I'm being more than a little passive-aggressive, and I'm sorry for that. But I also really do want to point out that the people most involved in Direct3D/GPU work in Wine have not been involved in this discussion at all, and before some point in this reply chain they/we had no idea it was even happening. And as a result when a submitter acts like some fact is obvious, to the point of not explaining it at all, just because they discussed it privately with someone else, it's more than a little frustrating. The only thing I have to say here is that my experiences working for codeweavers give me a different impression. We regularly get updated on what everyone is working on, and have been shared much more information about the ongoing PE/unix architectural rework than the outside community.
The bottom line is: it's really not clear that this patch set is taking the right approach. Not "it's taking the wrong approach", but it's really not clear that it's taking the right one. And most of that unclarity comes from a lack of public discussion, or even private discussion with the Wine contributors involved in Direct3D/GPU APIs. I'd like to reiterate here that this current patchset is not opinionated on the approach we end up taking for D3D resources. It simply implements 1:1 an exclusively Vulkan/GL feature with the almost identical corresponding Unix API. The discussions we are having about what to do in those cases are important, but they don't affect whether or not this current patch series should be merged. If you disagree with that statement, please refer to the code that would have to be substantially changed in any thus-far proposed approach to the greater problem, so that we can address it separately from the broader discussion of how we want to handle resources and interop with D3D.
[2] https://www.winehq.org/pipermail/wine-devel/2019-June/147452.html
Anyway, back to the actual discussion.
but anyway, we already use KMT device handles; see e.g. wined3d_output_init().
2) There's no way to update the private runtime data once the resource is created. In the current and simpler flow, the host graphics API will create the object, and the translation layer will then attach the needed private data. For this to work on windows, the translation layers would have to agree on some way to get Vulkan to set the desired private data, and that's assuming that no Windows drivers already use this for their own purposes.
Part of my point here is that, ideally, we shouldn't need to. Presumably if a Win32 application creates a Vulkan resource and tries to import it into Direct3D, the Microsoft Direct3D runtime will call such functions to get information from it. It seems at least plausible that we could do the same.
You can *not* import a Vulkan resource into Direct3D. The vulkan specification [1] says:
VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_BIT specifies an NT handle that has only limited valid usage outside of Vulkan and other compatible APIs. It must be compatible with the functions DuplicateHandle, CloseHandle, CompareObjectHandles, GetHandleInformation, and SetHandleInformation.
VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_KMT_BIT specifies a global share handle that has only limited valid usage outside of Vulkan and other compatible APIs. It is not compatible with any native APIs.
Note the "outside of Vulkan and other compatible APIs" part, which to my knowledge means Vulkan and the OpenGL import extension.
These handles also can *not* include the info needed for e.g. D3D11 because they are memory objects, not image/buffer objects. If you bind e.g. a 2D image to the memory, you don't know the width, the height or the format on import because it's *just* memory.
[1] https://www.khronos.org/registry/vulkan/specs/1.2-extensions/html/vkspec.htm...
That may be true for the OPAQUE bit, but that's not the only bit. E.g. as far as I can tell from my reading of the Vulkan specification, VK_EXTERNAL_MEMORY_HANDLE_TYPE_D3D11_TEXTURE_BIT isn't forbidden from being specified in VkExportMemoryAllocateInfo, and the language even seems to "explicitly imply", as it were, that it's allowed. See the Vulkan 1.2 specification § 11.2.4 in particular.
Granted, the documentation for VK_EXTERNAL_MEMORY_HANDLE_TYPE_D3D11_TEXTURE_BIT itself (no section number, I guess?) says "VK_EXTERNAL_MEMORY_HANDLE_TYPE_D3D11_TEXTURE_BIT specifies an NT handle returned by IDXGIResource1::CreateSharedHandle referring to a Direct3D 10 or 11 texture resource," which is a bit unclear. I haven't actually tested whether it works in practice, either, although of course even if it doesn't now it might in the future.
Good catch, I think we overlooked this possibility before. I wrote some tests to see whether any drivers support this on windows, and it seems they don't. (When querying the properties of sharing an image through VK_EXTERNAL_MEMORY_HANDLE_TYPE_D3D11_TEXTURE_BIT, both the NVIDIA and AMD windows drivers report only VK_EXTERNAL_MEMORY_FEATURE_DEDICATED_ONLY_BIT|VK_EXTERNAL_MEMORY_FEATURE_IMPORTABLE_BIT).
It seems that we could however expose this functionality in wine, and then write the relevant translation layer code that would work on windows if this were ever to be supported by a windows driver. Nevertheless, I'm still leaning against using this approach, as
1) It requires us to reverse engineer the undocumented runtime data format, which has a good chance of changing from windows version to windows version. I doubt that any windows applications have any reason to use these APIs when they can just go through D3D11 to get the information they want in a well-defined manner, meaning Microsoft probably doesn't have to worry about changing this.
2) This approach would require us to wrap the VkImage structure in winevulkan, since it is inferred that the runtime data we need is derived from VkImage used in the dedicated+shared allocation. (The spec doesn't specify this, but it's the only possible way this data is shared with the call creating the shared resource). According the Georg, doing this would slow down some critical hotpath functions, namely the descriptor update functions.
But I also think if we actually want to go down that path we could find other ways to store data per VkImage. VK_EXT_private_data is the most simplistic one at the cost of requiring that it's available if we want to expose VK_KHR_external_memory_win32.
participants (4)
-
Derek Lesho -
Georg Lehmann -
Joshua Ashton -
Zebediah Figura (she/her)