Registered Extension Number

283

Revision

1

Extension and Version Dependencies

Other Extension Metadata

Last Modified Date

2020-02-05

Interactions and External Dependencies
  • This extension requires VK_KHR_swapchain

  • This extension interacts with VK_EXT_fragment_density_map

Contributors
  • Jeff Leger, Qualcomm Technologies, Inc.

  • Brandon Light, Qualcomm Technologies, Inc.

Description

This extension provides a mechanism for applications to enable driver support for render pass transform.

Mobile devices can be rotated and mobile applications need to render properly when a device is held in a landscape or portrait orientation. When the current orientation differs from the device’s native orientation, a rotation is required so that the "up" direction of the rendered scene matches the current orientation.

If the Display Processing Unit (DPU) doesnt natively support rotation, the Vulkan presentation engine can handle this rotation in a separate composition pass. Alternatively, the application can render frames "pre-rotated" to avoid this extra pass. The latter is preferred to reduce power consumption and achieve the best performance because it avoids tasking the GPU with extra work to perform the copy/rotate operation.

Unlike OpenGL ES, the burden of pre-rotation in Vulkan falls on the application. To implement pre-rotation, applications render into swapchain images matching the device native aspect ratio of the display and "pre-rotate" the rendering content to match the device’s current orientation. The burden is more than adjusting the Model View Projection (MVP) matrix in the vertex shader to account for rotation and aspect ratio. The coordinate systems of scissors, viewports, derivatives and several shader built-ins may need to be adapted to produce the correct result.

It is difficult for some game engines to manage this burden; many chose to simply accept the performance/power overhead of performing rotation in the presentation engine.

This extension allows applications to achieve the performance benefits of pre-rotated rendering by moving much of the above-mentioned burden to the graphics driver. The following is unchanged with this extension:

The following is changed with this extension:

  • At vkCmdBeginRenderpass, the application provides extension struct VkRenderPassTransformBeginInfoQCOM specifying the render pass transform parameters.

  • At vkBeginCommandBuffer for secondary command buffers, the application provides extension struct VkCommandBufferInheritanceRenderPassTransformInfoQCOM specifying the render pass transform parameters.

  • The renderArea, viewPorts and scissors are all provided in the current (non-rotated) coordinate system. The implementation will transform those into the native (rotated) coordinate system.

  • The implementation is responsible for transforming shader built-ins (FragCoord, PointCoord, SamplePosition, interpolateAt(), dFdx, dFdy, fWidth) into the rotated coordinate system.

  • The implementation is responsible for transforming position to the rotated coordinate system.

New Object Types

None.

New Enum Constants

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_COMMAND_BUFFER_INHERITANCE_RENDER_PASS_TRANSFORM_INFO_QCOM

    • VK_STRUCTURE_TYPE_RENDER_PASS_TRANSFORM_BEGIN_INFO_QCOM

  • Extending VkRenderPassCreateFlagBits:

    • VK_RENDER_PASS_CREATE_TRANSFORM_BIT_QCOM

New Enums

None.

New Functions

None.

Issues

1) Should the extension support only rotations (e.g. 90, 180, 270-degrees), or also mirror transforms (e.g. vertical flips)? Mobile use-cases only require rotation. Other display systems such as projectors might require a flipped transform.

RESOLVED: In this version of the extension, the functionality is restricted to 90, 180, and 270-degree rotations to address mobile use-cases.

2) How does this extension interact with VK_EXT_fragment_density_map?

RESOLVED Some implementations may not be able to support a render pass that enables both renderpass transform and fragment density maps. For simplicity, this extension disallows enabling both features within a single render pass.

3) What should this extension be named?

We considered names such as "rotated_rendering", "pre_rotation" and others. Since the functionality is limited to a render pass, it seemed the name should include "render_pass". While the current extension is limited to rotations, it could be extended to other transforms (like mirror) in the future.

RESOLVED The name "render_pass_transform" seems like the most accurate description of the introduced functionality.

Version History

  • Revision 1, 2020-02-05 (Jeff Leger)

See Also

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 (c) 2014-2020 Khronos Group. This work is licensed under a Creative Commons Attribution 4.0 International License.