The project reports this result, but it needs careful interpretation. Although the project has published detailed data and methodology, no independent reproduction of its timing or image findings was identified. The result is not evidence that a game’s whole rendering time was cut in half, and it does not establish a corresponding frame-rate increase. It is a project-reported measurement of isolated upscaler work in a controlled Direct3D 12 scene on one highly unconventional platform. For Windows gamers, the important message is both promising and limited: shader-level work may substantially reduce a costly graphics workload, but this release does not yet qualify native Windows operation, retail-game gains, or broad GPU compatibility.
What RC9 is intended to change
The BC-250 FSR4 v4.0.0-rc9 pre-release was published by the developer on September 11, 2026. It distributes a Windows x64 replacement DLL labeled version 4.1.1r9. According to the project, it is intended for use through a compatible native FidelityFX integration or a separately installed OptiScaler configuration.
That delivery method is important. The project does not present RC9 as a new AMD driver branch or an official AMD FSR release. Instead, it uses a portable replacement-DLL approach intended to place the project’s optimizations closer to the application layer. The project says this avoids a need for an RC9-specific Mesa driver or Proton tool in its qualified BC-250/Linux environment.
That claimed convenience is not the same as universal compatibility. The release leaves native Windows, other GPUs, frame generation, and unlisted integrations unqualified. A replacement DLL can depend on the game’s FidelityFX API version, wrapper configuration, graphics driver behavior, anti-cheat policy, and game updates. Windows users should therefore treat RC9 as an experimental modding development rather than an FSR 4 update suitable for installation throughout a game library.
The reported benchmark, accurately framed
The headline figure comes from the project’s 2560×1440-output test in FSR Quality mode, using a 1706×960 input. In that specific setup, the project reports:
- Original FSR 4.1.1 shaders: 11.51 ms for a complete upscale dispatch
- RC9 replacement DLL: 5.92 ms for a complete upscale dispatch
The claimed reduction is approximately 48.6%. In other synthetic test cells, the project similarly reports substantial reductions in isolated whole-upscaler GPU cost:
- At 1080p, the reported cost moved from 7.13 ms to 3.93 ms.
- At 4K, the reported cost moved from 25.72 ms to 12.08 ms.
These figures are GPU timestamps around the entire FidelityFX dispatch. They are meaningful because upscaling consumes part of a frame’s GPU budget, and a reduction of several milliseconds could matter where that workload is particularly expensive. They are not, however, total game frame times.
A full game frame includes more than upscaling: CPU simulation and submission, geometry, rasterization, lighting, shadows, post-processing, ray tracing in applicable titles, compositing, and presentation all consume time. Consider a hypothetical frame that spends 5 ms on upscaling and 20 ms on other work. Reducing the upscaler cost by 2.5 ms improves the total, but does not halve the 25 ms frame. A title unusually constrained by this particular workload could benefit more, while a CPU-limited or otherwise GPU-limited game might show little practical difference. The project’s synthetic dispatch figures alone cannot determine which outcome applies to a particular game.
What the project methodology supports—and does not
The project describes four independent 600-frame launches for each test cell. It reports discarding the first 300 frames from each run and calculating medians from the remaining measurements. It also reports that all scored periods ran at a GPU clock of 1850 MHz. Repeated runs, a warm-up exclusion, median reporting, and disclosed clock behavior are useful controls that can reduce some common sources of benchmark noise.
The timing target is also clearly defined: project-reported GPU timestamps surround the complete FidelityFX dispatch rather than an unspecified shader stage. That makes the result relevant to the GPU cost of invoking the upscaler itself.
But the test design has important boundaries. It uses a controlled synthetic scene rather than a retail-game benchmark. As described, it does not incorporate the interaction between an actual game engine and the upscaler, including scene complexity, memory pressure, dynamic resolution, driver overhead, and presentation behavior. The reported measurement also excludes input upload, output readback, CPU time, and shader compilation.
It is also a one-board result. The project’s test environment used one BC-250, standard Mesa, and GE-Proton 11-6. BC-250 is not an ordinary supported desktop Radeon product, so the project-reported numbers cannot be assumed to transfer to current retail Radeon cards, Nvidia GPUs, or Intel GPUs.
There is a further timing caveat in the project’s own disclosure. RC9 was freshly measured on September 11, while the three baseline arms retained measurements from September 10. The project does not represent the result as a newly interleaved four-way campaign. Its reported clock control and test procedure help provide context, but separate test windows are still a reason not to overstate the precision of the comparison.
Most importantly, detailed project documentation is not a substitute for independent replication. No independent lab reproduction was found for the RC9 performance or image results. That distinction matters particularly for a community project working on rare hardware and a custom software path.
Reported image matching is not a universal quality verdict
The project reports matching final images in its synthetic validation cases, including 16 final images in the timing dataset. That is a useful validation within the tested cases. A faster path that visibly corrupted its outputs would not be a meaningful optimization.
Yet the scope of that claim remains narrow. The project-reported matches support the conclusion that tested synthetic outputs matched; they do not establish identical visual quality in every game, resolution preset, scene, or integration. They also cannot establish behavior across all camera-motion patterns, transparency effects, particles, user-interface composition, or hardware configurations.
This is especially relevant to temporal upscaling. Differences can emerge in motion-related conditions that a limited set of final-image comparisons may not reveal, including ghosting, disocclusion behavior, fine-detail stability, and temporal artifacts. The project additionally states that RC9 received no new game-rendering or endurance checks. As a result, game-session stability, save-and-reload behavior, driver resets, and complete-campaign image behavior remain unqualified rather than demonstrated.
RC9 should not be conflated with older Mesa work
The reported RC9 result is easy to blend with earlier BC-250 graphics-stack experimentation, but they concern different layers of the software path. A predecessor effort focused on Mesa-side shader handling. That earlier project identified an expensive software fallback for signed packed-dot operations and described signed i24 MUL24/MAD24 lowering. It also said the BC-250’s native signed packed-dot instruction remained disabled because direct tests reportedly produced incorrect results.
Earlier reporting described a representative shader instruction count declining from 64,269 to 37,613 in that older context. It helps explain why BC-250 FSR experimentation attracted interest: this unusual hardware and software combination appears to have exposed inefficiencies that encouraged low-level investigation.
That older instruction-count result should not be assigned to RC9’s DLL itself. RC9 packages its optimization work as a replacement DLL, while the earlier Mesa/RADV path concerned driver-side shader behavior. Combining both into a single claim of “50% faster FSR 4” would obscure what changed, where it changed, and whether the improvement might apply elsewhere.
Why BC-250 makes this technically interesting but commercially uncertain
The BC-250 became publicly notable through reporting in 2022 about an ASRock cryptomining system containing 12 BC-250 cards. Later reporting and community investigation described resale boards with six Zen 2 CPU cores, 24 enabled compute units, and 16 GB of GDDR6. Those descriptions come from reporting and community work, not from a familiar AMD consumer-product specification and support program.
The board’s connection to PlayStation 5-family silicon adds to its appeal for enthusiasts, but its exact architectural designation should be treated cautiously. Community documentation identifies the GPU as Cyan Skillfish/GFX1013 and associates it with the PS5 family, while qualifying exact die comparisons and classification. Calling the device definitively “RDNA 2-powered” would be convenient shorthand rather than a settled, vendor-confirmed specification on the available evidence.
Community projects also report that 40 physical compute units can be re-enabled from a stock 24-CU configuration on tested boards. Separate third-party firmware work claims to restore two CPU cores, moving a board from six to eight. Neither modification is vendor-supported, and neither should be presumed safe, available, or successful on every resale board. Board variation and silicon-lottery risk are practical concerns.
This unusual environment is why the RC9 result deserves technical attention while remaining commercially uncertain. The project reports a large reduction in the measured cost of a specific synthetic workload on hardware that mainstream drivers and game-testing programs do not target. That does not show that the same approach is stable, useful, or transferable to a typical Windows gaming PC.
What Windows users should take from it
For most Windows players, watching rather than installing is the proportionate response. The project explicitly leaves native Windows behavior unqualified. The presence of a Windows x64 DLL does not independently establish operation in Windows games, on Windows driver stacks, or alongside anti-cheat systems. A successful project-reported test using Mesa and Proton should not be treated as proof of safe Windows deployment.
Experienced modders with the precise compatible hardware and an explicitly supported integration may see a reason to inspect the release details and preserve a rollback route. Keeping original files, knowing how to verify game files, avoiding multiplayer or anti-cheat-sensitive use unless compatibility is specifically established, and testing carefully are sensible precautions. Frame pacing, visual stability, crashes, and long-session behavior are more useful signals than an isolated millisecond figure.
The responsible conclusion is narrower than the most dramatic headline. A community project reports that its RC9 DLL reduced the BC-250’s measured complete upscaler-dispatch GPU cost from 11.51 ms to 5.92 ms in one controlled 1440p synthetic setup. The project also reports matching outputs in its limited synthetic checks. Whether that result produces better game frame rates, sustained image quality, reliable Windows behavior, or broad compatibility remains unresolved pending retail-game and independent testing.