Intel TSNC: Neural Texture Compression Shrinks Textures 18x

Intel's TSNC SDK Can Shrink Game Textures Up to 18x Using Neural Networks — Here's How It Works

At GDC 2026, Intel graphics engineer Marissa du Bois presented the latest version of Intel's Texture Set Neural Compression technology — and announced it has been rebuilt from a research prototype into a production-ready standalone SDK. The headline number is striking: Intel TSNC neural texture compression can compress game textures by up to 18 times compared to uncompressed source bitmaps, with a perceptual quality loss of only around 6 to 7 percent at maximum compression. Even the more conservative mode delivers better than 9x compression at roughly 5 percent perceptual error.

Those numbers matter a great deal right now. Modern games are in the middle of a VRAM crisis — textures have gotten dramatically larger as resolutions push toward 4K and beyond, PBR material systems multiply the number of maps required per surface, and GPU memory has not kept pace. A game like Hogwarts: Legacy requires 58 GB of storage, with high-resolution texture packs adding nearly another 20 GB on top. The 8 GB VRAM ceiling that constrains mid-range GPUs is being hit regularly by modern titles. Technology that genuinely compresses those textures by 9 to 18 times is not a theoretical curiosity — it is a direct response to one of the most pressing practical problems in PC gaming today.

This article breaks down exactly what TSNC is, how it works at a technical level, what the compression numbers actually mean in practice, how it compares to Nvidia's competing approach, and what the deployment timeline looks like for developers and players.

Why Traditional Texture Compression Is Hitting Its Limits

To understand why TSNC exists, you need to understand what the current standard approaches do and where they fall short. Block compression formats — the BC1 through BC7 family that has been the GPU industry standard for over two decades — work by dividing a texture into small fixed-size blocks, typically 4x4 pixels, and reducing each block to a compact representation using fixed mathematical rules. The approach is fast, hardware-accelerated on every modern GPU, and universally supported. It is also reaching the limits of what it can achieve.

Standard BC block compression delivers roughly a 4 to 6x reduction in texture size compared to uncompressed bitmaps, depending on the format variant and content. For a 4K texture that starts at 64 MB uncompressed, BC compression brings it to roughly 10 to 16 MB. That is meaningful, but it still leaves a lot of data on the table — and crucially, BC compression treats each texture independently, with no awareness of how multiple related textures for the same material relate to each other.

Modern game materials are not single textures. A physically based rendering (PBR) material for a brick wall will have separate maps for albedo (color), normal direction, roughness, metalness, ambient occlusion, and potentially more. These maps all describe the same surface from different angles — they are deeply structurally related to each other. BC compression completely ignores that relationship. Each map is compressed in isolation, leaving enormous shared redundancy on the table. That is precisely the gap that TSNC is designed to exploit.

What Intel TSNC Does Differently

Texture Set Neural Compression takes a fundamentally different approach. Rather than compressing individual textures with fixed mathematical rules, TSNC trains a small neural network using stochastic gradient descent to learn the specific structure of an entire texture set — all the PBR maps for a given material, treated as a single optimization problem. The neural network learns to exploit the shared structure across all those channels in ways that BC compression cannot reach.

The core insight is that a texture set has enormous redundant structure across its channels. The roughness map and the normal map for the same material are not independent — they share information about the same physical surface. A neural network that sees all of those maps together can find a far more compact representation of the whole set than any compressor that looks at them one at a time.

The Feature Pyramid Architecture

At the heart of TSNC's compression scheme is what Intel calls the feature pyramid: a set of four BC1-encoded latent-space textures arranged across different resolution tiers. This structure is how the compressed data is actually stored. Rather than storing the original texture content, TSNC stores a much smaller set of learned feature representations that the neural network has encoded during offline compression. These latent textures are themselves BC1-compressed, meaning they remain hardware-compatible and can be stored and read using existing GPU infrastructure.

Intel's Variant A configuration uses two full-resolution latent images and two half-resolution ones. For a 4K input texture set, this means two 4K and two 2K BC1-encoded latent images. The total storage for that feature pyramid is around 26.8 MB — compared to 256 MB for the original uncompressed 4K bitmaps. That works out to over 9x compression, nearly double what traditional BC block compression achieves on its own.

The Three-Layer MLP Decoder

Reconstructing the original texture channels from the feature pyramid is handled by a three-layer MLP (Multi-Layer Perceptron) decoder — a small, purpose-built neural network that runs at decompression time. The decoder takes the feature pyramid values as input and reconstructs the full texture channel outputs through three layers of learned transformations. This decode step is what runs at runtime on the GPU, and its efficiency is critical to whether TSNC is practical for real-time use.

The MLP is kept deliberately small and fast. Its job is not to do complex scene understanding — it is doing a well-defined mathematical inverse: given the compressed latent representation, reconstruct the original material properties. The three-layer design balances reconstruction quality against runtime inference cost.

Two Variants: Quality vs. Maximum Compression

Intel currently offers TSNC in two configurations with different quality-to-compression trade-offs:

Variant A prioritizes image quality. It uses two full-resolution and two half-resolution BC1 latent images in the feature pyramid. On Intel's test data, it delivers over 9x compression compared to uncompressed bitmaps — roughly double what traditional BC block compression achieves. Perceptual quality loss, measured using Nvidia's FLIP analysis tool, sits at approximately 5 percent. In practice, this shows up mainly as minor precision loss in normal maps, with little visible difference in albedo or other channels under typical viewing conditions.

Variant B pushes compression much further. By reducing the resolution of the latent pyramid tiers, Variant B achieves over 18x compression — more than double Variant A and nearly four times what BC alone produces. The trade-off is a perceptual quality loss of approximately 6 to 7 percent, which begins to introduce BC1 block artifacts in normal maps and ARM (ambient occlusion / roughness / metalness) data. Intel positions Variant B as the high-compression option for scenarios where storage and VRAM savings are more important than maximum visual fidelity — smaller installs, lower-end hardware, streaming contexts where texture resolution can be traded for bandwidth.

To put those compression ratios in concrete terms: a 4K PBR texture set that takes 256 MB uncompressed would be brought to roughly 28 MB with Variant A and roughly 14 MB with Variant B. Against a standard BC-compressed baseline of around 53 MB, that is still a reduction of roughly 47 percent and 74 percent respectively — meaningful savings even when compared to what developers are already using today.

Four Deployment Strategies: Where the Decompression Happens

One of the more sophisticated aspects of TSNC is that it is not designed as a single fixed approach. Intel has defined four distinct deployment strategies, each placing the decompression step at a different point in the game asset lifecycle, with different consequences for disk footprint, VRAM usage, bandwidth consumption, and runtime cost:

Install-time decompression: The game ships with TSNC-compressed data, and decompression happens locally on the user's machine during installation. The textures then live uncompressed on the user's drive. Primary benefit is reduced distribution bandwidth and download size. VRAM usage is unchanged from standard BC-compressed assets once the game is running.

Load-time decompression: Textures stay TSNC-compressed on disk and decompress into VRAM as the game loads each level or scene. This reduces both install size and the peak VRAM footprint during loading. Decompression cost is paid once per asset load rather than continuously at runtime.

Stream-time decompression: Combined with texture streaming systems, textures decompress on demand as they are streamed in. This delivers the best combination of disk and memory savings but adds continuous runtime inference load that must be budgeted for alongside other GPU work.

Sample-time (per-pixel) decompression: The most aggressive option. Textures remain TSNC-compressed in VRAM permanently and are decoded per-pixel in the shader during rendering. This produces the maximum possible VRAM reduction — textures never exist in decompressed form in GPU memory at all — but carries a constant inference cost on every frame. This is where hardware acceleration via Intel's XMX cores becomes essential for maintaining acceptable performance.

Developers choose among these strategies based on what their game actually needs. A game already struggling with download size might benefit most from install-time decompression. A game that is VRAM-constrained at runtime — particularly relevant for 8 GB GPU owners — would get the most benefit from stream-time or sample-time decompression. The flexibility to pick the right trade-off for each game's specific constraints is a deliberate design goal of the SDK.

Hardware Acceleration: XMX Cores and the Fallback Path

The per-pixel sample-time decoding mode in particular requires fast neural network inference, and Intel has designed TSNC with two distinct execution paths to handle different hardware:

The XMX-accelerated path uses Intel's XMX (Xe Matrix eXtension) AI acceleration units found in Arc Alchemist, Arc Battlemage, and Intel Core Ultra (Meteor Lake, Lunar Lake, Panther Lake) processors. XMX units are purpose-built for matrix multiplication operations — exactly the kind of linear algebra that running an MLP decoder requires. On the integrated Arc B390 graphics inside Intel's upcoming Panther Lake processor, Intel measured this path at approximately 0.194 nanoseconds per pixel.

The fallback FMA path uses standard fused multiply-add operations available on any CPU or GPU — including non-Intel hardware. This path runs TSNC's decoder without any specialized AI hardware, maintaining broad compatibility with AMD and Nvidia GPUs as well as CPUs. On the same Panther Lake B390, the fallback path measured approximately 0.661 nanoseconds per pixel — roughly 3.4 times slower than the XMX path, but still fast enough to be useful for less demanding deployment strategies.

The existence of the fallback path is strategically important. A technology that only works on Intel hardware will struggle for developer adoption given Nvidia's roughly 85 percent GPU market share on Steam. By supporting a CPU/GPU-agnostic fallback while offering hardware acceleration as a premium path on Intel silicon, TSNC positions itself as a tool developers can use for all their players while delivering extra performance for users on Intel hardware — the same model XeSS has used for upscaling.

How TSNC Compares to Nvidia's Neural Texture Compression

