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