VK_QCOM_elapsed_timer_query(3)

# VK_QCOM_elapsed_timer_query(3) Manual Page

## Name

VK_QCOM_elapsed_timer_query - device extension

## Registered Extension Number

174

## Revision

1

## Ratification Status

Not ratified

## Extension and Version Dependencies

VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1

## Contact

- Matthew Netsch [GitHub]mnetsch

## Extension Proposal

VK_QCOM_elapsed_timer_query

## Other Extension Metadata

Last Modified Date

  2026-05-08

Interactions and External Dependencies

  - Interacts with `apiExt:VK_KHR_calibrated_timestamps`

  - Interacts with `apiExt:VK_KHR_maintenance7`

  - Interacts with `apiExt:VK_EXT_transform_feedback`

Contributors

  - Matthew Netsch, Qualcomm Technologies, Inc

  - Jacob Garcia, Qualcomm Technologies, Inc

  - Patrick Boyle, Qualcomm Technologies, Inc

## Description

This extension adds a new query type to write out the elapsed time between a set of commands, providing similar functionality to `GL_ARB_timer_query`.

There is no existing solution on tilers for measuring commands inside render pass instances, as comparing query timestamps will not give valid results.

This extension, solves the issue by adding a new query type that can be used to measure time between a begin and end query and works inside render pass instances. The implementation is responsible for accumulating the correct elapsed time for the commands across all tiles.

## New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceElapsedTimerQueryFeaturesQCOM

## New Enum Constants

- `VK_QCOM_ELAPSED_TIMER_QUERY_EXTENSION_NAME`

- `VK_QCOM_ELAPSED_TIMER_QUERY_SPEC_VERSION`

- Extending VkQueryType:

  - VK_QUERY_TYPE_TIME_ELAPSED_QCOM

- Extending VkStructureType:

  - VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ELAPSED_TIMER_QUERY_FEATURES_QCOM

## Issues

(1) How to handle overflows?

- Resolved: While VK_QUERY_RESULT_WITH_STATUS_BIT_KHR could have been used to indicate an overflow, it is difficult for an implementation to detect this. The accumulation occurs on the device, and overflow detection requires calculations prior to accumulation which may not be supported by the device. Instead, if the application rejects outliers as part of the profiling process, this issue should be exceedingly rare. If an application is sensitive to this in production, it will need to implement some mechanism to reject bad results. For example, measuring the timestamp before and after the render pass could give a clue about an overflow.

## Version History

- Revision 1, 2026-05-08 (Matthew Netsch)

  - Initial revision

## See Also

No cross-references are available

## Document Notes

For more information, see the Vulkan Specification.

This page is a generated document. Fixes and changes should be made to the generator scripts, not directly.

## Copyright

Copyright 2014-2026 The Khronos Group Inc.

SPDX-License-Identifier: CC-BY-4.0