[PATCH RFC wayland-protocols] unstable/linux-dmabuf: add wp_linux_dmabuf_device_hint
ppaalanen at gmail.com
Mon Nov 12 09:14:13 UTC 2018
On Sat, 10 Nov 2018 13:54:19 +0000
Simon Ser <contact at emersion.fr> wrote:
> Just a general update about this: I tried to see how we could make Mesa use this
> new protocol.
> A bad news is that the DRM FD is per-EGLDisplay and I think it would require
> quite some changes to make it per-EGLSurface. I'm still new to the Mesa
> codebase, so it'd probably make sense to only use the new protocol to get the
> device FD, without relying on wl_drm anymore. We could talk about using the
> protocol more efficiently in the future. I also think a lot of clients weren't
> designed to support multiple device FDs, so it would be nice to have a smoother
> upgrade path.
yeah, that sounds fine to me: use the new protocol, if available, to
only find the default device at EGLDisplay creation.
What can be done per surface later is only the changing of
format+modifier, within the limits of what EGLConfig the app is using,
so maybe it's the modifier alone. If EGL should do that automatically
and internally to begin with... it could change the modifier at least.
> That leaves an issue: the whole protocol provides hints for a surface. When the
> EGLDisplay is created we don't have a surface yet. I can think of a few possible
> * 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
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
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 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the wayland-devel