When Microsoft and Qualcomm launched the first Copilot+ PCs sporting Snapdragon X Elite processors, the CPU performance was beyond reproach, but whether due to immature software or underwhelming integrated hardware, the GPU horsepower left a lot to be desired. The easiest way to solve that is to hook up a discrete GPU, of course, but nobody's managed that yet. Instead, an enterprising hacker in China has become the first person to publicly get an Nvidia GeForce RTX GPU running on an Arm-based platform using Windows 11, but it's not Snapdragon, and it's not an Nvidia CPU, either, WindowsLatest reports.

We knew that the Nvidia RTX Spark processors used an integrated GPU directly derived from Nvidia's Blackwell technology, and we also knew that those machines would run Arm Windows 11, so this was bound to happen sooner or later, because that necessarily means that there is an Nvidia client graphics driver for Arm-based Windows 11 out there. That's exactly what "VoidTech" on BiliBili used for his experiment, though the experiment wasn't without some pitfalls.

Specifically, VoidTech got an Nvidia GeForce RTX 4060 8GB graphics card working in a Huawei Qingyun W510 workstation. This machine does not have a Snapdragon processor, of course; Huawei makes its own CPUs, and indeed this chip is the Kunpeng 920, created by Huawei's HiSilicon division. This chip was considered a major milestone when it was introduced in 2019, as it's a 7nm server CPU with up to 80 cores, although the specific implementation in the Qingyun W510 has "only" 24 cores.

All those cores don't help it much in gaming. As PC gamers will be well aware, CPU gaming performance is basically down to single-threaded CPU performance and system memory latency. The custom TaiShan v110 cores in the Kunpeng 920 only offer up around a sixth of the single-core performance of something like a Ryzen 9 9700X, at least going by Passmark, with the usual caveats that apply to Passmark. Combined with relatively small caches and a DDR4 memory interface that's clearly tuned for throughput, not latency, and you have a recipe for middling gaming performance. That's before we even start talking about x86 emulation penalties.

So did it work? Well, more or less. Actually, the GeForce RTX 4060 did about half of its job flawlessly, running advanced games like the Unreal Engine 5-based Black Myth Wukong and slightly less advanced games (Genshin Impact), as well as various 3DMark tests. Most software seemed to work without any issues aside from overall weak performance due to the slow Kunpeng 920 CPU; the Wukong benchmark finished at 21 FPS, while Genshin Impact struggled to break 25 FPS and stuttered frequently. However, Arknights: Endfield refused to launch, likely due to an incompatibility between its restrictive "Anti-Cheat Expert" package and the Prism translation layer required to run the x86 Windows games on Arm Windows.

The half of its job that the RTX 4060 didn't do was that VoidTech wasn't actually able to get a video signal out of the graphics card. He notes that the graphics card was recognized, and the monitor was picked up, too. He simply couldn't get the system to properly push pixels to the monitor. This likely comes down to the Nvidia Arm driver being built specifically for the RTX Spark and thus missing the necessary code to support the HDMI and DisplayPort encoders on desktop graphics cards. To get around this issue, VoidTech used the Sunshine game streaming server and the Moonlight game streaming client (on another system) to run the Huawei machine headlessly. A janky solution to be sure, but it does seem to have worked.

There's a bit more to the video, including how VoidTech had a hard time getting Windows 11 to boot on the machine at all due to broken ACPI tables, some frustration with missing Windows 11 drivers for the HiSilicon Network Subsystem (HNS), a bit where he runs a Blender Cycles render on the GeForce RTX 4060, and a couple of Nvidia RTX demos including the Star Wars "Reflections" demo that was shown with the introduction of the RTX 20 Series "Turing" GPUs. It's an interesting saga of making hardware that was never meant to work together run on an operating system that none of it supports.

This does somewhat bode well for RTX Spark. While you probably shouldn't expect the Cortex-X925 CPU cores in the RTX Spark to outpace the latest AMD or Intel CPUs due to still being forced to pay the Prism penalty, they're going to be a damn sight faster than this seven-year-old workstation chip. Since the drivers seem to be in good shape, the consumer laptops should indeed offer capable gaming performance when they arrive later this year—at least, as long as your game doesn't have kernel-level anti-cheat

AMD is reportedly testing FSR Multi Frame Generation for existing Radeon GPUs, with ratios of up to 8x. According to a screenshot shared on the Chiphell forums, AMD's latest Adrenalin Edition 26.6.2 driver includes support for Multi Frame Generation, as hidden experimental settings were discovered in RadeonTuner, a third-party open-source alternative to AMD Adrenalin Software. In addition to a new Multi Frame Generation Ratio setting, RadeonTuner also includes override options for FSR Ray Regeneration Denoiser and FSR Neural Radiance Caching.

This suggests that AMD is potentially testing FSR Multi Frame Generation, with options ranging from 1x to 8x. In theory, that could boost a base frame rate of 60 FPS to as high as 480 FPS, which is around 2x higher than what Nvidia currently offers on its RTX 50 series GPUs. That said, these settings are non-functional, and there is no confirmation whether AMD has plans to roll out an 8x Multi Frame Generation mode.

The discovery has also prompted a response from the developer of RadeonTuner on GitHub, where they explained that AMD occasionally adds the names of upcoming settings to its drivers months before the actual functionality is implemented. The developer also clarified that the newly listed Multi Frame Generation ratios of up to 8x are placeholders that have been added for testing purposes, meaning that it may or may not align with the final implementation that AMD ends up supporting eventually.

Interestingly, during Microsoft's recent unveiling of its upcoming Xbox platform codenamed Project Helix, the company confirmed that the console will feature FSR Diamond (previously called FSR Next). This was touted as an AI-powered rendering suite that would include machine learning-based upscaling, ray regeneration, and Multi Frame Generation. AMD's graphics chief, Jack Huynh, later described FSR Diamond as the result of a multi-year engineering collaboration with Microsoft.

While there is no indication that the hidden driver settings are directly tied to FSR Diamond, the presence of experimental options for Multi Frame Generation, Ray Regeneration, and Neural Radiance Caching suggests AMD is laying the groundwork for its next-generation FSR technologies across the Radeon ecosystem.

There's bittersweet news from the shore of the open-source Zluda project, a long-running effort to create a CUDA emulator for AMD GPUs. The project's latest blog post for version 6 shows off the fresh 32-bit PhysX support and improved Windows support. Additionally, there are a number of PyTorch-driven fixes. Unfortunately, the project has again lost commercial funding, and it's now back to being a hobby for developer Andrez Janik.

Zluda 6's 32-bit PhysX support is still in a pre-alpha stage, but the results are promising. Janik showed off multiple cloth and deformation demos running at speed, and even a screenshot showing a 3x performance uplift of 2010's Mafia II running with PhysX effects turned on. Given the pre-alpha nature, Janik notes that "fluid simulations can be glitchy, and the current method of loading ZLUDA into Steam games is poor." One of his goals is to have better support for Windows, and v6 includes a refreshed zluda.exe loader that now loads required performance libraries automatically.

Last but by no means least, Zluda v6 includes a host of PyTorch-driven enhancements, composed of compiler fixes and improvements to performance libraries. As a silver lining of sorts, Janik notes that since there's now no funding, the priorities for the project have shifted to things "[he] finds the most entertaining," justifying the addition of PhysX and the revamped Windows loader.

The project was initially started in 2020 to get CUDA running on Intel hardware, but has since then turned to AMD cards. After being abandoned in 2021, it was brought back from the dead around 2022 thanks to AMD pulling out the checkbook to make it happen — presumably because one of the main obstacles (if not the primary one) is that most all the AI software ecosystem revolves around Nvidia's GPUs.

Unfortunately, AMD also cut the funding to Zluda in 2024, and in August even forced Janik to rebuild the code the company paid for. He thankfully found an undisclosed sponsor in late 2024; likely an AI company to whom the translation layer would be valuable, letting them run CUDA AI workloads on Instinct cards. Said funding is now sadly gone once again, and Janik says Zluda is back to being a "weekend project."

For end users, it's nice to have a fully open-source drop-in replacement for CUDA binaries. As for large-scale conversion for AI usage, though, there are a number of alternative projects that look to accomplish the same end results via different means. These include AMD's HIP source code porting, Spectral Compute's Scale, and MooreThreads' Musify toolkit, to name a few.

Last month, AMD officially announced FSR 4.1 for older RDNA 2 and RDNA 3 hardware, with the RX 7000 series set to receive FSR 4.1 support in July. Well, Christmas has come early as FSR 4.1 is out now for RDNA 3 desktop GPUs, a few days before it was originally supposed to launch. It's available natively in over 300 games, and all you need to do is update your GPU drivers inside AMD Adrenaline software to unlock the latest upscaler.

• ASRock Challenger Radeon RX 9070 : was $639 now $599 at Newegg

FSR 4.1 for the RX 7000 series is based on INT8 code that differs from the FP8 instruction set that the RX 9000 series uses. Technically speaking, only RDNA 4 has the hardware required for FSR 4.1 to work optimally, while making it backwards compatible with previous generations requires a lot of tuning and falling back on older instructions that incur a slight performance loss in exchange for better visual quality.

AMD is confident that its in-house optimizations deliver better results than community efforts, as the video embedded above shows official FSR 4.1 achieving higher frame rates in Forza Horizon 6 and Crimson Desert versus FSR 4.0.2c. That version is built from leaked code that came out last year and has since served as the foundation of Optiscaler mods that force-inject FSR 4 by making the game think it's actually DLSS.

