Contact
-
David Zhao Akeley akeley98
Other Extension Metadata
- Last Modified Date
-
2021-02-04
- Contributors
-
-
David Zhao Akeley, NVIDIA
-
Jeff Bolz, NVIDIA
-
Piers Daniell, NVIDIA
-
Christoph Kubisch, NVIDIA
-
Description
This extension adds the ability for a secondary command buffer to inherit the dynamic viewport and scissor state from a primary command buffer, or a previous secondary command buffer executed within the same vkCmdExecuteCommands call. It addresses a frequent scenario in applications that deal with window resizing and want to improve utilization of re-usable secondary command buffers. The functionality is provided through VkCommandBufferInheritanceViewportScissorInfoNV. Viewport inheritance is effectively limited to the 2D rectangle; secondary command buffers must re-specify the inherited depth range values.
New Enum Constants
-
VK_NV_INHERITED_VIEWPORT_SCISSOR_EXTENSION_NAME -
VK_NV_INHERITED_VIEWPORT_SCISSOR_SPEC_VERSION -
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_COMMAND_BUFFER_INHERITANCE_VIEWPORT_SCISSOR_INFO_NV -
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_INHERITED_VIEWPORT_SCISSOR_FEATURES_NV
-
Issues
(1) Why are viewport depth values configured in the
VkCommandBufferInheritanceViewportScissorInfoNV struct, rather than by
a vkCmd… function?
DISCUSSION:
We considered both adding a new vkCmdSetViewportDepthNV function, and
modifying vkCmdSetViewport to ignore the x, y,
width, and height values when called with a secondary command
buffer that activates this extension.
The primary design considerations for this extension are debuggability and
easy integration into existing applications.
The main issue with adding a new vkCmdSetViewportDepthNV function is
reducing ease-of-integration.
A new function pointer will have to be loaded, but more importantly, a new
function would require changes to be supported in graphics debuggers; this
would delay widespread adoption of the extension.
The proposal to modify vkCmdSetViewport would avoid these issues. However, we expect that the intent of applications using this extension is to have the viewport values used for drawing exactly match the inherited values; thus, it would be better for debuggability if no function for modifying the viewport depth alone is provided. By specifying viewport depth values when starting secondary command buffer recording, and requiring the specified depth values to match the inherited depth values, we allow for validation layers that flag depth changes as errors.
This design also better matches the hardware model. In fact, there is no need to re-execute a depth-setting command. The graphics device retains the viewport depth state; it is the CPU-side state of VkCommandBuffer that must be re-initialized.
(2) Why are viewport depth values specified as a partial VkViewport struct, rather than a leaner depth-only struct?
DISCUSSION:
We considered adding a new VkViewportDepthNV struct containing only
minDepth and maxDepth.
However, as application developers would need to maintain both a
VK_NV_inherited_viewport_scissor code path and a fallback code path (at
least in the short term), we ultimately chose to continue using the existing
VkViewport structure.
Doing so would allow application developers to reuse the same
VkViewport array for both code paths, rather than constructing
separate VkViewportDepthNV and VkViewport arrays for each code
path.
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.