DirectX Raytracing Update: CLAS, PTLAS, and 66× Demo Gains

DirectX Raytracing Update: CLAS, PTLAS, and 66× Demo Gains

Microsoft has introduced one of the most significant updates to DirectX Raytracing (DXR) since its debut in 2018. Released as part of the DirectX 12 Agility SDK 1.722 Preview, the update introduces two major technologies: Clustered Geometry and Partitioned Top-Level Acceleration Structures (PTLAS).

These additions address one of the biggest performance challenges in modern ray tracing: the computational and memory overhead associated with continuously building and updating acceleration structures in complex, dynamic scenes.

In a demonstration running on an AMD Radeon RX 9070, Microsoft showed a dramatic improvement when replacing traditional Bottom-Level Acceleration Structure (BLAS) rebuilding with Clustered Geometry.

The reported results include:

• Up to 66× higher frame rates, increasing from 1.2 FPS to 79 FPS in the demonstration.
• Approximately 254× less acceleration-structure preparation and build time.
• Nearly 90% lower total acceleration-structure memory consumption.
• Approximately 87.2% lower per-frame GPU ray-tracing time.

These results are particularly interesting for large open-world games, animated geometry, procedural environments, and path-traced scenes containing millions of individual objects.

However, the improvements are not achieved through a new generation of fixed-function ray-tracing hardware. Instead, Microsoft is introducing a more efficient GPU-driven approach to organizing, building, and updating ray-tracing acceleration structures.

The new APIs also create a standardized DirectX implementation for techniques related to NVIDIA’s RTX Mega Geometry architecture, potentially making similar optimizations available across multiple GPU vendors.

An important qualification: the 66× performance improvement comes from a specific Microsoft test scene, not a commercial game. Microsoft warns developers not to expect the same magnitude of improvement in real-world games.

🚀 1. DirectX Agility SDK 1.722 Preview: A Major DXR Update

#

DirectX Raytracing first appeared in 2018 as part of the DirectX 12 ecosystem.

Since then, Microsoft has progressively expanded the API through new ray-tracing capabilities, shader functionality, and GPU execution mechanisms.

The Agility SDK 1.722 Preview introduces another major architectural step.

1.1 What Is New in Agility SDK 1.722 Preview?

#

The new SDK introduces three major DXR capabilities:

Together, these features reduce the need to rebuild large acceleration structures whenever individual objects or portions of a scene change.

This is particularly important for modern rendering engines.

As games increasingly adopt high-polygon assets, dynamic vegetation, detailed character animation, procedural environments, and large-scale streaming worlds, traditional acceleration-structure management becomes increasingly expensive.

The new APIs are designed to make ray tracing more scalable without requiring developers to sacrifice geometric detail.

1.2 Why This Matters for DXR

#

A conventional ray-tracing implementation generally relies on two major acceleration-structure levels:

• BLAS (Bottom-Level Acceleration Structure): Organizes the geometry of individual objects or meshes.
• TLAS (Top-Level Acceleration Structure): Organizes instances of those objects within a scene.

This hierarchical structure allows the GPU to determine which objects a ray might intersect without checking every individual triangle.

However, dynamic objects introduce a substantial maintenance cost.

When geometry changes, the corresponding BLAS may need to be rebuilt or refitted.

When object transforms or scene instances change, the TLAS may also require updating.

For a small scene, these operations are manageable.

For an open-world game containing millions of objects, repeatedly rebuilding large structures can consume significant GPU time and memory.

Microsoft’s new architecture addresses these costs at both the object and scene levels.

🧩 2. Clustered Geometry (CLAS): Breaking Large Meshes Into Reusable Units

#

The first major feature is Clustered Geometry, which introduces Cluster Level Acceleration Structures (CLAS).

The fundamental idea is to divide large meshes into smaller, manageable clusters rather than treating an entire mesh as one large acceleration-structure building unit.

2.1 What Is a Cluster Level Acceleration Structure?

#

A CLAS contains an indexed mesh with a maximum of:

• 256 triangles.
• 256 vertices.

