On 18 August 2016 at 18:28, Rob Clark <robdcl...@gmail.com> wrote: > On Thu, Aug 18, 2016 at 8:45 AM, Emil Velikov <emil.l.veli...@gmail.com> > wrote: >> On 16 August 2016 at 18:01, Rob Clark <robdcl...@gmail.com> wrote: >>> I noticed that fence extension wasn't exposed for drm/gbm, which sort >>> of defeats the purpose of using fence fd's for synchronizing rendering >>> and atomic pageflip. >>> >> Afaict this is a slightly more complete version of Philipp's patch. >> >> While my earlier suggestion still stands, I should have mentioned that >> it's not a show stopper for this patch. >> Namely: we really want a way to check and bail out on ABI mismatch >> between libEGL and libgbm. > > btw, I dug up Philipp's original patch/thread.. I didn't realize that > someone had already done this (would have saved me some time ;-)) > > As far as ABI mismatch, we don't currently ship libEGL/libgbm > separately. Indeed we don't ship anything - distros do ;-) And they (only sometimes, I hope,) do strange things without seeking information/confirmation.
> And there doesn't appear to be any versioning scheme so > far. (Although if we do split out libgbm from mesa, that would be a > good thing to add.) > True and true ;-) > So I'm inclined to punt on the version check (and actually not > entirely sure it is even possible). > As you pointed out above we do want it sooner or later. I do suggest doing it earlier than when it's too late. Here's an idea how it could be done: - define a couple of version/abi macros - one of EGL and another for GBM. - store the GBM one in struct gbm_device or gbm_dri_device (directly or use a vfunc which returns the version) - upon inheriting (in dri2_initialize_drm) from gbm check against the local EGL version. - bail out on mismatch. - stick a juicy comment on top of the respective struct(s) "do not move because .,." or alike. TL;DR; Considering that things work with the (updated) patch don't let the ABI check stop you. But _please_ don't ignore/leave it until it's too late. Thanks Emil _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev