# Vulkan® 1.4.321 - A Specification (with all registered extensions)

The Khronos® Vulkan Working Group
version 1.4.321, 2025-07-17 19:31:47Z
from git branch: makepkg commit: dad857284bf63d027ac9d6a97e9a1689831bab0d

Loading… please wait.

Search:

## 36. Deferred Host Operations

Certain Vulkan commands are inherently expensive for the host CPU to execute. It is often desirable to offload such work onto background threads, and to parallelize the work across multiple CPUs. The concept of deferred operations allows applications and drivers to coordinate the execution of expensive host commands using an application-managed thread pool.

The `VK_KHR_deferred_host_operations` extension defines the infrastructure and usage patterns for deferrable commands, but does not specify any commands as deferrable. This is left to additional dependent extensions. Commands must not be deferred unless the deferral is specifically allowed by another extension which depends on `VK_KHR_deferred_host_operations`. This specification will refer to such extensions as deferral extensions.

### 36.1. Requesting Deferral

When an application requests an operation deferral, the implementation may defer the operation. When deferral is requested and the implementation defers any operation, the implementation must return `VK_OPERATION_DEFERRED_KHR` as the success code if no errors occurred. When deferral is requested, the implementation should defer the operation when the workload is significant, however if the implementation chooses not to defer any of the requested operations and instead executes all of them immediately, the implementation must return `VK_OPERATION_NOT_DEFERRED_KHR` as the success code if no errors occurred.

A deferred operation is created complete with an initial result value of `VK_SUCCESS`. The deferred operation becomes pending when an operation has been successfully deferred with that deferred operation object.

A deferred operation is considered pending until the deferred operation completes. A pending deferred operation becomes complete when it has been fully executed by one or more threads. Pending deferred operations will never complete until they are joined by an application thread, using vkDeferredOperationJoinKHR. Applications can join multiple threads to the same deferred operation, enabling concurrent execution of subtasks within that operation.

The application can query the status of a VkDeferredOperationKHR using the vkGetDeferredOperationMaxConcurrencyKHR or vkGetDeferredOperationResultKHR commands.

Parameters to the command requesting a deferred operation may be accessed by the implementation at any time until the deferred operation enters the complete state. The application must obey the following rules while a deferred operation is pending:

- Externally synchronized parameters must not be accessed.

- Pointer parameters must not be modified (e.g. reallocated/freed).

- The contents of pointer parameters which may be read by the command must not be modified.

- The contents of pointer parameters which may be written by the command must not be read.

- Vulkan object parameters must not be passed as externally synchronized parameters to any other command.

When the deferred operation is complete, the application should call vkGetDeferredOperationResultKHR to obtain the VkResult indicating success or failure of the operation. The VkResult value returned will be one of the values that the command requesting the deferred operation is able to return. Writes to output parameters of the requesting command will happen-before the deferred operation is complete.

When a deferral is requested for a command, the implementation may perform memory management operations on the allocator supplied to vkCreateDeferredOperationKHR for the deferred operation object, as described in the Memory Allocation chapter. Such allocations must occur on the thread which requests deferral.

If an allocator was supplied for the deferred command at the time of the deferral request, then the implementation may perform memory management operations on this allocator during the execution of vkDeferredOperationJoinKHR. These operations may occur concurrently and may be performed by any joined thread. The application must ensure that the supplied allocator is able to operate correctly under these conditions.

### 36.2. Deferred Host Operations API

The `VkDeferredOperationKHR` handle is defined as:

    // Provided by VK_KHR_deferred_host_operations
    VK_DEFINE_NON_DISPATCHABLE_HANDLE(VkDeferredOperationKHR)

This handle refers to a tracking structure which manages the execution state for a deferred command.

To construct the tracking object for a deferred command, call:

    // Provided by VK_KHR_deferred_host_operations
    VkResult vkCreateDeferredOperationKHR(
        VkDevice                                    device,
        const VkAllocationCallbacks*                pAllocator,
        VkDeferredOperationKHR*                     pDeferredOperation);

- `device` is the device which owns `operation`.

- `pAllocator` controls host memory allocation as described in the Memory Allocation chapter.

- `pDeferredOperation` is a pointer to a handle in which the created VkDeferredOperationKHR is returned.