Each cluster represents a relatively small section of geometry.

Instead of building an entire BLAS directly from a large collection of triangles, the application can create multiple CLAS objects and assemble them into a Cluster BLAS.

The resulting hierarchy looks like this:

Scene Geometry
      |
+-----+-----+
|           |
v           v

Object A Object B | | +-+-+-+ +-+-+-+ | | | | | | | | v v v v v v v v CLAS CLAS CLAS CLAS | | v v Cluster BLAS Cluster BLAS | | +—–+—–+ | v Top-Level AS | v Ray Tracing

The important advantage is that geometry can be organized and reused at a much finer granularity.

2.2 Why Smaller Geometry Clusters Improve Efficiency

#

Traditional BLAS generation can become expensive when a large object changes frequently.

For example, consider a detailed character model containing hundreds of thousands of triangles.

When the character moves or deforms, the rendering engine must maintain a valid acceleration structure for its geometry.

With conventional approaches, rebuilding or refitting the entire structure can introduce considerable overhead.

Clustered Geometry allows the engine to divide that geometry into smaller units.

This enables several optimizations:

• Reusing existing cluster data.
• Updating animated geometry through cluster templates.
• Reassembling acceleration structures from existing clusters.
• Reducing duplicated geometry-building work.
• Supporting more detailed ray-tracing geometry.

One particularly important use case is Level of Detail (LOD) management.

A game engine can select different combinations of existing clusters according to camera distance and visual requirements.

Rather than rebuilding an entire mesh for every LOD transition, the application can assemble a different collection of existing geometry clusters.

This approach can make high-detail ray tracing more practical.

2.3 Cluster Templates for Animated Geometry

#

Dynamic geometry presents an additional challenge because the shape or position of vertices can change every frame.

Microsoft addresses this through cluster templates.

A cluster template stores reusable geometry-building information, including topology and other position-independent properties.

For animated objects, the workflow can be organized as follows:

1. Generate the cluster templates during initialization.
2. Calculate the current vertex positions using a GPU compute shader.
3. Instantiate the templates into CLAS objects using the updated positions.
4. Build a Cluster BLAS from the resulting cluster references.
5. Update the appropriate scene-level acceleration structures.

This allows the system to reuse topology-related work instead of repeatedly constructing everything from raw triangle data.

There is an important implementation detail: Clustered Geometry does not simply support an unrestricted in-place refit of existing clusters.

Changing the contents or GPU address of a referenced CLAS invalidates the corresponding Cluster BLAS and dependent structures, which must then be rebuilt.

The benefit comes from efficient reuse and incremental construction rather than eliminating all rebuilding operations.

2.4 Better Geometric Fidelity for Ray Tracing

#

Another important implication is that developers may be able to use more detailed geometry for ray tracing.

Many traditional rendering engines use simplified proxy meshes for ray-traced shadows and reflections because maintaining full-detail acceleration structures is expensive.

This can create visual inconsistencies.

For example:

• Rasterized geometry may display detailed foliage.
• Ray-traced shadows may use simplified leaf cards.
• Reflections may not accurately reproduce the visible geometry.
• Self-occlusion may differ between rendering techniques.

By reducing acceleration-structure construction costs, Clustered Geometry makes it more practical to ray trace the same detailed geometry used by the rasterization pipeline.

This can improve consistency between visible geometry, shadows, reflections, and path-traced lighting.

🌍 3. PTLAS: Partitioned Top-Level Acceleration Structures

#

While Clustered Geometry optimizes acceleration structures at the object level, Partitioned Top-Level Acceleration Structures (PTLAS) address the same problem at the scene level.

Large open-world environments can contain enormous numbers of object instances.

Even when only a small portion of the scene changes, conventional TLAS maintenance may require significant work.

PTLAS introduces partition-based management to reduce this overhead.

3.1 The Problem With Traditional TLAS Updates

#

A conventional TLAS contains references to multiple object-level BLAS structures.

These instances include information such as:

• Object transformation matrices.
• BLAS addresses.
• Instance identifiers.
• Hit-group contributions.
• Instance visibility and flags.

