AMD Shipped a Geometry Compression Format Four Months Ago. It Is the Portable One, and Nobody Wrote About It

By Indie Kings | September 27, 2026

Updated September 27, 2026: This is not breaking news and we will frame it accordingly. AMD shipped DGF SuperCompression in DGF SDK 1.2 back in May 2026, and it remains the current release, because the RDNA hardware it is designed for has not arrived. That is itself the interesting part. NVIDIA has taken three separate news cycles this month on its competing approach to the same problem, and AMD's has had none, despite the two being closer to direct opposites in design than the coverage suggests.

Verification note: Reported by VideoCardz's WhyCry on May 10, 2026, from AMD's own GPU Open article introducing DGF SuperCompression. All compression ratios and decode timings are AMD's own published figures and are attributed as such rather than independently verified. The age of the source is stated in the headline deliberately: this is a four-month-old SDK release that is still the current one, not a launch announcement. The comparison with NVIDIA's approach is drawn from VideoCardz's analysis of the two rather than from a shared benchmark, and the two technologies have not been measured against each other by anyone we can find.

Image: DGF SuperCompression. Credit: AMD via VideoCardz.

The problem both vendors are attacking

Ray-traced rendering runs into a wall with dense geometry, and both AMD and NVIDIA have now shipped something aimed at it.

A triangle mesh is an enormous amount of data. A modern game scene can carry tens of millions of triangles, and the geometric representation of that scene has to live somewhere, travel somewhere, and be traversed by the GPU every frame. The problem is not that the data is large in principle. It is that it is large, it is structured in a way that hardware traversal handles badly, and the cost shows up as ray-tracing throughput.

Ray tracing needs to find which geometry a ray hits. Traditional approaches build an acceleration structure, typically a bounding volume hierarchy, in front of the raw triangles. That structure is expensive to build, expensive to store alongside the mesh, and has to be regenerated whenever geometry changes, which during an animation is constantly.

Two vendors, two different answers to the same wall, and they are worth setting side by side because the difference is more fundamental than the announcement volume suggests.

What DGF SuperCompression actually does

Dense Geometry Format, DGF, is AMD's block-based compression format for dense meshes, and SuperCompression is an additional layer on top of it.

The detail that matters most is what the new layer is not. DGFS is not consumed by hardware. It is a smaller storage format for DGF data, sitting on the asset side of the pipeline rather than the silicon side.

Its guarantee is exactness. AMD says DGFS can exactly reconstruct the original DGF blocks, so nothing is lost relative to the uncompressed DGF. It can additionally decode to conventional vertex and index buffers, which is what makes the format portable: an asset stored as DGFS still runs on a GPU with no DGF support at all, because the decode produces the ordinary buffers any rasteriser or ray tracer already understands.

That gives DGF an unusual property for a vendor format. The SDK remains open source, and it reaches hardware through DirectX 12 and Vulkan, so it supports all GPU vendors rather than being locked to Radeon. AMD is building a format that its own future hardware will consume natively, and which every other vendor can already use.

The compression figures, and the more interesting headline

AMD published two sets of numbers and the headline uses the smaller one, which is worth noticing.

So the honest reading is that DGFS removes roughly 30 percent of the geometry storage versus raw DGF, and the "up to 22 percent" in the announcement is the conservative claim, measured against a baseline that has already had generic GPU compression applied on top.

That is an unusual way to headline a compression feature, and a fair one. The larger number is measured against a baseline nobody would ship, while the smaller one is measured against a pipeline that already applies GDeflate. Reporting the conservative figure as the headline suggests the format holds up when competing with existing compression rather than only in isolation.

Decode cost, which is where formats live or die

Compression on geometry is only worth having if the cost of getting the data back is small, and this is the part that decides whether a format is adopted.

AMD published decode timings on a Ryzen 9 7950X with 64GB of DDR5-6000 and a Radeon RX 9070 XT. A ten million triangle Statuette model decoded to meshlets in 0.15 seconds, while decoding the DGF blocks directly took 0.22 seconds.

Two caveats belong with those figures, both from AMD. The results are for a single CPU core, so they are a per-core figure rather than a whole-system one, and AMD notes that a GPU-based decoder is also possible.

The direction of the result is the interesting part. Going from DGF blocks to DGFS to meshlets is faster than going from DGF blocks to meshlets directly, which means the compression is not costing decode time, it is removing it. That is unusual and it is the number that would decide adoption if a studio is evaluating the format.

How it differs from what NVIDIA is doing

VideoCardz draws the comparison and it is the right frame, because the two are often described as rivals when they are not really comparable.

They are not directly compatible. Both address dense geometry in ray-traced rendering, and they come from opposing vendors, but the actual work is different.

The distinction is the key to understanding both. DGF is about what geometry costs to store. Mega Geometry is about what it costs to traverse at runtime. They could both be right and a title could use both, and neither is a substitute for the other.

The asymmetry in coverage, and why it is a design difference

There is a measurable gap in attention that is worth naming rather than pretending is normal.

Across the sources feeding this site, NVIDIA's approach has produced three separate items this month, from Tom's Hardware, TechPowerUp and Hardware Busters, covering an SDK release and a 2.0 update. AMD's DGF SuperCompression has produced one, from VideoCardz, in May.

