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

Fabien DESSENNE fabien.dessenne at st.com
Mon Nov 2 05:00:18 PST 2015


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


More information about the wayland-devel mailing list