When objects move or change, the TLAS must be updated to reflect the new scene configuration.

Consider an open-world game containing 100,000 object instances.

If only 100 objects move during a frame, rebuilding or extensively refitting the entire scene-level acceleration structure may be inefficient.

The GPU spends resources processing large amounts of scene information that has not changed.

PTLAS attempts to make the update cost more proportional to the amount of modified scene data.

3.2 Spatial Partitioning

#

PTLAS divides the scene into multiple partitions.

Each partition contains a group of object instances, ideally organized around spatial coherence.

For example:

Global PTLAS
      |
+-----+-----+-----+
|           |     |
v           v     v

Region A Region B Region C | | | +—+—+ +—+ +—+ | | | | | | | v v v v v v v Inst Inst Inst Inst Inst Inst

When an object changes, the application updates the corresponding partition rather than unnecessarily rebuilding unrelated scene regions.

Unchanged partitions can retain their previously constructed acceleration-structure data.

This is especially useful for:

• Large open-world environments.
• Dynamic vegetation.
• Moving vehicles.
• Animated environmental objects.
• Streaming geometry.
• Large procedural scenes.

3.3 Global Partition for Frequently Moving Objects

#

Not every object belongs in a fixed spatial partition.

Some objects move frequently, such as:

• Vehicles.
• Characters.
• Physics-driven objects.
• Moving environmental effects.

Repeatedly rebuilding larger spatial partitions around these objects could negate some of PTLAS’s benefits.

Microsoft therefore provides a special global partition.

Frequently moving instances can be moved into this partition and managed separately from the spatially organized scene partitions.

Once an object becomes less dynamic, the application can move it back into an appropriate spatial partition.

This introduces an optimization trade-off:

• Larger spatial partitions reduce management complexity but may increase update costs.
• Smaller partitions provide finer updates but introduce additional structural overhead.
• A global partition can isolate frequently changing objects but may increase traversal work.

The optimal partitioning strategy depends on scene structure and object activity.

3.4 Sparse Updates Instead of Full Scene Rebuilds

#

PTLAS supports different operations for managing instance data.

Important operations include:

One important restriction is that UPDATE_INSTANCE does not replace a general transform-update operation.

Sparse transform changes require WRITE_INSTANCE.

This distinction matters when designing the application-side update pipeline.

PTLAS also maintains persistent instance records, allowing updates to target specific records without rewriting the entire scene’s instance list.

3.5 PTLAS Benchmark: Domino Simulation

#

Microsoft also published a separate domino simulation demonstrating PTLAS.

In this sample, a conventional TLAS rebuild required approximately 2.88 ms per frame.

Using PTLAS with localized updates reduced the measured update time to approximately 0.79 ms.

This represents an approximately 72.6% reduction in scene-update time.

The PTLAS sample also reported slightly slower ray-tracing traversal, illustrating an important architectural trade-off.

A partitioned structure may require additional traversal work depending on how instances are distributed.

Therefore, reducing construction time does not automatically guarantee that every subsequent ray query becomes faster.

The overall benefit depends on whether the reduction in update cost outweighs any increase in traversal time.

⚡ 4. GPU-Driven Acceleration Structure Builds

#

Another important addition in Agility SDK 1.722 Preview is the GPU-driven acceleration-structure operation API.

Traditionally, applications perform substantial CPU-side preparation before submitting acceleration-structure build operations.

This involves generating operation descriptions, managing memory allocations, and preparing the information required by the GPU.

For large dynamic scenes, CPU-side preparation can become another bottleneck.

Microsoft introduces a more flexible approach in which GPU-generated argument buffers can drive acceleration-structure operations indirectly.

4.1 ExecuteIndirectRTASOperations

#

The new API introduces two important entry points:

GetRTASOperationPrebuildInfo()

This function queries the required result and scratch-memory sizes for acceleration-structure operations.

Developers can use the returned information to allocate the necessary GPU memory.

ExecuteIndirectRTASOperations()

This function executes batches of acceleration-structure operations using argument data that can reside in GPU memory.

