About migrating framebuffers in multi-GPU compositors

[Pekka Paalanen]

On Wed, 23 Mar 2022 14:19:08 +0000
"Hoosier, Matt" <Matt.Hoosier at garmin.com> wrote:

> Hi,
> 
> I recently had a reason to wade through Mutter's code to support
> systems with more than one GPU. I was a bit surprised to see that
> it supports several different strategies for dealing with
> scanning out a buffer on a KMS output not associated with the GPU
> where the buffer was originally rendered.

Hi,

indeed. The reason for multiple paths is that different systems
don't support all ways, or do support some of the ways but the
performance might be abysmal. Knowing which path to take is a
difficult problem, and other than benchmarking (which I didn't
implement in Mutter) you can't really know if what you picked is
going to be fine.

> In particular, the approach of using the secondary GPU's OpenGL
> implementation to blit into a dumb buffer was really unexpected.
> Typically, dumb buffers get described as a really slow, uncached
> mapping of GPU memory into the CPU.
> 
> The support got added here (by Pekka):
> 
> https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/615

That MR is using the primary GPU to blit, not the secondary GPU.

If a secondary GPU can have a hardware accelerated OpenGL context,
I don't know why anyone would deliberately use dumb buffers on that
device with OpenGL. GBM offers better ways.


This MR cover letter has a better overview of all the methods:
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/810

> If I follow this right, the blit occurs directly between video
> memory owned by the primary GPU into dumb-buffer memory owned by
> the secondary GPU, without laboriously using the CPU to do PIO.

Correct.

> Does this imply that the two GPUs' drivers have to be at least
> minimally aware of each other to negotiate some kind of DMA path
> directly between the two?

I don't know the details. It depends on whether you can map
secondary GPU memory to be written by the primary GPU. The specific
use case here is iGPU as primary and virtual as secondary, which
means that video memory for both is more or less "system RAM". No
discrete VRAM involved.

It is accomplished through the kernel dmabuf framework where
drivers export and import dmabuf.


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/20220324/bb605a09/attachment.sig>