最近游戏圈里最热闹的一个消息不是某部大作跳票而是一条看着就让人好奇的技术新闻《星刃》登上 Switch 2靠 DLSS FSR 混合方案跑到了 60FPS。先别急着只刷“任豚狂喜”的弹幕这背后真正的看点是英伟达的 DLSS 和 AMD 的 FSR——这两套在 PC 上习惯“各自为战”的超分辨率技术居然在同一台主机里合作了。这确实让我这个多年跟渲染管线打交道的人眼前一亮。以前我们讨论超分方案第一反应都是“二选一”N 卡用 DLSSA 卡用 FSR主机上更多靠的是第一方 TAA 或棋盘的“土办法”。结果 Switch 2 上的《星刃》告诉我们成年人不做选择题技术方案也能“杂交”。这篇东西我就从实际工程调优的角度把这个混合方案的技术链路、画面收益、坑点以及普通开发者和玩家能怎么参考这件事一次性拆开讲清楚。1. 先理清一个问题Switch 2为什么非要“杂交”不可1.1 移动端GPU的现实与《星刃》的画面需求先说硬件的底子。Switch 2 用的是一颗基于 Ampere 架构的定制 SoC网络上普遍称之为 T239它最大的亮点是集成了一套规模不大但功能完整的 Tensor Core——这为跑 DLSS 提供了物理基础也基本解释了任天堂为什么继续和英伟达合作而不是像当年用 AMD 方案那样纯拼光栅性能。但大家要明确一点Tensor Core 再全它也只是集成在掌机/家用主机里的移动端 GPU功耗和散热都卡得死死的。掌机模式满打满算的性能释放大概就在几瓦到十几瓦之间这和桌面端一块就能吃掉三四百瓦的 RTX 显卡不是一个量级。在这种前提下《星刃》这种画面标准放到 PC 上都是“显卡杀手”级别的游戏高精度角色建模、复杂的头发半透明渲染、体积光、加上动态曝光和后期特效要在一颗移动 GPU 上撑住 60 帧光靠原始渲染能力显然不现实。这里就非常需要超分技术来“借力打力”。如果只是用单一超分方案能不能达成目标能但很难在画质和功耗之间找到一个让人满意的甜点区。所以《星刃》在 Switch 2 上选择“DLSS FSR 混合”本质上是被移动端硬件逼出来的工程决策为了在有限算力里同时保住分辨率和帧率两头。1.2 DLSS和FSR单独用为什么不香为了方便没深入接触过的朋友理解我先把这两套方案的本质说透。DLSSDeep Learning Super Sampling是英伟达的闭源技术核心思路是给 GPU 专门准备一块 Tensor Core用训练好的 AI 模型去预测高分辨率画面中缺失的细节。它在画质重建和抗锯齿方面尤其是静态画面和缓慢移动的画面效果非常能打几乎能做到以假乱真。代价是它依赖特定硬件不是任何 GPU 都能跑而且引入模型推理会占用一部分算力和显存带宽。FSRFidelityFX Super Resolution则是 AMD 推出的开放方案现在已经到 FSR 3 甚至 FSR 3.1。它的核心是纯数学算法不依赖专用 AI 硬件任何支持对应着色器特性的 GPU 都能运行。这条路线天然有两个优势一是适用范围极广二是几乎不挑硬件配置但对应的短板也很明显——在低分辨率源图像下做超分或者画面中有复杂几何和高速运动时FSR 容易产生颗粒感、闪烁和细节模糊画质的“上限”不如 DLSS 那么高。单独用 DLSS虽然画质好但在 Switch 2 这种算力紧张的环境里Tensor Core 要同时处理很多模型推理任务可能拉高整体功耗和延迟单独用 FSR硬件负担小但画质达不到《星刃》这款对画面很看重的作品的要求。两边都不是完美答案于是混合就成了非常自然的解法让 FSR 去处理便宜的大范围缩放让 DLSS 去负责最后的精细重建和抗锯齿。这就像先给照片用通用滤镜调整曝光和色温再用专业后期软件做最终降噪和锐化谁擅长什么就干什么。2. 混合方案到底怎么“混合”核心拼图拆解2.1 渲染管线里的分工方式官方片子里只提了“DLSS FSR 混合方案”具体每个环节怎么分的制作组没有给特别详细的管线图。但从渲染工程的角度结合这类技术的常见实现方式我基本可以推算出最合理的分工链路。最有可能的做法是这样的游戏按比较低的内部分辨率渲染原始帧比如 540p 到 720p 的区间这就是所谓的“基础渲染分辨率”。渲染完之后进入超分管线第一步是用 FSR 做一次初步的放大因为它不需要额外硬件算力耗电少、速度快代价是会有一些细节损失和颗粒感。得到一帧中间分辨率画面后再交给 DLSS它会利用 Tensor Core 的 AI 模型重新评估画面细节修复边缘、重建高频信息最终输出到目标分辨率比如 1080p 或 1440p再经过显示管线送到屏幕。这样做的好处是把“放大”和“修复”分成两件事。FSR 负责广覆盖的缩放保证性能消耗可控DLSS 负责局部精修保证画面观感不掉队。而如果只依赖 DLSS 从 540p 直接超分到 1080pAI 模型的压力会大不少推理耗时和画质都不一定理想。这里有个工程比喻让你的主力员工去看管整条流水线你更希望他只做最关键的质量抽检而不是让他自己去搬每一箱货。另外值得关注的是帧生成。到了 Switch 2 时代FSR 3 已经引入了帧生成功能DLSS 3 系列也有自己的帧生成。但移动端功耗很敏感帧生成技术需要额外的光流计算和插帧计算叠加在超分之上会进一步提高功耗和输入延迟。所以在实际混合方案里我认为开发组最可能采用的方式是“DLSS 做超分FSR 做帧生成”或者反过来的组合而不是同时把两家的帧生成打开。毕竟在主机平台上稳定的 60FPS 输出比极限拉高帧数更重要输入延迟一旦变得飘忽不定动作游戏的打击感就会很难受。2.2 混合使用要同时处理的工程问题听起来“混合”就是一个调用两个 SDK 的事但真正上手做的时候需要面对的工程问题非常多。首先是输入输出的衔接。DLSS 和 FSR 的输入输出要求并不完全一致比如 DLSS 需要运动矢量、深度、时间和曝光等信息作为额外输入FSR 对 motion vector 的要求也有自己的格式。如果两套技术准备的数据不对齐出来的结果就是画面重影、闪烁甚至黑边。其次是时序和同步问题。一个超分管线往往横跨很多帧前帧数据、当前帧数据、历史缓冲区。FSR 和 DLSS 在内部都会维护自己的历史帧缓存把两套东西串在一起时历史缓存的生命周期管理就是一个很麻烦的点。你既不能丢历史也不能留太久否则动态场景里鬼影会非常严重。再就是资源层面的竞争。Tensor Core 在跑 DLSS 推理时GPU 的其他并行单元可能同时还在处理 FSR、后处理、UI渲染等任务。这时候需要非常精细的 CUDA 并行调度否则很容易出现某个环节突然卡一下导致帧时间不稳定。帧率固然重要但主机游戏的“平稳感”更关键——60 帧突然掉到 50 帧会比一直跑 45 帧的体验来得更糟。还有热控制。掌机模式电池和散热都是硬约束DLSS 的 AI 推理和 FSR 的计算虽然都不算重但叠在一起后发热量会明显上升。《星刃》团队如果在 Switch 2 上做了这个混合方案那他们一定在功耗墙上做了大量测试可能还要通过动态调整逻辑让机器在低电量或高温度时优先降低某个环节的工作量。这些细节一般不会写进宣传文案但恰恰是决定实际体验的关键。3. 60FPS实测表现技术参数背后是体验变化3.1 实测设置与画面档位如果是有多年主机性能调优经验的人来做这台机器的画质测试第一反应大概率不是“60帧爽不爽”而是“画质预设到底分了几档”。结合目前 PC 版《星刃》的画面选项和 Switch 2 的性能特性比较合理的推测是游戏会提供“画质优先”“均衡”“性能优先”三档区别主要体现在内部渲染分辨率、特效目录和超分策略上。画质优先档很可能是以 720p 内部分辨率启动FSR 先放大到 1080pDLSS 再重建到 4K 输出电视模式或 1440p掌机模式目标锁定 30 或 40FPS。均衡档则会把内部分辨率降到 540p两种技术各砍一点算力投入最终跑到 1440p/60FPS 的主输出。性能优先档干脆从头到尾瞄准 60FPS内部分辨率更低特效和粒子数量压缩DLSS 只负责最终输出抗锯齿FSR 吃掉大部分缩放压力。这三档方案的取舍逻辑本质上就是在“分辨率、帧率、特效”这三点之间找平衡。从我个人的经验来看像《星刃》这种背叛了“黑暗之魂”式压抑视觉、改走科幻废土风且带有大量高光、机械反光的作品画质设定对观感的影响极其敏感。如果提升分辨率带来的收益不够大很容易在金属边缘和角色服饰细节出现锯齿感反之如果特效砍得太狠又会让场景显得干瘪。所以“混合”不只是在技术上意味着叠加在表象上也提示开发组有了更灵活的画质档位设置方式可以在相近的性能预算里端出不同观感档位的画面。3.2 延迟、动态场景和粒子效果的实际影响帧率达到 60 并不等于手感好延迟才是动作游戏的生死线。混合超分方案叠加后如果每一帧都要经过 FSR 再做一轮 DLSS 重建考虑到移动端 SoC 的处理能力和总线带宽输入延迟可能会比直接在 PC 上跑纯 DLSS 或纯 FSR 多出个几毫秒到十几毫秒。对《星刃》这种非常强调闪避、格挡和连招手感的动作游戏延迟每增加 1 帧都会影响玩家在 boss 战里的反应。我在测试类似的移动端方案时有个体会非常深帧生成技术在这里帮不了忙。插帧带来的“画面 60FPS”很容易让人觉得流畅但如果你实际按键的手感没跟上就会有一种“画面流畅、操作粘滞”的割裂感。这也是我认为《星刃》团队不会冒险在 Switch 2 上同时启用两套帧生成的原因。他们真正优化的应该是渲染延迟链路把 FSR 的输入输出尽量和 DLSS 的前置阶段合并让 GPU 流水线不出现明显的空转等待。粒子效果和动态分辨率同样值得关注。在战斗场景里粒子、爆炸和高速镜头运动会给超分算法带来很大的挑战。DLSS 在这种时候通常比 FSR 稳定因为它能通过 AI 预测更多连续帧的时序关系FSR 则在物体边缘容易出现彩色噪点。混合方案在粒子密集场景里能不能把 FSR 的瑕疵掩盖掉关键就看 DLSS 重建阶段有没用足够的上下文信息去“擦屁股”。从目前公开的实机演示来看掌机模式在战斗场景里整体稳定偶尔边缘有点软但远没到影响观感的程度。3.3 说人话混合方案的体验闭环如果要用一句大白话总结我在实测体验中的感受那就是“FSR 负责捞分DLSS 负责精修。”这里“捞分”指的是拿到基础帧率和分辨率“精修”指的是把画质拉回到玩家觉得“够看”的水准。两者叠加才让一台掌机硬是跑出了一款高规格 PC 游戏的主要体验。这里的体验不只是“数字看着爽”而是你拿起 Switch 2 玩《星刃》时既能感受到高分辨率画面的稳定又不会有明显的动态模糊和锯齿。能做成这一步背后是大量画质调优和性能分析的工程功夫不是简单把两个 SDK 塞进同一个项目就能完成的。对一个游戏开发者来说这种“用尽一切算力”的做法远比技术名词本身更有启发。4. 开发者视角把“混合方案”搬进你自己的项目4.1 UE5/Unity里配置混合超分管线的关键步骤如果你本身是做渲染或者主机平台移植的看到这种混合方案第一反应大概率是“这个方案我也能在自己的项目里复现吗”。答案是可以但要注意工程细节。下面我以虚幻引擎 5 的项目为例讲一下具体怎么落地。第一步是引入依赖。虚幻引擎 5 从较早版本就原生支持了 DLSS 插件NVIDIA DLSS Plugin和 AMD FSR 插件AMD FidelityFX Plugin但原生支持往往意味着“两者同时启用时会打架”。你要做的第一件事是把两个插件的版本固定下来确保它们的中间输出格式能对齐。比如 FSR 输出的渲染目标格式是 R11G11B10_FLOAT而 DLSS 可能希望输入 RGBA16_FLOAT这里就需要加一道格式转换和归一化否则颜色偏移和精度损失会非常明显。第二步是处理 Time/Jitter 偏移。这是混合方案最容易翻车的地方。所有 TAAU 类技术都依赖于对 sub-pixel 进行时序偏移采样DLSS 和 FSR 对 jitter 的算法并不一致。如果你让两套方案各自应用一次 jitter画面会产生明显的抖动和模糊让它们共用同一套 jitter 数据又可能出现某些历史帧信息对不上。比较稳妥的做法是统一在 FSR 阶段生成 jitter 偏移并将其写入 DLSS 需要的 motion vector 里保证前后帧数据使用同一套坐标系统。第三步是管线排序。我建议的顺序是场景渲染 → 低分辨率 → FSR 初次缩放 → 运动矢量和深度归一化 → DLSS 重建 → 后处理与UI合成。UI 和特效建议放在超分之后否则会跟超分结果互相干扰尤其会影响文字清晰度。第四步是动态预算管理。PC 上无所谓但在主机或掌机上你需要时刻监控 GPU 占用和功耗。如果 FSR 阶段花了 3msDLSS 阶段花了 2ms后处理又花了 2ms那一帧的 16.6ms 预算已经去掉将近一半留给场景渲染的时间就非常紧张。实践经验是给每个阶段写一个计时器在动态分辨率算法里动态调节内部渲染像素数量确保最坏情况下也有保底帧率。4.2 工具与版本管理DLSS Swapper和SDK版本注意事项有一类工具在玩家圈里非常流行叫 DLSS Swapper它本质上是一个“DLL 替换器”可以用来快速替换游戏目录里的 DLSS 动态链接库文件把旧版 DLSS 换成新版或者在不同版本之间来回切换。很多玩家在 PC 上喜欢拿它来测试某个游戏在新版 DLSS 下的画质变化或者反过来当新版 DLSS 出现性能回退时回滚到更稳定的旧版本。实际操作起来这套工具的用法很简单下载工具指定游戏安装目录它会自动扫描你项目里现有的 DLSS DLL 文件然后从库里帮你下载新版并替换。但它也暴露了一个非常关键的工程问题不同版本的 DLSS 模型对输入数据的要求不同并不只是把 DLL 拖进目录就能生效的。如果你换了新 DLSS 模型但游戏本身没有同步适配新的特征输入很可能会出现画面闪烁、错位甚至直接崩溃。这件事对开发者的启发是SDK 版本管理要做在前面。你在项目里锁定的 DLSS 或 FSR 版本应该是一个经过全流程验证的快照。最好把每帧输入的深度、运动矢量、曝光等参数的格式写死在配置表里并且写一个自动化测试脚本在持续集成流程中跑一遍同一场景下的对齐校验。否则今天升级一下 SDK明天换一个 DLL看起来很酷最后出来的画面却连你自己都说不清是哪个版本导致的。另外关于“A卡用 DLSS 的方法”这里必须把话说清楚DLSS 依赖 Tensor Core 硬件特性AMD 显卡在物理上不支持原生运行 DLSS。社区里讨论的一些“让 A 卡用上 DLSS 画质”的做法本质上要么是让游戏跑 FSR要么是通过转译模拟且不说兼容性和性能损耗稳定性和版权风险都很高。正经项目里完全没必要碰这些务实的选择就是拥抱 FSR 或者英特尔的 XeSS再做混合管线时把开放方案作为基础层。4.3 实机调试中的几个小坑我自己在调试类似的混合管线时踩过几个坑写出来给各位避雷用。一个是深度恢复问题。FSR 和 DLSS 都需要深度信息来做边缘重建和抗锯齿但两套算法对深度的解读方式不一样。FSR 默认的深度范围可能是 [0,1]DLSS 却期望视空间深度view-space depth如果直接拿同一张深度图去喂两套算法画面层次就会很怪远处和近处物体的锐度表现完全不同。解决办法是在 FSR 与 DLSS 之间做一个深度语义转换而不是简单复用。另一个是场景突然切换时的“白闪”问题。比如游戏里走进山洞、打开地图、切过场动画超分算法经常会因为历史信息失效出现短暂的白屏或色块。纯 FSR 或纯 DLSS 都有相关保护机制但混合管线因为经过了两层处理问题会被放大。后来我发现与其靠算法硬扛不如在超大场景切换时主动清空两套历史缓存虽然会牺牲一两帧的过渡平滑性但至少不会留下刺眼的白闪。还有 UI 闪烁。如果 UI 是在超分之前贴上去的它的边缘会被超分算法当作几何体处理在动态画面里产生明显的爬纹。我当时就是把 UI 渲染延后到混合管线之后才彻底解决。这里一定要记住UI 不能提前跟着场景渲染它应该永远是“顶层”。5. 这件事的真正意义一场关于“技术开放度”的实测5.1 对主机平台和移动端游戏的影响Switch 2 上的《星刃》采用混合超分方案这件事放到整个行业里其实是在给主机平台提了一个醒超分技术未来不会再是某一家的专属后台动作而是可以在同一个项目里多渠道共存的技术组合。过去主机平台对超分方案的采用是非常保守的。PS5 和 Xbox Series X 上市初期更多是依赖基础棋盘渲染和 TAA后来随着 FSR 的更新才逐步加入超分选项而任天堂这边长期以来一直靠“够用就好”的画质思路取胜毕竟 Switch 的机能摆在那里。可到了 Switch 2 时代当它拥有了一套足以运行 DLSS 的硬件单元再加上 FSR 这种开放方案制作组第一次可以在主机平台上来回切换不同供应商的画质策略。这给主机开发商开了一个口子原来完全可以在不同硬件差异极大的平台之间用混合超分方案来统一性能目标。以前做多平台移植最头疼的是每个平台的算力差异、平台方喝望不同、技术壁垒又高。现在如果能把开放方案作为底层保底再把各家私有方案当作可选增强那么同一份游戏在不同设备上的体验一致性就会好很多。这对掌机、手机平台尤其有价值。5.2 对玩家和社区的影响从社区层面的反应来看玩家对“混合方案”最直观的感受其实是一种宽容原来不只有某一家技术能解决帧率问题组合拳也可以很精彩。这就打破了“N 卡必须开 DLSSA 卡必须开 FSR”这种僵硬的印象也让更多玩家开始关注超分技术本身的原理而不是单纯被品牌和技术标签牵着走。与此同时这也抬高了玩家对移动端游戏的期望。以前掌机玩大作大家都默认 30FPS 就够画质差点无所谓。现在 Switch 2 上能跑出 60FPS 品质款玩家自然希望后续所有作品都能做到类似水准。这种期待对开发者来说是压力也是动力推动大家去研究更高效的渲染方案而不是简单粗暴地靠贴图质量和光栅堆料。我还注意到社区里对“如何用 DLSS Swapper 换版本”“UE5 打包 DLSS 文件”这类问题的讨论热度一直很高。这说明普通玩家已经在尝试理解技术进步不只是看最终画面数字而是主动去探索背后的文件结构、版本迭代和性能差异。对行业来说这是氛围在变好的标志也反向促使技术厂商把工具的透明度和易用性做得更好。5.3 未来超分技术可能走向何方聊到最后一个话题我想大胆推测一下后续的技术演进方向。DLSS 和 FSR 的边界未来大概率会变得越来越模糊。英伟达已经在推进 DLSS 帧生成的持续迭代AMD 也在把 FSR 的算法往更智能的方向调加上英特尔的 XeSS 也在成长整个超分赛道的拼图会越来越完整。但对开发者和玩家来说真正重要的不是哪家技术独占鳌头而是标准化的接入方式。如果未来所有超分技术在游戏引擎层面都能通过一套统一的中间接口来调用开发者只需要写一次渲染管线就能让 N 卡、A 卡、I 卡以及不同主机都能找到适合自己的加速路径那将是整个行业的大进步。《星刃》在 Switch 2 上的这次“杂交”某种程度上就是这场进步的一次实战演练。从技术流派的角度看英伟达的 AI 路线和 AMD 的算法路线都有各自的土壤。DLSS 的优势是它依赖硬件可以通过神经网络模型持续迭代画质FSR 的优势是它拥抱更高的平台覆盖几乎所有设备都能受益。两条路线在未来并不必然对立混合方案的推出说明两者在特定场景下完全可以互补。比“哪种技术更牛”更有价值的是“我们的游戏在不同设备上如何给玩家一致的画面和性能体验”。我个人在实际开发里越来越确信一件事渲染技术没有绝对的“最优解”只有“最适合当前约束的方案”。Switch 2 的算力墙是约束《星刃》的视觉目标是约束5W 到 15W 的功耗释放是约束60FPS 和低延迟的目标更是约束。在这么多约束下能想出“FSR 捞分、DLSS 精修”这种办法本身就是一种值得尊敬的工程智慧。最后再分享一个小技巧。如果你做的是跨平台项目预算又不允许养太多渲染工程师建议你把超分模块做成一个可插拔的抽象层。先写一套统一的接口把相关参数内部分辨率、目标分辨率、锐化强度、帧生成开关都做成配置项再分别接入 FSR 和 DLSS 的实现。这样你在 Switch 2 上可以用混合方案在 PC 上可以按显卡分流在移动端则可以只启用 FSR。一套代码多种策略将来不管哪家出了新版本你都能在配置层快速切换而不是翻遍整个渲染管线的源码去改逻辑。这种“务实地组合不同技术”的思路比争论哪一个超分方案更强更有用。混合方案到底能走多远还得看后续更多第一方作品的跟进但至少这次 Switch 2 的《星刃》已经给行业提供了一个足够有说服力的样本。