Compute shaders can generate the operation arguments, reducing the need for the CPU to construct every individual operation description.

4.2 Why GPU-Driven Construction Matters

#

Consider a scene with thousands of dynamically changing objects.

A conventional implementation may require the CPU to:

1. Identify modified objects.
2. Prepare acceleration-structure descriptors.
3. Generate build parameters.
4. Submit the corresponding operations.
5. Coordinate synchronization.

The new approach allows some of this preparation to move into GPU compute workloads.

This can reduce CPU-side overhead and allow more efficient GPU scheduling.

For a complex rendering engine, the advantages include:

• GPU-generated build commands.
• Batched acceleration-structure operations.
• More flexible resource allocation.
• Better support for dynamic geometry.
• Reduced CPU preparation overhead.

There is one important synchronization requirement.

Operations submitted in a single ExecuteIndirectRTASOperations() call may execute in any order and must not depend on one another.

When operations have dependencies, applications must separate them into different calls and insert appropriate barriers.

For example:

Build CLAS
    |
    v
Memory / Execution Barrier
    |
    v
Build Cluster BLAS
    |
    v
Memory / Execution Barrier
    |
    v
Build or Update PTLAS
    |
    v
Ray Tracing Dispatch

This makes resource dependencies explicit and ensures that later operations do not consume incomplete acceleration structures.

📊 5. Benchmark Results: Up to 66× Higher Frame Rates

#

The most eye-catching results come from Microsoft’s D3D12 Clustered Geometry sample.

The demonstration ran on an AMD Radeon RX 9070 and compared conventional BLAS rebuilding against Clustered Geometry.

The scene included both static geometry and animated objects.

5.1 Traditional BLAS vs. Clustered Geometry

#

The measured results were:

These results demonstrate how dramatically acceleration-structure management can affect rendering performance in highly dynamic scenes.

The largest improvement comes from the reduction in geometry preparation and building overhead.

5.2 Why Did Frame Rate Increase So Dramatically?

#

The conventional implementation spends approximately 788 ms per frame preparing and building acceleration structures.

That cost alone makes real-time rendering impractical.

Clustered Geometry reduces this work to approximately 3.11 ms.

This represents a reduction of more than 99.6% in the measured acceleration-structure preparation and build time.

The remaining rendering workload also benefits from more efficient scene organization.

Per-frame ray-tracing time drops from 72.6 ms to 9.27 ms.

Together, these improvements allow the sample to increase from 1.2 FPS to 79 FPS.

However, the result must be interpreted carefully.

Microsoft explicitly warns:

Do not assume games will see this magnitude of performance improvement.

The demonstration is a technical test scene designed to expose the costs of conventional BLAS rebuilding.

Commercial games have different rendering bottlenecks, geometry distributions, animation patterns, and shader workloads.

Therefore, the 66× result demonstrates the potential of the API under favorable conditions, not the expected performance improvement for ordinary games.

5.3 The 90% Memory Reduction: What Is Actually Being Measured?

#

The memory results are equally important.

Traditional BLAS rebuilding in the demonstration requires approximately 7,519 MiB of total acceleration-structure memory.

Clustered Geometry reduces this to 774 MiB.

The resulting reduction is approximately 89.7%.

However, this number refers specifically to acceleration-structure memory, including TLAS.

It does not mean that the graphics card’s entire VRAM consumption drops by 90%.

Other resources, including textures, render targets, shaders, buffers, and application data, are not included in this comparison.

This distinction is important when evaluating the technology’s real-world impact.

5.4 The Hidden Trade-Off: Scratch Memory Consumption

#

Although the completed acceleration structures require substantially less memory, the new build process can require considerably more temporary scratch memory.

Microsoft’s measurements include:

This is a significant increase.

The application must therefore manage temporary GPU allocations carefully.

A rendering engine cannot simply look at the reduced final acceleration-structure footprint and assume that all memory requirements have decreased.

Instead, it must consider:

• Final acceleration-structure allocation.
• Temporary build scratch.
• Concurrent build operations.
• Resource lifetime.
• GPU memory fragmentation.
• Synchronization between dependent operations.

