[PATCH] dmabuf: get supported dmabuf formats from compositor backend

[Fabien DESSENNE]

Hi,

> -----Original Message-----
> From: Daniel Stone [mailto:daniel at fooishbar.org]
> Sent: vendredi 30 octobre 2015 09:31
> To: Bryce Harrington
> Cc: Fabien DESSENNE; Giulio Camuffo; Vincent ABRIOU; Benjamin Gaignard;
> wayland-devel at lists.freedesktop.org
> Subject: Re: [PATCH] dmabuf: get supported dmabuf formats from
> compositor backend
> 
> Hi,
> 
> On 30 October 2015 at 00:27, Bryce Harrington <bryce at osg.samsung.com>
> wrote:
> > On Tue, Oct 20, 2015 at 08:45:50AM -0700, Bryce Harrington wrote:
> >> On Tue, Oct 20, 2015 at 04:54:30PM +0200, Fabien Dessenne wrote:
> >> > Add the possibility for the compositor backend to provide with the
> >> > list of supported pixel formats for dmabuf-based buffers.
> >> > This information is used by linux_dmabuf to inform clients when
> binding.
> >> >
> >> > Signed-off-by: Fabien Dessenne <fabien.dessenne at st.com>
> >>
> >> Reviewed-by <bryce at osg.samsung.com>
> >>
> >> There's not a way to verify the list is getting sent across to the
> >> client is there?
> >
> > Also, patch no longer applies since e3c0d8af.
> >
> > I'd like to better understand what this is going to be used for,
> > before landing it.  Another R-b on this would be nice as well; Giulio
> > perhaps you could give this patch a review?
> 
> Hm, to be honest I'd prefer this not land just now, or like this.
> 
> dmabuf usage in compositor-drm is just an optimisation, where the fallback
> path is through gl-renderer. Anything gl-renderer doesn't support, we
> essentially can't display.

Maybe this is not always true : I use a forked version of compositor-drm
(I plan to upstream some patches later) where the dmabuf buffers are
displayed by the DRM planes: these buffers are not used by gl-renderer.

This is a typical optimization use case: video playback frames being sent
as dmabuf buffer to the compositor, and rendered without any copy
through a DRM plane.

Now, back to the proposed patch: in my proposal building the list of
dmabuf formats is delegated to the backend, not built by the compositor
itself.
Not a big change and it does not solve the "EGL dmabuf formats" issue
but there are two improvements:
1/ IMHO the supported formats are backend-dependent, so this patch
makes some sense here.
2/ Depending on the backend implementation, the list of formats may
be successfully built: this is the case with the compositor I use as it does
not use gl-renderer for dmabuf buffers.

> Those formats are what we need to send to the
> compositor (possibly with the intersection between gl-renderer and
> compositor-drm marked as preferred), but right now, as the comment notes,
> we lack a way to query this through EGL. This is being worked on though.

Good news! Do you know if there is any schedule for this?

By the way, I think that my proposed patch and this EGL future patch
are not incompatible: as explained, EGL is not the only dmabuf consumer:
DRM plane is another consumer. At the end the format list shall be built
by the backend, not by the compositor.

Please, let me know your feedback.

Fabien

> 
> Cheers,
> Daniel