[Mesa-dev] [PATCH v2] gbm: add support for loading third-party backend (v2)
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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 832 bytes
Desc: not available
More information about the mesa-dev