On Mon, Oct 28, 2024 at 6:51 AM Michel Dänzer <michel.daen...@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.daen...@mailbox.org > >>> <mailto:michel.daen...@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.daen...@mailbox.org <mailto:michel.daen...@mailbox.org> > >>> <mailto:michel.daen...@mailbox.org <mailto:michel.daen...@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
