AMD BC-250 FSR 4 Mod 将超分辨率时间减半，但真正的考验是游戏表现

根据随社区构建的 FidelityFX DLL 一同发布的基准测试，AMD BC-250 的 FSR 4 处理速度已大幅提升。在 1440p 下，报告中的超分辨率开销从 11.51 毫秒降至 5.92 毫秒。这一降幅让 FSR 4 不再只是昂贵的实验，而成为这块特殊 RDNA 架构板卡上更具可行性的选择。

BC-250 从未被设计为传统游戏 PC，因此这一结果尤为重要。AMD 为 ASRock 矿机系统生产了这款半定制处理器，其硅芯片与 PlayStation 5 处理器密切相关。随后，Linux 爱好者通过定制固件、驱动、散热方案和安装工具，将被淘汰的板卡改造成紧凑型游戏设备。

这次发布将核心问题从基础兼容性转向实际性能。此前的优化工作依赖修改后的 Mesa 图形栈；最新实现则将改动封装在可移植的 FidelityFX 库中，用户可将其与 OptiScaler、Proton 等工具一同安装。

不过，报告中的数据衡量的是超分辨率器本身，而非完整游戏性能。开发者公布的是合成 RC9 测量结果，最新的实际游戏测试仍然有限。这项成果确实值得关注，但其价值仍取决于稳定性、画质以及在真实游戏中的表现。

AMD BC-250 FSR 4 处理时间在三种分辨率下均有所下降

RC9 版本将 FSR 4.1.1 在 1080p、1440p 和 4K 下的测量开销大约减半。

最重要的结果来自使用 1706 x 960 Quality 输入、输出为 2560 x 1440 的测试。原始 FSR 4.1.1 着色器据称需要 11.51 毫秒才能完成整个超分辨率调度。4.0.0-rc9 版本则在 5.92 毫秒内完成了同样的测量工作负载。

这意味着开销减少约 49%。同时，它为渲染管线的其余部分腾出了近 5.6 毫秒。对于目标为每秒 60 帧、每帧仅有 16.67 毫秒预算的游戏而言，这一差异相当显著。

其他记录的分辨率也呈现相同趋势。在 1920 x 1080 下，处理时间从 7.13 毫秒降至 3.93 毫秒；在 3840 x 2160 下，则从 25.72 毫秒降至 12.08 毫秒。

这些结果分别相当于约 45% 和 53% 的降幅。因此，改进似乎并不局限于某一种输出分辨率。随着输出分辨率提高、超分辨率器需要处理更多像素，绝对节省的时间也会增加。

开发者的 RC9 release 将优化代码打包为 amd_fidelityfx_upscaler_dx12.dll。该库会在受支持的集成路径中充当 FidelityFX 超分辨率提供程序，无需此前的定制 Mesa 构建即可替换相关超分辨率组件。

根据公开的 test summary，这些数据反映的是独立 FSR 调度开销，而非完整帧时间或游戏平均性能。CPU 工作、游戏渲染、着色器编译、转换层以及显示同步均不在测量范围内。

这一差异意味着，不能将节省的毫秒数直接换算为增加的帧数。受 CPU 限制的游戏可能几乎不会改善；而严重受 GPU 限制的游戏则可能获益更多，尤其是在此前超分辨率阶段占据大量帧预算时。

即便如此，这些数字仍解决了一个具体障碍。在 RC9 之前，FSR 4 已能在 BC-250 上技术性运行，但超分辨率器可能耗尽高刷新率帧预算的大部分。将这一负担近乎减半，使更广泛的测试变得值得。

因此，这次发布改变了问题的性质。社区不再只需询问 FSR 4 能否在该板卡上执行，也可以探究优化路径是否足以改善完整游戏体验，从而值得安装。

可移植 FidelityFX DLL 取代了定制 Mesa 路径

核心进展在于可移植性，因为优化现在随超分辨率器一起部署，而非依赖专用图形驱动。