In some applications, the additional scratch-memory requirement may become an important constraint.

Efficient memory-pool management will therefore be essential when integrating these features into large rendering engines.

🎮 6. Hardware Compatibility: NVIDIA RTX, AMD Radeon, and Intel Arc

#

One of the most interesting aspects of Microsoft’s announcement is that the new DXR features do not require a new generation of fixed-function ray-tracing hardware.

Instead, they build on existing ray-tracing capabilities and introduce new software interfaces for acceleration-structure management.

However, that does not mean every existing GPU automatically supports the new APIs.

Driver implementation and validation remain necessary.

6.1 NVIDIA GeForce RTX

#

NVIDIA has confirmed support for GeForce RTX GPUs.

This includes the RTX 20, RTX 30, RTX 40, and RTX 50 series.

The implementation benefits from NVIDIA’s existing experience with clustered geometry through its RTX Mega Geometry technology.

However, developers still need compatible drivers and the Agility SDK preview runtime.

6.2 AMD Radeon

#

AMD currently lists support for Radeon RX 9000 series GPUs.

The Radeon RX 9070 was also used in Microsoft’s primary Clustered Geometry demonstration.

This provides an early hardware example of the benefits achievable through the new DXR architecture.

For additional context on AMD’s ray-tracing development, see AMD’s Tetrahedral Cages: Reducing Ray-Tracing Acceleration-Structure Memory, which explores another approach to reducing the memory and update costs of dynamic geometry.

6.3 Intel Arc and Core Ultra Integrated Graphics

#

Intel has confirmed support for:

• Intel Arc B-Series desktop graphics.
• Intel Core Ultra 200V series.
• Intel Core Ultra Series 3.

This is particularly interesting because it extends the new API beyond discrete graphics cards.

Supported integrated graphics platforms can also participate in the new DXR architecture, subject to the capabilities of the specific GPU and driver.

6.4 Qualcomm Snapdragon X2

#

Qualcomm is working with Microsoft to support the new features on Snapdragon X2 platforms.

However, the planned driver-support window is Q1/Q2 2027.

This makes Qualcomm’s implementation a future compatibility target rather than an immediately available option in November 2026.

6.5 Hardware Support Summary

#

Although the new features do not require additional fixed-function hardware capabilities beyond existing ray-tracing support, Microsoft notes that support for some older ray-tracing GPUs remains undecided.

Driver implementation may uncover hardware-specific performance or validation issues that make support impractical on certain generations.

Consequently, developers should check the actual feature-support flags rather than assuming compatibility based only on the GPU’s ability to perform conventional DXR operations.

For broader context on the evolution of GPU ray-tracing hardware, see AMD’s Next-Generation RDNA GPU Architecture: Ray Tracing, AI, and Rendering.

🏗️ 7. NVIDIA RTX Mega Geometry and Industry Adoption

#

Microsoft’s new DirectX implementation has an important relationship with NVIDIA RTX Mega Geometry.

NVIDIA has been developing cluster-based geometry management to improve ray tracing in highly detailed environments.

The objective is to make complex geometry more practical for real-time path tracing.

7.1 RTX Mega Geometry and DirectX Standardization

#

RTX Mega Geometry is NVIDIA’s vendor-specific technology for managing detailed geometry efficiently within its ray-tracing ecosystem.

Clustered Geometry introduces related concepts into the native DirectX Raytracing pipeline.

This is important because a standardized API can provide a common integration path for multiple GPU vendors.

Instead of requiring each graphics vendor to maintain a separate implementation, game developers can target a common set of DirectX interfaces when compatible hardware and drivers are available.

However, standardizing the API does not mean that every vendor implements the technology identically.

Performance will still depend on hardware architecture, memory management, drivers, and game-engine integration.

7.2 Gears of War: E-Day

#

Microsoft identifies Gears of War: E-Day as an early example of a game adopting clustered geometry through NVIDIA’s vendor-specific RTX Mega Geometry API.

This is an important example of how clustered acceleration structures can be used in real game-engine development.

