Microsoft Overhauls DirectX 12 Ray Tracing, Cutting BVH Build Time to Roughly 1/254 in Sample

One of the biggest challenges in bringing real-time ray tracing to game engines is the cost of building the hierarchical structures used for ray intersection tests. As characters deform and objects move, a data structure called a bounding volume hierarchy (BVH) has to be updated. With conventional approaches, changes in geometry can force large-scale rebuilds, straining GPU compute time and memory bandwidth. In scenes with many dynamic objects, or in vast open worlds, this work easily becomes a performance bottleneck.

On October 28, 2026, Microsoft released the Agility SDK 1.722-preview, a development kit for DirectX 12. It introduces "Clustered Geometry," which splits geometry into small units for reuse; "Partitioned TLAS (PTLAS)," which partially updates the scene-wide acceleration structure; and an indirect build API that runs build operations based on data residing on the GPU. Microsoft positions these features as the most significant advance since it introduced DirectX Raytracing (DXR) in 2018.

The new features do not require new dedicated circuits or instruction sets in ray-tracing-capable GPUs. They are designed to reduce build costs by splitting and reusing data structures and by moving work onto the GPU, while leveraging existing hardware capabilities. However, using them requires supporting drivers, and they will not immediately work on every existing ray-tracing-capable GPU. Moreover, the large performance gains Microsoft published were obtained in a specific test environment and do not mean every game will speed up by the same proportion.

A Two-Tier Approach to Reducing Full BVH Rebuilds

Traditionally, ray tracing has managed geometry data with a two-level BVH: a bottom-level acceleration structure (BLAS) that manages individual mesh shapes, and a top-level acceleration structure (TLAS) that gathers multiple instances of those shapes placed in the scene. When a character's vertices deform, level of detail (LOD) switches, or streaming loads new geometry, the related BLAS must either be rebuilt from triangle polygons or updated through a "refit" process on the existing hierarchy. When the mesh topology, which describes how the mesh is connected, changes, however, refitting alone is not enough, and rebuilding the whole structure becomes a heavy burden.

The new preview addresses this problem at two levels: the geometry inside objects and the placement of the whole scene. Specifically, it combines the following three technologies to make builds more efficient.

1. Clustered Geometry: Splits an object's internal geometry into small clusters of up to 256 vertices and 256 triangles, and builds and reuses the BVH on a per-cluster basis.
2. Partitioned TLAS (PTLAS): Divides the scene-wide TLAS into spatial partitions, preserving the structure of unchanged regions and updating only the parts that need it.
3. Indirect RTAS Operation API: Executes acceleration structure build operations using arguments prepared in GPU memory, enabling coordination with compute shaders and batch execution of multiple operations.

The indirect build API reduces the burden of the CPU issuing individual, fine-grained build commands every frame. An application first calls GetRTASOperationPrebuildInfo() to check the memory sizes needed for the temporary working area (scratch buffer) and output area. It then references an argument array placed in GPU memory from ExecuteIndirectRTASOperations() and executes multiple build operations together.

This API has an important constraint, though. Multiple operations contained in a single ExecuteIndirectRTASOperations() call have no guaranteed execution order inside the GPU and may be processed in parallel. Therefore, when a later operation uses the results of an earlier one, such as generating clusters, building a BLAS that references those clusters, and registering it in the PTLAS, the calls must be separated with appropriate GPU resource barriers in between. Clustered Geometry and PTLAS can each be used independently or together, but they cannot be adopted with only minor changes to existing code. To get the full benefit, a game engine's ray tracing pipeline needs to be reworked.

{
  "type": "bar",
  "title": "BLAS Build and Ray Tracing Time on RX 9070",
  "unit": "ms",
  "categories": ["Conventional BLAS rebuild", "Clustered Geometry"],
  "series": [
    { "name": "AS preparation/build time", "values": [788.0, 3.11] },
    { "name": "Ray tracing time", "values": [72.6, 9.27] }
  ],
  "caption": "Measurements from Microsoft's official sample (D3D12RaytracingClusteredGeometry)",
  "source": "Microsoft DevBlogs (2026-10-28)"
}

