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#L47... [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