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

[Joshua Ashton]

On 4/13/21 3:41 PM, Georg Lehmann wrote:
> 
> 
> 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.

I had not considered that the memory FD returned may not actually be 
mappable.
I guess the spec doesn't provide any guarantees other than "you can 
import this into another VkDeviceMemory" on closer look.

I guess that's another concern... 🐸

- Joshie 🐸✨

> 
> 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)