+ 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? > * 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? Regards, Qiang _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
