AMD DGF: An Open Geometry Compression Standard

Originally posted:
Josh Barczak's avatar
Josh Barczak

Dense Geometry Format (DGF), a block-based geometry compression technology developed by AMD, is an innovation with the potential to deliver transformative increases in geometric complexity for ray traced rendering in gaming, content creation, virtual production, and other real-time 3D applications.

In July of 2024, AMD published a research paper introducing its upcoming geometry compression technology. Since that time, we have been working steadily to advance DGF as an open standard:

Today we’re releasing an updated AMD DGF SDK with a preview of a new technology called DGF SuperCompression, which makes DGF even smaller, and simplifies rendering of DGF content on non-DGF devices. You can read about that here.

In partnership with Samsung, we’re also announcing some exciting news on the standardization front, but first, we’ll start with a review of what DGF is and what problems it solves.

The dense geometry problem

Historically, in graphics, we’ve stored triangle data in memory as vertex and index buffers, sent it to a hardware rasterizer, and produced pixels. A few years ago, we added ray tracing to the pipeline, so now we pass our meshes through driver routines, which produce vendor-specific acceleration structures that the hardware can consume.

In the same timeframe, technologies like Nanite in Unreal Engine raised the bar for model complexity by introducing small triangle formats that are directly rasterized — in some cases using software rasterization in compute shaders. Systems like these create challenges for ray tracing.

A custom compression format can’t be consumed directly by current ray tracing APIs. Instead, it must be decoded it into something APIs understand. This increases memory pressure and adds latency to the acceleration structure build, both actions that can lead to unstable, stuttering frame rates. Even if API restrictions were lifted, existing hardware acceleration structures are much too large to support future content, which will be authored with lower data rates in mind.

The situation is illustrated in the figure below:

Moving beyond opaque APIs

The current API design for ray tracing acceleration structures is a “black box” in which a neutral input format is translated by the driver into a hardware-specific format. This provided considerable flexibility for implementations. It was a necessary step in the API evolution, but it has certain fundamental limitations:

  • The allocation for “pre-build” memory must be sized for the worst-case compression rate, increasing the minimal footprint and adding complexity and inefficiency to the build process.
  • The implementation must store enough information to exactly reproduce the input triangle order for index references, which will increase memory consumption.
  • The implementation must convert the input into a hardware format, ultimately impacting performance, silicon area, and/or power. A mandatory runtime transcode discourages implementations from parts of the design space that are denser but harder to encode. The result is an indirect increase in memory consumption.

Software developers have expressed interest in creating a standard efficient geometry compression format to address these limitations. DGF fills this role — performing for geometry compression what formats like DXT, ETC, and ASTC have done for texture compression.

Native graphics processing unit support for DGF moves complex compression work outside the driver, enabling an ecosystem like this one:

Toward standardized geometry compression

Today we are pleased to announce that AMD has partnered with Samsung to develop a multivendor DGF extension for Vulkan®, which both companies intend to implement.

“Samsung, with the AMD RDNA architecture, brought ray tracing to the smartphone market in 2022,” said Gabe Dagani, Senior Director of GPU Software at Samsung. “We continue to work closely with AMD to bring advancements such as the DGF extension to future mobile devices.”

If you’re an engine developer or technical artist with a next-gen focus, we invite you to download the AMD DGF SDK and think about how this technology will fit into your workflow. Feedback and general questions on the AMD Developer Community are invited and appreciated.

Footnotes

Links to third party sites are provided for convenience and unless explicitly stated, AMD is not responsible for the contents of such linked sites and no endorsement is implied. GD-97.

The “Samsung” name, the “Samsung logo” and all related names, logos, product and service names, designs and slogans are trademarks of Samsung Electronics Co., Ltd.

Vulkan and the Vulkan logo are registered trademarks of the Khronos Group Inc.

Josh Barczak's avatar

Josh Barczak

Josh Barczak is an AMD Fellow focused on GPU raytracing architecture and 3D API evolution. He has been enjoying GPU hardware and software architecture for roughly 6 years. Prior to this he spent time in the game industry as a rendering lead.

Related news and technical articles

Related videos

Introducing AMD Render Pipeline Shaders SDK
Introducing AMD Render Pipeline Shaders SDK
The brand-new AMD Render Pipeline Shaders (RPS) SDK is a comprehensive and extensible Render Graph framework for graphics applications and engines using explicit APIs (such as DirectX® 12 and Vulkan®). In this video we will take a look at the overview of the design and implementation of the SDK. We will demonstrate how the RPS SDK can help game engines building render graphs easily, managing resource barriers and transient memory efficiently, and more!