[Mesa-dev] [PATCH] gbm: add support for loading third-party backend

[Emil Velikov]

On 6 February 2017 at 05:58, Yu, Qiang <Qiang.Yu at amd.com> wrote:
> + David
>
> Hi Emil,
>
>> * With the discussion(s) about liballoc/libgbm2 in motion wouldn't it
>> be better to focus/target it ?
> [yuq] I think this small improvement won't conflict with libgbm2 work
> which is not my current focus. My purpose is getting current mesa co-exist
> with amdgpu-pro. BTW. will libgbm2 land soon?
>
The discussion and prototyping is over at github. Needless to say,
input from everyone is appreciated.

https://github.com/cubanismo/allocator

>> * As-is most/all of the private GBM API/ABI becomes semi public. As
>> such were _really_ want some (ideally all) of the following:
>> - clear definition/split which should and shouldn't be part of the
>> driver backend API
>> - API/ABI tests to catch breakage
>> Note: we have broken the ABI a few times already, but since libgbm and
>> mesa's libEGL should be (are) from the same tree things haven't
>> exploded
> [yuq] Seems same requirement and Nicolai's. I can address them next version.
>
>> * The ImgTec guys were able to tweak their binary which combined with
>> a bit of mesa glue produces a DRI module.
>> This in itself lead of a number of nice improvements and fixes that
>> landed in Mesa. Have you/others considered that option ?
> [yuq] You mean make amdgpu_dri.so a DRI compatible module which can
> be used with the current default GBM DRI backend? But this still need a way
> to select which vendor's DRI module because amdgpu_dri.so overlap support
> cards with radeonsi_dri.so and the current GBM DRI backend always load
> radeonsi_dri.so from a PCIID-DRI table lookup. Also not sure if the ABI is stable
> for different mesa versions? @David what's your opinion?
>
As Michel covered all the questions, just a friendly request:

Do continue to send upstream any patches, that you guys apply on top
of the stack ?

Thanks
Emil