In Microsoft's official sample, acceleration structure build time dropped dramatically and frame rates improved significantly. However, these results were obtained under specific conditions well suited to Clustered Geometry, and the same effect is not guaranteed in real games. Achieving this performance also requires correctly handling the rules for creating, updating and destroying clusters, as well as how shaders identify geometry.

How Clusters of Up to 256 Vertices and 256 Triangles Are Reused

The basic unit of Clustered Geometry is the Cluster Level Acceleration Structure (CLAS). A single CLAS holds up to 256 triangles and 256 vertices as an indexed mesh. An application first builds individual CLAS objects, then gathers references to them to create a "Cluster BLAS." That Cluster BLAS is then placed in the scene as an instance in a TLAS or PTLAS.

A major advantage of this design is that a CLAS can be shared among multiple Cluster BLAS objects. For example, when loading new terrain or objects in a game, or when switching LODs incrementally, existing clusters can be reused to build a new BLAS. Modern game engines use "meshlets," which divide meshes into small groups of triangles, and engines that adopt such data structures can easily use their existing partitioning results as CLAS input.

Sharing clusters, however, demands strict memory management. A Cluster BLAS does not hold the CLAS data itself; it points to locations in memory. If vertex coordinates in a referenced CLAS are rewritten or its memory address changes, any Cluster BLAS referencing it becomes invalid. In that case, the Cluster BLAS must be rebuilt to fix the references, and higher-level acceleration structures must be updated as needed.

All CLAS objects belonging to the same Cluster BLAS are also placed in a common object-local coordinate system. There is no mechanism for applying an independent transform matrix to each cluster when building individual CLAS objects. Therefore, when combining multiple CLAS objects into one BLAS, each one's vertex coordinates must follow the shared coordinate system.

When a mesh deforms through animation or procedural generation, it is also updated differently from before. Clustered Geometry has no refit operation that updates only vertex positions while preserving the existing hierarchy. Instead, it introduces the "Cluster Template," a mechanism that retains in advance the results of build processing that does not depend on vertex positions, such as cluster topology and vertex connectivity.

A Cluster Template cannot be used directly for ray intersection tests, but by supplying the latest vertex coordinates generated in, for example, a compute shader, a CLAS can be built efficiently. For instance, even if a mesh deforms substantially through character animation, as long as the topology doesn't change, the structure does not need to be analyzed from scratch every frame. By reusing precomputed information, a CLAS matching the latest vertex positions can be generated with less computation.

How shaders retrieve geometry attributes has changed as well. In the conventional ray tracing pipeline, a primitive index unique across the whole BLAS was available, but with Clustered Geometry, PrimitiveIndex() returns a local triangle number (0 to 255) within the CLAS it belongs to. Therefore, when a hit shader retrieves per-triangle normals or material information, it must identify the triangle by combining the application-assigned 32-bit ClusterID() with PrimitiveIndex(). Shaders that assume the existing primitive index need to be fixed in this respect.

Support for built-in functions such as TriangleObjectPositions() in Shader Model 6.10 is also important. With the corresponding setting enabled, triangle vertex coordinates can be retrieved directly from the acceleration structure in object space. This makes it possible to skip reading a separately prepared vertex buffer from VRAM, making shader work such as normal calculation more efficient.

Vertex storage formats have been extended as well. In addition to ordinary floating-point and normalized integer formats, developers can use quantization that truncates the lower bits of the mantissa, and a fixed-point compression called "COMPRESSED1." With COMPRESSED1, a shared anchor coordinate and a power-of-two scale are set per cluster, and each vertex position is stored as a packed integer offset relative to that anchor. This kind of compression reduces the memory required for geometry data.

Depending on how clusters are built, however, ray tracing performance could instead degrade. The DirectX specification recommends partitioning so that the triangles making up a cluster sit close together in space. If distant triangles are grouped into the same cluster, unnecessary bounding boxes must also be examined during ray intersection tests. In other words, even if clustering shortens build time, a poor partitioning method increases the time spent on BVH traversal.

