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

[Emil Velikov]

On 26 May 2016 at 11:28, Philipp Zabel <p.zabel at pengutronix.de> wrote:
> Hi Emil,
>
> Am Mittwoch, den 25.05.2016, 23:42 +0100 schrieb Emil Velikov:
> [...]
>> 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.
>
> Thank you for the explanation. What is the reason for this indirection?
>
The idea is that in order for one to use GBM, alone, you do need a
dri_screen at the bare minimum. That's how you interact with the dri
module probing/querying various things. At the same time as you use
both APIs in the same program you'd want those to be shared, as
otherwise, from a dri module point of view, you'll be having two
separate users/clients. Which makes it harder/impossible to implement
some some extensions such as EGL_EXT_image_dma_buf_import.

^^ Is my non-expert take on it, so it might be a bit off.

>> 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?
>
> I didn't think of that. How do you envision this ABI check to look like?
> gbm(_drm)_device currently don't have any version fields and I'm not
> sure how a new gbm backend would check for an old libEGL.
> The first thing that comes to mind is a simple ABI version number to be
> incremented in lock-step between libgbm and libEGL.
>
Sadly there's nothing we can do for old libgbm/libEGL. The proposed
approach, on the other hand sounds great imho.

Thanks
Emil