Thanks for the explanation!
On 13.04.21 14:45, Jacek Caban wrote:
Hi Georg,
On 13.04.2021 09:52, Georg Lehmann wrote:
On 13.04.21 00:53, Jacek Caban wrote:
Signed-off-by: Jacek Caban jacek@codeweavers.com
In preparation for split PE/.so parts.
dlls/winevulkan/make_vulkan | 8 +-- dlls/winevulkan/vulkan.c | 111 ++++++++++++++++++------------------ 2 files changed, 60 insertions(+), 59 deletions(-)
Hi,
could you give an overview of all the changes that you are planning to make for the .so/PE split? winevulkan had quite a few contributors over the past years, and I think those who aren't part of codeweavers aren't super familiar with wine internals. I would certainly like to know more about the implications of this rework.
Sure. Generally, Wine is moving towards stricter separation between PE/Windows side and Unix side. This already has a great effect on compatibility with stuff like API hooking, DRMs, debuggers etc. In the future, this will be also needed for stuff like 32on64.
In practice, in its current shape, it means that winevulkan should be built as a PE file. As such, it may do Windows calls, but not direct Unix calls. For Unix calls, it will have a separated .so library. .so library exports its internal interface to PE side and can do any Unix calls. However, .so part should avoid calling PE side, so it's very limited to what win32 APIs it can use. #pragma makedep unix controls which side given source file lives on.
In case of winevulkan, the transition is quite straightforward. Most of the code can live in .so part (namely, vulkan.c and vulkan_thunks.c). There are a few Windows calls that we need to be moved out of there and this series moves most of win32 calls out of vulkan.c. We will also need dispatch tables and exported functions on PE part, so that will need another thin layer of thunking. Using wine_vkResetEvent as an example, in my WIP tree, there is a new PE function for PE side:
VkResult WINAPI wine_vkResetEvent(VkDevice device, VkEvent event) { return unix_funcs->p_vkResetEvent(device, event); }
That's what applications can see, while unix_funcs->p_vkResetEvent points to the existing vkResetEvent thunk living in .so part:
VkResult WINAPI unix_vkResetEvent(VkDevice device, VkEvent event) { TRACE("%p, 0x%s\n", device, wine_dbgstr_longlong(event)); return device->funcs.p_vkResetEvent(device->device, event); }
This sounds like it could potentially negatively affect performance up to a measurable degree due to another indirection. But I guess there's no way to have a function in the unix library (with the correct calling convention and everything) and to return that from the PE in vkGet*ProcAddr?
Thanks,
Georg