VK_QCOM_tile_shading(3)

# VK_QCOM_tile_shading(3) Manual Page

## Name

VK_QCOM_tile_shading - device extension

Loading… please wait.

## Registered Extension Number

310

## Revision

1

## Ratification Status

Not ratified

## Extension and Version Dependencies

VK_QCOM_tile_properties
or
VK_KHR_get_physical_device_properties2

## SPIR-V Dependencies

- SPV_QCOM_tile_shading

## Contact

- Matthew Netsch [GitHub]mnetsch

## Extension Proposal

VK_QCOM_tile_shading

## Other Extension Metadata

Last Modified Date

  2023-10-12

IP Status

  No known IP claims.

Interactions and External Dependencies

  - This extension interacts with `VK_KHR_dynamic_rendering`

  - This extension interacts with `VK_EXT_transform_feedback`

  - This extension interacts with `VK_EXT_debug_marker`

  - This extension interacts with `VK_EXT_attachment_feedback_loop_layout`

  - This extension interacts with `VK_KHR_dynamic_rendering_local_read`

  - This extension interacts with `VK_QCOM_image_processing`

Contributors

  - Jeff Leger, Qualcomm

  - Matt Netsch, Qualcomm

  - Srihari Babu Alla, Qualcomm

  - Matthew Smith, Qualcomm

  - Kevin Matlage, Qualcomm

  - Alex Bourd, Qualcomm

## Description

This extension exposes tile shading in Vulkan. Many mobile GPUs utilize Tile-Based Deferred Rendering (TBDR) to optimize for power and performance. Conversely, most desktop GPUs use immediate-mode rendering (IM). Adreno ™ GPUs uniquely have the ability to operate in either mode, and when this extension is not enabled, the Adreno driver will select the most optimal mode (TBDR or IM) based on the workload; this feature is called FlexRender ™. When this extension is in use, FlexRender is disabled and the GPU operates exclusively in TBDR wherever possible.

The TBDR mode divides the color and depth/stencil buffer attachments into a regular grid of smaller regions called "tiles". When a render pass instance is submitted for execution on an Adreno GPU, the rendering is split into two phases: a single "visibility pass" followed by multiple "rendering passes" where a separate render pass is issued for each tile in the framebuffer.

The "visibility pass" processes the geometry: identifies which tiles are covered by each primitive, eliminates occluded primitives and unneeded state changes, and performs other tile-specific optimizations. The primitive coverage information collected during the visibility pass is used in the subsequent "rendering pass" for each tile. During the rendering pass for each tile, any primitives that were determined not to cover the current tile are skipped.

This deferred rasterization additionally utilizes a specialized high-bandwidth on-die memory, "tile memory". Tile memory is dramatically more efficient than other device memory. The tile memory temporarily stores the color and other attachments for each tile during rasterization. After each tile is fully rasterized, the resulting tile is typically copied to device memory backing the attachment as specified by the render pass STORE_OP. The per-tile rendering passes occur independently for each tile, with multiple tiles potentially being processed in parallel.

This extension enables applications to leverage the power and performance of tile memory in new ways:

- Adds a mechanism for recording dispatches or draws that are guaranteed to be executed per-tile.

- Such draws bypass the above-mentioned visibility-based skipping and are guaranteed to be executed for every tile in the rendering pass.

- Shaders can declare "tile attachments" variables, providing shader access to color, depth/stencil, and input attachment pixels.

- Fragment and compute shaders can read these render pass attachments at any location within the tile. Compute shaders can also write to color attachments at any location within the tile.

- Shaders can use new built-in variables that provide the location, size, and apron region of the tile.

- A new tile dispatch command automatically scales workgroup sizes and counts to the tile size, given a desired shading rate.

- Framebuffer-local dependencies are expanded to tile-sized regions, rather than a single pixel or sample.

- A tile shading render pass can also enable tiling "aprons". This is a specialized rendering mode where the GPU renders overlapping tiles that enable specific use-cases.

## New Commands

- vkCmdBeginPerTileExecutionQCOM

- vkCmdDispatchTileQCOM

- vkCmdEndPerTileExecutionQCOM

## New Structures

- VkDispatchTileInfoQCOM

- VkPerTileBeginInfoQCOM

- VkPerTileEndInfoQCOM

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceTileShadingFeaturesQCOM

- Extending VkPhysicalDeviceProperties2:

  - VkPhysicalDeviceTileShadingPropertiesQCOM

- Extending VkRenderPassCreateInfo, VkRenderPassCreateInfo2, VkRenderingInfo, VkCommandBufferInheritanceInfo:

  - VkRenderPassTileShadingCreateInfoQCOM

## New Enums

- VkTileShadingRenderPassFlagBitsQCOM

## New Bitmasks

- VkTileShadingRenderPassFlagsQCOM

## New Enum Constants

- `VK_QCOM_TILE_SHADING_EXTENSION_NAME`

- `VK_QCOM_TILE_SHADING_SPEC_VERSION`

- Extending VkAccessFlagBits2:

  - `VK_ACCESS_2_SHADER_TILE_ATTACHMENT_READ_BIT_QCOM`

  - `VK_ACCESS_2_SHADER_TILE_ATTACHMENT_WRITE_BIT_QCOM`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_DISPATCH_TILE_INFO_QCOM`

  - `VK_STRUCTURE_TYPE_PER_TILE_BEGIN_INFO_QCOM`

  - `VK_STRUCTURE_TYPE_PER_TILE_END_INFO_QCOM`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_TILE_SHADING_FEATURES_QCOM`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_TILE_SHADING_PROPERTIES_QCOM`

  - `VK_STRUCTURE_TYPE_RENDER_PASS_TILE_SHADING_CREATE_INFO_QCOM`

- Extending VkSubpassDescriptionFlagBits:

  - `VK_SUBPASS_DESCRIPTION_TILE_SHADING_APRON_BIT_QCOM`

## New or Modified Built-In Variables

- `TileOffsetQCOM`

- `TileDimensionQCOM`

- `TileApronSizeQCOM`

## New SPIR-V Capabilities

- `TileShadingQCOM`

## Issues

- none

## Version History

- Revision 1, 2023-10-12 (Jeff Leger)

## 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-2025 The Khronos Group Inc.

SPDX-License-Identifier: CC-BY-4.0