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

[Daniel Stone]

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