The biggest difference will still be seen against native rendering — playing Crimson Desert at 4K, an RX 7900 XTX only managed about 43 FPS on average, while FSR 4.1 bumped that up to 64 FPS. That's nearly a 50% improvement, while looking considerably better than FSR 3.1 and remarkably close to FSR 4.1 on the RX 9000 series. Sure, FSR 3.1 could probably net a few more FPS, but the image quality won't be as sharp.

AMD also confirmed it's working on "lightweight machine learning models" to bring FSR 4.1 to RDNA 3 APUs, which should extend support to a wide range of devices. For instance, the Z1 Extreme chip inside Valve's Steam Deck is based on RDNA 3 architecture. Phoenix Point and Hawk Point silicon, i.e., Ryzen 7040, Ryzen 8000(G), Ryzen 8040, and Ryzen 200 series, also rely on RDNA 3 graphics.

RDNA 3.5 is an extension of RDNA 3, and AMD pushed back against it, not receiving FSR 4.1 just this month. If we assume this announcement also counts RDNA 3.5, then expect FSR 4.1 to also come to Ryzen AI 300 and Ryzen AI 400 series, along with Ryzen AI Max processors. AMD's current-gen Ryzen Z2 family for handhelds is also based on RDNA 3.5. For now, though, FSR 4.1 seems limited strictly to RDNA 3 desktop GPUs.

Support for older RDNA 2-based graphics cards is expected in early 2027, even though the community has interchangeably used INT8 mods for both the RX 6000 and RX 7000 series. Expect a bigger performance tradeoff on RDNA 2 compared to RDNA 3, which is what the company is likely trying to minimize in the months leading up to its launch. Nonetheless, it's exciting to see AMD at least try to catch up to Nvidia in terms of its upscaler support.

One last thing to note is that FSR 4.1.1 INT8 leaked earlier today through Proton Experimental. There was a DLL file signed by AMD, intended to work on RDNA 3.5 silicon — so basically the Steam Machine. A few people got hold of the file before it was removed and got it to work on even RDNA 2 GPUs via Optiscaler. Since the cat was out of the bag, perhaps that's why AMD decided to officially release FSR 4.1 for the RX 7000 series earlier than expected.

NVK, the community-built open-source Vulkan driver for Nvidia GPUs in Mesa, has gained experimental DLSS support, with the code landing in Mesa 26.2-devel, as reported by Phoronix. The driver doesn’t reimplement the upscaler but instead loads Nvidia's own pre-compiled CUDA binaries and runs them, a workaround that keeps the feature behind an experimental flag and ties it to whether compatible bytecode exists for a given card. Nvidia's proprietary Linux driver has of course handled DLSS for years, so the change closes one of the bigger gaps between the closed driver and its open-source counterpart, rather than bringing the technology to Linux for the first time.

DLSS runs on NVK through VK_NVX_binary_import, a Vulkan extension that lets an application load Nvidia CuBIN files, the pre-baked CUDA binaries Nvidia, and loads them on the GPU. Autumn Ashton opened the original pull request for the extension last year, and Thomas Andersen revived it roughly two months ago to clear merge conflicts and finish the work, with the path sitting behind the NVK_EXPERIMENTAL=dlss environment variable because known bugs remain.

The catch is the reliance on pre-compiled binaries; NVK can only run DLSS where compatible bytecode already exists for the GPU in use. The proprietary Nvidia driver avoids that limit with a route that compiles PTX, Nvidia's intermediate assembly, down to GPU bytecode at runtime. NVK has no equivalent, because it can’t translate Nvidia PTX into NIR, which is the intermediate representation Mesa drivers compile from.

Support for DLSS across the broader Linux graphics stack has been uneven, to say the least. As of late last year, Nvidia's DLSS 4 was still unsupported in Valve's VKD3D-Proton translation layer, which converts DirectX 12 calls to Vulkan for games running through Proton.

NVK began in 2022 as a from-scratch Vulkan driver led by Collabora's Faith Ekstrand alongside Karol Herbst and Dave Airlie at Red Hat, and it supports Turing (RTX 20-series and GTX 16-series) and newer architectures. In late 2024, it became the first open-source Vulkan driver for Nvidia hardware to pass Khronos conformance, reaching Vulkan 1.4 provisional spec. It runs on the Nouveau kernel driver and is separate from Nvidia's own open-source kernel modules, which the company ships with its proprietary user-space software stack.

At the XDC2025 conference in November, Ekstrand said NVK runs at around 50% of the official Nvidia driver's speed in many titles, that ray tracing is still in progress, and that the team is "barely keeping the lights on" with current developer resources, according to Phoronix.