Render pass area is not inherited to secondary command buffers

[khronosgroup]

Render pass area is not inherited to secondary command buffers

[krOoze]

@mark-lunarg Probably fixed by 3a548ef

BTW might make sense to close issues in the original repo...

[karl-lunarg]

Comment by chrisforbes (MIGRATED)
Tuesday Mar 21, 2017 at 22:53 GMT

---

Difficult to do a good job here -- render area isn't included in VkCommandBufferInheritanceInfo, so we're never going to know it in a secondary command buffer at recording time.

Have to defer either to CmdExecuteCommands, or QueueSubmit, like some other recently adjusted checks.

[karl-lunarg]

Comment by karl-lunarg (MIGRATED)
Wednesday Mar 22, 2017 at 18:00 GMT

---

There's a similar issue in LunarG's LunarXchange (654). Probably exactly the same.

[karl-lunarg]

Comment by phaulos (MIGRATED)
Wednesday Mar 22, 2017 at 18:01 GMT

---

If possible it would be best to do the check in vkCmdExecuteCommands(). At
that point the primary command buffer has seen vkCmdBeginRenderPass() and
knows the render area. That is also off the critical path, unlike
vkQueueSubmit().

On Wed, Mar 22, 2017 at 10:54 AM Karl Schultz [email protected]
wrote:

There is an issue like this logged in LunarG's LunarXchange (#654).

I got "Vulkan internal report (code 1115): vkCmdClearAttachments(): The
area defined by pRects[0] is not contained in the area of the current
render pass instance."

but I'm only recording secondary command buffer, primary command buffer
didn't yet got vkCmdBeginRenderPass! Like in this case:
vkBeginCommandBuffer( vkSecondaryCmdBuffer, &vkCmdBufferBeginInfo);

VkClearAttachment vkClear; vkClear.colorAttachment = 0; vkClear.aspectMask
= VK_IMAGE_ASPECT_COLOR_BIT; vkClear.clearValue.color.float32[0] = 0.0;
vkClear.clearValue.color.float32[1] = 0.0;
vkClear.clearValue.color.float32[2] = 0.0;
vkClear.clearValue.color.float32[3] = 0.0; const VkClearRect vkRect = { { {
0,0 },{ 128,128 }, }, 0,1 }; pvkCmdClearAttachments( vkCmdBuffer, 1,
&vkClear, 1, &vkRect);

And right here VL reports! It's true that at that time primary command
buffer didn't record begin render pass yet, but I think this report should
be moved to execution of secondary command buffer.

It is a new-ish issue and has not been resolved yet.

But in the validation layer code, in PreCallValidateCmdClearAttachments(),
there is:

// TODO: This check should be moved to CmdExecuteCommands or
QueueSubmit to cover secondary CB cases

Chris, do you think that this can/should be resolved by moving the check?

On Tue, Mar 21, 2017 at 4:53 PM, Chris Forbes [email protected]
wrote:

Difficult to do a good job here -- render area isn't included in
VkCommandBufferInheritanceInfo, so we're never going to know it in a
secondary command buffer.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<
KhronosGroup/Vulkan-LoaderAndValidationLayers#1601 (comment)
,
or mute the thread
<
https://github.com/notifications/unsubscribe-auth/APq0i0o_6ZVK6BMrakh0pfsJW2rPU59uks5roFUEgaJpZM4Misus

.

--
Karl Schultz
LunarG
[email protected]

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
KhronosGroup/Vulkan-LoaderAndValidationLayers#1601 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AASCSA_Xo6SjshhnPVWU2ffcVVpgyl6pks5roWBsgaJpZM4Misus
.

[jzulauf-lunarg]

Triage notes: see discussion above. First step would be to verify the bug still exists vs. the CTS test case.

[locke-lunarg]

The error doesn't happen in dEQP-VK.api.command_buffers.render_pass_continue of CTS any longer with Vulkan SDK 1.1.101.0, and VkPositiveLayerTest.ConfirmNoVLErrorWhenVkCmdClearAttachmentsCalledInSecondaryCB passes. So should we close the issue?

[jzulauf-lunarg]

@phaulos -- this appears to be resolved, ok to close?