vkCmdWriteTimestamp(3)

# vkCmdWriteTimestamp(3) Manual Page

## Name

vkCmdWriteTimestamp - Write a device timestamp into a query object

Loading... please wait.

## C Specification

To request a timestamp, call:

    void vkCmdWriteTimestamp(
        VkCommandBuffer                             commandBuffer,
        VkPipelineStageFlagBits                     pipelineStage,
        VkQueryPool                                 queryPool,
        uint32_t                                    query);

## Parameters

- `commandBuffer` is the command buffer into which the command will be recorded.

- `pipelineStage` is one of the VkPipelineStageFlagBits, specifying a stage of the pipeline.

- `queryPool` is the query pool that will manage the timestamp.

- `query` is the query within the query pool that will contain the timestamp.

## Description

`vkCmdWriteTimestamp` latches the value of the timer when all previous commands have completed executing as far as the specified pipeline stage, and writes the timestamp value to memory. When the timestamp value is written, the availability status of the query is set to available.

| Note If an implementation is unable to detect completion and latch the timer at any specific stage of the pipeline, it may instead do so at any logically later stage.

vkCmdCopyQueryPoolResults can then be called to copy the timestamp value from the query pool into buffer memory, with ordering and synchronization behavior equivalent to how other queries operate. Timestamp values can also be retrieved from the query pool using vkGetQueryPoolResults. As with other queries, the query must be reset using vkCmdResetQueryPool or vkResetQueryPool before requesting the timestamp value be written to it.

While `vkCmdWriteTimestamp` can be called inside or outside of a render pass instance, vkCmdCopyQueryPoolResults must only be called outside of a render pass instance.

Timestamps may only be meaningfully compared if they are written by commands submitted to the same queue.

| Note An example of such a comparison is determining the execution time of a sequence of commands.

If `vkCmdWriteTimestamp` is called while executing a render pass instance that has multiview enabled, the timestamp uses N consecutive query indices in the query pool (starting at `query`) where N is the number of bits set in the view mask of the subpass the command is executed in. The resulting query values are determined by an implementation-dependent choice of one of the following behaviors:

- The first query is a timestamp value and (if more than one bit is set in the view mask) zero is written to the remaining queries. If two timestamps are written in the same subpass, the sum of the execution time of all views between those commands is the difference between the first query written by each command.

- All N queries are timestamp values. If two timestamps are written in the same subpass, the sum of the execution time of all views between those commands is the sum of the difference between corresponding queries written by each command. The difference between corresponding queries may be the execution time of a single view.

In either case, the application can sum the differences between all N queries to determine the total execution time.

Valid Usage

- `queryPool` must have been created with a `queryType` of `VK_QUERY_TYPE_TIMESTAMP`

- The query identified by `queryPool` and `query` must be unavailable

- The command pool’s queue family must support a non-zero `timestampValidBits`

- All queries used by the command must be unavailable

- If `vkCmdWriteTimestamp` is called within a render pass instance, the sum of `query` and the number of bits set in the current subpass’s view mask must be less than or equal to the number of queries in `queryPool`

Valid Usage (Implicit)

- `commandBuffer` must be a valid VkCommandBuffer handle

- `pipelineStage` must be a valid VkPipelineStageFlagBits value

- `queryPool` must be a valid VkQueryPool handle

- `commandBuffer` must be in the recording state

- The `VkCommandPool` that `commandBuffer` was allocated from must support transfer, graphics, or compute operations

- Both of `commandBuffer`, and `queryPool` must have been created, allocated, or retrieved from the same VkDevice

Host Synchronization

- Host access to `commandBuffer` must be externally synchronized

- Host access to the `VkCommandPool` that `commandBuffer` was allocated from must be externally synchronized

Command Properties

Command Buffer Levels | Render Pass Scope | Supported Queue Types | Pipeline Type
--- | --- | --- | ---
Primary Secondary | Both | Transfer Graphics Compute | Transfer

## See Also

VkCommandBuffer, VkPipelineStageFlagBits, VkQueryPool

## Document Notes

For more information, see the Vulkan Specification

This page is extracted from the Vulkan Specification. Fixes and changes should be made to the Specification, not directly.

## Copyright

Copyright (c) 2014-2020 Khronos Group. This work is licensed under a Creative Commons Attribution 4.0 International License.