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

[Simon Ser]

On Monday, November 12, 2018 10:14 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> > * Create a wl_surface, get the hints, and destroy everything (without mapping
> >   the surface)
> > * Allow the get_surface_hints to take a NULL surface
> > * Add a get_hints request without a wl_surface argument
> > * Forget about per-surface hints, make hints global
> > * (Someone else volunteers to patch Mesa to use per-surface FDs)
> >
> > What do you think?
>
> I think maybe it would be best to make the device hint "global" in a
> way, not tied to any surface, while leaving the format+modifier hints
> per-surface. IOW, just move the primary_device event from
> zwp_linux_dmabuf_device_hints_v1 into zwp_linux_dmabuf_v1 (or
> equivalent).
>
> Can anyone think of practical uses where the default device would need
> to depend on the surface somehow?
>
> I seem to recall we agreed that the primary device is the one the
> compositor is compositing with. Using the compositing device as the
> recommended default device makes sense from power consuption point of
> view: the compositor will be keeping that GPU awake anyway, so apps
> that don't care much about performance but do want to use a GPU should
> use it.

In the case of compositing the surface, yes the primary device will be the one
used for compositing. However there are two cases in which a per-surface device
hint would be useful.

First, what happens if the surface isn't composited and is directly scanned out?
Let's say I have two GPUs, with one output each. The compositor is using one GPU
for compositing, and the surface is fullscreened on the other's output. If we
only have a global device hint, then the primary device will be the one used for
compositing. However this causes an unnecessary copy between the two GPUs: the
client will render on one, and then the compositor will copy the DMA-BUF to the
other one for scan-out. It would be better if the client can render directly on
the GPU it will be scanned out with.

Second, some compositors could support rendering with multiple GPUs. For
instance, if I have two GPUs with one output each, the compositor could use GPU
1 for compositing output 1 and GPU 2 for compositing output 2. In this case, it
would be better if the client could render using the GPU it will be composited
with, and this depends on the output the surface is displayed on.

> Your possible solutions are a valid list for another problem as well:
> the initial/default format+modifier hints before a surface is mapped. I
> think it should be either allowing get_surface_hints with NULL surface
> or adding get_default_hints request that doesn't take a surface.
> Technically the two equivalent.

I think the cleanest solution would be to add get_default_hints, which would
create a wp_linux_dmabuf_hints object.

> I do not like the temp wl_surface approach, and we really do want hints
> to be per-surface because that's the whole point with the
> format+modifier hints.

Aye.