On 4/13/21 3:00 PM, 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?
Several things:
There may be certain usage restrictions on memory that is exportable this way.
It'll require a dedicated allocation for everything and we don't know ahead of the time buffer/image to associate it with (the app may allocate the memory first, then bind it to the image/buffer) so we are kinda SOL there without stupid tracking. (!)
Sparse binding won't work due to requiring a dedicated allocation. (!)
It also can also change how residency is dealt with (ie. local bo list vs global bo list).
There may also be performance implications wrt residency and image compression given the assumption seems to be "this is for interprocess or interdevice sharing."
There may be video memory fragmentation from disallowing suballocations and requiring dedicated allocations for every resource also.
- Joshie 🐸✨
Thanks,
Jacek