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

[Pekka Paalanen]

On Fri, 02 Nov 2018 18:38:10 +0000
Simon Ser <contact at emersion.fr> wrote:

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

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.

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

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

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


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/20181105/057110d0/attachment.sig>