However, it should not be confused with confirmation that the game already uses the new DirectX Clustered Geometry API.

The existing implementation is based on NVIDIA’s own technology.

7.3 Large-Scale Path-Traced Forest Demonstration

#

Microsoft also referenced NVIDIA’s work on large-scale path-traced environments.

The associated forest demonstration contains:

• Approximately 25 square kilometers of terrain.
• More than 60 million plants.
• Approximately one million trees.
• More than 200 plant species.

The scene illustrates the potential of cluster-based geometry management in environments where conventional acceleration-structure rebuilding would be extremely expensive.

It also demonstrates why LOD management, geometry reuse, and efficient scene updates are becoming increasingly important for future game engines.

Importantly, this is a technology demonstration rather than evidence of equivalent performance in a finished commercial game.

🛠️ 8. Developer Requirements: How to Enable DXR Clustered Geometry

#

For graphics developers, Agility SDK 1.722 Preview is currently the entry point for experimenting with Clustered Geometry and PTLAS.

These features are not yet part of a retail Agility SDK release.

8.1 Required Development Environment

#

Developers need several components:

The matching preview headers and runtime are important because the new API includes experimental interfaces that are not available through the ordinary retail SDK.

8.2 Enabling Experimental DXR Features

#

Before creating the D3D12 device, applications must enable the relevant experimental features.

A simplified C++ example based on Microsoft’s documentation is:

UUID features[] = {
    D3D12ExperimentalShaderModels,
    D3D12RaytracingPreview
};

ThrowIfFailed(
    D3D12EnableExperimentalFeatures(
        _countof(features),
        features,
        nullptr,
        nullptr
    )
);

This enables the experimental shader-model and ray-tracing interfaces required by the preview.

8.3 Querying Hardware Support

#

Applications should not assume that a GPU supports Clustered Geometry simply because it supports conventional DXR.

Microsoft provides a feature query through ID3D12Device16.

For example:

D3D12_FEATURE_DATA_D3D12_OPTIONS_RAYTRACING2 options = {};

ThrowIfFailed(
    device16->CheckFeatureSupport1(
        D3D12_FEATURE_D3D12_OPTIONS_RAYTRACING2,
        &options,
        sizeof(options),
        D3D12_PREVIEW_SDK_VERSION
    )
);

if (!options.ClustersAndPTLASSupported)
{
    // Fall back to traditional BLAS/TLAS.
    // Or report that the feature is unavailable.
}

The application can then select the appropriate rendering path.

This is important for games targeting multiple GPU generations.

A conventional BLAS/TLAS implementation should remain available as a fallback when the new features are unavailable.

8.4 Shader Model 6.10 Requirements

#

Clustered Geometry also introduces new shader functionality.

The relevant Shader Model 6.10 features include:

• ClusterID()
• TriangleObjectPositions()
• CandidateTriangleObjectPositions()
• CommittedTriangleObjectPositions()

These intrinsics allow shaders to access information associated with clustered geometry.

For example, ClusterID() allows a hit shader to identify the cluster associated with an intersection.

Together with PrimitiveIndex(), applications can use the resulting information to retrieve material properties, triangle data, or other geometry-related attributes.

This is particularly useful when cluster-based acceleration structures reorganize geometry independently of the application’s original vertex-buffer layout.

8.5 PIX Debugging Support

#

Microsoft has also introduced PIX support for the new acceleration-structure functionality.

Developers can inspect:

• CLAS objects.
• Cluster BLAS structures.
• Partitioned TLAS.
• GPU-driven acceleration-structure operations.
• Build inputs and outputs.
• Resource allocation and memory usage.

This is important because debugging hierarchical ray-tracing structures is significantly more complicated than debugging conventional rasterization pipelines.

A dedicated acceleration-structure viewer helps developers understand how geometry is organized and whether the intended partitioning strategy is working correctly.

🔧 9. Agility SDK 1.620 Retail: Partial Graphics Programs and Other Improvements

#

Alongside the 1.722 Preview, Microsoft also released Agility SDK 1.620 Retail.

