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

Simon Ser contact at emersion.fr
Fri Nov 2 18:38:10 UTC 2018

On Friday, November 2, 2018 9:53 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> > 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?

I think Daniel refers to the format + modifier combination. Yes, modifiers
cannot be mixed with each other.

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

True. Any reason why this hasn't been done in the global?

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

What do you mean by "the currently used format"?

I expect clients to bind to this interface and create a surface hints object
before the surface is mapped. In this case there's no "currently used format".

It will be a fair amount of data, yes. However it's just a list of integers.
When we send strings over the protocol (e.g. toplevel title in xdg-shell) it's
about the same amount of data I guess.

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

Yeah, that's what I've understood too.

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

Right. I don't think we can do any better.

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

A reminder might be a good idea. The whole surface hints are just hints. The
client can choose to use another device or another format, and in the worst case
it'll just be more work and more copies on the compositor side.

More information about the wayland-devel mailing list