最初的 BC-250 优化面向 Mesa——Linux 系统常用的开源图形栈。它修改了 RADV Vulkan 驱动对 FSR 4 所使用 INT8 操作的处理方式。INT8 指八位整数运算，机器学习模型使用它来降低处理与内存成本。

这项工作解决了 BC-250 的 GFX1013 图形处理器的一项特殊限制。该板卡能够执行所需工作负载，但其有符号打包整数点积路径性能较差。点积结合了多次乘法与加法，是神经图像处理模型中的常见运算。

此前的项目以更适合 BC-250 的指令序列替代了这条高成本路径。其代码库将其描述为实验性 Mesa 构建：使用替代整数指令，而不是依赖存在问题的原生路径。该修改针对特定设备标识符和经过验证的着色器集。

这种方案证明了性能提升的机会，但部署工作位于驱动栈中。用户需要专用 Mesa 构建，并通过正确的 Vulkan 配置启动游戏。Mesa、Proton 或 Linux 发行版发生变化时，驱动修改也会带来维护成本。

可移植实现将优化迁移至 FidelityFX DLL 中。这样，超分辨率器成为可替换组件，而非全系统驱动变体。用户可将该库置于受支持的游戏或适配器配置中，并且无需重建 Mesa 即可移除它。

项目的 installation guide 表示，RC9 不需要旧版兼容性工具或特殊驱动安装。其经过测试的范围仍限于通过常规 Proton 运行 Linux 的 BC-250 硬件。Proton 是 Valve 用于在 Linux 上运行 Windows 游戏的兼容层。

OptiScaler 可以充当游戏与 FidelityFX 库之间的适配器。它会拦截可用的超分辨率路径，然后提供所选后端。即便注入的 FidelityFX 提供程序执行最终超分辨率处理，游戏菜单仍可能显示 DLSS、FSR 或 XeSS。

这一安排提供了灵活性，但也增加了配置变量。游戏需要兼容的时序输入，即重建更高分辨率图像所需的运动矢量及其他帧数据。DLL 本身无法为从未生成这些信息的游戏添加它们。

用户还需要确认 RC9 是当前激活的提供程序。该项目建议启用内置水印，并检查 FSR-INT8、4.1.1R9 和本地源标签。校验和可确认已安装文件，而渲染出的水印可验证由哪个提供程序处理图像。

这一点很重要，因为 Proton 前缀或经 Mod 修改的游戏目录中可能同时存在多个超分辨率组件。自动驱动更新、现有 OptiScaler 文件和游戏补丁，都可能悄然恢复另一套库。能够正常打开的菜单并不能证明优化模型正在渲染场景。

因此，可移植性并不等于通用兼容性。它意味着优化已被转移到一个更易安装、验证、替换和回滚的软件包中。对于围绕不受支持硬件构建的社区项目而言，这是一项重大的运营改进。

为什么 BC-250 让这一结果不只是 Mod 圈的趣闻

更快的超分辨率器延续了从专用挖矿产品中挖掘可用游戏硬件价值的更大努力。

BC-250 结合了六核、12 线程 Zen 2 CPU 和集成式 GFX1013 图形处理器。原始板卡提供 24 个计算单元，并配备 16 GB GDDR6 统一内存。与普通桌面设备不同，该系统不依赖独立 DDR 内存模块。

社区 hardware documentation 将该板卡描述为采用非标准外形规格的定制矿机设计。它缺少视频编解码硬件，普通 PC 机箱或散热器无法直接适配。其存储连接能力也比常规主板更受限制。

该处理器源自与 Sony PlayStation 5 相关的同一大类半定制硅芯片系列。然而，将 BC-250 称为桌面版 PS5 会夸大两者的关系。其启用的 CPU 核心、图形配置、固件、I/O 和运行环境均与游戏主机不同。

随着加密货币挖矿需求减弱，这块板卡进入了爱好者市场。Mod 制作者随后开发出固件补丁、Linux 驱动支持、风扇控制、机箱以及面向游戏的发行版。每一项改进都消除了这类硬件的一项限制——它原本并没有常规消费者支持渠道。

