Advertising supported Dmabuf modifiers of DRM device

[Ucan, Emre (ADITG/ESB)]

Hi Daniel,

IMO, entire point of having wayland surfaces and buffers to use them for display scanout.

If an application does not want to display its rendered content, it can use surfaceless context or render to texture etc.

Furthermore, we don’t have information in weston about content producing device.
If an application wants to render with gpu, it should be responsibility of the application to query and use gpu friendly modifiers.
We can provide them a list of scanout friendly modifiers which application can use. Then, application should choose a format which would work for rendering and scanout.

Best regards

Emre Ucan
Engineering Software Base (ADITG/ESB)

Tel. +49 5121 49 6937

> -----Original Message-----
> From: Daniel Stone [mailto:daniel at fooishbar.org]
> Sent: Donnerstag, 26. Juli 2018 16:05
> To: Ucan, Emre (ADITG/ESB) <eucan at de.adit-jv.com>
> Cc: wayland <wayland-devel at lists.freedesktop.org>
> Subject: Re: Advertising supported Dmabuf modifiers of DRM device
> 
> 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