An open-source research project called dlss-nr-on-intel has been published, applying neural rendering derived from NVIDIA's DLSS 5 to a real game running on Intel Arc 140V integrated graphics. According to the author's measurements, running Tekken 7 at 640×360 with this processing pipeline reached 10.5fps. The original Tom's Hardware headline that sparked coverage labeled the GPU as "Arc 140T," but the article body and the project's primary sources confirm the actual hardware is the Lunar Lake-generation Arc 140V.
Summarizing this achievement as "DLSS 5 ported to Intel GPUs" erases an important distinction. The repository doesn't use any of NVIDIA's execution code, NGX, or CUDA — it reimplements the inference pathway from scratch for Vulkan and Intel's XMX matrix engines. However, the trained weights themselves were not independently created. Users must extract the weights from their own copy of NVIDIA's nvngx_dlssnr.dll. Rather than a port of the official product, this is more accurately described as a research port that runs the same lineage of weights through a completely different computational pathway.
Intercepting Frames Through a Vulkan Layer, Not NVIDIA's DLL
The mechanism doesn't integrate DLSS 5 directly into the game. A Vulkan layer intercepts vkQueuePresentKHR, passing the frame—just before it would be displayed—to a resident daemon via a Unix socket. That daemon runs a 71-block U-Net on the Arc 140V's XMX units and returns the processed frame to the game.
This architecture separates the game and the neural model into distinct processes. Windows games could theoretically be supported too, provided their rendering gets translated to Vulkan through Proton. However, this doesn't mean a native Windows version currently works out of the box. All development and benchmarking was done on Linux, using Mesa ANV, on the Arc 140V. The GPU must support Vulkan's VK_KHR_cooperative_matrix extension and expose an FP16-input, FP32-accumulate configuration. Not just any Vulkan-capable GPU will work.
Previous unofficial DLSS 5 experiments largely centered on calling leaked or bundled NVIDIA DLLs from other games. This implementation doesn't execute any inference code from the DLL at all—it replaces that code entirely with Intel-targeted compute shaders and a resident runtime. That distinction represents a bigger technical leap than the modest frame rate suggests.
Code Is Public, but Weights Must Be Extracted by the User
What's in the repository is code — NVIDIA's binaries and weights are not distributed. Users must supply their own DLL and extract the logical weights using tools provided by a separate project, MLX-DLSS. According to the current architecture documentation, the extracted result comprises 649 named tensors totaling 145,755,123 parameters.
The roughly 143 million parameters that make up the large matrices are compressed inside the DLL using FP8 E4M3 format, one byte per element. About 2.7 million smaller-tensor parameters use FP16, and 714 scale values use FP32. Once extracted and expanded to FP16, the large matrices alone require 291.5MB. At 720p processing resolution, device buffers—including activations—reportedly reach roughly 2.3GiB.
The model architecture consists of a 5-stage Swin encoder, an 8-block ViT-1D bottleneck, and a 5-stage decoder. Its input has 16 channels, including the current frame, the previous frame's output, deterministic noise, and tone/structure control values. The output has 4 channels: an RGB correction and a temporal gate that determines how much history to retain.
What's running here is not super-resolution. Input and output share the same resolution range; the model generates a correction that gets added to the original frame. Even when the processing resolution is lowered, the system doesn't upscale the game's own pixels—it upscales the generated correction and composites that instead.
The Denominator Behind 10.5fps: 412ms of Processing Alone at 1080p
The author's daemon-only measurements, taken on September 18, 2026, represent the median of 5 frames for the full socket round-trip that the game waits on. This differs from the 10.5fps figure for Tekken 7, which includes actual game rendering.
Daemon-only processing on the Arc 140V took 72ms at 512×288, rising to 412ms at 1920×1080. The Tekken 7 figure of 10.5fps at 640×360 (with the game running) is under different conditions than the daemon-only 12.5–13.5fps range measured at 640×360 in isolation.
| Output Resolution | Processing Scale | Daemon Round-Trip | Max fps |
|---|---|---|---|
| 512×288 | 0.35 | 72ms | 13.9fps |
| 640×360 | 0.35 | 74ms | 13.5fps |
| 640×360 | 0.50 | 80ms | 12.5fps |
| 854×480 | 0.50 | 105ms | 9.5fps |
| 1024×768 | 0.55 | 168ms | 6.0fps |
| 1920×1080 | 0.55 | 412ms | 2.4fps |
The reason the live 640×360 match ran at 10.5fps is that the neural processing load stacks on top of the game's own rendering load. At 1080p, neural processing alone takes 412ms per frame, meaning even if the game rendered instantly, throughput couldn't exceed 2.4fps. This is far from a practical, ready-to-use feature, and the author explicitly states it's "a research port, not a product."
The workload isn't limited to the neural network's matrix multiplications. According to the README, of the 488ms total at 720p, GEMM operations accounted for 216ms. The rest goes to full-frame operations: resizing, feature assembly, compositing, and data movement. The author notes that a data-movement-only pass already hits the Arc 140V's memory bandwidth ceiling. Lowering the processing scale doesn't shrink the full-screen operations tied to output resolution.
What this table demonstrates isn't that DLSS 5's product-grade functionality has become practical on the Arc 140V. It's that an independent inference pathway running on different hardware could be connected to a game's display loop and process continuously. The 10.5fps figure isn't a performance win—it's empirical evidence of portability.
Same Weights, Different Output: Why It Won't Match Official DLSS 5
The Intel implementation's matrix multiplication runs with FP16 input and FP32 accumulation. The 218 NVIDIA-side PTX kernels the project analyzed used FP16 accumulation instead. In the author's isolated GEMM tests, FP32 accumulation reduced error by a factor of 400 to 800—but this doesn't mean image quality improves by 400 to 800 times. It simply reflects a change in how numbers get rounded, meaning the output won't match the original implementation bit-for-bit.
Official DLSS 5 is anchored to the color and motion vectors the game engine outputs, and also draws on information ranging from surface reflectance to lighting and normals. Developers can select among multiple models, adjust the strength of structural and tonal representation, and apply semantic masks to characters and backgrounds. NVIDIA's recommended integration paths are Streamline or the Unreal Engine 5 plugin.
The independent implementation reconstructed the mechanism of feeding back the previous frame's output as history and using a trained gate to decide how much to retain. However, there's no evidence it reproduces all the inputs and developer-facing controls that the official product receives. The documentation itself notes unresolved items, including partial correspondences within the pack, setting identification, and window shift amounts. Image quality comparisons also rely solely on the author's still images and metrics, and the direction of the effect wasn't consistent across the three fighting games tested.
Don't Trust AI-Written Code Just Because AI Wrote It
Another notable aspect of this project is that the author openly discloses the code, benchmarks, and notes were produced by AI agents. The author supplied the hardware and binaries, set direction, and made judgment calls. Claude Opus 5 and Astra reportedly handled the hands-on work.
The author doesn't claim to be able to explain the code line by line. Instead, roughly 180 tests, benchmark programs under src/bench/, and a documented history of failed hypotheses and retractions are offered as evidence. One hypothesis—that resolving shared-memory bank conflicts would yield major speedups—only achieved a 1.11x improvement in actual testing. Three stages of work that proceeded on the false premise of a nonexistent driver bug were also documented. Even the parameter count and an earlier 1080p performance figure were later corrected after further verification.
The fact that errors persisted undercuts any narrative that AI agents have automated low-level GPU development. At the same time, it reinforces the importance of a structure where mistakes get caught through measurement, retracted, and reflected in updated documentation. What matters isn't the names Claude or Astra—it's whether a third party can run the same tests and arrive at the same results.
The 10.5fps figure on the Arc 140V doesn't signal the arrival of a ready-to-play feature. What it demonstrates is that the inference pathway can be decoupled from NVIDIA-exclusive APIs and transplanted onto a different GPU's matrix engines. Challenges remain, though: obtaining the weights, speed, official integration, distribution terms, and third-party reproducibility. What this research port crossed wasn't the threshold of productization—it was the threshold of whether the computation can run on different hardware at all.