libdrm_amdgpu being forked and merged into Mesa

[Bas Nieuwenhuizen]

On Mon, Oct 28, 2024 at 11: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.
>

Yeah that won't conflict.

>
>
> --
> 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/20241028/2e37e5ce/attachment.htm>