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

[Georg Lehmann]

On 13.04.21 16:00, Jacek Caban wrote:
> On 13.04.2021 14:58, Joshua Ashton wrote:
>> How do you plan to deal with vkMapMemory with 32on64?
> 
> 
> It's not yet a concern and not really related to module split itself, so 
> I wasn't planning to deal with it (at least not yet).
> 
> 
>> 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? 
> 
> 
> I'm not very familiar with Vulkan yet, but is there something 
> fundamentally wrong with vkGetMemoryFdKHR and mmaping ourselves?
> 

No, the fd return by vkGetMemoryFdKHR is only usable for imports via the
driver.

We could potentially propose an extension which gives us a mappable fd 
or one where we give the driver an address to map the memory to.
Both options probably take a decent amount of work for the driver 
stacks. So if we need an extension it's better to start early on that.
(I have no idea how far away 32on64 is)