On 25 May 2016 at 15:46, Philipp Zabel <p.za...@pengutronix.de> wrote: > Am Mittwoch, den 25.05.2016, 16:01 +0200 schrieb Marek Olšák: >> On Wed, May 25, 2016 at 3:44 PM, Philipp Zabel <p.za...@pengutronix.de> >> wrote: >> > Am Dienstag, den 10.05.2016, 17:35 +0200 schrieb Philipp Zabel: >> >> To support the EGL_KHR_fence_sync extension on the DRM EGL platform, >> >> add the DRI2 fence extension to the dri_core_extensions match table. >> >> >> >> Signed-off-by: Philipp Zabel <p.za...@pengutronix.de> >> > >> > Gentle ping. Is this about the right way to enable the >> > EGL_KHR_fence_sync extension on DRM EGL platforms? >> >> Unlikely. Where are the __DRI2fenceExtension callbacks implemented? > > The callbacks are implemented and added to the dri_screen_extensions[] > array in src/gallium/state_trackers/dri/dri2.c. The array is assigned to > the __DRIscreen member "extensions" in dri2_init_screen(). > > dri_screen_create_dri2() in src/gbm/backends/dri/gbm_dri.c > then obtains the extensions array via dri->core->getExtensions() and > binds selected extensions to the gbm_dri_device according to the > placement information in the dri_core_extensions[] array. > This was already done for the flush and image extensions, so I have > similarly added a fence extension pointer to the gbm_dri_device and an > entry to dri_core_extensions to have it initialized from the dri2 > extension array that already contained the fence extension. > > dri2_initialize_drm() in src/egl/drivers/dri2/platform_drm.c > then copies the extension pointers from the gbm_dri_device > dri2_dpy->gbm_dri into the dri2_egl_display dri2_dpy proper. > This also was already done for a few other extensions, among them image > and flush, and the dri2_egl_display already has a fence pointer that I > used to assign to the gbm_dri_device's new fence pointer. > > dri2_setup_screen() in src/egl/drivers/dri2/egl_dri2.c later checks > dri2_dpy->fence to enable the extension. > Or in other words, in case of egl + gbm, egl inherits the screen from the gbm device. As such platform_gbm does not call the core egl setup function, dri2_create_screen (like everyone else does x11, wayland...) but only the follow-up dri2_setup_screen.
That said this patch will break things when using old libgbm and new libEGL and vice-versa. Sadly there's no way around it atm. Thus can we get an ABI check so that in the future we printout a message and abort early, instead of crashing in spectacular ways down the line? Thanks Emil _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev