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

[Fabien DESSENNE]

Hi,
> -----Original Message-----
> From: Daniel Stone [mailto:daniel at fooishbar.org]
> Sent: lundi 2 novembre 2015 12:44
> To: Fabien DESSENNE
> Cc: Bryce Harrington; 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 2 November 2015 at 09:39, Fabien DESSENNE <fabien.dessenne at st.com>
> wrote:
> >> On 30 October 2015 at 00:27, Bryce Harrington
> <bryce at osg.samsung.com>
> >> wrote:
> >> > 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.
> 
> Yeah, of course. In your confined usecase this will always be true, but in
> general we cannot rely on it being true: we will always need a fallback to gl-
> renderer. Since gl-renderer is the fallback, we need to limit the exposed
> formats to what it can display, for the general case.
> 
> > 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.
> 
> I'd say more renderer-dependent than backend-dependent, as below.
> (Again, talking about the _general_ upstream case, not the specific usecase
> you have in a closed - in the engineering rather than freedom sense -
> system.)
> 
> >> 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?
> 
> Unfortunately Khronos work is necessarily opaque, but it is being actively
> worked on and is a relatively straightforward change, so.
> 
> > 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.
> 
> Yes, but the problem is that while there are a million different ways we can
> require EGL but not KMS (recording/screenshot, view transformation,
> partially-occluded buffer, etc etc), and if you end up in a situation where you
> both require EGL, but also have a buffer you cannot display through EGL, the
> result is not pretty.
> 
> I don't think your patch is in any way wrong for your usecase, but
> unfortunately it is very much unsuitable for upstream, as it does break
> everything listed above.
> 
> My preference, as stated, would be to generate a list of formats/modifiers
> from the renderer (in practical terms, always EGL), then pass this list to the
> backend for filtering, which would essentially just be adding 'preferred' flags
> to formats which could be pulled out to hardware planes.
> 
> Cheers,
> Daniel

OK, so let's wait for the EGL update and see how we can implement all of this.
My proposed patch can be abandoned.
BR,
Fabien