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

Eric Anholt eric at anholt.net
Fri Apr 14 18:25:11 UTC 2017


Emil Velikov <emil.l.velikov at gmail.com> writes:

> On 14 April 2017 at 10:38, Yu, Qiang <Qiang.Yu at amd.com> wrote:
>>
>> Hi Emil,
>>
>>> What happened with the idea of reusing your existing amdgpu_dri.so ?
>>> As mentioned before the DRI loader (libgbm) <> DRI driver (foo_dri.so)
>>> interface is stable, so things should just work.
>> Sorry for the late reply. I've asked our amdgpu_dri.so team for this, they
>> seems have no interest and resource for implementing this interface.
>> So the only option left for me is to reuse our current gbm_amdgpu.so
>> and upstream libgbm.so changes if possible.
>>
> Quick look through `strings amdgpu_dri.so' shows that you guys are
> missing the DRI2_FENCE and DRI2_INTEROP extensions.
> Both of which are fairly trivial to implement and it will be the better option.
>
> Doing so will give you:
>  - acknowledgement to the good work done by Marek (your colleague from
> the other end of the org chart)
>  - less binaries to manage - remove gbm_amdgpu.so
>  - less code to manage - remove many of the libEGL and libgbm patches
> that you have on top of Mesa.
>
> The proposed GBM interface end up broken rather often since:
>  - there's no open-source users that people test
>  - we have no tests to catch regressions :-\
>
> TL;DR; You really want to implement the missing functionality in
> amdgpu_dri.so - its more robust and it will reduce the code you have
> to maintain.

I agree with Emil here.  Building ABI-stable interfaces is hard and
error-prone, and the DRI interface and the GL interface are where where
we do that already.  We shouldn't introduce another ABI at the GBM
backend level.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170414/c15258a1/attachment.sig>


More information about the mesa-dev mailing list