PTLAS Splits the Whole Scene and Updates Only the Regions That Changed

"Partitioned TLAS (PTLAS)" makes the scene-wide acceleration structure more efficient. It extends the conventional TLAS and can handle both ordinary BLAS objects and the new Cluster BLAS. Its defining feature is that it divides the scene into multiple spatial regions (partitions) and can update only the parts where changes occurred.

In a vast open world, many objects such as buildings and terrain stay in the same position for long periods. With a conventional TLAS, even when only part of the scene changes, the update could affect a wide range. With PTLAS, the hierarchy of unchanged partitions is reused and only the regions that need updating are rebuilt. This helps keep the load from updating dynamic objects low while maintaining a large scene.

For frequently moving objects, a special mechanism called the "Global Partition" is provided. Instances registered there are treated, at build and traversal time, as if each were an independent partition. This means that even if some objects move violently, the entire partitions containing the many static objects around them need not be rebuilt every frame. Objects that stop moving can also be returned to a normal spatial partition.

PTLAS uses three types of operations depending on what is being updated.

Importantly, UPDATE_INSTANCE cannot change an object's position. To update a transform, you must use WRITE_INSTANCE. If only the changed instances are extracted in a compute shader and update operations are executed based on that list, unnecessary writes to unchanged instances can be avoided. Differential updates like this are expected to be more effective in scenes with few changes.

PTLAS performance, however, depends heavily on how partitions are divided. If multiple partitions overlap substantially in space, a ray passing through must examine multiple bounding boxes, increasing traversal cost. Overusing the Global Partition also reduces the rebuild burden but increases the number of targets for intersection tests at the top level. Partitions must therefore be designed with ray traversal efficiency in mind, not just reduced build time.

Memory management has constraints as well. With in-place updates, which update a PTLAS within its existing memory region, buffers corresponding to the instance capacity and partition capacity declared in advance must remain allocated. Even if few instances actually change, the reserved memory region cannot be shrunk accordingly. As a result, reducing computation through differential updates and minimizing memory usage do not necessarily go hand in hand.

Required Environment and Support From GPU Vendors

This Agility SDK preview is not immediately usable on every PC that supports DirectX 12. Testing it requires the specified runtime and compiler, plus supporting drivers prepared by each GPU vendor. The development environment must meet the following conditions.

• Agility SDK: Use the headers and runtime of 1.722.0-preview.
• DirectX Shader Compiler (DXC): Use the preview build "Patch 2 v1.10.2605.37," which supports Shader Model 6.10.
• Windows settings: Enable Developer Mode and enable the experimental features D3D12ExperimentalShaderModels and D3D12RaytracingPreview before creating the device.
• Ray tracing pipeline: To use Cluster BLAS, explicitly specify D3D12_RAYTRACING_PIPELINE_FLAG_ALLOW_CLUSTERED_GEOMETRY. For inline ray tracing, use the corresponding RayQuery flag.

Microsoft explains that the new features require no new hardware capabilities beyond ray tracing. That does not mean, however, that the same features can immediately be used on every past ray-tracing-capable GPU. The actual range of support depends on each vendor's driver development and validation, and on whether sufficient performance is achieved on the target GPU.

The support status published by each vendor as of the end of October 2026 is as follows.

• NVIDIA: "Game Ready Driver 621.01" supports the Clustered Geometry and PTLAS previews across all generations of GeForce RTX series.
• AMD: Released the Agility SDK preview-compatible driver "RN-RAD-MS-AGILITY-SDK-26-20-12-01" for the Radeon RX 9000 series.
• Intel: Released the compatible driver "931698" for the discrete "Intel Arc B-Series Graphics" and for "Core Ultra processors (200V series and Series 3)" with integrated GPUs.
• Qualcomm: Support on the Snapdragon X2 platform is under development, with a target of making drivers available in the first to second quarter of 2027.

