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

[Pekka Paalanen]

On Mon, 12 Nov 2018 10:13:39 +0000
Simon Ser <contact at emersion.fr> wrote:

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

Theoretically yes. However, apps are not usually prepared to switch the
GPU they render with.

Rendering with and being scanned out on are somewhat orthogonal. In the
above case, the compositor could keep the default device as the
compositing GPU, but change the modifiers so that it would be possible
to import the dmabuf to the scanout GPU either for direct scanout or
having the scanout GPU make the copy. It's not always possible for
other reasons like an incompatible memory domain, I give you that.

If you envision that apps (toolkits) might be willing to implement GPU
switching sometimes, then I have no objections. It is again the
difference between initial default hints vs. optimization hints after
the surface is mapped.


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

From protocol point of view this does not differ from the first case.


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

Right. And if we want the preferred device to also have the initial
hints vs. optimized hints after mapping, you'd keep the device event in
zwp_linux_dmabuf_device_hints_v1.

Sounds fine to me.


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/20181112/fb89d452/attachment.sig>