libdrm_amdgpu being forked and merged into Mesa

[Bas Nieuwenhuizen]

On Fri, Oct 25, 2024 at 11:21 AM Michel Dänzer <michel.daenzer at mailbox.org>
wrote:

> On 2024-10-24 17:08, Marek Olšák wrote:
> > We don't need to share the same VMID between ROCm and Mesa. We don't
> > need to share the same driver FD between ROCm and Mesa either. It will
> > be like having 2 different processes, and that should always work.
>
> Per
> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31756#note_2626236,
> does anything prevent the application from passing the same DRM file
> description (doesn't need to be the same *descriptor*) to separate drivers?
> (Not sure it can even pass a DRM fd to ROCm, surely can e.g. to radeonsi &
> AMDVLK though)
>

In RADV the app has no way to pass in a drm fd, there is only a way to
query the major/minor from the fd (
https://registry.khronos.org/vulkan/specs/1.3-extensions/html/chap55.html#VK_EXT_physical_device_drm).
Surely AMDVLK has no way to pass in fds either?

Even if you can for radeonsi through e.g. gbm (can you?), I believe most
vendors in mesa do not do this deduping, so why would we need to be the one
vendor that actually protects against this (not to mention that it would
mean that any users would need to use libdrm_amdgpu. Given that the most
likely combination of GBM with shared fd/handle stuff is kernel modesetting
and nobody uses libdrm_amdgpu with that, having a shared libdrm_amdgpu
would not help there)

>
> I guess one way to avoid this issue would be for Mesa to always use a
> different DRM file description internally, then it would have to share
> buffers with the DRM file description passed in by the application as
> needed though.
>
>
> --
> Earthling Michel Dänzer       \        GNOME / Xwayland / Mesa developer
> https://redhat.com             \               Libre software enthusiast
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20241025/45eced85/attachment.htm>