NVIDIA has added Windows 11 ARM64 support to the RTX Neural Texture Compression SDK, giving developers an early path to build and test neural texture workflows for RTX Spark PCs before the platform’s expected fall 2026 arrival. The change is documented in NVIDIA’s RTXNTC GitHub build guide, and was first spotted by Compusemble and reported by VideoCardz.
The practical significance is narrower than the headline may suggest. This is developer enablement for a beta SDK, not an operating-system feature that makes existing Windows games consume less VRAM, nor a driver switch that turns neural texture compression on across an RTX library. A game must package NTC-trained materials and implement NVIDIA’s decompression paths itself.
Still, the update is an important piece of NVIDIA’s Windows-on-Arm preparation. CUDA 13.4’s developer preview already added native compilation and cross-compilation support for Windows ARM64 targets, explicitly calling out the upcoming RTX Spark hardware. RTXNTC is now one of the first graphics-oriented RTX Kit components whose own build instructions formally connect that toolchain to an NVIDIA Windows-on-Arm device.
RTX Neural Texture Compression, or NTC, combines material data that normally ships as several separate textures into one compressed set. NVIDIA’s SDK supports up to 16 channels, covering the usual physically based rendering inputs such as albedo, normal maps, roughness, metallic data, ambient occlusion, opacity, and other material-specific maps.
Instead of storing each channel in a conventional GPU block-compressed format such as BCn, the asset pipeline produces a compact collection of latent data plus a small neural-network decoder. At runtime, the decoder reconstructs the texture values either while a scene is loading or while pixels are being shaded.
The first route, called inference on load, converts an NTC texture into conventional BCn textures as a level or scene is loaded. It can reduce game-download and installation sizes but does not provide the large live VRAM reduction that makes neural texture compression interesting in the first place. Because the material ends up in conventional texture memory, it also avoids a recurring neural-inference cost during rendering.
The more aggressive inference on sample mode decodes texture data during shading. That is the route intended to shrink the texture working set in memory, but it trades memory capacity for GPU work. NVIDIA’s own SDK recommends newer architectures for this mode: the documented baseline is Shader Model 6-capable hardware, while Ada-generation GeForce RTX 40-series GPUs or newer are recommended for practical performance.
Independent testing by Tom’s Hardware earlier this year found substantial texture-memory savings in NVIDIA’s sample workload, while also confirming the central limitation: on-sample inference is slower than decoding to BCn at load time. The technology can be useful when texture capacity is the bottleneck, but it does not make the rendering work free.
Windows ARM64 support means developers can now build that workflow into native Arm64 Windows binaries for RTX Spark. NVIDIA says DirectX 12, Vulkan 1.3, and CUDA-based texture compression all work in the ARM64 build. That covers the core compression and decompression pipeline rather than merely allowing a project to compile.
DLSS is NVIDIA’s upscaling and frame-generation family; OptiX is its ray-tracing and AI-acceleration framework used in professional visualization, rendering, and research workloads. Their absence means an RTXNTC project can compile and run its stated texture paths on Windows ARM64, but it cannot assume that the other RTX SDK integrations enabled in an x64 Windows project will be present.
For developers, automatic disabling is better than a build that appears successful and fails at runtime. For buyers and IT teams, it is evidence that RTX Spark’s software story remains segmented. NVIDIA has begun moving the compute and graphics foundation to native Arm64 Windows, but the company has not yet published a timetable for DLSS or OptiX support on that architecture.
That is especially consequential for game developers. NTC’s on-sample mode is designed around advanced shader capabilities, and NVIDIA has emphasized DirectX Cooperative Vector and related neural-rendering paths in its desktop RTX work. But a game that relies on DLSS for its performance target would still need an alternate upscaling strategy on native Windows ARM64 until NVIDIA closes that gap.
NVIDIA’s current RTXNTC requirements do include fallbacks based on DP4a instructions or ordinary integer math. Those paths let decompression function on broader Shader Model 6 hardware, including validated older NVIDIA GPUs, AMD Radeon RX 6000-series cards, and Intel Arc A-series GPUs. The meaningful performance advantage, however, is expected on hardware that can exploit the newer neural shader capabilities.
CUDA 13.4 is not a routine production toolkit release. NVIDIA labels it a developer preview and says it has not completed full validation. Its release notes warn that APIs, tool coverage, platform support, and architecture-specific optimizations may change before general availability; NVIDIA also says the preview should not be used for production deployment, certification, or benchmarking.
There is one documentation problem that administrators and developers should not overlook. The RTXNTC repository says the required Windows ARM64 driver “comes with” the ARM64 CUDA Toolkit, yet its Windows ARM64 build instructions separately require an R616-series-or-newer driver. CUDA 13.4’s own release notes say the driver is not bundled with the developer preview and identify version 616.00 or later as the Windows driver needed for newly enabled platform support.
Those statements cannot all be read as a single installation instruction. The safe interpretation is to treat CUDA 13.4 and the R616-or-newer developer driver as separate prerequisites, confirm the installed driver version after deployment, and avoid assuming that an ARM64 CUDA installer will update the display and compute driver on its own. NVIDIA’s release notes make clear that a compatible existing CUDA driver may run older functionality, but CUDA 13.4 additions and newly enabled platforms need the new driver support.
This matters more on Windows on Arm than it does on established x64 workstations. The development machine may be native Arm64 while a team’s content pipeline, plug-ins, source-control hooks, shaders, and third-party SDKs still carry x64 assumptions. CUDA 13.4 supports both native Arm64 development and cross-compilation from Windows x86-64, giving teams a way to port in stages. It does not make those dependencies Arm64-ready.
That fallback question is more complicated than NVIDIA’s marketing claims about lower texture memory can make it sound. A cross-platform game cannot simply assume every player has the same feature set or performance profile. On-load transcoding offers a broadly compatible route and may cut download size, but it does not eliminate the resident texture-memory constraint. On-sample inference can substantially reduce that pressure, but only if the shader cost is acceptable on the target GPU and the game’s rendering architecture.
NVIDIA’s public SDK remains marked version 0.10.0 beta. Its repository provides Explorer and Renderer sample applications, test tooling, a command-line compressor, and integration documentation, but it does not list a commercial game shipping with RTXNTC support. NVIDIA has discussed NTC in RTX Kit materials and demonstrations, yet as of August 6, 2026, it has not announced an on-sale Windows game using the SDK.
That makes the immediate audience for this update quite specific: engine teams, tools developers, and studios evaluating RTX Spark rather than ordinary PC gamers. For them, the ARM64 build guide is valuable because it replaces a theoretical CUDA-on-Arm promise with a concrete texture-processing workload that can be compiled today.
The company’s immediate task is no longer proving that an Arm64 Windows executable can invoke CUDA. It must close the practical gaps around the surrounding graphics stack, beginning with DLSS and OptiX, while turning preview drivers and beta SDKs into software that developers can ship and support.
For now, RTX Neural Texture Compression on Windows ARM64 is a credible sign that NVIDIA is preparing RTX Spark for native content creation and engine work. It is not yet proof that RTX Spark will launch with a mature native gaming stack—and the missing DLSS and OptiX support makes that distinction impossible to ignore.
Still, the update is an important piece of NVIDIA’s Windows-on-Arm preparation. CUDA 13.4’s developer preview already added native compilation and cross-compilation support for Windows ARM64 targets, explicitly calling out the upcoming RTX Spark hardware. RTXNTC is now one of the first graphics-oriented RTX Kit components whose own build instructions formally connect that toolchain to an NVIDIA Windows-on-Arm device.
What Windows ARM64 support actually adds
RTX Neural Texture Compression, or NTC, combines material data that normally ships as several separate textures into one compressed set. NVIDIA’s SDK supports up to 16 channels, covering the usual physically based rendering inputs such as albedo, normal maps, roughness, metallic data, ambient occlusion, opacity, and other material-specific maps.Instead of storing each channel in a conventional GPU block-compressed format such as BCn, the asset pipeline produces a compact collection of latent data plus a small neural-network decoder. At runtime, the decoder reconstructs the texture values either while a scene is loading or while pixels are being shaded.
The first route, called inference on load, converts an NTC texture into conventional BCn textures as a level or scene is loaded. It can reduce game-download and installation sizes but does not provide the large live VRAM reduction that makes neural texture compression interesting in the first place. Because the material ends up in conventional texture memory, it also avoids a recurring neural-inference cost during rendering.
The more aggressive inference on sample mode decodes texture data during shading. That is the route intended to shrink the texture working set in memory, but it trades memory capacity for GPU work. NVIDIA’s own SDK recommends newer architectures for this mode: the documented baseline is Shader Model 6-capable hardware, while Ada-generation GeForce RTX 40-series GPUs or newer are recommended for practical performance.
Independent testing by Tom’s Hardware earlier this year found substantial texture-memory savings in NVIDIA’s sample workload, while also confirming the central limitation: on-sample inference is slower than decoding to BCn at load time. The technology can be useful when texture capacity is the bottleneck, but it does not make the rendering work free.
Windows ARM64 support means developers can now build that workflow into native Arm64 Windows binaries for RTX Spark. NVIDIA says DirectX 12, Vulkan 1.3, and CUDA-based texture compression all work in the ARM64 build. That covers the core compression and decompression pipeline rather than merely allowing a project to compile.
DLSS and OptiX remain absent on Windows on Arm
The most revealing line in NVIDIA’s updated build guide is also the one that prevents this from being mistaken for a complete RTX software stack: DLSS and OptiX are unsupported on Windows ARM64 and are automatically disabled.DLSS is NVIDIA’s upscaling and frame-generation family; OptiX is its ray-tracing and AI-acceleration framework used in professional visualization, rendering, and research workloads. Their absence means an RTXNTC project can compile and run its stated texture paths on Windows ARM64, but it cannot assume that the other RTX SDK integrations enabled in an x64 Windows project will be present.
For developers, automatic disabling is better than a build that appears successful and fails at runtime. For buyers and IT teams, it is evidence that RTX Spark’s software story remains segmented. NVIDIA has begun moving the compute and graphics foundation to native Arm64 Windows, but the company has not yet published a timetable for DLSS or OptiX support on that architecture.
That is especially consequential for game developers. NTC’s on-sample mode is designed around advanced shader capabilities, and NVIDIA has emphasized DirectX Cooperative Vector and related neural-rendering paths in its desktop RTX work. But a game that relies on DLSS for its performance target would still need an alternate upscaling strategy on native Windows ARM64 until NVIDIA closes that gap.
NVIDIA’s current RTXNTC requirements do include fallbacks based on DP4a instructions or ordinary integer math. Those paths let decompression function on broader Shader Model 6 hardware, including validated older NVIDIA GPUs, AMD Radeon RX 6000-series cards, and Intel Arc A-series GPUs. The meaningful performance advantage, however, is expected on hardware that can exploit the newer neural shader capabilities.
CUDA 13.4 is the real platform dependency
The new ARM64 instructions require Visual Studio 2022 with ARM64 C++ build tools, NVIDIA’s CUDA 13.4 Windows ARM64 developer preview, and an R616-series or later NVIDIA driver. Developers can generate a native ARM64 Visual Studio solution or build through Ninja from the ARM64 Native Tools command prompt.CUDA 13.4 is not a routine production toolkit release. NVIDIA labels it a developer preview and says it has not completed full validation. Its release notes warn that APIs, tool coverage, platform support, and architecture-specific optimizations may change before general availability; NVIDIA also says the preview should not be used for production deployment, certification, or benchmarking.
There is one documentation problem that administrators and developers should not overlook. The RTXNTC repository says the required Windows ARM64 driver “comes with” the ARM64 CUDA Toolkit, yet its Windows ARM64 build instructions separately require an R616-series-or-newer driver. CUDA 13.4’s own release notes say the driver is not bundled with the developer preview and identify version 616.00 or later as the Windows driver needed for newly enabled platform support.
Those statements cannot all be read as a single installation instruction. The safe interpretation is to treat CUDA 13.4 and the R616-or-newer developer driver as separate prerequisites, confirm the installed driver version after deployment, and avoid assuming that an ARM64 CUDA installer will update the display and compute driver on its own. NVIDIA’s release notes make clear that a compatible existing CUDA driver may run older functionality, but CUDA 13.4 additions and newly enabled platforms need the new driver support.
This matters more on Windows on Arm than it does on established x64 workstations. The development machine may be native Arm64 while a team’s content pipeline, plug-ins, source-control hooks, shaders, and third-party SDKs still carry x64 assumptions. CUDA 13.4 supports both native Arm64 development and cross-compilation from Windows x86-64, giving teams a way to port in stages. It does not make those dependencies Arm64-ready.
NTC is still a content decision, not a platform checkbox
The update also does not mean current games can be retrofitted through GeForce drivers or Windows Update. Neural texture compression has to be considered while a game’s materials are authored and built. Developers need to determine which texture channels are correlated enough to benefit, train or encode them, integrate the NTC library, choose a decompression mode, and retain fallback paths for systems where neural decoding is impractical.That fallback question is more complicated than NVIDIA’s marketing claims about lower texture memory can make it sound. A cross-platform game cannot simply assume every player has the same feature set or performance profile. On-load transcoding offers a broadly compatible route and may cut download size, but it does not eliminate the resident texture-memory constraint. On-sample inference can substantially reduce that pressure, but only if the shader cost is acceptable on the target GPU and the game’s rendering architecture.
NVIDIA’s public SDK remains marked version 0.10.0 beta. Its repository provides Explorer and Renderer sample applications, test tooling, a command-line compressor, and integration documentation, but it does not list a commercial game shipping with RTXNTC support. NVIDIA has discussed NTC in RTX Kit materials and demonstrations, yet as of August 6, 2026, it has not announced an on-sale Windows game using the SDK.
That makes the immediate audience for this update quite specific: engine teams, tools developers, and studios evaluating RTX Spark rather than ordinary PC gamers. For them, the ARM64 build guide is valuable because it replaces a theoretical CUDA-on-Arm promise with a concrete texture-processing workload that can be compiled today.
RTX Spark now has a visible graphics-software runway
NVIDIA introduced RTX Spark at Computex in June as a Windows-on-Arm platform combining Arm CPU cores and Blackwell RTX graphics, with partner laptops and desktop systems expected in fall 2026. CUDA 13.4 was the essential first toolchain release; ARM64 support in RTXNTC now establishes that RTX Kit components are being adapted as well.The company’s immediate task is no longer proving that an Arm64 Windows executable can invoke CUDA. It must close the practical gaps around the surrounding graphics stack, beginning with DLSS and OptiX, while turning preview drivers and beta SDKs into software that developers can ship and support.
For now, RTX Neural Texture Compression on Windows ARM64 is a credible sign that NVIDIA is preparing RTX Spark for native content creation and engine work. It is not yet proof that RTX Spark will launch with a mature native gaming stack—and the missing DLSS and OptiX support makes that distinction impossible to ignore.
References
- Primary source: videocardz.com
Published: 2026-08-06T09:03:25+00:00
Loading…
videocardz.com - Related coverage: github.com
Loading…
github.com - Related coverage: docs.nvidia.com
Loading…
docs.nvidia.com - Related coverage: packages.nvidia.com
Loading…
packages.nvidia.com - Related coverage: tomshw.it
Loading…
www.tomshw.it - Related coverage: research.nvidia.com
Loading…
research.nvidia.com - Related coverage: tomshardware.com
Loading…
www.tomshardware.com - Related coverage: developer.nvidia.com
Loading…
developer.nvidia.com - Related coverage: github.com
Loading…
github.com - Related coverage: packages.nvidia.com
Loading…
packages.nvidia.com - Related coverage: techspot.com
Loading…
www.techspot.com - Related coverage: hwbusters.com
Loading…
hwbusters.com - Related coverage: research.nvidia.com
Loading…
research.nvidia.com - Related coverage: images.nvidia.com
- Related coverage: images.nvidia.cn
- Related coverage: docs.nvidia.com
Loading…
docs.nvidia.com - Related coverage: raytracing-docs.nvidia.com
Loading…
raytracing-docs.nvidia.com - Related coverage: tomshardware.com
Nvidia says RTX Spark chip will support all major anti-cheat and DRM technologies — Fortnite, Valorant, Denuvo, and more to work natively with Windows on Arm | Tom's Hardware
Solving one of the biggest hurdles of a non-x86 platform.www.tomshardware.com - Related coverage: windowscentral.com
Microsoft wants AI to help developers port apps for RTX Spark and Snapdragon X | Windows Central
A Build session will show how AI agents can port apps to get native Arm performancewww.windowscentral.com - Related coverage: strayspark.studio
Loading…
www.strayspark.studio - Related coverage: nvidia.com
Loading…
www.nvidia.com - Related coverage: developer.nvidia.com
Loading…
developer.nvidia.com - Related coverage: forums.developer.nvidia.com
Loading…
forums.developer.nvidia.com - Related coverage: forums.developer.nvidia.com
Loading…
forums.developer.nvidia.com - Related coverage: pcworld.com
Loading…
www.pcworld.com - Related coverage: nvidia.com
Loading…
www.nvidia.com - Related coverage: vulkan.org
Loading…
www.vulkan.org - Related coverage: pausehardware.com
Loading…
pausehardware.com - Related coverage: windowscentral.com
Loading…
www.windowscentral.com - Related coverage: techradar.com
Loading…
www.techradar.com