GNOME Mutter Improves Damage Tracking For Secondary GPU Copy Buffers

As an early improvement to Mutter to look forward to with GNOME 52, the compositor is now tracking damage for secondary GPU copy buffers. This should improve the experience for those with multi-GPU setups such as some hybrid laptops. Ray Strode of Red Hat authored the support to track damage for secondary GPU copy buffers for helping out where the display is connected to a different GPU. Ray explained in the merge request: "The native backend copies rendered frames when a monitor is connected to a different GPU. Depending on the selected copy mode, it uses two GPU buffers or three CPU-accessible buffers as destinations. The damage region passed to these paths describes changes from the newest frame. The primary-GPU copy rotates through three destination buffers. A reused buffer can be several frames old, so copying only the newest damage can leave older pixels behind. The serialized secondary-GPU copy has a valid two-frame assumption while every copy succeeds, but failures can make its damage history disagree with the buffer contents. The CPU fallback copies the whole frame, but it currently returns a buffer after a failed read. A successful zero-copy interval can also leave fallback buffers older than their recorded state. This merge request adds MetaSecondaryGpuCopyState, which records the last successful source frame in each destination buffer and keeps the damage from recent frames. The native copy paths use it to include every change needed by the selected buffer. Unknown or too-old buffers receive the whole frame, as do regions with more than 16 rectangles. Buffer selection advances only after a successful copy, and a successful zero-copy import invalidates the fallback state." The code was merged to Mutter Git yesterday via this merge request. The code was authored a month ago albeit initially held up over concerns of some of the commit messages being AI/LLM-generated slop. Strode worked on this damage tracking improvement as part of his efforts on castkms as an experimental Linux DRM/KMS driver for virtual displays. Related to that as well is his Pronk project for turning Google Cast devices into managed Linux desktop displays.