libdrm_amdgpu being forked and merged into Mesa

[Marek Olšák]

On Mon, Oct 28, 2024 at 6:51 AM Michel Dänzer
<michel.daenzer at mailbox.org> wrote:
>
> On 2024-10-28 11:27, Christian König wrote:
> > Am 28.10.24 um 11:13 schrieb Michel Dänzer:
> >> On 2024-10-25 19:07, Bas Nieuwenhuizen wrote:
> >>> On Fri, Oct 25, 2024 at 6:57 PM Michel Dänzer <michel.daenzer at mailbox.org <mailto:michel.daenzer at mailbox.org>> wrote:
> >>>      On 2024-10-25 17:57, Bas Nieuwenhuizen wrote:
> >>>      > On Fri, Oct 25, 2024 at 4:36 PM Michel Dänzer <michel.daenzer at mailbox.org <mailto:michel.daenzer at mailbox.org> <mailto:michel.daenzer at mailbox.org <mailto:michel.daenzer at mailbox.org>>> wrote:
> >>>      >     On 2024-10-25 12:18, Bas Nieuwenhuizen wrote:
> >>>      >
> >>>      >     > (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)
> >>>      >
> >>>      >     Not sure what you mean here, Wayland compositors use radeonsi with KMS.
> >>>      >
> >>>      > That is what I mean, since they use KMS directly, anything that radeonsi does wrt using or not using libdrm_amdgpu doesn't impact them.
> >>>
> >>>      Still not following. Wayland compositors generally use the same DRM file description for radeonsi (via the EGL GBM platform) and KMS.
> >>>
> >>>
> >>> And they will after this change, i.e. this is not a problem wrt this change.
> >> I'm not saying it is, it just seems to contradict the point you're making above. Maybe I'm being dense though, or maybe it just doesn't matter, feel free to drop it.
> >
> > Michel can you elaborate a bit more on how the EGL GBM platform and KMS play together?
>
> How it generally works in Wayland compositors:
>
> The compositor opens /dev/dri/card* (or receives a corresponding fd e.g. from logind) and passes the resulting fd to gbm_create_device. It then passes the resulting struct gbm_device pointer as the native display handle when creating the EGL GBM platform display. The compositor then uses the same fd for KMS ioctls.
>
> radeonsi currently uses a duplicate of that fd internally by default, i.e. it uses the same DRM file description for allocating BOs etc. that the compositor uses for KMS.
>
> What I'm worrying about is that if Mesa stops using libdrm_amdgpu, and if it's possible for the same DRM file description to be used for another API context (Vulkan, OpenCL, ...) using another driver, the two contexts would certainly run into errors due to conflicting GPUVM ranges.
>
> It's looking like that might not actually be possible though.

If that ever happened, Mesa could reopen the FD to get a clean GPUVM.

Basically the only thing that can block this is if there is an issue
that doesn't have a workaround, including ugly workarounds.

Marek