Valid Usage (Implicit)

- VUID-vkCreateDeferredOperationKHR-device-parameter
  `device` must be a valid VkDevice handle

- VUID-vkCreateDeferredOperationKHR-pAllocator-parameter
  If `pAllocator` is not `NULL`, `pAllocator` must be a valid pointer to a valid VkAllocationCallbacks structure

- VUID-vkCreateDeferredOperationKHR-pDeferredOperation-parameter
  `pDeferredOperation` must be a valid pointer to a VkDeferredOperationKHR handle

- VUID-vkCreateDeferredOperationKHR-device-queuecount
  The device must have been created with at least `1` queue

Return Codes

Success

  - `VK_SUCCESS`

Failure

  - `VK_ERROR_OUT_OF_HOST_MEMORY`

To assign a thread to a deferred operation, call:

    // Provided by VK_KHR_deferred_host_operations
    VkResult vkDeferredOperationJoinKHR(
        VkDevice                                    device,
        VkDeferredOperationKHR                      operation);

- `device` is the device which owns `operation`.

- `operation` is the deferred operation that the calling thread should work on.

The `vkDeferredOperationJoinKHR` command will execute a portion of the deferred operation on the calling thread.

The return value will be one of the following:

- A return value of `VK_SUCCESS` indicates that `operation` is complete. The application should use vkGetDeferredOperationResultKHR to retrieve the result of `operation`.

- A return value of `VK_THREAD_DONE_KHR` indicates that the deferred operation is not complete, but there is no work remaining to assign to threads. Future calls to vkDeferredOperationJoinKHR are not necessary and will simply harm performance. This situation may occur when other threads executing vkDeferredOperationJoinKHR are about to complete `operation`, and the implementation is unable to partition the workload any further.

- A return value of `VK_THREAD_IDLE_KHR` indicates that the deferred operation is not complete, and there is no work for the thread to do at the time of the call. This situation may occur if the operation encounters a temporary reduction in parallelism. By returning `VK_THREAD_IDLE_KHR`, the implementation is signaling that it expects that more opportunities for parallelism will emerge as execution progresses, and that future calls to vkDeferredOperationJoinKHR can be beneficial. In the meantime, the application can perform other work on the calling thread.

Implementations must guarantee forward progress by enforcing the following invariants:

1. If only one thread has invoked vkDeferredOperationJoinKHR on a given operation, that thread must execute the operation to completion and return `VK_SUCCESS`.

2. If multiple threads have concurrently invoked vkDeferredOperationJoinKHR on the same operation, then at least one of them must complete the operation and return `VK_SUCCESS`.

Valid Usage (Implicit)

- VUID-vkDeferredOperationJoinKHR-device-parameter
  `device` must be a valid VkDevice handle

- VUID-vkDeferredOperationJoinKHR-operation-parameter
  `operation` must be a valid VkDeferredOperationKHR handle

- VUID-vkDeferredOperationJoinKHR-operation-parent
  `operation` must have been created, allocated, or retrieved from `device`

Return Codes

Success

  - `VK_SUCCESS`

  - `VK_THREAD_DONE_KHR`

  - `VK_THREAD_IDLE_KHR`

Failure

  - `VK_ERROR_OUT_OF_HOST_MEMORY`

  - `VK_ERROR_OUT_OF_DEVICE_MEMORY`

When a deferred operation is completed, the application can destroy the tracking object by calling:

    // Provided by VK_KHR_deferred_host_operations
    void vkDestroyDeferredOperationKHR(
        VkDevice                                    device,
        VkDeferredOperationKHR                      operation,
        const VkAllocationCallbacks*                pAllocator);

- `device` is the device which owns `operation`.

- `operation` is the completed operation to be destroyed.

- `pAllocator` controls host memory allocation as described in the Memory Allocation chapter.

Valid Usage

- VUID-vkDestroyDeferredOperationKHR-operation-03434
  If `VkAllocationCallbacks` were provided when `operation` was created, a compatible set of callbacks must be provided here

- VUID-vkDestroyDeferredOperationKHR-operation-03435
  If no `VkAllocationCallbacks` were provided when `operation` was created, `pAllocator` must be `NULL`

