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

[Jacek Caban]

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?


Thanks,

Jacek