On the application side, too, you need to check whether the runtime environment supports the new features. Specifically, call CheckFeatureSupport1 through the ID3D12Device16 interface and confirm that the ClustersAndPTLASSupported flag is enabled. On environments that don't support it, a fallback to processing with conventional BLAS and TLAS is needed. Even when adopting the new API, the existing ray tracing pipeline must be maintained to run the game on a wide range of GPUs.

Build Time Cut to About 1/254, but Scratch Memory Rises Sharply

Microsoft's sample "D3D12RaytracingClusteredGeometry" reports a large performance improvement from Clustered Geometry. The testing used AMD's Radeon RX 9070, measuring a test scene with a large number of static geometry objects and deforming sphere meshes. This is a simplified scene created for technical validation and does not reproduce the load of a typical commercial game.

In this environment, rebuilding a conventional BLAS from triangle data every frame yielded a frame rate of just 1.2 FPS. With Clustered Geometry, it reached 79 FPS, an improvement of about 66 times. Especially large was the improvement in acceleration structure preparation and build time, which fell from 788 milliseconds to 3.11 milliseconds, about 1/254. In addition, the memory held by the acceleration structures for static and animated meshes combined dropped by about 89.7%, from 7,519 MiB to 774 MiB.

Microsoft cautions, however, against interpreting this result as the performance gain to expect in commercial games. The test was run under conditions in which Clustered Geometry is particularly effective and conventional BLAS rebuilding is extremely costly. In real games, bottlenecks vary with mesh composition, animation, shader work and other rendering loads, so the same rate of improvement is not guaranteed.

While build time and retained memory fell dramatically, scratch memory, the temporary working area needed during builds, increased. The main measurements shown in Microsoft's sample are summarized below.

Source: Microsoft DevBlogs (October 28, 2026), D3D12RaytracingClusteredGeometry official sample

Notably, the scratch buffer for building static meshes rose about 287 times, from 1.83 MiB to 526 MiB. The scratch buffer for animation also grew about 21.7 times, from 8.25 MiB to 179 MiB. Although the memory retained by finished acceleration structures falls sharply, executing the build requires a larger temporary area than before. In game engines where GPU memory use is tightly limited, how to allocate these scratch buffers could become a new challenge.

For PTLAS, which manages the whole scene, there is also a trade-off between shorter build time and traversal performance. In Microsoft's "D3D12RaytracingPartitionedTLAS" sample, performance was measured with a scene of 4,702 falling dominoes. The update step, which took 2.88 milliseconds with a full rebuild of a conventional TLAS, dropped to 0.79 milliseconds with PTLAS. Ray tracing time after the update, however, was reportedly slightly longer than with the conventional TLAS.

This is because partitioning does not always produce a hierarchy optimal for intersection tests, and rays may have to examine more regions. PTLAS can reduce build load by narrowing the update targets, but it is not a technology that always speeds up traversal itself. To actually shorten frame time, the time saved in building must exceed the time added in traversal.

As a prior example of a related technology, "Gears of War: E-Day" can be cited. The game uses clustered geometry for ray tracing, but what it adopts is NVIDIA's proprietary "RTX Mega Geometry" API. It is not a case of adopting the newly announced standard DirectX API, so the two must be distinguished.

NVIDIA has also released the "dx12_forest_ray_tracing" demo, which places 60 million plants in a 25-square-kilometer forest scene. This too, however, is a demo showing technology under development, not performance data measured in the actual play environment of a commercial game. These examples show the potential of clustered ray tracing, but judging how much improvement DirectX's new API will bring in real games will require further validation.

This DirectX 12 extension aims to streamline BVH rebuilds, a burden in dynamic geometry and large scenes, through cluster reuse and GPU-driven differential updates. The large build-time reductions shown in specific samples are promising, but practical use will require attention to scratch memory management, spatial partition design and traversal performance optimization. As supporting drivers from GPU vendors mature and validation in real game engines progresses, it will become clear how far this technology can improve frame rates and image quality.