@vanvugt please take a look at "Example of how to execute a variation of the Test Plan"
** Description changed: [ Impact ] - * Mutter has a number of scanout failure issues due to incorrect GPU + * Mutter has a number of scanout failure issues due to incorrect GPU capability detection and lookups with multiple GPUs present. - * We correct the secondary GPU lookups to avoid these types of failures + * We correct the secondary GPU lookups to avoid these types of failures allowing rendering with GPU X and scanout with GPU Y to succeed. [ Test Plan ] - * Run vulkan or other graphics applications with explicit control over + * Run vulkan or other graphics applications with explicit control over the rendering GPU - * Render to GPU X while having the window be presented by GPU Y + * Render to GPU X while having the window be presented by GPU Y + + [ Example of how to execute a variation of the Test Plan ] + + Hardware / session requirements: + * A machine with two GPUs where at least one monitor is connected to each GPU + (e.g. Intel/AMD iGPU + NVIDIA dGPU, or two dGPUs). + * GNOME on Wayland (the fix is in the native KMS backend; X11 sessions are + not affected). + * Packages: vulkan-tools (vkcube), mesa-vulkan-drivers and/or the NVIDIA + driver, drm-info (optional, for step 1). + + 1. Identify the GPUs and which monitor is on which GPU + * Map DRM card nodes to PCI devices: + ls -l /dev/dri/by-path/ + * Map connectors to cards (only connectors reporting "connected" matter): + for c in /sys/class/drm/card*-*; do echo "$c: $(cat $c/status)"; done + * Determine which GPU mutter treats as primary. By default this is the boot + VGA device: + grep -H . /sys/class/drm/card*/device/boot_vga + Call that GPU "P" (primary) and the other one "S" (secondary). Call the + monitor connected to P "Mon-P" and the monitor connected to S "Mon-S". + * List Vulkan physical device indices: + vulkaninfo --summary + Note the "GPU<n>" index of P and S. These are passed to vkcube below as + --gpu_number. + + 2. Enable mutter render debug logging (gives a positive signal for the fix) + * Create ~/.config/environment.d/mutter-debug.conf containing: + MUTTER_DEBUG=render + * Log out and back in to GNOME on Wayland. + * In a terminal, follow the shell log: + journalctl --user -u [email protected] -f | grep -i scanout + + 3. Make it possible to fullscreen vkcube + * Direct scanout is only attempted for fullscreen windows, and vkcube has no + fullscreen switch. In Settings > Keyboard > Keyboard Shortcuts > Windows, + assign a shortcut to "Toggle fullscreen mode" (e.g. Super+F). + + 4. Run the test matrix + For each row, launch vkcube with the Wayland WSI and the given rendering GPU, + move the window to the given monitor (Super+Shift+Left/Right), then press the + fullscreen shortcut. Leave it running for at least 30 seconds, then toggle + fullscreen off and on a few times, then move the still-fullscreen window to + the other monitor and back. + + vkcube --wsi wayland --gpu_number <idx> + + Row | Rendering GPU | Monitor | Expected result + ----+---------------+---------+------------------------------------------- + A | P | Mon-P | Smooth cube. Log shows a direct scanout + | | | candidate being used (control case, same + | | | before and after the fix). + B | P | Mon-S | Smooth cube, no flicker, no black frames, + | | | no unrelated content. Log shows + | | | "No direct scanout candidate: onscreen + | | | framebuffer doesn't support direct scanout". + C | S | Mon-P | Smooth cube, no corruption. + D | S | Mon-S | Same expectations as row B. This is the + | | | primary cross-GPU case from the bug. + + * Then run rows B and D with a second fullscreen client already running on + Mon-P (another vkcube instance, or mpv --fullscreen). This raises the + chance of a framebuffer-ID collision, which is the worst case described in + upstream commit 2853853c09. + + 5. Optional: swap the primary/secondary roles and repeat + * Tag the other GPU as mutter's preferred primary with a udev rule, e.g. + /etc/udev/rules.d/61-mutter-primary-gpu.rules: + ENV{DEVNAME}=="/dev/dri/card1", TAG+="mutter-device-preferred-primary" + (adjust the card node), reload udev, log out and in, and repeat step 4. + + Pass criteria: + * No flicker, black frames, tearing of unrelated content, or stale buffers on + Mon-S in any row. + * No "Failed to post KMS update" / atomic commit errors in the journal + while vkcube is fullscreen on Mon-S. + * With MUTTER_DEBUG=render, views on Mon-S log that the onscreen framebuffer + doesn't support direct scanout, while Mon-P (row A) still uses direct + scanout. + + Failure signature on unpatched mutter (what to look for when verifying the + -proposed package fixes it): + * Momentary flicker or black frames when vkcube goes fullscreen on Mon-S, + and in the worst case an unrelated window's contents shown on Mon-S. [ Where problems could occur ] - * Since multigpu scanout is essentially unusable in older versions of + * Since multigpu scanout is essentially unusable in older versions of Mutter due to momentary flicker, if a backporting mistake was done, maybe scanout would fail altogether while rendering with another GPU. - * This scenario should be easy to catch in testing with the test plan. + * This scenario should be easy to catch in testing with the test plan. [ Other Info ] - * + * https://gitlab.gnome.org/GNOME/mutter/-/commit/2853853c0923ee878f66f7593dfb951ca417532c - * + * https://gitlab.gnome.org/GNOME/mutter/-/commit/a22902abed8e107cce86ad2c46719d4d24b1a5fa -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2169221 Title: Mutter scanout failures with more than one gpu To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/2169221/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
