最近圈子里最热的一条新闻就是《星刃》在 Switch 2 上跑出了 60FPS。说实在的单看这个数字我并不意外——毕竟 Switch 2 用的就是 NVIDIA 定制芯片能开 DLSS 是意料之中。但让我真正提起兴趣的是媒体稿里被一笔带过的那句话“DLSS FSR 混合方案”。这两家在 PC 上打了这么多年擂台从来都是二选一结果任天堂这边直接把俩技术捏到一起用还跑出了稳定 60 帧。这事儿放在几年前想都不敢想。我第一时间就去翻了各路拆解和测试数据又结合自己折腾 PC 游戏超采样的经验捋了一遍今天就把这套混合渲染方案到底是怎么运作的、为什么 Switch 2 敢这么干、以及对咱们普通玩家意味着什么一次性讲清楚。1. 这次混合方案的爆发点为什么 Switch 2 非要“两条腿走路”1.1 先说清楚 Switch 2 的硬件底子到底是个什么水平很多人一听说 Switch 2 用上了 NVIDIA 芯片第一反应是“那肯定比 PS5 强”。这里必须泼一盆冷水。Switch 2 用的这颗定制 SoC 内部代号叫 T239GPU 部分是基于 Ampere 架构的拥有 1280 个 CUDA 核心峰值算力大概在 4 TFLOPS 上下。这是个什么概念呢PS5 的 GPU 算力是 10.28 TFLOPSXSX 是 12 TFLOPS。也就是说Switch 2 在纯光栅化性能上大概只有 PS5 的三分之一到四成。要知道《星刃》在 PS5 上的标准模式也就是 1440p 到 4K 动态分辨率、60FPS性能模式甚至还要牺牲一些特效和阴影质量。现在要搬到一台算力只有 PS5 三成的机器上还要保持 60FPS 的画面流畅度靠老办法硬扛渲染是绝对不可能的。这时候就轮到超分辨率技术登场了。DLSS 和 FSR 的核心思路都是“用低分辨率渲染再用算法放大到高分辨率”从而大幅降低 GPU 的实际渲染负载。区别在于一个是闭源的、绑硬件一个是开源的、吃通用算力。本来这两者在 PC 上是互斥的竞品但 Switch 2 的真实处境让开发者意识到也许可以换个思路让它们俩“分工合作”把各自最强的部分拿出来拼到一起。1.2 为什么只用 DLSS 还不够非要再叠一个 FSR看到这里你可能会有个疑问DLSS 质量不是公认比 FSR 更好吗那 Switch 2 本身就有 Tensor Core直接全权交给 DLSS 处理不就行了为什么还要引入 FSR这就是 PC 玩家和主机开发者思考问题的最大区别。PC 上我们只追求单帧画面的极致质量但主机要考虑的是持续的功耗、温度和帧生成时间预算。DLSS 确实质量好但它的计算开销并不低——尤其是需要 Tensor Core 参与的时间性累积计算每一帧都要消耗不少 GPU 资源。在 Switch 2 那个 4 TFLOPS 的规模下如果让 DLSS 直接接管所有放大任务GPU 需要同时负担游戏渲染和 DLSS 计算的完整流程。实测类似场景下DLSS 的质量模式大约会占用 1 到 2 毫秒的帧时间。这一来一回就直接压缩了游戏逻辑、骨骼动画、物理模拟这些 CPU 侧任务的分配空间。FSR 的优势在于它是一个纯空间算法靠的是着色器里跑的通用计算指令几乎不挑硬件而且开销极低。所以开发者选择让 FSR 先做第一轮放大把一个很低的原始分辨率比如 540p快速抬升到中等分辨率比如 810p这个过程几乎不费吹灰之力。然后再让 DLSS 从 810p 放大到最终的 1080p 或 1440p 输出。这样 DLSS 需要处理的输入分辨率就不是难看的 540p而是相对清晰的 810p时序稳定性大幅提升还不容易出鬼影。这就是“两条腿走路”的逻辑FSR 负责快速铺量DLSS 负责精细收尾各干各的强项。1.3 “60FPS”这个目标的背后是一连串严苛的预算分配很多人觉得 60FPS 就是“帧数翻一倍”这么简单但在主机开发里60FPS 意味着每一帧的总时间预算只有 16.67 毫秒。超过这个线帧生成就会延后画面就开始卡顿。我拿这个标准反推了一下《星刃》在 Switch 2 上的实际渲染管线大概能估算出开发者的时间分配思路渲染环节预估耗时说明游戏逻辑与动画系统4~5ms角色动作、AI、物理碰撞检测这部分在 CPU 上完成几何与光照渲染5~6msGPU 绘制主场景模型、贴图采样、光影计算FSR 第一轮放大1~1.5ms从 540p 提升到 810p纯空间计算开销非常小DLSS 时序放大1.5~2ms依赖 Tensor Core 进行运动矢量分析和时间累积后处理与输出1~2msTAA 淡化、色调映射、UI 叠加、缓冲区提交总耗时12.5~16.5ms勉强压进 60FPS 的及格线可以看到留给每一环的余量都很小任何一环超出预估整条管线就会打磕绊。这也是为什么最后一套方案必须是混合的——单靠其中任何一个技术都没法把帧时间压到这个安全范围内。2. 核心细节拆解DLSS 和 FSR 究竟是怎么“和平共处”的2.1 超分辨率原理对比时间换质量 vs 空间省开销要想理解这套混合方案为什么成立得先把 DLSS 和 FSR 各自的底细摸清楚。**DLSS深度学习超采样**走的是时间性超采样路线。它不只是对当前这一帧做放大处理还要参考前面几帧的运动矢量信息预测画面中每个像素接下来的移动方向然后从历史帧里“搬”细节填充到当前帧。这个过程依赖 Tensor Core 上的神经网络模型模型越新比如 DLSS 3.5 的光线重建和 DLSS 4 的 Transformer 模型预测越准画面就越干净。但也正因为是时间性算法它对输入画面的质量有要求如果原始分辨率太低、锯齿太重历史帧里就积累不出干净的细节反而容易产生鬼影和拖影。**FSRFidelityFX Super Resolution**走的是纯粹的空间性超采样路线。它是从当前这一帧出发通过边缘检测和方向性锐化算法把低分辨率图像中缺失的像素“猜”出来。这个过程不需要历史帧参与也不依赖专用硬件靠的是一组可编程的着色器指令所以兼容性极强。但它的上限也很明显在同样放大倍率下空间算法的细节还原能力不如时间算法尤其在复杂纹理区域和细碎几何边缘上FSR 容易出现闪烁和纹理涂抹。这就形成了一种天然的互补关系——FSR 不挑输入质量、速度快但最终画质不如 DLSSDLSS 画质上限高但需要一个相对干净的输入源且计算开销较大。混合方案的本质就是拿 FSR 当“预处理滤镜”把脏乱差的原始低分辨率画面先打扫干净再把接力棒交给 DLSS 做最终的美化输出。2.2 混合管线实际的执行顺序和切换逻辑我在 PC 上用 MOD 折腾过不少 DLSSFSR 共存的花样比如通过 DLSS Enabler 强制让 A 卡跑 DLSS 的替代模型或者用 DLSS Swapper 替换不同版本的 DLSS 文件。但那都是在系统层面做手脚和 Switch 2 这种游戏原生就写死两套方案的玩法完全不同。从技术角度推测《星刃》在 Switch 2 上的实际渲染流程大致是这样的GPU 先用一个极低的内部渲染分辨率比如 540p 甚至更低绘制游戏画面。这个阶段不追求清晰度只要保证光照、阴影、特效这些大框架是完整的。画面从帧缓冲区读出来以后先过一次 FSR 的缩放管线从 540p 抬升到 810p 左右。这一步主要是为了让画面边缘的锯齿先“糊掉”一部分让后续 DLSS 拿到的是比较平滑的源图像。随后810p 的画面连同运动矢量数据一起送入 DLSS。DLSS 基于 Tensor Core 做时间性超采样把 810p 放大到 1080p 甚至 1440p 的最终输出分辨率。最后叠加 UI、HUD 和后期特效输出到屏幕。关键就在于第二步和第三步的分工逻辑FSR 负责把“输入端”清洗干净DLSS 负责把“输出端”做到精致。这个链路里面还有一个小细节就是 DLSS 在处理输入时并不直接读取 FSR 输出的颜色缓冲还会读取一份运动矢量数据。所以 FSR 在放大图像时并不会破坏运动矢量信息DLSS 依然能拿到准确的时序参考。这也是这个混合方案能成立的前提之一。2.3 为什么 PC 上很少见到这种原生混合方案这个问题我想了很久后来发现原因其实很简单PC 上的 GPU 性能余量大不需要用这么抠门的方式压缩时间预算。PC 上一张 RTX 4060 跑 1080p 原生渲染绰绰有余开 DLSS 是为了追求更高的帧数上限比如从 60 拉到 144或者为了开光追。这种情况下DLSS 自身就能完整处理从低分辨率到高分辨率的全链路再引入 FSR 反而多余。更何况同时跑两套算法的 API 调度和显存缓冲管理非常复杂稍有不慎就会出现画面撕裂、资源竞争或者显存带宽瓶颈。而 Switch 2 的处境完全不同它要在极低的绝对性能下、保持比掌机模式更高的画面标准、还兼顾续航。当单靠 DLSS 或单靠 FSR 都无法满足帧时间预算时引入第二套方案就不再是“锦上添花”而是“非如此不可”。这就像你买不起一台完整的拖挂卡车但手上有一台小货车和一辆摩托你把摩托绑在小货车后面拉不动的重货让摩托搭把劲两台车凑在一起也能跑完长途运输。3. 实操视角这套混合方案对玩家意味着什么以及我们能在 PC 上模拟它吗3.1 Switch 2 玩家实际能享受到的画面提升从目前流出的实机演示来看《星刃》在 Switch 2 底座模式下的画质表现是相当惊艳的。虽然最终输出分辨率大概率是 1080p 到 1440p 之间并没有上 4K但画面锐度、细节纹理的清晰度以及高速运动时的稳定性都远超 Switch 初代机的表现。这中间最重要的提升其实是“鬼影控制”。单用 FSR 做大倍率放大时画面里的细碎元素比如头发丝、树叶间隙的光斑会因为算法猜不出正确的运动方向而出现明显的拖影和闪烁单用 DLSS 直接从 540p 拉起来时又需要 Tensor Core 花更多时间去“脑补”细节一旦补错就会产生更严重的伪影。混合方案正好避免了这两个雷区FSR 的空间算法把最容易出错的高频闪烁先压制住DLSS 再基于相对平滑的画面做时序累积最终就能得到一个干净、稳定、细节清晰的高速画面。我自己看试玩片段里高速挥剑和镜头快速转动的场景时特意逐帧观察了角色边缘和背景建筑轮廓几乎看不到类似 TAA 那种昏昏沉沉的模糊感也没有明显鬼影。这个画质表现放在一台掌机上真的是两年前没法想象的事情。3.2 普通玩家想体验建议优先关注哪几个指标如果你拿到 Switch 2 之后准备玩《星刃》我建议你关注这几个关键指标别只看“60FPS”这一个数字动态分辨率范围这决定了你在复杂场景里会不会突然看到画面变糊。如果游戏在战斗激烈时把内部渲染分辨率压到 450p 左右那即便有 DLSS 兜底输出画面也会明显发虚。好的混合方案应该把动态分辨率的最低阈值控制在 540p 以上。帧生成时间稳定性比平均帧数更重要的是“千分之一低帧”也就是最差情况下那 0.1% 的帧生成时间。如果混合超采样在场景切换瞬间发生缓冲竞争帧生成时间会突然拉到 30 毫秒以上造成肉眼可见的卡顿。这块只能等发售后看权威机构的帧时间曲线。底座模式和掌机模式的画质差异掌机模式因为功耗限制GPU 频率会大幅下调DLSS 和 FSR 的算力预算都会被压缩。很可能底座模式跑 1440p/60FPS掌机模式只能跑 720p/60FPS 或者 1080p/30FPS。这个差异会在媒体评测里重点体现。说实话我认为《星刃》在 Switch 2 上最终的目标形态应该是底座模式 1080p/60FPS 作为基准部分简单场景能跑到 1440p 输出掌机模式稳定 720p/60FPS。这套混合方案恰恰就是为这种“多模式弹性画质”量身定做的。3.3 PC 上模拟混合方案的现成工具与操作思路聊到这儿我知道肯定有 PC 玩家动心了想把这种混合方案的思路搬到自己的电脑上试试。好消息是现在确实有工具能帮助你模拟一部分效果。其中最值得一试的就是最近在 PC 圈子里很火的开源工具DLSS Swapper。它的核心功能是帮你批量替换游戏里内置的 DLSS DLL 文件——比如某款游戏内置的是 DLSS 3.5 的老版本文件你可以一键替换成 DLSS 4 的新版本模型。这个工具本身不修改游戏源码只是把nvngx_dlss.dll这个动态链接库换掉配合游戏里的 DLSS 选项就能启用新版算法。我实际操作下来DLSS Swapper 的使用过程非常简单从 GitHub 下载 DLSS Swapper 并安装它会自动扫描你电脑里装过的游戏库支持 Steam、Epic、Xbox 等主流平台。扫描完成后工具会列出每款游戏内置的 DLSS 版本号并提示哪些版本号已经过时、官方最新版本是多少。点击“替换”工具会先备份原始 DLL然后自动下载对应版本的新 DLL 并覆盖到游戏目录。进入游戏保持 DLSS 开启画质通常会比旧版本有明显提升。不过我要泼一盆冷水DLSS Swapper 只能替换 DLSS 本身并不能让一款游戏同时启用 FSR 和 DLSS。像《星刃》这种原生混合方案是需要游戏引擎层面深度定制的普通玩家在 PC 上想还原只能通过 MOD 脚本去同时调用两套 API难度非常大而且很容易冲突崩溃。3.4 一个现实问题并不是所有游戏都适合套用这套方案我在折腾过程中也踩过一些坑发现混合方案并不是在任何环境下都能带来正面收益。比如在显存带宽充足的 PC 独显上FSR 和 DLSS 同时工作画面质量反而不如单独使用 DLSS 4 的 Transformer 模型。因为模型本身已经足够聪明再叠加一层 FSR 预处理反而会把细节“磨平”。但在 Switch 2 这个场景里情况完全不同。它的 Tensor Core 数量有限DLSS 模型的推理速度被硬件绑死。在这种性能瓶颈下让 FSR 先分担一部分放大工作相当于给 Tensor Core 减负反而能提升 DLSS 模型实际处理效率。一句话总结混合方案的本质不是“叠 buff”而是“分工减负”。在性能过剩的环境里分工带来的提升微乎其微在性能匮乏的环境里分工的价值才真正凸显出来。4. 常见问题与避坑实录从 DLSS 版本替换到“真实 8K HDR”的迷思4.1 为什么替换了 DLSS 版本游戏画面反而变差了关于 DLSS 的版本替换我在 PC 圈子里见得太多了。经常有人兴奋地告诉我“我把《燕云十六声》的 DLSS 文件替换成了最新版结果画面反而模糊了。”这里面有个误区DLSS 版本并不是越新就越好。DLSS 4 的新版模型是基于 Transformer 架构的它更擅长处理光线追踪产生的高频细节但对某些游戏的特定渲染风格比如风格化渲染或者手绘贴图反而不如旧版模型匹配。DLSS 模型是要跟游戏引擎的运动矢量输出和金字塔缓冲区结构“对齐”的版本差太大时画面信息对不上号AI 模型再聪明也是巧妇难为无米之炊。我的建议是替换 DLSS 文件时优先选择“同一大版本内的小版本升级”不要跨大版本盲目替换。比如游戏内置的是 DLSS 3.5 的某个旧小版本替换成 3.5 的最新小版本兼容性基本无忧但你要直接把 3.5 换成 4.x就要做好心理准备很可能出现画面细节丢失或者闪烁。4.2 混合方案下如何判断画面到底有没有“真实”提升还有一件事让我特别想聊就是最近到处飘的“真实 8K HDR 60FPS 杜比视界 8K 视频”这种说法。我理解平台方需要一些吸引眼球的标题来拉播放量但从技术角度讲这里面水分不小。先说“真实 8K”这个概念。如果一段视频是 8K 分辨率、HDR 色深、60FPS 帧率、杜比视界编码它确实可以称为“8K 视频素材”。但如果你说的是“8K 游戏画面”那目前没有任何一款主机能从原生分辨率跑出 8K/60FPS 的 3D 渲染画面。即便是 RTX 4090 这样的顶级显卡在 8K 分辨率下跑 3A 大作也得靠 DLSS 性能模式从 4K 强行放大上去跟“原生 8K”完全是两个概念。普通玩家要识别这些信息其实很简单看视频 производитель 标注的是“原生分辨率”还是“输出分辨率”。如果是用超采样技术放大到 8K 输出的只能叫 8K 输出不能叫 8K 原生渲染。就像 Switch 2 上《星刃》跑 60FPS输出分辨率大概率是 1080p 或 1440p你硬要说它跑的是“4K 60FPS”那就属于概念混淆了。4.3 排查实录混合超采样最常见的四个典型问题我在折腾 PC 超采样工具时整理过一张高频问题排查表这里分享出来玩《星刃》或者折腾 DLSS Swapper 时都能用得上问题表现可能原因排查方向画面边缘出现白色描边FSR 锐化强度过高调低 FSR 内部锐化参数或改到质量模式而非性能模式高速运动时人物周围有透明拖影DLSS 时序累积失效检查运动矢量数据是否正常输出关闭屏幕空间反射后再测试帧数骤降且无法稳定 60FPSFSR 占用时间超出预算确认原始渲染分辨率是否过低导致 FSR 放大倍率超过 2.5 倍画面间歇性模糊闪烁两套算法的缓冲区格式不匹配检查 FSR 输出是否为 RGBA16F 格式DLSS 对该格式兼容性最好4.4 关于“A 卡用 DLSS”的传言别被带偏了最后再聊聊“A 卡用 DLSS 的方法”这个话题。很多朋友看到这个说法以为是 AMD 显卡在未来能原生支持 DLSS其实并不是。A 卡确实可以通过第三方工具比如 DLSS Enabler把一个叫 FSR 的模型转成类似 DLSS 的替代品然后模拟跑一些原本只有 DLSS 的游戏。但这本质上是在用 FSR 的算法“披上”DLSS 的外壳走的还是 AMD 的通用着色器不会真的启动 NVIDIA 的 Tensor Core效果跟原生 DLSS 差距明显。我理解很多 A 卡用户希望体验 DLSS 的心情但说实话与其折腾这些兼容层不如直接去玩那些原生支持 FSR 3 的游戏。FSR 3 最近几个版本的质量提升非常大尤其是帧生成部分在不少游戏里已经能接近 DLSS 3 的效果。超采样技术本身就是个持续进化的领域没有谁能永远领先一个身位。5. 展望混合采样会是未来游戏开发的标配吗5.1 从 Switch 2 反推整个行业的技术风向《星刃》在 Switch 2 上采用 DLSSFSR 混合方案这件事短期看是任天堂为了在这颗不算强的芯片上跑出次世代画面所做出的妥协方案。但往深了想它可能给整个行业打开了一扇新大门。过去超采样技术之争停留在“哪个技术更好用”的二元逻辑里开发者必须在两套方案里选一个嵌入游戏引擎。但《星刃》的例子证明了两套方案可以同时在一条渲染管线里工作这给了开发者极大的技术自由我完全可以根据不同 GPU 的硬件特性动态调整两套算法的参与比例。比如在同一款游戏的 PC 版里N 卡用户让 DLSS 出力 80%、FSR 出力 20%A 卡用户反过来到了 Steam Deck 这类掌机平台还能进一步调低 DLSS 的参与比例以降低功耗。这种“按硬件负载动态分配超采样任务”的思路未来会成为引擎级的功能也说不定。5.2 开发套件和引擎方面接下来会有什么变化从技术演进的角度看我认为 UE5 在后续版本里很可能把“多超采样方案融合”作为正式功能推出。目前已经有民间开发者通过在引擎蓝图里同时调用 FSR 和 DLSS 的接口成功跑通了两者的串联管线。如果 Epic 官方愿意下场支持那这项技术的应用门槛会急剧降低。特别是 UE5 的渲染管线本身已经非常复杂Lumen 全局光照和 Nanite 虚拟几何体都消耗大量 GPU 资源。在 30 系、40 系显卡上跑还好一旦要移植到掌机或者低功耗设备上超采样的压力会成倍增加。这时候双方案混合就成了一条务实的出路FSR 先把基础的几何载体跑稳DLSS 再负责把光影细节补齐全。5.3 但也要警惕一个潜在风险任何技术都有它的适用边界。混合方案最大的隐患是调试成本呈指数级上升。两套算法串行工作意味着画面中的每个像素都要经过两次处理和两次采样任何一个环节的精度损失都会被另一套算法放大或者抵消。这对开发团队的渲染调试能力提出了极高的要求。我自己在 PC 上折腾双超采样管线时最头疼的就是定位“画面的模糊感到底来自哪一步”。你很难判断是 FSR 预处理太粗暴还是 DLSS 时序累积时输入帧率不够稳定。这个问题在开发机上还会被放大十倍因为开发机的性能与正式零售机有差异调试好的参数不一定能在量产机上复现。所以《星刃》团队能把这套方案实装到 Switch 2 上并保持稳定 60FPS背后的工程能力确实值得认可。最后再分享一个我自己的体会。我最初看到“DLSS FSR”这种组合时第一反应是“这不是胡闹吗俩竞品咋可能共存”。但仔细拆解完 Switch 2 的硬件限制和帧时间预算后才意识到技术方案从来没有“绝对的对错”只有“合适不合适”。在 PC 这颗大树下衣食无忧地长大的玩家可能很难体会主机开发者那种在钢丝上跳舞的感觉。但也正是这种极限条件下的技术整合才不断推动着超采样技术的边界。以后你看到一款游戏在矮子里面拔高个、硬是跑出了惊艳画质时不妨也多看一眼它背后那些“不讲武德”的技术混搭——很多时候惊喜就是这么来的。