Emil Velikov <emil.l.veli...@gmail.com> writes: > On 14 April 2017 at 10:38, Yu, Qiang <qiang...@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.
signature.asc
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
