Advertising supported Dmabuf modifiers of DRM device

[Daniel Stone]

Hi Emre,

On Thu, 26 Jul 2018 at 14:54, Ucan, Emre (ADITG/ESB)
<eucan at de.adit-jv.com> wrote:
> We are currently querying supported modifiers only from gpu drivers via EGL_EXT_image_dma_buf_modifiers extension.
> But we should also query and advertise modifiers which are supported by DRM device. We are already getting this information via IN_FORMATS of a drm plane.
>
> IMO, it is not enough to just query and advertise every supported format and modifiers combination to applications.
> Applications can easily choose a format, which is only supported by GPU device and not DRM device. In the end, this would force us to use gpu for composition.
> We should mark modifiers of DRM device as preferred ones. This would require modifying linux-dmabuf protocol.

I agree; I've had the same thought. I think we want to do something
more nuanced than this though.

Say for example the display controller only supports linear formats.
Doing a clear intersection would mean all clients rendering to linear
at a performance loss, even if they are not candidates for display
scanout. What we would want is a more dynamic hint from the
compositor: to tell clients to prefer scanout-compatible formats where
they are useful, but else to just pick the best GPU format.

I think the best thing to do would be to make a new dmabuf interface
which takes a surface as a creation parameter, where the compositor
would update the per-surface interface with preferred modifiers. Since
we don't know preference order between modifiers, rather than
enforcing any order, the best thing to do would be to break it into
tranches: send one set of modifiers which are both GPU + scanout
compatible and ask the client to preferentially allocate from that
set, then send a second GPU-only set which the client may fall back to
if it cannot render to the first set.

I don't have plans to work on that right now - I'd happily review any
patches or have a more detailed discussion though! - but as part of
the debug work I sent out last week, I am planning to expose the
current scanout status of surfaces to the core compositor. For
example, 'is on a plane now', vs. 'can never be on a plane because of
compositor configuration (transform/alpha/etc)' vs. 'could maybe be on
a plane but is not allowed (couldn't find suitable plane, kernel
rejected, etc)' vs. 'could be on a plane but client needs to change
(modifiers, transform, etc)'. That should be quite useful for this
work as well.

Cheers,
Daniel