Earlier this year, AMD brought the previously RX 9000-exclusive FSR 4 upscaling tech to Radeon RX 7000-series graphics cards and promised an early 2027 release for RX 6000-series products. Christmas has come early for RDNA 2 and many other Radeon gamers, as Radeon honcho Jack Hyunh has announced an FSR 4.1 release for Radeon RX 6000 series cards, Xbox Series X and Series S consoles, Ryzen Z-series handhelds, and machines with Ryzen AI Max and AI 9 chips today.

To accomplish this feat, AMD says it tweaked FSR 4.1's neural network model to support the INT8 shader hardware (as opposed to the higher-precision FP8 matrix acceleration hardware on Radeon 9000 cards). Additionally, the version specific to handhelds is slimmed down even further, to less than half the size of the full one.

AMD says that compared to FSR 3, games on the aforementioned GPUs and APUs will now deliver better image quality, all else equal. With Cyberpunk 2077 running in FSR Balanced mode at 4K, our quick testing with a Radeon RX 6900 XT shows that running FSR 4 costs just about 13% performance, a small price to pay for sharper and more stable visuals, especially in motion.

And the higher upscaling quality of FSR 4.1 might let gamers use Performance mode where they might previously have used Balanced, or so on, which might offset that performance cost.

There are more goodies in store, too. The Radeon team says that FSR Frame Generation now ought to have better frame pacing, resolving a longstanding complaint with the tech and potentially making for smoother gameplay with framegen enabled. Support for the Vulkan API with FSR 4.1 is set to arrive at some point, as well, a boon for some games and console emulators. Finally, AMD says FSR Ray Regeneration will also be coming to more games, too. The company showed the tech running in Warhammer 40,000: Darktide, and that integration is available now.

To get all this goodness into your GPU, you can download the just-released Radeon 26.10.1 drivers from the AMD Adrenalin application or directly from AMD's website. The updated software also adds support for Call of Duty: Modern Warfare 4, Star Wars: Galactic Racer, and Final Fantasy Resonance. You can check out the full release notes here.

For owners of Xbox and Ryzen Z2-series handhelds, AMD says that an update from their manufacturers will be forthcoming, as those devices depend on OEM-specific drivers.

We're pleased to see that Radeon gamers are getting upgrades for their existing graphics chips along the lines of what Nvidia has been delivering throughout 2025, because the way things are going, it looks like it'll be around 2077 before there will be a new gaming graphics card launch. If you're an RDNA 2 gamer, go give FSR 4 a shot and see what you think.

Panchovix on GitHub recently released a VBIOS configurator for RTX 30-to 50-series cards that doesn’t require flashing. The loader provides a UI for easy configuration and lowers the risk of bricking your GPU by avoiding a risky flash process, and it's available for Linux, too.

Software like MSI Afterburner or ASUS GPU Tweak is often the go-to tool for quickly changing your graphics card’s settings; however, those tools have hard limits to how much you can push the graphics card. If you want to tweak your GPU beyond the firmware’s set limits, you can change it by tweaking the parameters in the VBIOS. Configuring VBIOS is similar to changing BIOS settings in the BOOT menu. With the VBIOS loader, you can change settings beyond the firmware’s hard limits.

The way it works is by storing the modified VBIOS image in the GPU’s register key; as the Nvidia driver looks for a VBIOS override on startup, it finds the VBIOS image and restarts, applying the override settings. The flash chip on the graphics card is not overwritten, reducing the risk of bricking your GPU. However, this does not protect the card from any extreme settings that could destroy electrical components; it merely provides a safer and more convenient way to adjust and apply VBIOS settings, including a way to roll back to the default VBIOS settings should you face any instability.

Bricking a flash chip isn’t as catastrophic as it seems, however. As long as you have a backed-up version of the VBIOS, you can easily buy an SPI flash chip programmer or even build your own using a cheap Raspberry Pi Pico and its many clones; sometimes programming the flash chip may not even require desoldering. Programming a flash chip is very tedious and inconvenient, though, which is why avoiding the risk of a botched flash process altogether is so appealing.