Unlike the experimental DXR features, this version introduces several capabilities that are already part of the retail SDK.

One of its most interesting additions is Partial Graphics Programs.

9.1 Partial Graphics Programs

#

Modern games often contain thousands of graphics pipeline state object (PSO) combinations.

Compiling every required pipeline can increase loading times and cause shader-compilation stutter.

Partial Graphics Programs address this by allowing developers to reuse common compiled program components across different pipeline variants.

For example, several graphics pipelines may share:

• Vertex-processing logic.
• Input-layout configuration.
• Primitive topology.
• Pixel-shader functionality.
• Common rendering state.

Instead of independently compiling all variations, developers can create reusable partial programs and link them into complete graphics programs.

This reduces duplicated compilation work.

Potential benefits include:

• Smaller shader delivery packages.
• Reduced pipeline compilation time.
• Less duplicated shader data.
• Reduced shader-compilation stutter.
• More efficient shader-cache management.

9.2 Hardware Support for Partial Graphics Programs

#

According to Microsoft’s feature-support table, the initial driver support covers:

• AMD Radeon RX 7000 series.
• AMD Radeon RX 9000 series.

Intel, NVIDIA, and Qualcomm support is listed as planned for future drivers rather than universally available at the time of the SDK announcement.

This is an important distinction between a feature becoming available in a retail SDK and support becoming available across every GPU vendor.

9.3 Other Agility SDK 1.620 Features

#

Agility SDK 1.620 also introduces several additional DirectX 12 improvements.

These additions demonstrate that Microsoft’s DirectX development is progressing beyond rendering performance alone.

The SDK is also improving GPU diagnostics, synchronization, video processing, shader delivery, and machine-learning integration.

9.4 Shader Model 6.10 Retail Timeline

#

Shader Model 6.10 remains in preview with Agility SDK 1.722.

Microsoft indicated that it expects to move the functionality into the retail Agility SDK 1.621 release in early December 2026.

This provides developers with a relatively short transition period between the experimental preview and the planned retail availability.

However, the exact final delivery schedule remains subject to Microsoft’s release process.

🪟 10. Why Doesn’t Windows Run Task Manager at Realtime Priority?

#

The original DirectX announcement also included an interesting Windows engineering discussion from Microsoft engineer Raymond Chen.

The question is relatively simple:

If Task Manager is essential for recovering an unresponsive system, why doesn’t Windows run it at Realtime priority so that it always remains responsive?

At first glance, increasing Task Manager’s process priority seems like an obvious solution.

However, Windows scheduling does not work that way.

10.1 High Priority Cannot Bypass Shared Resources

#

Increasing a thread’s scheduling priority helps it compete for CPU time.

It does not allow the thread to bypass locks or other shared resources.

For example, suppose an ordinary application holds a mutex and takes an unusually long time to release it.

A high-priority Task Manager thread that needs the same resource must still wait.

The higher scheduling priority cannot force the resource-owning thread to finish immediately.

The same problem can occur with:

• Kernel synchronization objects.
• Shared file-system resources.
• Critical sections.
• Inter-process communication.
• Other shared subsystem resources.

Priority determines which runnable thread receives CPU time.

It does not automatically resolve resource dependencies.

10.2 UI Subsystem Dependencies

#

Task Manager also depends on Windows’ graphical subsystem to display its interface.

If the UI subsystem becomes blocked because another thread holds a required resource, Task Manager may also become unresponsive.

Even if Task Manager receives a higher scheduling priority, its UI operations can still wait for resources controlled by lower-priority threads.

This is why simply assigning REALTIME_PRIORITY_CLASS to Task Manager would not guarantee that it remains usable during severe system lockups.

10.3 Why Windows Already Prioritizes the Foreground Application

#

Windows already provides preferential scheduling treatment to the application currently in focus.

This helps improve responsiveness for the foreground application without introducing the risks associated with unrestricted real-time scheduling.

Microsoft’s engineering explanation highlights a broader operating-system principle:

A recovery tool cannot always recover a system when it depends on the same resources that have become unavailable.

