I'm starting to consider wrapping more vulkan objects in win32u, I think it'll be useful to implement compositing (and incidentally shared resources with interop with the D3DKMT/NtGdi API), starting with nulldrv/offscreen swapchains. Alternatively we could export more functions from win32u and keep all the wrappers in winevulkan, but having access to win32u internals with a generic vulkan object wrapping mechanism seems to be more interesting.
Right now this is not very convenient because the vulkan object hierarchy is only available in winevulkan. This introduces shared structures and API between win32u and winevulkan so they can manipulate the wrapped objects from both side. The interface would only expose what is necessary, ie: the object hierarchy and wrapped handles, the instance and device functions, and the objects rbtree for debugging, so win32u can insert its wrapper there as well.
After moving the surface and swapchain wrappers to win32u, the interface would look like this: https://gitlab.winehq.org/rbernon/wine/-/blob/65ca1280d46a2dff792e298c22242… (I pushed a complete WIP branch to https://gitlab.winehq.org/rbernon/wine/-/commits/wip/vulkan-win32u-driver?r…). We can also consider moving all the winevulkan wrappers to win32u but it's not clear whether it's necessary or desirable, and we can also do that later using this interface.
--
v6: winevulkan: Introduce a new vulkan_physical_device base structure.
winevulkan: Introduce a new vulkan_instance base structure.
winevulkan: Hoist physical device array and client instance handle.
winevulkan: Name wine_instance parameters and variables more consistently.
winevulkan: Move vulkan_client_object header to wine/vulkan_driver.h.
winevulkan: Generate ALL_VK_(DEVICE|INSTANCE)_FUNCS in wine/vulkan.h.
winevulkan: Get rid of the instance/device funcs structs.
win32u: Use PFN_* typedefs for vulkan function pointers.
winevulkan: Add missing wine_vkGetPhysicalDeviceSurfaceFormatsKHR manual wrapper.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6427
I'm starting to consider wrapping more vulkan objects in win32u, I think it'll be useful to implement compositing (and incidentally shared resources with interop with the D3DKMT/NtGdi API), starting with nulldrv/offscreen swapchains. Alternatively we could export more functions from win32u and keep all the wrappers in winevulkan, but having access to win32u internals with a generic vulkan object wrapping mechanism seems to be more interesting.
Right now this is not very convenient because the vulkan object hierarchy is only available in winevulkan. This introduces shared structures and API between win32u and winevulkan so they can manipulate the wrapped objects from both side. The interface would only expose what is necessary, ie: the object hierarchy and wrapped handles, the instance and device functions, and the objects rbtree for debugging, so win32u can insert its wrapper there as well.
After moving the surface and swapchain wrappers to win32u, the interface would look like this: https://gitlab.winehq.org/rbernon/wine/-/blob/65ca1280d46a2dff792e298c22242… (I pushed a complete WIP branch to https://gitlab.winehq.org/rbernon/wine/-/commits/wip/vulkan-win32u-driver?r…). We can also consider moving all the winevulkan wrappers to win32u but it's not clear whether it's necessary or desirable, and we can also do that later using this interface.
--
v5: winevulkan: Introduce a new vulkan_physical_device base structure.
winevulkan: Introduce a new vulkan_instance base structure.
winevulkan: Pass physical device array params to some helpers.
winevulkan: Name wine_instance parameters and variables more consistently.
winevulkan: Move vulkan_client_object header to wine/vulkan_driver.h.
winevulkan: Generate ALL_VK_(DEVICE|INSTANCE)_FUNCS in wine/vulkan.h.
winevulkan: Get rid of the instance/device funcs structs.
win32u: Use PFN_* typedefs for vulkan function pointers.
winevulkan: Add missing wine_vkGetPhysicalDeviceSurfaceFormatsKHR manual wrapper.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6427
The cast there seems safe from looking at the struct definitions, and is also used elsewhere in the codebase (dlls/kernelbase/locale.c:5682).
It's obviously not a full implementation, but works well enough for my usecase and maybe others as well.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4851
I'm starting to consider wrapping more vulkan objects in win32u, I think it'll be useful to implement compositing (and incidentally shared resources with interop with the D3DKMT/NtGdi API), starting with nulldrv/offscreen swapchains. Alternatively we could export more functions from win32u and keep all the wrappers in winevulkan, but having access to win32u internals with a generic vulkan object wrapping mechanism seems to be more interesting.
Right now this is not very convenient because the vulkan object hierarchy is only available in winevulkan. This introduces shared structures and API between win32u and winevulkan so they can manipulate the wrapped objects from both side. The interface would only expose what is necessary, ie: the object hierarchy and wrapped handles, the instance and device functions, and the objects rbtree for debugging, so win32u can insert its wrapper there as well.
After moving the surface and swapchain wrappers to win32u, the interface would look like this: https://gitlab.winehq.org/rbernon/wine/-/blob/65ca1280d46a2dff792e298c22242… (I pushed a complete WIP branch to https://gitlab.winehq.org/rbernon/wine/-/commits/wip/vulkan-win32u-driver?r…). We can also consider moving all the winevulkan wrappers to win32u but it's not clear whether it's necessary or desirable, and we can also do that later using this interface.
--
v4: winevulkan: Introduce a new vulkan_physical_device base structure.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6427
On Tue Nov 26 09:45:58 2024 +0000, Michele Dionisio wrote:
> I remove the check as you request. but in my opinion now the test fails
> on linux and windows too
they fail on linux when run from a unix console, I don't see failure on windows
you can add the attached patch to work around this
[patch-timeout](/uploads/e311af5c8318f780aad5ff66a714ba26/patch-timeout)
I let you fix the remaining failure
Note: since MR!6888 has been merged, you don't need to take care of returning STATUS_CONTROL_C_EXIT, it's done by the default handlers now
Note2: the SetStdHandle() call between FreeConsole() and AllocConsole() in this patch looks suspicious : it's not needed under Windows, so likely another Wine bug (but it's needed for now, esp. when running the tests under Wine from a unix console)
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6869#note_88940