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

[Pekka Paalanen]

On Thu, 1 Nov 2018 17:04:51 +0000
Daniel Stone <daniel at fooishbar.org> 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.
> > +      </description>
> > +      <arg name="fd" type="fd" summary="device file descriptor"/>
> > +    </event>  
> 
> I _think_ this might want to refer to separate objects.
> 
> When we receive an FD from the server, we don't know what device it
> refers to, so we have to open the device to probe it. Opening the
> device can be slow: if a device is in a low PCI power state, it can be
> a couple of seconds to physically power up the device and then wait
> for it to initialise before we can interrogate it.

Hi,

wouldn't drmGetDevice2() with flags=0 gets us everything needed without
waking up a sleeping PCI device?

I just read it from Emil:
https://lists.freedesktop.org/archives/mesa-dev/2018-October/207447.html

> 
> One way around this would be to have a separate wp_linux_dmabuf_device
> object, lazily sent as a new object in an event by the root
> wp_linux_dmabuf object, with the per-surface hints then referring to a
> previously-sent device. This would allow clients to only probe each
> device once per EGLDisplay, rather than once per EGLSurface.

This optimization does sound attractive to me in any case.

> 
> > +    <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,

Combination? I thought modifiers are never combined with other
modifiers?

> 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()

Yeah. Another option is to send a wl_array of modifiers per format and
tranch.

I suppose it will be enough to send tranches for just the currently
used format? Otherwise it could be "a lot" of data.

> 
> 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?

At first I didn't understand this at all. I wonder if Simon is as
puzzled as I was. :-)

Is the idea of tranches such that within a tranch, a client will be able
to pick a modifier that is optimal for its rendering? This would convey
the knowledge that all modifiers withing a tranch are equally good
for the compositor, so the client can pick what it can use the best.

This is contrary to a flat preference list, where a client would pick
the first modifier it can use, even if it is less optimal than a later
modifer for its rendering while for compositor it would not make a
difference.

I'm also not sure I understand your tranch categories. Are you thinking
that, for instance, if a client uses same-GPU-composition modifers
which exclude cross-GPU-composition that a compositor would start
copy-converting buffers if the composition no longer happens on the
same GPU, until the client adjusts to the new preference? That makes
sense, if I guessed right what you meant.

I'm wondering how the requirement "a compositor must always be able to
consume the buffer regardless of where it will be shown" is accounted
for here. Do we need a reminder about that in the spec?


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20181102/12a6c8b7/attachment.sig>