[PATCH 1/4] winevulkan: Use standard CRT memory allocators.

[Joshua Ashton]

On 4/13/21 1:45 PM, 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 at 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.

How do you plan to deal with vkMapMemory with 32on64?

You can't simply mremap that into 32-bit space as the pointer gets 
stored to be deduplicated and may also be stored and used by the Vulkan 
driver:
( 
https://gitlab.freedesktop.org/mesa/drm/-/blob/master/amdgpu/amdgpu_bo.c#L473 
[not amdgpu specific, they all do this, just an example] )

There is also no guarantee that it isn't from a suballocation also so 
the pointer you get may be offset from some other mmap.

There may need to be extensions needed to vkMapMemory with a base 
address + flags, but that still doesn't fully solve the other problems 
unless we forced dedicated allocations for everything and did something 
about the deduping...

This stuff also applies to mapped pointers returned by GL fwiw.

Am I missing something obvious that makes this much simpler than I am 
thinking?

Thanks!
- Joshie 🐸✨

> 
> 
> 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);
> }
> 
> 
> Thanks,
> 
> Jacek
> 
>