- VUID-vkDestroyDeferredOperationKHR-operation-03436
  `operation` must be completed

Valid Usage (Implicit)

- VUID-vkDestroyDeferredOperationKHR-device-parameter
  `device` must be a valid VkDevice handle

- VUID-vkDestroyDeferredOperationKHR-operation-parameter
  If `operation` is not VK_NULL_HANDLE, `operation` must be a valid VkDeferredOperationKHR handle

- VUID-vkDestroyDeferredOperationKHR-pAllocator-parameter
  If `pAllocator` is not `NULL`, `pAllocator` must be a valid pointer to a valid VkAllocationCallbacks structure

- VUID-vkDestroyDeferredOperationKHR-operation-parent
  If `operation` is a valid handle, it must have been created, allocated, or retrieved from `device`

Host Synchronization

- Host access to `operation` must be externally synchronized

To query the number of additional threads that can usefully be joined to a deferred operation, call:

    // Provided by VK_KHR_deferred_host_operations
    uint32_t vkGetDeferredOperationMaxConcurrencyKHR(
        VkDevice                                    device,
        VkDeferredOperationKHR                      operation);

- `device` is the device which owns `operation`.

- `operation` is the deferred operation to be queried.

The returned value is the maximum number of threads that can usefully execute a deferred operation concurrently, reported for the state of the deferred operation at the point this command is called. This value is intended to be used to better schedule work onto available threads. Applications can join any number of threads to the deferred operation and expect it to eventually complete, though excessive joins may return `VK_THREAD_DONE_KHR` immediately, performing no useful work.

If `operation` is complete, `vkGetDeferredOperationMaxConcurrencyKHR` returns zero.

If `operation` is currently joined to any threads, the value returned by this command may immediately be out of date.

If `operation` is pending, implementations must not return zero unless at least one thread is currently executing vkDeferredOperationJoinKHR on `operation`. If there are such threads, the implementation should return an estimate of the number of additional threads which it could profitably use.

Implementations may return 232-1 to indicate that the maximum concurrency is unknown and cannot be easily derived. Implementations may return values larger than the maximum concurrency available on the host CPU. In these situations, an application should clamp the return value rather than oversubscribing the machine.

Note | The recommended usage pattern for applications is to query this value once, after deferral, and schedule no more than the specified number of threads to join the operation. Each time a joined thread receives `VK_THREAD_IDLE_KHR`, the application should schedule an additional join at some point in the future, but is not required to do so.

Valid Usage (Implicit)

- VUID-vkGetDeferredOperationMaxConcurrencyKHR-device-parameter
  `device` must be a valid VkDevice handle

- VUID-vkGetDeferredOperationMaxConcurrencyKHR-operation-parameter
  `operation` must be a valid VkDeferredOperationKHR handle

- VUID-vkGetDeferredOperationMaxConcurrencyKHR-operation-parent
  `operation` must have been created, allocated, or retrieved from `device`

The `vkGetDeferredOperationResultKHR` function is defined as:

    // Provided by VK_KHR_deferred_host_operations
    VkResult vkGetDeferredOperationResultKHR(
        VkDevice                                    device,
        VkDeferredOperationKHR                      operation);

- `device` is the device which owns `operation`.

- `operation` is the operation whose deferred result is being queried.

If no command has been deferred on `operation`, `vkGetDeferredOperationResultKHR` returns `VK_SUCCESS`.

If the deferred operation is pending, `vkGetDeferredOperationResultKHR` returns `VK_NOT_READY`.

If the deferred operation is complete, it returns the appropriate return value from the original command. This value must be one of the VkResult values which could have been returned by the original command if the operation had not been deferred.

Valid Usage (Implicit)

- VUID-vkGetDeferredOperationResultKHR-device-parameter
  `device` must be a valid VkDevice handle

- VUID-vkGetDeferredOperationResultKHR-operation-parameter
  `operation` must be a valid VkDeferredOperationKHR handle

- VUID-vkGetDeferredOperationResultKHR-operation-parent
  `operation` must have been created, allocated, or retrieved from `device`

Return Codes

Success

  - `VK_SUCCESS`

  - `VK_NOT_READY`

Failure

  None