On Tue Sep 3 14:53:44 2024 +0000, Jacek Caban wrote:
Could you please summarize what exactly we need to have access to from win32u? The code looks correct. I can't say that the host handle union is particularly pretty, but I think I could be fine with it. I'd still like to understand why something lighter is not enough. For modifying handle mapping, I guess that the reasoning is that surfaces/swapchains may change the underlying actual host handle during their lifetime and we want that reflected in debug callbacks. One alternative approach for that would be to report an opaque win32u handle to winevulkan (so that it's constant from winevulkan's point of view) and have a separate host->win32u opaque unwrapping in win32u. I also recall a problem accessing object's parents outside winevulkan. For that, sharing just specific bits of structs implementing handles could be enough.
* winevulkan needs to access any wrapper host handle (through the vulkan_object->host union), so that it can unwrap in the generated code. * win32u needs to access the wrapper host handle to unwrap them when it calls into the host functions. * win32u needs to access the parent object chain, and the device/instance functions, in order to call the right host functions from its parent device/instance. [^1] * win32u needs to access the instance object tree and lock, to register newly created wrappers as instance objects. To register the mappings it also needs to access the client handle of a wrapper, although for swapchain and surface that's the wrapper itself. [^2]
[^1]: We could selectively expose them in a separate table, but it seems simpler to just expose the full table. It also makes it possible to query more host functions in advance for unix side only extensions, and use the function tables for everything.
[^2]: I don't think the handles would ever change, but being able to register wrappers from win32u makes things simpler because we then don't need a manual function in winevulkan to register the objects, and the winevulkan thunks can call directly into win32u functions.