KhronosGroup / KhronosGroup/Vulkan-Docs

Pipeline states VUs issues?

Open
#543 4 comments 0 reactions 1 assignee View on GitHub

@critsec is already working on this.

Since Aug 21, 2017.

Resolving Inside Khronos
Dominant language
JavaScript
Stars
3.3k
Forks
549
Avg merge
5d 5h
Merged PRs (30d)
2

Description

I feel the pipeline state VUs are a bit off in several places:

  1. VkGraphicsPipelineCreateInfo VU says:
  • If no element of the pDynamicStates member of pDynamicState is VK_DYNAMIC_STATE_VIEWPORT, the pViewports member of pViewportState must be a pointer to an array of pViewportState::viewportCount VkViewport structures

and

  • If the rasterizerDiscardEnable member of pRasterizationState is VK_FALSE, pViewportState must be a pointer to a valid VkPipelineViewportStateCreateInfo structure

So, what if rasterizerDiscardEnable is VK_TRUE and pDynamicStates does not contain VK_DYNAMIC_STATE_VIEWPORT? In such case one VU allows invalid pViewportState, but the other requires valid state inside it (suspicious).


  1. Similarly as # 1 but for scissors.

  1. VkGraphicsPipelineCreateInfo VU says:
  • If the wide lines feature is not enabled, and no element of the pDynamicStates member of pDynamicState is VK_DYNAMIC_STATE_LINE_WIDTH, the lineWidth member of pRasterizationState must be 1.0

If rasterizerDiscardEnable is VK_TRUE does it make sense to require lineWidth to be set? Is the value used for something in such case?


  1. Does it even make sense to allow VK_DYNAMIC_STATE_LINE_WIDTH in pDynamicStates if wide lines feature is not enabled? In such case only one value(1.0) exists. Sounds unnecessary to set it dynamically and sounds unnecessary even for flexibility sake cosidering that feature is enabled/disabled for a whole Device.

  1. VkGraphicsPipelineCreateInfo VU says:
  • If the rasterizerDiscardEnable member of pRasterizationState is VK_FALSE, pMultisampleState must be a pointer to a valid VkPipelineMultisampleStateCreateInfo structure

and

  • If subpass uses color and/or depth/stencil attachments, then the rasterizationSamples member of pMultisampleState must equal the maximum of the sample counts of those subpass attachments

What if rasterizerDiscardEnable is VK_TRUE and subpass uses color attachment? One VU allows invalid pMultisampleState while other requires a valid state inside it (suspicious).

  • If subpass has a depth/stencil attachment and depth test, stencil test, or depth bounds test are enabled, then the rasterizationSamples member of pMultisampleState must be the same as the sample count of the depth/stencil attachment

Could be more explicitly worded (how do I know those tests are enabled? This VU uses "has a depth/stencil attachment"; does UNUSED count?).

Also does rasterizerDiscardEnable=VK_TRUE also imply those tests are disabled or not? Shouldn't there be VU forcing user to explicitly disable those tests if rasterizerDiscardEnable=VK_TRUE to reduce surprises?

If subpass has any color attachments, then the rasterizationSamples member of pMultisampleState must be greater than or equal to the sample count for those subpass attachments

What if rasterizerDiscardEnable is VK_TRUE and subpass has color attachments? One VU allows invalid pMultisampleState while this VU requires valid value inside it (suspicious).

If subpass does not use any color and/or depth/stencil attachments, then the rasterizationSamples member of pMultisampleState must follow the rules for a zero-attachment subpass

What if rasterizerDiscardEnable is VK_TRUE and subpass has no such attachments? One VU allows invalid pMultisampleState while this VU requires valid value inside it (suspicious).


  1. Why does pAttachments[] of VkPipelineColorBlendStateCreateInfo have to be valid for subpass attachments that are VK_ATTACHMENT_UNUSED?

  1. pDynamicState parameter descriptions are twice in the text. Well, the paragraps below the bullet point parameter descriptions seem redundant.

  1. Should pDynamicState have VK_DYNAMIC_STATE_VIEWPORT if rasterizerDiscardEnable is VK_TRUE (i.e. pViewportState is invalid). What is the the viewport count in that case? Does it still have to be set as draw commands say:

If the VkPipeline object currently bound to VK_PIPELINE_BIND_POINT_GRAPHICS requires any dynamic state, that state must have been set on the current command buffer


  1. Similarly as # 8 but for scissors.

a) Should VK_DYNAMIC_STATE_LINE_WIDTH be allowed in pDynamicStates if rasterization is disabled? Does it really have to be set before a draw command?

b) Should VK_DYNAMIC_STATE_DEPTH_BIAS be allowed in pDynamicStates if depthBiasEnable is VK_FALSE? Does it still really have to be set before a draw command?

c) Similarly should other VK_DYNAMIC_STATE_* be allowed if that feature is disabled elsewhere in the VkGraphicsPipelineCreateInfo?

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.