Unless you’re familiar with power delivery, voltage tables, and the patience required to test for hours, we wouldn’t recommend jumping into this unless you’re prepared to risk your GPU. However, you can still safely take advantage of this software by tweaking the fan curves and other settings you’ve applied and tested in software like MSI Afterburner if, for some reason, the startup settings don’t stick. This software will give your GPU new default settings that override at every startup, so long as Nvidia doesn’t remove the registry key that allows the VBIOS override.

With the latest ROCm updates, AMD finally brought robust, official PyTorch and HIP SDK support to Windows for consumer GPUs, fully supporting the Radeon RX 7000 and the RX 9000 series. For native, supported frameworks, AMD on Windows is finally a viable reality, but what happens when you want to run a proprietary application, an older repository, or a specialized AI tool that absolutely refuses to support anything but NVIDIA's CUDA? That's where a new project, Speedstu's "CUDA-for-AMD-Windows," could save the day. It proves that running rigidly CUDA-exclusive workloads on AMD hardware in Windows is possible without virtualization or dual-booting.

To be clear, this project is not a brand-new runtime. Instead, it is a highly automated and reproducible PowerShell setup that bridges the gap between ZLUDA, the well-known, formerly AMD-funded translation layer, and AMD's native HIP/ROCm SDK for Windows. Through a series of clever scripts, the toolkit automatically detects the user's GPU architecture, grabs a specifically pinned version of ZLUDA (v6-preview.69), and, at least in theory, seamlessly maps it to the ROCm math libraries already present in Windows.

The result is that the developer successfully intercepted and mapped the CUDA driver API as well as the cuBLAS, cuSPARSE, and cuFFT libraries directly over to their AMD equivalents. As a proof-of-concept, the author even trained a 2.2-million-parameter PPO reinforcement-learning network end-to-end using unmodified CUDA libraries on an AMD Radeon RX 9060 XT, which happens to be the only officially supported GPU at this time.

Even with AMD's official ROCm support on Windows, the local developer community frequently runs into dependency hell when trying out experimental GitHub repos or specialized AI tools that hardcode CUDA as a requirement. For developers who want to experiment with these CUDA-only tools natively on their Windows daily driver machines without dealing with WSL2 passthrough issues or waiting for the original author to write a HIP port, this project offers a highly desirable translation pipeline. It acts as a sort of hacky adapter for software that stubbornly demands an NVIDIA card.

Benchmark testing included in the project's documentation offers some interesting findings. In a controlled A/B test running a 2.2M-parameter reinforcement learning workload on a Radeon RX 9060 XT, the "public upstream path," which relies purely on official ZLUDA releases and AMD's stock HIP SDK 6.4, achieved a median throughput of 13,278 steps per second (SPS). By contrast, an optional "recovered custom overlay" apparently built from salvaged legacy ZLUDA binaries ran slightly worse at 12,876 SPS, making it roughly 3% slower. While the clean official setup is faster, the author notes that "a later rewrite removed LibTorch/ZLUDA from PPO and achieved substantially higher throughput," indicating that there is still a performance hit for this stack of translators.

Now, before anyone declares the CUDA moat officially drained, it is crucial to set realistic expectations. First, this is a solo open-source project, not an enterprise-grade solution. The author is extremely transparent about its narrow scope, as crucial machine learning libraries like cuDNN, TensorRT, and NCCL do not resolve yet. This means compatibility is strictly workload-dependent; if your specific AI tool relies heavily on cuDNN, this setup will fail. Furthermore, it's worth pointing out that ZLUDA itself is currently being maintained as a "weekend hobby project" after losing its commercial backing a second time. Relying on this pipeline for production-level work remains a massive risk. This repository is a tinkerer's tool, not a corporate IT deployment strategy.

Despite these limitations, "CUDA-for-AMD-Windows" is pretty exciting, as it proves that the barrier to entry for running CUDA-exclusive software on AMD GPUs isn't an insurmountable hardware flaw, but a relatively tractable translation tooling problem. Because the project is entirely open-source, its potential extends far beyond this initial proof-of-concept. With community contributions, we could see expanded hardware detection and clever patches to get more stubborn CUDA libraries resolving properly.