此前的项目已经证明，原始配置可通过 Linux 运行要求较高的 PC 游戏。社区成员后来还尝试在兼容处理器上恢复被禁用的 CPU 核心，并启用更多物理图形计算单元。这些修改取决于芯片，无法在每块板卡上生效。

FSR 4 为这一硬件再利用努力又增加了一层能力。AMD 当前的 FSR SDK 结合空间与时序数据以及机器学习模型，以重建更高分辨率画面。它通过官方支持的实现面向较新的图形平台，而 BC-250 支持则来自社区工程工作。

其中的矛盾很清晰。FSR 4 有望提供比旧版超分辨率器更好的重建画质，但其模型也带来显著处理成本。在受限板卡上，超分辨率器可能抵消以较低输入分辨率渲染所获得的性能收益。

在 1440p 下，原本 11.51 毫秒的开销占据了约 69% 的 60 fps 帧预算。这一计算仅涵盖 FSR 调度；游戏仍需要时间处理几何、光照、特效、CPU 模拟、驱动工作和最终显示。

RC9 将这一占比降至约 36%。新数据依然昂贵，但为实际游戏留下了更多空间。在 4K 下，从 25.72 毫秒降至 12.08 毫秒，使超分辨率器的开销低于完整 60 fps 帧预算。

这并不意味着 BC-250 很可能实现 4K 60 fps 游戏。其余工作负载仍需处理时间，板卡的图形性能依旧有限。但这表明，优化超分辨率器为何比仅让它成功启动更重要。

AMD BC-250 FSR 4 项目也体现了开放 Linux 组件的价值。开发者能够检查着色器行为、识别高成本指令路径、测试替代方案，并将结果打包。在完全封闭的驱动与应用链中，这一过程会更加困难。

但该项目部分依赖逆向工程和第三方集成。AMD 尚未将 RC9 作为官方 BC-250 版本推出。用户必须将该 DLL 视为面向小众设备的实验性软件，而非受支持的 Radeon 驱动功能。

真正的对手是缺乏实际性能的兼容性

RC9 直面了“让 FSR 4 跑起来”与“让它在完整游戏帧中真正有用”之间的差距。

兼容性演示往往能呈现出引人注目的截图：某项功能成功加载，水印出现，硬件渲染出了其厂商从未正式支持过的图像。这证明了技术层面的可访问性，却几乎无法说明延迟、稳定性或持续游戏体验。

BC-250 已经跨过了兼容性门槛。此前社区的工作表明，FSR 4.1.1 可以通过该主板的 Linux 图形栈运行。问题在于其机器学习着色器耗时过长，尤其是有符号压缩整数运算。

在 1440p 下，单次 11.51 毫秒的超分处理会对任何性能目标造成巨大压力。30 fps 的单帧时长为 33.33 毫秒，因此更容易吸收这部分开销。60 fps 的目标只允许一半时间，而 120 fps 则仅有 8.33 毫秒。

RC9 的 5.92 毫秒结果本身已能纳入 120 fps 的单帧预算。显然，当计入其他所有工作后，完整游戏并无法满足这一预算。不过，优化后的调度不再会在游戏渲染其他任何内容之前，就耗尽整段预算。

这正是该项目的核心转变。FSR 通常通过让游戏渲染更少像素来提升性能。但在未经优化的 BC-250 路径上，重建过程可能会吞掉大量节省下来的时间。这项功能的解决方案反而有可能成为新的瓶颈。

优化后的 DLL 缓解了这一矛盾。它并未消除成本，但缩小了理论支持与可用性能之间的差距。这让开发者和用户能更自由地将 FSR 4 与 FSR 3、XeSS 或更低的原生分辨率进行比较。

这些比较需要严格控制变量。每种超分技术采用不同的重建逻辑，并可能提供不同的质量模式。某一实现中的 Quality 设置，不一定与另一种实现的输入分辨率、锐化程度或视觉表现相匹配。

