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?
I do remember that AMDs closed source OpenGL drivers relied somehow on
this when we initially created the whole stuff, but I'm not sure how
exactly and if that also applies to other open source use cases.
Thanks,
Christian.
