[PATCH v10 [rebased] 2/4] vulkan-1/tests: Add tests for VK_KHR_external_memory_win32.

Zebediah Figura (she/her) zfigura at codeweavers.com
Fri Jul 9 19:50:26 CDT 2021


On 7/6/21 11:24 AM, Derek Lesho wrote:
> 
> On 7/1/21 3:59 PM, Zebediah Figura (she/her) wrote:
>>> +    argc = winetest_get_mainargs(&argv);
>>> +    if (argc > 3 && !strcmp(argv[2], "resource"))
>>> +    {
>>> +        sscanf(argv[6], "%p", &handle);
>>> +
>>> +        import_handle_info.sType =
>>> VK_STRUCTURE_TYPE_IMPORT_MEMORY_WIN32_HANDLE_INFO_KHR;
>>> +        import_handle_info.pNext = &dedicated_alloc_info;
>>> +        import_handle_info.handleType = strcmp(argv[5], "kmt") ?
>>> +            VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_BIT_KHR :
>>> + VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_KMT_BIT_KHR;
>>> +        import_handle_info.handle = handle;
>>> +        import_handle_info.name = NULL;
>>> +
>>> +        alloc_info.pNext = &import_handle_info;
>>> +
>>> +        vr = vkAllocateMemory(vk_device, &alloc_info, NULL,
>>> &vk_memory);
>>> +        ok(vr == VK_SUCCESS, "vkAllocateMemory failed, VkResult
>>> %d.\n", vr);
>>> +
>>> +        vkFreeMemory(vk_device, vk_memory, NULL);
>>> +        vkDestroyBuffer(vk_device, vk_buffer, NULL);
>>> +        vkDestroyDevice(vk_device, NULL);
>>
>> Any reason not to include the by-name tests here?
>>
>> For that matter, you could add a helper function to test both
>> in-process and cross-process import.
> 
> I don't think a helper function for this would be very helpful, the only
> part you could truly abstract away would be filling import_handle_info
> and import_handle_info, which isn't too much boilerplate to duplicate.

I don't follow. As far as I can see you should be able to perform the 
same tests both in-process and out-of-process—i.e. import by handle and 
by name with vkAllocateMemory(). Hence my comment regarding the by-name 
tests. The calls to vkAllocateMemory look identical to me; am I missing 
something?

>>
>>> +static void test_unique_device(uint8_t driver_uuid[VK_UUID_SIZE],
>>> uint8_t device_uuid[VK_UUID_SIZE],
>>> +        uint32_t extension_count, const char * const
>>> *enabled_extensions,
>>> +        void (*test_func_instance)(VkInstance, VkPhysicalDevice),
>>> void (*test_func)(VkPhysicalDevice))
>>
>> Could we instead use for_each_device_instance(), and match the UUID in
>> the callback?
> 
> I added this in v11, with the one drawback being that we no longer
> ensure that there exists a physical device in the child process that
> matches.

Strikes me as really weird if there isn't; I think it's fair to assume 
that all processes start from the same state ;-)

>>
>>> +            if (test_func_instance)
>>> +                test_func_instance(vk_instance,
>>> vk_physical_devices[i]);
>>> +            else
>>> +                test_func(vk_physical_devices[i]);
>>
>> This isn't new, but it strikes me as really awkward. Can't we just
>> pass a VkInstance to the callback and leave it unused?
> 
> Agreed, but yeah normalizing this will have to come into another patch,
> as I removed test_unique_device in v11.
>>>    # 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.
>>>
>>
>> This doesn't look like it belongs in this patch.
> 
> 
> Ended up keeping this in one patch for v11.
> 
> 



More information about the wine-devel mailing list