图像质量同样比单纯的调度耗时更重要。如果更快的着色器会引入不稳定、鬼影、闪烁、反遮挡错误或界面元素损坏，其价值就微乎其微。这些问题往往在运动过程中出现，而非静态截图中。

平均帧率也存在同样的问题。基准测试可能显示更高的平均值，却伴随着不均匀的帧输出。帧时间百分位数和可见卡顿，往往才决定一款游戏是否真的感觉有所改善。

因此，RC9 必须与更简单的选项竞争。用户可以选择开销更低的旧版 FSR 实现、降低原生设置，或接受更低帧率。只有当 FSR 4 的图像质量提升足以证明其剩余开销和安装复杂度是值得的，优化后的 FSR 4 路径才算胜出。

该项目并不需要击败每一种替代方案。只要能在特定设备上的少数高负载游戏中带来改善，社区工具就可能很有价值。不过，在解读该基准测试时，这一更狭窄的标准应保持明确。

这也正是便携式 DLL 与 headline 数字同样重要的原因。更简单的安装降低了进行真实比较的成本。更多用户能够测试相同的二进制文件、报告可复现的结果，并识别出这种取舍有效的游戏。

该基准测试尚未证明什么

已发布的数据表明超分调度速度更快，但尚未证明其具有等效的视觉质量，或能在不同游戏中带来可预测的提升。

首个不确定因素是测试范围。项目文档称，其记录的七项游戏测试使用的是更早的 RC7 构建版本。RC9 已完成合成验证，并提供了已安装的 Cyberpunk 2077 配置，但指南并未宣称已在每款游戏中重新进行 RC9 游戏测试。

这一差距并不会使基准测试失效。合成测试能够隔离超分器，使优化前后的比较更加直接。只是它回答的问题比游戏基准测试更有限。

完整评估需要来自可重复场景的平均帧率、1% low 结果和帧时间图表，也应比较完全相同的输入与输出分辨率。没有这些控制变量，CPU 波动或无关的渲染变化可能会掩盖 DLL 的影响。

第二个不确定因素涉及视觉等效性。该基准测试表明，优化路径能更快地处理工作负载。但它并未独立证明每一个输出像素都与 AMD 原始路径一致，也未证明游戏过程中的时间性表现保持不变。

机器学习超分器可能以特定场景的方式失效。精细几何结构可能出现闪烁，透明效果可能损坏，粒子可能留下拖影，新近显露的表面也可能出现重建错误。快速镜头移动常会暴露静态截图掩盖的问题。

第三个问题是游戏兼容性。OptiScaler 提供多种注入路径，但每款游戏暴露的 API 和时序数据各不相同。反作弊系统、启动器、更新和渲染器变更，都可能导致原本正确的安装无法工作。

原生 FidelityFX 集成也各不相同。一款有文档记录的游戏需要一个经过特定重命名的加载器库，另一款则使用 OptiScaler 后端。项目明确警告，不应将某款游戏的文件替换方式用于无关游戏。

第四个不确定因素是平台范围。RC9 面向在 Linux 与 Proton 环境下运行的 BC-250 硬件。该指南并未承诺支持原生 Windows 或其他 GPU。便携式 DLL 更容易转移，但文件的可移植性并不能证明其优化行为同样可移植。

该实现还是未签名的第三方软件。用户应从指定发布版本获取它、验证校验和，并保留被替换文件的备份。游戏更新可能覆盖该库，或造成需要回滚的不兼容问题。

更广泛的 RDNA 2 影响尤其尚不明确。BC-250 使用了一种不寻常的 GFX1013 处理器，具有特定的指令行为。对该设备有效的变通方案，无法自动预测 Radeon RX 6000 显卡、Steam Deck 硬件或主机处理器上的性能。

这项报道的基准测试也来自一个小型改装生态系统。独立复现应在不同主板、频率、固件版本和散热条件下验证这些数据。

散热值得关注，因为持续着色器负载的表现可能不同于短时测试。散热不足的主板可能在长时间游玩后降低频率，从而削弱或掩盖短暂合成运行中观察到的性能收益。

