[PATCH RFC wayland-protocols] unstable/linux-dmabuf: add wp_linux_dmabuf_device_hint

[Philipp Zabel]

On Thu, 2018-11-01 at 17:04 +0000, Daniel Stone wrote:
> Hi Simon,
> Thanks a lot for taking this on! :)
> 
> On Thu, 1 Nov 2018 at 16:45, Simon Ser <contact at emersion.fr> wrote:
> > This commit introduces a new wp_linux_dmabuf_device_hints object. This object
> > advertizes a preferred device via a file descriptor and a set of preferred
> > formats/modifiers.
> 
> s/advertizes/advertises/g (including in the XML doc)
> 
> I also think this would be better called
> wp_linux_dmabuf_surface_hints, since the change over the dmabuf
> protocol is that it's surface-specific.
> 
> > +  <interface name="zwp_linux_dmabuf_device_hints_v1" version="4">
> > +    <description summary="dmabuf device hints">
> > +      This object advertizes dmabuf hints for a surface. Such hints include the
> 
> *advertises
> 
> > +    <event name="primary_device">
> > +      <description summary="preferred primary device">
> > +        This event advertizes the primary device that the server prefers. There
> > +        is exactly one primary device.

Which device should this be if the scanout engine is separate from the
render engine (e.g. IPU/imx-drm and GPU/etnaviv on i.MX6)

[...]
> > +    <event name="modifier">
> > +      <description summary="preferred buffer format modifier">
> > +        This event advertises the formats that the server prefers, along with
> > +        the modifiers preferred for each format.
> > +
> > +        For the definition of the format and modifier codes, see the
> > +        wp_linux_buffer_params::create request.
> > +      </description>
> > +      <arg name="format" type="uint" summary="DRM_FORMAT code"/>
> > +      <arg name="modifier_hi" type="uint"
> > +           summary="high 32 bits of layout modifier"/>
> > +      <arg name="modifier_lo" type="uint"
> > +           summary="low 32 bits of layout modifier"/>
> > +    </event>
> 
> I think we want another event here, to group sets of modifiers
> together by preference.
> 
> For example, say the surface could be directly scanned out, but only
> if it uses the linear or X-tiled modifiers. Our surface-preferred
> modifiers would be LINEAR + X_TILED. However, the client may not be
> able to produce that combination. If the GPU still supports Y_TILED,
> then we want to indicate that the client _can_ use Y_TILED if it needs
> to, but _should_ use LINEAR or X_TILED.
> 
> DRI3 implements this by sending sets of modifiers in 'tranches', which
> are arrays of arrays, which in this case would be:
> tranches = {
>   [0 /* optimal */] = {
>     { .format = XRGB8888, .modifier = LINEAR }
>     { .format = XRGB8888, .modifier = X_TILED }
>   },
>   [1 /* less optimal */] = {
>     { .format = XRGB8888, .modifier = Y_TILED }
>   }
> }
> 
> I imagine the best way to do it with Wayland events would be to add a
> 'marker' event to indicate the border between these tranches. So we
> would send:
>   modifier(XRGB8888, LINEAR)
>   modifier(XRGB8888, X_TILED)
>   barrier()
>   modifier(XRGB8888, Y_TILED)
>   barrier()
>   done()
> 
> For a simple 'GPU composition or scanout' case, this would only be two
> tranches, which are 'most optimal' and 'fallback'. For multiple GPUs
> though, we could end up with three tranches: scanout-capable,
> same-GPU-composition, or cross-GPU-composition. Similarly, if we take
> media recording into account, we could end up with more than two
> tranches.
> 
> What do you think?

What about contiguous vs non-contiguous memory?

On i.MX6QP (Vivante GC3000) we would probably want the client to always
render DRM_FORMAT_MOD_VIVANTE_SUPER_TILED, because this can be directly
read by both texture samplers (non-contiguous) and scanout (must be
contiguous).

On i.MX6Q (Vivante GC2000) we always want to use the most efficient 
DRM_FORMAT_MOD_VIVANTE_SPLIT_SUPER_TILED, because neither of the
supported render formats can be sampled or scanned out directly.
Since the compositor has to resolve into DRM_FORMAT_MOD_VIVANTE_TILED
(non-contiguous) for texture sampling or DRM_FORMAT_MOD_LINEAR
(contiguous) for scanout, the client buffers can always be non-
contiguous.

On i.MX6S (Vivante GC880) the optimal render format for texture sampling
would be DRM_FORMAT_MOD_VIVANTE_TILED (non-contiguous) and for scanout
DRM_FORMAT_MOD_VIVANTE_SUPER_TILED (non-contiguous) which would be
resolved into DRM_FORMAT_MOD_LINEAR (contiguous) by the compositor.

All three could always handle DRM_FORMAT_MOD_LINEAR (contiguous) client
buffers for scanout directly, but those would be suboptimal if the
compositor decides to render on short notice, because the client would
have already resolved into linear and then the compositor would have to
resolve back into a texture sampler tiling format.

regards
Philipp