David Zhao Akeley akeley98
- Last Modified Date
David Zhao Akeley, NVIDIA
Jeff Bolz, NVIDIA
Piers Daniell, NVIDIA
Christoph Kubisch, NVIDIA
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.
(1) Why are viewport depth values configured in the
VkCommandBufferInheritanceViewportScissorInfoNV struct, rather than by
We considered both adding a new
vkCmdSetViewportDepthNV function, and
modifying vkCmdSetViewport to ignore the
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
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’s 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?
We considered adding a new
VkViewportDepthNV struct containing only
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
Doing so would allow application developers to reuse the same
VkViewport array for both code paths, rather than constructing
VkViewportDepthNV and VkViewport arrays for each code
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.