On October 28, 2026, Microsoft released new DirectX Raytracing (DXR) features in "Agility SDK 1.722.0-preview." In the official sample, the size of the acceleration structure (AS), the data structure that speeds up ray-versus-object intersection tests in ray tracing, fell 89.7%, from 7,519 MiB to 774 MiB. However, this compares the size of the finished acceleration structures only. It does not mean that a game's overall VRAM usage will drop by the same proportion.
To evaluate real VRAM usage, you need to consider not just the size of the finished acceleration structures but also the temporary working memory required to build them. How the built data is placed in memory also changes the required capacity and processing time. To judge how much the 89.7% reduction will help in actual games, it is important to examine these factors separately.
The 89.7% reduction applies to the finished acceleration structure
In the official D3D12 Clustered Geometry sample comparison published by Microsoft, the same scene is processed with the conventional method and with the new cluster method, and the size of the acceleration structures and the processing times are measured. The conventional method rebuilds the acceleration structures that handle object geometry, whereas the cluster method splits geometry into small units and manages them individually. The test used an AMD Radeon RX 9070, and the sample lets you compare different build methods, memory layouts, vertex data formats, and more.
Breaking the officially published memory usage into finished acceleration structures and build-time working memory gives the following. All units are MiB.
| Metric | Conventional | Cluster method | What is measured |
|---|---|---|---|
| Total finished AS | 7,519 | 774 | Total size of finished acceleration structures, including the TLAS |
| Static AS | 723 | 527 | Size of acceleration structures for static geometry |
| Animated AS | 6,794 | 244 | Size of acceleration structures for moving geometry |
| Working memory for static geometry | 1.83 | 526 | Temporary space needed to build static geometry |
| Working memory for moving geometry | 8.25 | 179 | Temporary space needed to build moving geometry |
Note: Figures are based on Microsoft's official comparison results. The finished AS and working memory are different metrics, and the totals use the figures from the official announcement.
The finished AS size fell from 7,519 MiB to 774 MiB, a reduction of about 89.7% relative to the conventional method. This ratio, however, applies only to the size of the finished acceleration structures. It is not based on a game's total VRAM usage or on the VRAM capacity installed on a graphics card. Meanwhile, the working memory needed during the build increased with the cluster method for both static and moving geometry. Even so, these figures cannot simply be added together to get the peak usage during the build. The published table does not show whether each region is allocated at the same time or whether regions are reused once processing finishes.
US tech outlet HotHardware also reported on October 31 that VRAM usage could potentially be cut by up to about 90%. But the 89.7% figure cited in that article is the reduction in acceleration structure size, and independent testing has not confirmed a comparable reduction in overall game VRAM. Microsoft itself cautions against assuming that actual games will see improvements of the same magnitude as the official sample.
Sharing small acceleration structures and updating only what is needed
Conventional DXR combines the BLAS (Bottom-Level Acceleration Structure), which manages object geometry, with the TLAS (Top-Level Acceleration Structure), which manages how objects are arranged in the scene. The newly introduced "Clustered Geometry" splits geometry into small units and lets each unit's acceleration structure, the CLAS (Cluster Acceleration Structure), be shared among multiple Cluster BLASes. The basic hierarchy in which the TLAS references the BLAS is retained.
Instead of rebuilding large acceleration structures in one piece as before, it manages them in smaller units and shares them as needed. This may reduce the burden of holding duplicate copies of the same geometry data. However, Microsoft has not published how much each mechanism, such as CLAS sharing, contributed to the 89.7% reduction, so the breakdown of the savings cannot be determined.
Another new feature is the Partitioned TLAS (PTLAS). It divides the scene's placement information into multiple regions, keeps the unchanged parts, and updates only the regions that need it. Because it reduces the need to update everything each time part of the scene changes, it is expected to lighten the processing load, especially in dynamic scenes.
However, even if the amount of data to update shrinks, the required memory does not necessarily shrink by the same proportion. When PTLAS is updated within an existing memory region, the size of the allocated region is determined by the number of instances and partitions declared in advance. The required capacity is not determined solely by the number of instances that actually changed, so update efficiency and memory reduction need to be evaluated separately.
Memory placement changes capacity and processing time
Another factor affecting the memory efficiency of acceleration structures is how the built data is placed. Here, placement means at which address within a buffer a built acceleration structure is stored. The official DirectX specification explains the differences between ways of determining the destination address in the section "Implicit vs explicit destinations for acceleration structure operations."
With an "implicit destination," the application allocates an output buffer in bulk, and the driver decides the address at which each acceleration structure is placed inside it. However, the required size calculated in advance is a conservative estimate, so more memory than the actual finished size may be allocated. In addition, structures cannot always be packed without gaps, so even if the finished data is small, the total allocated buffer does not necessarily shrink by the same amount.
With an "explicit destination," by contrast, the application specifies the destination address of each acceleration structure. Because the GET_SIZES operation can be used to check the size of the build results beforehand and memory can be allocated accordingly, unnecessary space may be reduced. There is also a method that builds with implicit destinations, then obtains the actual finished sizes and moves the acceleration structures to repack them without gaps.
The characteristics of each placement method are summarized below. This comparison is based on the DirectX specification and is separate from the memory usage measured in the official sample above.
| Placement method | Memory allocation and placement | Effect on memory usage | Effect on processing time |
|---|---|---|---|
| Implicit | The driver decides the placement within the output buffer | Conservative estimates can leave extra space and gaps | Speed differences depend on the implementation and conditions |
| Explicit | The application checks each structure's size in advance and specifies the destination | May reduce peak usage compared with implicit placement | Size calculation duplicates work with the build, which can increase processing time |
| Implicit, then move | Structures are relocated to fit their finished sizes | Packs structures most tightly, but may require temporary space for the move | Adds a step of moving data after the build |
With explicit placement, knowing the required capacity in advance makes memory allocation more efficient, but the size calculation and the actual build duplicate work and may increase processing time. The method of moving data after an implicit build can also pack finished acceleration structures without gaps, but it may require a temporary buffer for the move. In other words, the method that minimizes final memory usage is not necessarily the best in terms of peak usage during the build or processing time. Implementers need to measure both memory efficiency and processing speed.
These placement differences do not explain how the 89.7% size reduction in the official sample was achieved. The placement method used in the sample and the savings from each method cannot be determined from this comparison. What the specification makes clear is the placement options available to developers and the trade-offs in memory capacity and processing time that come with each.
In real games, peak VRAM usage and processing speed matter
To judge how much VRAM the new features can save in actual games, it is necessary to measure the peak memory required during the build in addition to the size of the finished acceleration structures. The individual working-memory figures alone do not show how long each region is in use at the same time or how much is reused during processing. Because the placement method can also change peak usage, comparisons should be made under the same scene and load conditions.
Processing speed should likewise be evaluated separately for building acceleration structures and for running ray tracing. In Microsoft's official sample, the time to prepare and build acceleration structures fell from 788 ms to 3.11 ms, and the GPU ray-tracing time fell from 72.6 ms to 9.27 ms. The former is the time to prepare the data structures needed for ray tracing, while the latter is the time to trace rays using the finished structures. They are different processes, so the change in each needs to be checked to judge performance gains in actual games.
The new features are currently offered as a preview. Using them requires a runtime and headers that support Agility SDK 1.722.0-preview, a compatible driver, Windows Developer Mode, and a Shader Model 6.10 preview environment. No new hardware features are required, but support and validation for each GPU generation depend on the vendors, and developers must also integrate the features into their games.
The 89.7% size reduction alone does not tell us whether a graphics card with 8 GB of VRAM will be able to run a particular game comfortably. If future testing in actual games examines peak VRAM usage for each placement method, acceleration structure build times, and ray-tracing performance, it will become clearer under what conditions the new features are effective. For developers, what matters is whether they can choose an implementation suited to each game's scenes while balancing memory savings against processing speed.