The Tensor Cores on the 2018 RTX 20-series shipped as a footnote. Ray tracing got the headlines; the dedicated AI silicon existed to run DLSS 1.0, a technique so visually unconvincing that plenty of reviewers filed it under curiosity. Those cores were actually the opening move in a longer bet: that AI inference would eat the rendering pipeline stage by stage until the GPU stopped being a rasterizer that occasionally infers and became an inference engine that occasionally rasterizes.
The bet has paid out on a roughly two-year clock. DLSS 2.0 in 2020 made upscaling competitive with native resolution using a temporal transformer. DLSS 3.0 in 2022 pushed past spatial upscaling into frame synthesis, with Frame Generation on Ada Lovelace inventing whole frames between rendered ones. A year later, DLSS 3.5 ripped out the hand-tuned denoiser in ray-traced pipelines and dropped in Ray Reconstruction, a network trained to rebuild lighting from sparse ray samples. Blackwell brought DLSS 4 and Multi-Frame Generation, generating up to three interpolated frames per rendered one. Different bottleneck each time, same recipe underneath: train offline, ship the weights, run inference on Tensor Cores at runtime, and claw back headroom no fixed-function algorithm could reach. RTX Neural Shaders and the Neural Radiance Cache carried the pattern into shading and global illumination. RTX Neural Texture Compression is the newest arrival, and the SDK that just landed, version 0.10.0 BETA, hands it Windows-on-Arm for the first time.
GPU texture compression has barely moved since the early 2000s, which tells you how good the old tricks were. BC7 chops a texture into 4×4 pixel blocks and encodes each with a tiny palette plus interpolation weights, landing around 4:1 over raw RGBA with quality loss you mostly won’t notice. BC6H does the HDR variant. Both decompress in fixed-function hardware on effectively every GPU built in the last fifteen years, and that is the whole point: zero runtime cost, universal support. The ceiling is the block structure itself. Push BC7 harder and artifacts show, because the format has no idea what the texture depicts. It sees pixel blocks and nothing else.
NTC throws that out. Rather than store compressed texture data, it stores a small neural network trained to reproduce the texture’s content when you query it. The GPU never unpacks a block; it runs inference on Tensor Cores to reconstruct each texel on demand, from a network small enough to occupy a fraction of the original texture’s VRAM yet expressive enough to hold quality against traditional compression.
A 32 MB raw texture drops to roughly 12 MB under block compression, about 2.7:1. NTC takes that same texture down to around 2.5 MB. That’s a further 4.8× past BC7, and roughly 12.8× against raw. Scale it up, and the effect gets loud: at GTC 2026, NVIDIA showed a scene holding 6.5 GB of texture data in VRAM collapsing to 970 MB, an 85% cut sitting close to the 90% marketing line. The pitch is blunt: NTC could make 8 GB or 12 GB cards viable for 4K workloads that would otherwise demand 16 GB or more.
None of it is free. Tensor Cores do the decompression, so the floor is RTX 20-series or newer, the first consumer architecture to carry Tensor Cores at all. That floor is load-bearing for everything NTC can and can’t do to the market.
VRAM has quietly become the sore spot in the whole stack. Texture resolutions, asset counts, and ray tracing data structures have all grown faster than memory capacity has scaled. The RTX 4090 gets 24 GB, the 4080 gets 16, the 4070 gets 12, and the $300–400 mid-range still ships 8 GB, which is already marginal at 1440p or 4K on high-fidelity titles. The 50-series fixed the top end; the 5090 packs 32 GB and left the middle structurally identical. Developers author assets against a VRAM ceiling that most installed GPUs can’t clear.
So NTC is a software patch on a hardware wall, and if adoption hits critical mass it could genuinely stretch the useful life of 8 to 12 GB cards. It also drags a new tension in. Because it needs Tensor Cores, NTC is RTX-exclusive by construction. A developer who budgets textures around it, say targeting 8 GB on the assumption NTC crushes a 60 GB asset set down to something shippable, builds a game that behaves very differently the moment it runs on AMD or Intel silicon with no NTC path. DLSS was always an optional layer on top. NTC, used as a budget assumption, becomes load-bearing, and a title whose high-quality texture pack only fits with NTC active doesn’t run slower on non-RTX hardware; it runs with a worse asset set entirely. Intel has its own answer in Texture Set Neural Compression, but it lives in a different ecosystem, and neural compression formats splintering across vendors is exactly the kind of thing that turns middleware integration into a slog.
The update itself is NTC SDK v0.10.0 BETA, out around August 6–7, 2026, adding Windows ARM64 as a target. First in line is RTX Spark, NVIDIA’s debut SoC, which mates a 20-core Grace Arm CPU to a Blackwell RTX GPU in two flavors, 6,144 and 5,120 CUDA cores. The memory layout is the odd part: a unified LPDDR5X pool up to 128 GB shared between CPU and GPU, nothing like the discrete model where GDDR6X sits on its own bus.
That unified pool partly dissolves the problem NTC exists to solve. The acute VRAM pain belongs to discrete cards with 8 or 12 GB of dedicated GDDR6X. Spark’s 128 GB shared pool has no hard ceiling in the same sense. Textures can spill into system memory without the bandwidth cliff a discrete GPU falls off when it runs out of VRAM. By that reasoning, NTC is less urgent on Spark than on some 8 GB RTX 4070 laptop chip.
NVIDIA ported it regardless, and did it in the very first public SDK beta to touch Arm at all. Read the signal. NVIDIA isn’t handing Spark a curated subset of RTX features; it’s treating the entire RTX SDK surface as something that ought to run natively on Arm. The CUDA toolkit already ships as a native Windows-on-Arm build, DLSS already runs there, and NTC now joins them. Parity, not differentiation. SEGA has already committed AAA titles optimized for Spark, so the pressure for complete SDK coverage is concrete: a studio wiring NTC into a Spark title needs the tool running natively, not limping through x86 emulation.
Microsoft, Arm Ltd., and NVIDIA are all publicly betting that Windows-on-Arm becomes a real gaming and developer platform instead of a Snapdragon laptop footnote, and every native SDK port strips one more excuse to treat Arm as a second-class target. What I actually doubt is the middleware timing. Unreal and Unity are the paths most studios ever touch, and a feature that lives in the SDK but hasn’t reached the engine plugin layer is only reachable by studios with the budget to write custom rendering code. If NTC-on-Arm lands in those engines after Spark laptops ship in volume rather than before, the port is a press release for most of the industry.
NTC closes a picture that’s been assembling across the whole RTX generation. DLSS owns the output end, turning a low-res frame into a high-res one or fabricating frames outright. Neural Radiance Cache owns lighting, holding a learned cache of radiance a path tracer can query instead of tracing every bounce cold. Neural Shaders own material evaluation, running learned material models on Tensor Cores in place of traditional BRDF code. NTC owns the input end, swapping out the static texture store that feeds every stage downstream. Put them together and inference touches asset decompression, material evaluation, lighting estimation, denoising, and final reconstruction. Rasterization and ray tracing still happen, but they’re increasingly ringed by learned systems that feed them or clean up after them. The footnote from 2018 is now the foundation.
That’s why the Arm port reads as more than a routine SDK bump. The question was never whether Spark gets one more checkbox; it’s whether the neural rendering stack, the thing that increasingly defines what RTX hardware even does, runs natively on the Arm platform NVIDIA has pinned its PC SoC ambitions to. Version 0.10.0 BETA answers yes for this piece. The part still worth doubting is whether it reaches Unreal and Unity before Spark laptops ship, because until it does, the native port helps almost no one who isn’t already writing their own renderer.