Mutter proposed secondary GPU scanout changes

multigpu_scanout.md

Multi-GPU scanout in Mutter

I'd like to add support for direct scanout on secondary GPUs in mutter. i.e. app becomes fullscreened on an output connected to the secondary GPU, we resend dmabuf feedback to include scanout formats for that GPU, the app reallocates buffers to use a scanout format, direct scanout takes place. When the screen leaves fullscreen dmabuf feedback is resent (no secondary scanout formats this time) and the existing buffer is copied to the primary GPU for rendered composition if needed until the app reallocates.

This is something I proposed for wlroots as well, so prior example here: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4055

There's some high level descriptions in that MR's description of how the flow works for this feature that might be helpful.

This is interesting from a performance perspective but it also opens the door to enabling features. Direct scanout is needed for GSync to take place, and some features like dynamic display muxing require the ability to scanout on both GPUs.

Implementation Ideas

• Allow MetaMultiTexture to contain a texture that is only imported on the secondary GPU
  • First call to meta_multi_texture_get_plane performs a copy to primary GPU and caches the result.
• Try importing dmabuf on secondary GPUs in meta_wayland_dma_buf_realize_texture and creating a MetaMultiTexture from it.
• Advertise scanout tranches for secondary GPUs
• Potentially make find_scanout_candidate aware that secondary GPU outputs can be scanned out?

The core ideas are the changes to advertising scanout feedback tranches and using MetaMultiTexture to abstract away the texture residency. The dmabuf feedback bits are pretty much just what was described when that version of the protocol was made. MetaMultiTexture seems like the most convenient place to hide cross-GPU copies, since its interface for querying plane textures seems compatible.

fwiw this is conceptually pretty similar to how the wlroots implementation goes, although in that one the copying is abstracted behind wlr_texture_set.

Questions

• Is MetaMultiTexture the right place for what I'm suggesting?
• Can existing copy infrastructure be reused? i.e. copy_shared_framebuffer_gpu.
  • It seems the existing ones have a framebuffer as the destination. But for something like what I'm suggesting we would probably want to copy to a CoglTexture instead. Not sure if there's an easy way to reuse the existing ones and avoid duplicating or reinventing the wheel?
• Any other suggestions?