libdrm_amdgpu being forked and merged into Mesa

[Christian König]

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?

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.