{"id":14450,"date":"2026-10-28T09:52:19","date_gmt":"2026-10-28T16:52:19","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/directx\/?p=14450"},"modified":"2026-10-28T09:52:19","modified_gmt":"2026-10-28T16:52:19","slug":"async-commands-fallback-layer","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/directx\/async-commands-fallback-layer\/","title":{"rendered":"Async Commands Fallback Layer"},"content":{"rendered":"

We’re pleased to announce that Agility SDK 1.620.1 includes a fallback layer for Batched Async Commands, letting developers use the new commands on hardware that doesn’t support them natively. You can find the NuGet package here<\/a>.<\/p>\n

Background<\/h3>\n

Batched Async Commands were introduced in the Agility SDK 1.720 Preview<\/a> as a new set of copy, fill, clear, and resolve commands. The legacy versions of these operations are implicitly serialized, since the original resource barrier model has no way to say that two copies don’t depend on each other. The batched versions drop that implicit serialization and take many operations in a single call, so the driver and GPU are free to overlap independent work and you only add enhanced barriers where there’s an actual dependency. They also fill in some long-standing gaps in the API. ClearTextureSubresources<\/code> can clear a texture without an RTV, UAV, or descriptor heap (including block-compressed formats), FillBuffers<\/code> can write formatted or raw patterns into buffers without any UAV clear setup, and ClearBoundRenderTargetViews<\/code> and ClearBoundDepthStencilView<\/code> clear whatever is currently bound, even in the middle of a render pass.<\/p>\n

The downside is that the feature is only supported on newer GPUs. At the 1.720 Preview launch, that meant AMD Radeon RX 7000 and 9000 series, Intel Arc B-Series, and NVIDIA RTX GPUs. There’s a lot of hardware still in use that isn’t on that list, and if you want to ship on all of it, you’d have to keep your existing copy and clear code around alongside the new path.\nThat’s where the fallback layer comes in.<\/p>\n

Batched Async Commands Fallback<\/h3>\n

The goal of the fallback layer is to let you move to the new commands now, without having to maintain two separate systems while the hardware ecosystem catches up. When the fallback is enabled on a device that doesn’t support Batched Async Commands, the runtime implements the commands itself using operations that every driver already supports. On devices with native support, the calls go straight to the driver as usual, so the same code takes the fast path wherever it’s available.<\/p>\n

The fallback is opt-in, for a couple of reasons. First, it isn’t a perfect match for native behavior, and there are some cases it can’t handle at all (covered below). Second, it has a cost even if you never call one of the new commands. To implement fallback support for commands like FillBuffers<\/code> and the bound clears, the runtime needs to know the barrier state of the resources involved and has to put back your pipeline state, root signature, bindings, and render targets when it’s done. That means tracking all of that on every direct, compute, and bundle command list while the fallback is enabled.<\/p>\n

The Performance section below covers what that costs. None of it is huge on its own, but it adds up over a frame, and apps that don’t use Batched Async Commands shouldn’t have to pay for it.<\/p>\n

The fallback itself requires Enhanced Barriers support, so on a device without Enhanced Barriers or native support, the batched commands aren’t available.<\/p>\n

Example Usage<\/h4>\n
\/\/ Opt in to the fallback on a device factory, before creating the device\r\nComPtr<ID3D12DeviceFactory> pFactory;\r\nD3D12GetInterface(CLSID_D3D12DeviceFactory, IID_PPV_ARGS(&pFactory));\r\n\r\nComPtr<ID3D12AsyncCommandsFallback> pFallback;\r\nif (SUCCEEDED(pFactory->GetConfigurationInterface(CLSID_D3D12AsyncCommandsFallback, IID_PPV_ARGS(&pFallback))))\r\n{\r\n    pFallback->SetFallbackLayerEnabled(TRUE);\r\n}\r\n\r\nComPtr<ID3D12Device> pDevice;\r\npFactory->CreateDevice(pAdapter, D3D_FEATURE_LEVEL_12_0, IID_PPV_ARGS(&pDevice));\r\n\r\n\/\/ Check whether you got native support, the fallback, or neither\r\nD3D12_FEATURE_DATA_ASYNC_COMMANDS asyncCommands = {};\r\npDevice->CheckFeatureSupport(D3D12_FEATURE_ASYNC_COMMANDS, &asyncCommands, sizeof(asyncCommands));\r\n\r\nif (asyncCommands.Impl == D3D12_ASYNC_COMMANDS_IMPL_NOT_SUPPORTED)\r\n{\r\n    \/\/ Batched Async Commands unavailable, keep using the legacy path\r\n    return;\r\n}\r\n<\/code><\/pre>\n
The setting applies to devices that factory creates, and you can read it back as D3D12_DEVICE_FLAG_ASYNC_COMMANDS_FALLBACK_ENABLED<\/code> in ID3D12DeviceConfiguration::GetDesc<\/code>. If you create your device with D3D12CreateDevice<\/code> instead, you can get the same interface from D3D12GetInterface(CLSID_D3D12AsyncCommandsFallback, ...)<\/code>. That sets the option globally, for devices created with D3D12CreateDevice<\/code>. Like other global settings, set it before creating any devices. It doesn’t carry over to device factories unless you call InitializeFromGlobalState<\/code> on them.<\/p>\n
If you tried Batched Async Commands in the preview SDK, note that D3D12_FEATURE_DATA_ASYNC_COMMANDS<\/code> has changed. The BOOL Supported<\/code> field is now D3D12_ASYNC_COMMANDS_IMPL Impl<\/code>, which tells you whether you got the native implementation, the fallback, or neither. Since D3D12_ASYNC_COMMANDS_IMPL_NATIVE<\/code> is 2, code that compares the old field against TRUE<\/code> will treat native support as unsupported, so check against D3D12_ASYNC_COMMANDS_IMPL_NOT_SUPPORTED<\/code> instead.<\/p>\n
Where the Fallback Differs from Native<\/h3>\n
Most of the batched commands map pretty directly onto existing operations. Batched copies, tile copies, and resolves run as a loop over their legacy equivalents, so you get the same results as native, just without the overlap. Fills and clears are where the fallback has to do real work, and where there are a few differences to be aware of.<\/p>\n
When the fallback can’t handle a call, it fails rather than silently skipping the work. The command list is removed and Close<\/code> returns an error, usually E_FAIL<\/code>. With the debug layer enabled, the rejected call also produces a debug-layer error that names the API the fallback couldn’t record, so if Close<\/code> starts failing after you’ve switched to one of the new commands, check the debug output first. The fallback also validates its inputs more strictly than the runtime does when passing calls to a native driver, so a call that works natively can still be rejected on a fallback device.<\/p>\n
ClearTextureSubresources<\/h4>\n
Multisampled textures can only be cleared on direct command lists; on compute command lists the call fails, though single-sample clears work fine there. The fallback is fastest when it knows a texture’s current layout, which it learns from the barriers you record earlier in the same command list. A barrier that only covers some of a texture’s subresources makes the layout unknown until the next whole-resource barrier, and until then clears take a slower copy-based path. There are also a few combinations the fallback can’t handle, and these fail outright:<\/p>\n