[Mesa-dev] [PATCH 1/2] gbm: Enable DRI2 fence extension in the GBM DRI backend

[Emil Velikov]

On 25 May 2016 at 15:46, Philipp Zabel <p.zabel at 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.zabel at 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.zabel at 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