vm binding interfaces and parallel with mmap

[Christian König]

Am 24.08.22 um 18:14 schrieb Jason Ekstrand:
> On Mon, Aug 22, 2022 at 8:27 AM Christian König 
> <christian.koenig at amd.com> wrote:
> [SNIP]
>
>     >> I suppose it also asks the question around paralleling
>     >>
>     >> fd = open()
>     >> ptr = mmap(fd,)
>     >> close(fd)
>     >> the mapping is still valid.
>     >>
>     >> I suppose our equiv is
>     >> handle = bo_alloc()
>     >> gpu_addr = vm_bind(handle,)
>     >> gem_close(handle)
>     >> is the gpu_addr still valid does the VM hold a reference on the
>     kernel
>     >> bo internally.
>     > For Vulkan it looks like this is undefined and the above is not
>     necessary:
>     >
>     > "It is important to note that freeing a VkDeviceMemory object with
>     > vkFreeMemory will not cause resources (or resource regions) bound to
>     > the memory object to become unbound. Applications must not access
>     > resources bound to memory that has been freed."
>     > (32.7.6)
>
>
> I'm not sure about this particular question.  We need to be sure that 
> maps get cleaned up eventually.  On the one hand, I think it's 
> probably a valid API implementation to have each mapped page hold a 
> reference similar to mmap and have vkDestroyImage or vkDestroyBuffer 
> do an unmap to clean up the range.  However, clients may be surprised 
> when they destroy a large memory object and can't reap the memory 
> because of extra BO references they don't know about.  If BOs unmap 
> themselves on close or if we had a way to take a VM+BO and say "unmap 
> this BO from everywhere, please", we can clean up the memory pretty 
> easily.  Without that, it's a giant PITA to do entirely inside the 
> userspace driver because it requires us to globally track every 
> mapping and that means data structures and locks.  Yes, such an ioctl 
> would require the kernel to track things but the kernel is already 
> tracking everything that's bound, so hopefully it doesn't add much.

For both amdgpu as well as the older radeon mapping a BO does *not* grab 
a reference to it. Whenever a BO is released all it's mappings just 
disappear.

We need to keep track of the mappings anyway to recreate page tables 
after (for example) suspend and resume, so that isn't any overhead.

Regards,
Christian.

>
> --Jason
>
>     Additional to what was discussed here so far we need an array on
>     in and
>     out drm_syncobj for both map as well as unmap.
>
>     E.g. when the mapping/unmapping should happen and when it is
>     completed
>     etc...
>
>     Christian.
>
>     >
>     >
>     >> Dave.
>     >>> Dave.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20220825/f77f48c8/attachment.htm>