On Sat, 10 Nov 2018 13:54:19 +0000 Simon Ser <cont...@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. Hi, 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 > solutions: Indeed. > > * 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. 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 format+modifier hints. Thanks, pq
pgprQJZfcbKNR.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
