On 6 February 2017 at 05:58, Yu, Qiang <qiang...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