Part of that is timing. Mega Geometry 2.0 is genuinely new this month, while DGF SDK 1.2 has been current since May. Part of it is that the hardware is not here. There is also a separate report in circulation that NVIDIA GeForce Rubin and most AMD RDNA 5 GPUs are not expected until 2028, which would push AMD's hardware-dependent advantage well past the point where it can be measured in a shipping game.

But the asymmetry is not only about timing. It follows the design. A vendor whose format is a proprietary runtime structure has to announce SDK versions, because developers have to adopt them to get anything. A vendor whose format is open source, reachable through DirectX 12 and Vulkan, and decodes to conventional buffers on hardware that does not support it, has nothing that needs announcing once it ships. The quieter technology is the more portable one, and portability does not generate headlines.

FAQ

What is DGF SuperCompression?

A feature added in AMD's DGF SDK 1.2 that provides an additional compression layer for Dense Geometry Format data. It is a smaller storage format for DGF, and it is not consumed by hardware directly. AMD says it can exactly reconstruct the original DGF blocks and can also decode to conventional vertex and index buffers.

How much does it compress geometry data?

AMD's own figures put it roughly 30 percent smaller than raw DGF on its test models, with the Dragon asset going from 29.25MB to 20.15MB and the Statuette from 40.99MB to 29.31MB. The up-to-22-percent headline figure is the conservative one, measured against a baseline that has already had GDeflate applied.

Does compressing geometry cost decode time?

On AMD's published figures, no. On a Ryzen 9 7950X with a Radeon RX 9070 XT, a ten million triangle model decoded to meshlets in 0.15 seconds from DGFS, against 0.22 seconds decoding DGF blocks directly. AMD notes both results are for a single CPU core and that a GPU-based decoder is also possible.

Is it the same as NVIDIA RTX Mega Geometry?

No, and the two are not directly compatible. DGF is a geometry compression format concerned with storage, while RTX Mega Geometry is clustered acceleration structure building concerned with runtime traversal. They are complementary rather than rival, and no one we can find has measured them against each other.

Can it run on NVIDIA or Intel GPUs?

Yes. The SDK is open source and reaches hardware through DirectX 12 and Vulkan, so it supports all vendors. Because DGFS decodes to conventional vertex and index buffers, content stored in it runs on GPUs with no DGF hardware support at all.

Why has there been so little coverage of this?

Partly timing, since the SDK shipped in May 2026 and the RDNA hardware it targets has not arrived, with reports suggesting RDNA 5 may not arrive until 2028. Partly design. A proprietary runtime format has to be announced repeatedly to drive developer adoption, whereas an open format that already reaches other vendors through standard APIs has nothing to announce once shipped. The quieter technology is the more portable one.

Bottom Line

The two companies solving the same ray-tracing geometry problem are doing almost opposite things, and only one of them is being written about. NVIDIA's approach builds clustered acceleration structures at runtime and has produced three separate news items this month across three outlets. AMD's ships a compressed asset format and has produced one, four months ago, and the reason is partly timing and partly that AMD built the quieter technology. DGF SuperCompression is not consumed by hardware. It sits on the asset side, guarantees an exact reconstruction of the original blocks, and can also decode to conventional vertex and index buffers, which is the property that makes it interesting. An asset stored as DGFS runs on a GPU with no DGF support at all, because the decode produces the ordinary buffers a rasteriser already understands. The SDK is open source and reaches hardware through DirectX 12 and Vulkan, so it works on every vendor's silicon rather than being locked to Radeon. AMD is building a format its own future hardware will consume natively and that everyone else can already use, and that asymmetry produces a predictable result: a proprietary runtime format has to be announced repeatedly to drive adoption, while an open format reached through standard APIs has nothing to announce once it ships. The numbers are respectable and, in one respect, better than the headline suggests. Around 30 percent smaller than raw DGF on the test assets, and the quoted 22.22 percent is the conservative figure measured against a baseline that already had GDeflate applied, which is an unusually honest way to headline a compression feature. The number that would actually decide adoption is the decode timing, and it goes the right way. Decoding a ten million triangle model to meshlets takes 0.15 seconds from DGFS against 0.22 seconds from DGF blocks directly, on a single core. The compression is not costing time, it is removing it. Both caveats are AMD's own, that the figures are per-core and that a GPU decoder is also possible. None of this is measurable yet. DGF hardware support is for future RDNA GPUs that have not shipped, and there is reporting that most RDNA 5 parts will not arrive until 2028, which would put AMD's hardware-dependent advantage well past the point where any studio can evaluate it in a shipping game. So the position is that AMD has shipped a technically sound, genuinely portable, and unusually quiet piece of infrastructure four months ahead of any silicon that would consume it natively, while its competitor ships the structure-building equivalent now and gets the coverage. That is not a verdict on which is better, because they are complementary rather than rival and a title could use both. It is a note about how the two ecosystems allocate attention, and about how easily a technology designed not to need a launch event ends up looking like nothing happened.

Source: VideoCardz, AMD DGF SuperCompression cuts geometry storage size by up to 22% by WhyCry, May 10, 2026, reporting AMD's GPU Open article introducing DGF SuperCompression, with the compression ratios and decode timings from AMD's own published data

Related: RTX Mega Geometry 2.0 adds geometry streaming and gears | AMD Neural Lighting rumoured as an answer to DLSS 5 on RDNA 5 | NVIDIA DLSS 5 unveiled: photo-realistic neural rendering | Radeon RX 9070 XT vs. GeForce RTX 5070, 52 game benchmarks