SwayWM中多GPU系统下外部显示器全屏应用渲染问题分析

问题现象

在SwayWM窗口管理器中，当用户在多GPU系统（特别是双AMD显卡配置）上尝试将某些应用程序全屏显示在外部显示器时，会出现渲染异常。具体表现为：

1. 部分应用程序（如VLC、GIMP、Alacritty等）在全屏模式下无法正确渲染，屏幕显示冻结
2. 应用程序实际上仍在运行（可接收输入，音频继续播放）
3. 界面元素（如Waybar）仍可见，未真正进入全屏状态
4. 使用OBS Studio捕获屏幕时问题会神奇消失

技术背景

这个问题涉及几个关键组件和技术点：

1. 多GPU渲染架构：系统使用两块AMD显卡，需要跨GPU传输帧缓冲区
2. 直接扫描输出(Direct Scan-Out)：优化技术，允许直接将应用缓冲区扫描输出到显示器，避免额外复制
3. Vulkan/GLES2渲染器：Sway支持的不同底层渲染后端
4. DMA-BUF：Linux内核的直接内存访问缓冲区机制，用于GPU间共享数据

根本原因分析

通过日志和测试可以确定：

1. 在多GPU环境下，当尝试直接扫描输出时，系统无法正确导入源缓冲区
2. 错误表现为Vulkan下格式与修饰符不兼容，GLES2下EGL创建图像失败
3. 问题与特定的缓冲区格式(AR24)和修饰符组合有关
4. 直接扫描输出在多GPU场景下的实现存在缺陷

解决方案

目前有以下几种解决方案：

1. 临时解决方案：设置环境变量WLR_SCENE_DISABLE_DIRECT_SCANOUT=1禁用直接扫描输出
2. 长期解决方案：等待并应用wlroots项目的修复补丁（已合并）
3. 变通方案：使用OBS Studio捕获屏幕（会改变渲染路径）

技术细节深入

该问题揭示了多GPU系统中几个重要的技术挑战：

1. 缓冲区共享机制：不同GPU间的内存管理单元(MMU)可能有不兼容的地址转换方案
2. 格式协商：显示控制器支持的像素格式与渲染器输出格式需要精确匹配
3. 修饰符处理：现代GPU使用的平铺、压缩等内存布局修饰符需要正确传播

开发者建议

对于Wayland合成器开发者，这个问题提供了几点启示：

1. 多GPU场景需要特别测试直接扫描输出路径
2. 应实现完善的回退机制，当直接扫描输出失败时自动切换到常规渲染路径
3. 需要更全面的格式/修饰符协商和验证机制
4. 考虑为多GPU系统提供专门的性能优化策略

用户建议

对于最终用户，如果遇到类似问题：

1. 首先尝试禁用直接扫描输出功能
2. 检查系统日志获取更详细的错误信息
3. 考虑更新wlroots和Sway到最新版本
4. 报告问题时提供详细的硬件配置和应用列表

这个问题展示了Linux图形栈在复杂硬件配置下仍存在的挑战，也体现了开源社区快速响应和修复问题的能力。随着Wayland生态的不断成熟，这类多GPU场景的问题将逐步得到更好的解决。