Nvidia has been developing its own Neural Texture Compression (NTC) technology in parallel. Both companies presented at GDC 2026, and both technologies are described as deterministic — meaning the same input always produces the same output, which is important for consistency in real-time rendering. The core approach is similar in both cases: neural network encoding of texture sets into compact latent representations, with hardware-accelerated decoding.

The numbers tell a more interesting story. Nvidia has cited compression figures of up to 85 percent reduction — comparable to TSNC's numbers when expressed on the same scale. Nvidia's most striking demonstration showed a scene compressed from 6.5 GB of VRAM down to 970 MB using NTC, which works out to roughly a 6.7x reduction — in the same range as TSNC Variant A, though across a full scene rather than per-material.

Nvidia has also been developing a related concept called Neural Materials, which aims to encode the physical properties of materials rather than just compressing texture data — a more ambitious approach that goes beyond pure compression toward generative reconstruction of material behavior. Intel's TSNC is focused specifically on the compression problem and is not attempting to generalize to material property encoding at this stage.

AMD has not yet released an SDK for neural texture compression, though the company published a research paper on the topic in 2024, describing roughly 70 percent size reduction with their approach. AMD's practical developer tools in this space are not yet available.

The SDK: Availability and Developer Integration

Intel plans to release TSNC as a standalone SDK with a decompression API that can be compiled targeting C, C++, or HLSL — covering both CPU-side and GPU shader integration paths. The SDK takes standard BC1-compressed textures as input and converts them to the TSNC compressed format, meaning developers working with existing BC-compressed asset pipelines do not need to rebuild from scratch.

The release timeline follows a staged rollout: an alpha SDK is planned for later in 2026, followed by a beta phase and then full public release. No specific dates have been confirmed. Intel first demonstrated TSNC as an R&D prototype at GDC 2025, and the GDC 2026 presentation marks the transition from research to productized technology — which is typically the phase where external developer access begins.

The Cooperative Vectors API, which Intel uses to implement the XMX-accelerated path, is built on Microsoft's DirectX 12 Agility SDK and requires the Agility SDK 1.717 preview or later. This ties the hardware-accelerated path to DirectX 12, which is essentially universal on modern Windows gaming hardware. The fallback path has no such requirement and should work on any hardware that can run the HLSL shader code.

What TSNC Means for Players With 8 GB GPUs

The most immediate real-world relevance of TSNC is for gamers running cards with 8 GB of VRAM — a situation that currently describes roughly 30 percent of Steam users according to the platform's hardware survey data. As covered in detail in our earlier piece on Valve's Linux vRAM management patches, the 8 GB boundary is being crossed regularly by demanding 2025 and 2026 titles at 1440p with high texture settings.

If TSNC reaches meaningful developer adoption, a game that currently requires 8 GB of VRAM to run texture-heavy scenes at 1080p or 1440p could potentially run within 4 to 5 GB with TSNC stream-time or sample-time decompression enabled. That is a realistic change in which hardware tier can run a game at quality settings that were previously out of reach. The sample-time per-pixel decoding mode — where textures never decompress into VRAM at all — takes this furthest, though it requires developers to budget for the ongoing inference cost in their frame budget.

For install size, the impact is similarly significant. Variant B's 18x compression ratio applied to a game's texture data could theoretically reduce a 100 GB install by 40 to 60 GB depending on how much of that data is texture. In a world where SSD capacity is under pressure from the same memory shortage affecting GPU VRAM costs, that is not a trivial benefit.

The Bigger Picture: Neural Rendering Is Becoming a Real Pipeline

TSNC does not exist in isolation. It is part of a broader shift in how the GPU industry is thinking about rendering pipelines. Nvidia's NTC and neural materials work, Intel's TSNC, AMD's research on neural block compression, and Microsoft's investment in neural rendering APIs through DirectX are all converging on the same conclusion: the traditional rasterization pipeline that has served PC gaming for three decades is being augmented — and in some stages, replaced — by neural network inference running on dedicated AI hardware inside modern GPUs.

TSNC is the texture storage layer of this neural pipeline. XeSS and DLSS are the upscaling layer. Neural materials and neural shading are the material evaluation layer. What these technologies share is that they use learned compact representations of data instead of explicit mathematical approximations — and they depend on the XMX, Tensor Core, and similar AI acceleration units that GPU vendors have been building into their silicon for the last several years. That hardware is now starting to pay off in ways that matter directly to game quality and performance rather than just AI workloads.

The alpha SDK release later in 2026 will be the real test of whether TSNC becomes a technology developers actually ship with, or remains a technical demonstration that struggles for adoption. The fallback path for non-Intel hardware is the key design decision that could make the difference — it means Pearl Abyss or any other studio does not have to choose between Intel users and the 85 percent of their audience on Nvidia to use TSNC. If the quality results hold up under real game conditions and the integration cost is low, the motivation to adopt it is strong.


Want more GPU technology coverage, graphics driver news, and deep-dives on the latest hardware innovations? Browse our other posts for the latest on Intel Arc, Nvidia, AMD, and PC gaming technology.