主板差异又增加了一层复杂性。一些 BC-250 处理器可稳定支持解锁核心或计算单元，另一些则只能在原厂配置下保持稳定。基准测试必须清楚标明启用的硬件、频率、功耗限制、固件、Mesa 版本和 Proton 构建版本。

这些限制都不会抹去已报告的降幅。它们界定了现有证据所能支持的结论。RC9 看起来确实能让目标系统上的 FSR 调度显著加快，但完整游戏层面的价值仍是一项有待验证的主张。

这种谨慎解读比将结果视为通用 FSR 4 支持更有利于项目本身。清晰的边界有助于用户复现工作，也有助于开发者确定哪些问题仍需要工程投入。

三个信号将揭示 RC9 是否改变 BC-250 游戏体验

下一阶段必须把合成效率与可重复的游戏表现、视觉稳定性和可维护的分发方式联系起来。

第一个信号是受控的 RC9 游戏基准测试套件。Cyberpunk 2077 和 Control 是合理的起点，因为项目已经记录了两者的安装路径。测试应在相同设置下比较原始着色器、RC9 和旧版超分器。

最有价值的报告将包含平均性能和帧时间百分位数，同时记录完整帧时间以及独立的 FSR 成本。如果 RC9 在 GPU 受限场景中带来一致提升，当前基于机制的结论将显著增强。

如果完整游戏性能几乎没有变化，这项基准测试仍能为开发者带来启示。它将表明渲染管线的另一部分占据主导地位。该优化可能在技术上仍然有效，却无法实质改善某一特定游戏。

第二个信号是独立的图像质量验证。用户应捕捉运动、精细几何、粒子、反射、界面元素和反遮挡表面。比较需要采用相同的镜头路径和输入分辨率，而不是无关的截图。

若能稳定地匹配原始输出，将强化 RC9 以大幅降低成本提供近乎相同重建效果的主张。即便时序优势依然存在，持续出现的鬼影或闪烁也会削弱其实际价值。

第三个信号是通过维护完善的 Linux 软件包和安装工具实现的采用。该 DLL 已经减少了对自定义 Mesa 构建的依赖。若能持续集成至 BC-250 发行版、Proton 工作流及固定校验和的软件包中，测试将更具可重复性。

一个 Linux 项目已经将该分支作为实验性的 OptiScaler 选项提供，同时警告未签名构建并非推荐方案。这种定位是恰当的。可复现的打包能够让实验性软件更安全，而不将其转变为官方支持。

游戏、Proton 和驱动更新后的维护情况，将揭示可移植性能否经受真实使用的考验。频繁失效的替换库会带来隐性成本。具备清晰回滚说明的稳定软件包，则会让这项优化成为实用基础设施。

短期内 AMD 的回应不那么重要，但仍值得关注官方支持。该公司掌控 FSR 的开发和受支持的 Radeon 路径。社区发现可以揭示需求，但并不保证 AMD 会支持这款源自挖矿的处理器。

对 BC-250 用户而言，合理的下一步是有节制地进行实验：验证发布文件，保留原始库，确认渲染水印，并对可重复场景进行基准测试。在决定剩余开销是否值得之前，先比较视觉表现。

对于图形开发者而言，该项目提供了一个关于软件假设的更广泛教训。围绕较新整数硬件设计的模型，即使某个特殊处理器能执行所需指令，也可能在其上表现不佳。有针对性的着色器工作能够找回通用路径未加利用的性能。

因此，AMD BC-250 FSR 4 的结果之所以令人期待，原因非常具体：它将一次专门的驱动实验转化为便携式软件包，并将测得的工作负载几乎减半。它并未证明通用支持或保证帧率提升。

决定性证据应来自普通游戏，而不是又一个孤立数字。RC9 是否能在高负载场景中改善帧时间稳定性，同时保留稳定的重建细节？对这一问题的可复现答案，将决定这款 DLL 是成为 BC-250 游戏体验的长期组成部分，还是停留在令人印象深刻的技术演示阶段。