Problem: Increasing Triangle Density
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 raytracing 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 have raised the bar for model complexity, by introducing very small triangle formats which 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 the current raytracing API. Instead, we need to decode it into something which the APIs understand. This increases memory pressure and adds latency to the BVH build, both of which can lead to unstable, stuttery frame rates. Even if the API restrictions were lifted, the existing hardware acceleration structures are much too large to support future content, which will be authored with the lower data rates in mind.
The situation is illustrated in the figure below:
Solution: Hardware Geometry Compression
Dense Geometry Format (DGF) is a block-based geometry compression technology developed by AMD, which will be directly supported by future GPU architectures. It aims to solve these problems by doing for geometry data what formats like DXT, ETC and ASTC have done for texture data.
DGF is engineered to meet the needs of hardware by packing as many triangles as possible into a cache aligned structure. This enables a triangle to be retrieved using one memory transaction, which is an essential property for ray tracing, and also highly desirable for rasterization.
By moving geometry compression outside the driver, the compressor can process the data in ways that would either be too slow to perform at runtime or would violate the API specifications.
Native GPU support for DGF will close the geometric complexity gap between raster and ray tracing, enabling an ecosystem like this one:
Competitive Performance
DGF compression is competitive with the state of the art in terms of accuracy and data-rate, and decoding, even emulated in shader code, is fast enough for direct real-time rendering. DGF also enables encoding times which are fast enough to support rapid iteration.
Some example results are shown below (frame times were measured on an AMD Radeon RX7900 XT):
| Triangles | Input Size | DGF Size | Bytes Per Triangle | Frame Time | Compression Time | |
|---|---|---|---|---|---|---|
 |
1.6 M | 29 MB | 5.7 MB | 3.73 | 0.26 ms | 0.84 s |
 |
2.1 M | 37 MB | 6.2 MB | 3.05 | 0.31 ms | 0.65 s |
 |
12.7 M | 271 MB | 41.3 MB | 3.39 | 1.33 ms | 5.14 s |
For a description of the compression algorithms and data format, and further analysis, we refer the reader to our HPG 2024 paper.
Intuitive and Controllable
DGF compresses the input mesh while preserving its connectivity. There’s no need to re-mesh or resample in order to use it. Remeshing is labor-intensive if done manually, and algorithms for automating it can be slow and difficult to control. By preserving topology, we’re able to preserve sharp corners and important features like UV chart and LOD cluster boundaries.
Instead of a fixed encoding precision for vertices, DGF provides fine-grained control. This allows developers to make fine-grained tradeoffs between accuracy and memory consumption, based on the needs of the content and the type of shading that’s in use. Another benefit of fine-grained control is that if compression artifacts become a problem, they can often be fixed just by dragging a slider. The DGF encoder works by taking a target precision (in bits), and quantizing the coordinates into signed integers with that bit width. This initial quantization is the only source of error in DGF.
 |
 |
 |
|
|---|---|---|---|
| Precision Target | 16 bits | 14 bits | 12 bits |
| Compressed Size | 4.4 MB | 3.5 MB | 3.0 MB |
AMD Dense Geometry Compression Format SDK
AMD has released the Dense Geometry Compression Format (DGF) SDK to encourage developers to experiment with geometry compression, and provide a reference toolchain for integration into content pipelines.
The SDK provides the following essential building blocks:
- CPU libraries for geometry compression and decompression.
- Optimized HLSL code for GPU decompression.
- An interactive viewer which loads and compresses models (OBJ or PLY), and allows users to assess compression quality.
All of the provided code is released under a permissive license and runs on any hardware.
If you’re an engine developer or technical artist with a next-gen focus, we invite you to download the DGF SDK and think about how this technology will fit into your workflow. Feedback (positive or negative), and general questions are invited and appreciated.
If you have questions about the data format and encoding algorithms, or want more data points, you can also read our HPG 2024 paper.
