On Mon, Oct 28, 2024 at 11: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. > Yeah that won't conflict. > > > -- > Earthling Michel Dänzer \ GNOME / Xwayland / Mesa developer > https://redhat.com \ Libre software enthusiast >
