Stable Diffusion WebUI DirectML 项目中GFPGAN与CodeFormer的兼容性问题分析

问题背景

在Stable Diffusion WebUI DirectML项目中，用户在使用GFPGAN和CodeFormer面部修复功能时遇到了兼容性问题。这些问题主要出现在AMD显卡环境下，特别是当用户启用DirectML支持时。本文将深入分析问题的技术原因，并提供可行的解决方案。

技术分析

核心问题

问题表现为两种主要错误：

1. DMLTensor类型不匹配错误：当使用DirectML后端时，系统会抛出"unbox expects Dml at::Tensor as inputs"的错误。这是由于DirectML对存储访问(storage access)的支持不完善导致的。

2. CUDA与CPU张量类型不匹配：在使用ZLUDA方案时，会出现"Input type (torch.FloatTensor) and weight type (torch.cuda.FloatTensor) should be the same"的错误，表明模型权重与输入数据不在同一设备上。

根本原因

1. DirectML限制：

   • DirectML不支持某些PyTorch操作，特别是涉及存储访问的操作
   • GFPGAN和CodeFormer模型中的某些层需要这些不被支持的操作
   • 这是AMD显卡在Windows平台上的一个已知限制

2. ZLUDA兼容性：

   • ZLUDA虽然性能更好，但缺少hiprtc支持
   • CodeFormer需要hiprtc进行实时编译，因此只能回退到CPU运行
   • 模型权重加载到GPU而输入数据在CPU导致类型不匹配

解决方案

方案一：使用旧版本WebUI(1.7)

对于使用GCN架构显卡(如Radeon VII)的用户：

1. 回退到WebUI 1.7版本
2. 继续使用DirectML后端
3. 此方案下GFPGAN和CodeFormer都能正常工作

方案二：使用ZLUDA方案

对于支持ROCm的AMD显卡用户：

1. 安装最新版WebUI
2. 配置ZLUDA环境
3. 注意：
   • GFPGAN可以正常工作
   • CodeFormer会回退到CPU运行
   • 需要额外安装用户构建的ROCm库

方案三：强制使用CPU

临时解决方案：

1. 在启动参数中添加：--use-cpu gfpgan codeformers
2. 优点：简单易行，兼容所有版本
3. 缺点：处理速度较慢

实施建议

1. 显卡兼容性检查：

   • 确认显卡型号是否在ROCm支持列表中
   • 较新的AMD显卡(RX 6000/7000系列)更适合ZLUDA方案

2. 环境配置要点：

   • 使用ZLUDA时需要完全删除venv目录重新安装
   • 确保PATH环境变量包含ZLUDA路径
   • 对于不支持的显卡，考虑用户构建的ROCm库

3. 性能权衡：

   • 追求稳定性：选择WebUI 1.7 + DirectML
   • 追求性能：选择最新版 + ZLUDA(牺牲CodeFormer GPU加速)
   • 简单使用：强制CPU模式

结论

Stable Diffusion WebUI DirectML项目在AMD显卡上面临的面部修复功能兼容性问题，本质上是由于不同技术方案对PyTorch操作支持程度的差异所致。用户应根据自身硬件条件和功能需求，选择最适合的解决方案。随着ROCm对Windows平台支持的不断完善，未来这些问题有望得到更好的解决。

对于大多数用户，如果面部修复不是核心需求，使用--use-cpu参数是最简单的解决方案；而对于需要高质量面部修复的专业用户，则可能需要根据显卡型号精心配置ZLUDA环境或回退到旧版本。