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

[Simon Ser]

On Monday, November 5, 2018 9:57 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> > > 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?
>
> For formats? Well, it is simpler without a wl_array, and there might be
> a lot of formats.
>
> Could there be a lot of modifiers per format? Would a wl_array make
> anything easier? Just a thought.

It's true that for this list of formats sorted by preference, we'll probably
need to split modifiers anyway so I don't think we'd benefit a lot from this
approach.

> > > 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"?
>
> This interface is used to send clients hints after they are already
> presenting, which means they already have a format chosen and probably
> want to stick with it, just changing the modifiers to be more optimal.

If we only send the modifiers for the current format, how do clients tell the
difference between the initial hints (which don't have a "currently used
format") and the subsequent hints?

> > 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".
>
> Right, that's another use case.
>
> > 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.
>
> If the EGLConfig or GLXFBConfig or GLX visual lists are of any
> indication... yes, they account for depth, stencil, aux, etc. but then
> we will have modifiers.
>
> We already advertise the list of everything supported of format+modifer
> in the linux_dmabuf extension. Could we somehow minimize the number of
> recommended format+modifiers in hints? Or maybe that's not a concern
> for the protocol spec?

I'm not sure.

After this patch, I'm not even sure how the formats+modifiers advertised by the
global work. Are these formats+modifiers supported on the GPU the compositor
uses for rendering? Intersection or union of formats+modifiers supported on all
GPUs?

> > > > 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.
>
> Yeah. What I precisely mean is that even if a client chooses a
> recommended format+modifier, the compositor will not be exempt from the
> requirement that it must work always. I.e. a compositor cannot
> advertise a format+modifier that would work only for scanout but not
> for fallback composition, even if the surface is on scanout right now.

Yeah, this makes sense.