This is also why independent diagnostic mechanisms, watchdogs, kernel debugging, and out-of-band management remain important for critical systems.

Raymond Chen discusses the issue in Why doesn’t Windows run Task Manager at high priority?.

🔮 11. What This Means for Future Game Engines

#

The introduction of Clustered Geometry and PTLAS could influence how game engines organize and maintain ray-tracing scenes.

Historically, many engines have treated ray-tracing acceleration structures as expensive auxiliary data structures that must be carefully limited to maintain acceptable performance.

The new APIs provide a more flexible approach.

11.1 More Detailed Dynamic Geometry

#

With lower acceleration-structure construction costs, developers may have more freedom to use high-detail geometry.

This is particularly useful for:

• Dense forests.
• Animated characters.
• Destructible environments.
• Procedural terrain.
• Large-scale simulations.
• Detailed environmental objects.

Instead of relying heavily on simplified ray-tracing proxies, engines can explore closer integration between rasterization geometry and ray-tracing geometry.

11.2 Better Open-World Streaming

#

Large worlds frequently load and unload objects as players move through different areas.

PTLAS can help update scene structures according to localized changes.

For example, when a player enters a new region:

• Newly loaded objects can be assigned to the relevant partitions.
• Unchanged regions can retain their acceleration structures.
• Removed objects can be deleted from affected partitions.
• Frequently moving objects can be managed separately.

This could make large-scale ray-traced environments more practical.

11.3 Improved Path Tracing

#

Path tracing is particularly sensitive to scene complexity.

Every additional object and geometric detail increases the amount of information that the ray-tracing system must manage.

Reducing acceleration-structure memory and build overhead can make it easier to support:

• High-detail geometry.
• Complex indirect lighting.
• Detailed reflections.
• Dense vegetation.
• More realistic shadowing.
• Dynamic global illumination.

However, path tracing also depends on ray traversal efficiency, shader execution, sampling, denoising, and memory bandwidth.

Clustered Geometry and PTLAS address specific architectural bottlenecks rather than eliminating every performance limitation.

11.4 A Broader Industry Transition

#

The wider industry is moving toward increasingly geometry-intensive rendering techniques.

NVIDIA’s RTX Mega Geometry, Microsoft’s new DXR APIs, and AMD’s research into alternative acceleration-structure representations all point toward a common challenge: efficiently managing increasingly complex and dynamic scenes.

Different architectures may ultimately adopt different approaches, but the underlying objective remains the same: reduce the cost of maintaining the scene data required for real-time ray tracing.

🧭 Conclusion: DirectX Is Making Ray Tracing More Scalable Through Software Architecture

#

Microsoft’s Agility SDK 1.722 Preview represents a major step forward for DirectX Raytracing.

Clustered Geometry introduces reusable object-level acceleration-structure components, while PTLAS enables localized scene-level updates.

The addition of GPU-driven acceleration-structure operations further reduces CPU-side preparation overhead and provides developers with more control over dynamic scene management.

The most important results from Microsoft’s Radeon RX 9070 demonstration include:

The results demonstrate the potential of improving ray-tracing performance through better acceleration-structure management rather than relying exclusively on additional hardware resources.

However, developers must also account for increased temporary scratch-memory requirements, driver compatibility, synchronization, and the trade-off between acceleration-structure construction time and traversal efficiency.

For developers, Agility SDK 1.722 Preview provides an opportunity to experiment with a new generation of GPU-driven ray-tracing infrastructure.

For GPU manufacturers, the standardized DirectX APIs create a common foundation for implementing advanced geometry-management techniques across different architectures.

For game developers, the long-term opportunity is particularly significant: more detailed dynamic geometry, larger environments, and more consistent path-traced rendering without the traditional acceleration-structure overhead.

The most important development is not the 66× benchmark result itself. It is the architectural shift behind it.

DirectX Raytracing is moving toward reusable geometry clusters, partition-aware scene management, and GPU-driven acceleration-structure construction.

If these techniques mature into widely adopted game-engine features, they could fundamentally change how future games handle complex geometry, dynamic environments, and real-time path tracing.