VK_QCOM_tile_properties

Adreno GPUs uses a rendering technique called tiled rendering. In this technique, the attachments are divided into a uniform grid of small regions or "tiles". Tile size is shared by and affects all attachments in use. Splitting a render target into multiple chunks or tiles, and rendering each tile individually in order to reconstruct the full render target can be faster and more power-efficient.

A typical tile size will be such that it is contained completely within the attachment but tiles can span outside the attachment’s extent as well. This is because Number of tiles = ceil(attachment_width / tile_width). Such tiles are called partially filled tiles and are less-efficient to render.

In the case of fragment density map, a "local framebuffer region" and all fragments within it will share a value for "fragment area" determined from a corresponding texel in the fragment density map as described in "Fragment Area Conversion" section in the "Fragment Density Map Operations" chapter of the Vulkan specification. Implementations are also free to fetch additional texels within an implementation-defined window as described in "Fragment Area Filter" section of "Fragment Density Map Operations" chapter of the Vulkan specification. Adreno implementations utilize this behavior and will perform both windowing and fragment area assignment within a region defined by a "tile".

The "tiles" exposed in this extension also each define a "framebuffer-local region" as described in the "Framebuffer Region Dependencies" section in the "Synchronization and Cache Control" chapter of the Vulkan specification.

Currently, developers do not know how the implementation is tiling their applications. Several application-controlled factors will implicitly influence the tile size, such as attachment resolution, number of attachments, formats, number of samples, etc.

Adreno implementations will window and apply fragment density map values on a tile-basis. Currently, applications are unable to determine the size and location of tiles, preventing them from knowing how their fragment density map will be applied and the final fragment areas that will result.

With regard to framebuffer-local dependencies, applications are unable to determine the size of the framebuffer-local region and thus must assume it is the size of a single fragment or sample. Due to this, applications must use framebuffer-global dependencies outside of single pixel or sample sized regions, possibly at the cost of efficiency.

Another problem is that currently, applications are unable to align the renderArea with tile boundaries which would achieve the most efficient rendering. The command vkGetRenderAreaGranularity does not allow implementations to fully describe the tiling grid and reported granularity is based solely on a renderpass.

Create a new extension with API entrypoints that allows developer to query the tile properties.

With the knowledge from this extension, applications can create fragment density maps that will apply in a more direct way to the final fragment areas in use, allowing more purposeful creation of maps.

Information from this extension can also be used to determine the size and location of framebuffer-local regions, allowing applications to use local-region dependencies in place of framebuffer-global ones for potential increases in efficiency.

This extension introduces new API calls and a new struct:

When using renderpasses, use the above command after framebuffer creation to query the tile properties from the framebuffer. pPropertiesCount is a pointer to an integer related to the number of pProperties available or queried. pProperties is a pointer to an array of VkTilePropertiesQCOM structure that holds the returned properties. If pProperties is NULL, then the total number of tile properties available is returned in pPropertiesCount. pPropertiesCount must point to a variable set by the user to the number of elements in the pProperties array, and on return the variable is overwritten with the number of properties actually written to pProperties. If pPropertiesCount is less than the number of pProperties available, at most pPropertiesCount structures will be written, and VK_INCOMPLETE will be returned instead of VK_SUCCESS, to indicate that not all the available tile properties were returned.

The number of tile properties available is determined by the number of merged subpasses, and each tile property is associated with a merged subpass. There will be at most as many properties as there are subpasses within the render pass. To obtain the tile properties for a given merged subpass, the pProperties array can be indexed using the postMergeIndex value provided in VkRenderPassSubpassFeedbackInfoEXT.

For dynamic rendering, a new API entrypoint is introduced because it does not have a framebuffer:

When using dynamic rendering, use the above command to query the tile properties. pRenderingInfo is a pointer to the VkRenderingInfo structure specifying details of the render pass instance in dynamic rendering. Tile properties are returned in pProperties which is a pointer to VkTilePropertiesQCOM structure that holds the available properties.

Support for querying tile properties is indicated by feature bit in a structure that extends VkPhysicalDeviceFeatures2.

tileProperties indicates that the implementation supports queries for tile properties.

A new structure is introduced to hold the tile properties.

The reported value for apronSize will be zero and its functionality will be described in a future extension.

tileSize describes the dimensions of a tile, with width and height describing the width and height of a tile in pixels, and depth corresponding to the number of slices the tile spans. All attachments share the same tile width and height. The tile depth value reflects the maximum slice count of all in-use attachments.

origin is top-left corner of the first tile in attachment space.

All tiles will be tightly packed around the first tile, with edges being multiples of tile width and/or height from the origin.

This section describes issues that came up during discussion and their resolution.