1
votes

Event is signaled by another cmd buffer on the same queue with VK_PIPELINE_STAGE_LATE_FRAGMENT_TESTS_BIT stage mask.

Event is not signaled via vkSetEvent on the host.

Event is waited by vkCmdWaitEvents with src stage mask VK_PIPELINE_STAGE_LATE_FRAGMENT_TESTS_BIT and dst stage mask VK_PIPELINE_STAGE_FRAGMENT_SHADER_BIT.

Is this correct stage masks for depth attachment writting and reading as color attachment after?

Validation layers callback message:

Submitting cmdbuffer with call to VkCmdWaitEvents using srcStageMask 0x200 which must be the 
bitwise OR of the stageMask parameters used in calls to vkCmdSetEvent and 
VK_PIPELINE_STAGE_HOST_BIT if used with vkSetEvent but instead is 0x0. The Vulkan spec 
states: srcStageMask must be a valid combination of VkPipelineStageFlagBits values 
(https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/vkspec.html#VUID-
vkCmdWaitEvents-srcStageMask-parameter)

It actually says, that "submitted value is 0x200, but is 0x0". Is this a bug? Where from 0x0 value come from, how it can be 0x200 and 0x0 at the same time?


Some code

Signal after depth buffer renderpass:

cmd.cmd_event_set_signaled(cmd_data.event<EventId::SHADOW_MAP>(),
                           vkw::StageFlag::LATE_FRAGMENT_TESTS);

Wait before primary render pass in another cmd:

vkw::StageMaskChange stage_masks;
stage_masks.src = vkw::StageFlag::LATE_FRAGMENT_TESTS;
stage_masks.dst = vkw::StageFlag::FRAGMENT_SHADER;
auto &shadow_map_event = cmd_data.event<EventId::SHADOW_MAP>();
cmd.cmd_event_wait(shadow_map_event, stage_masks);
cmd.cmd_event_set_unsignaled(shadow_map_event, stage_masks.dst);

Wrapper code. There is some C++ type conversions magic, but values are passing to vkCmd functions correctly.

void cmd_event_set_signaled(Event e, StageMask stage_mask) {
    vkCmdSetEvent(*this, e, stage_mask);
}
void cmd_event_set_unsignaled(Event e, StageMask stage_mask) {
    vkCmdResetEvent(*this, e, stage_mask);
}
void cmd_event_wait(Events es, StageMaskChange smc) {
    vkCmdWaitEvents(*this, es.count32(), &es.begin()->p_vk, smc.src, smc.dst,
                    0, {}, 0, {}, 0, {});
}
2
Please provide code rather than a description of the code. - Nicol Bolas
@NicolBolas I put some code, I hope it’s clear enough. - Jackalope
Well, might be a bug. The layer code sure looks bug prone. 0 seems to be the default if the layers fail to find the vkCmdSet. In what function is this reported from; the vkSubmit or vkCmdWait? Is the vkCmdSet and vkCmdWait in separate command buffers? What's your layer\SDK version. Doublecheck what Vulkan actually sees with VK_LAYER_LUNARG_api_dump. Check if you did not forget to actually submit the command buffers and that they are submitted in the right order. - krOoze
@krOoze Reported from vkQueueSubmit, vkCmdSet and vkCmdWait are from separate cmd buffers, layers from gentoo package media-libs/vulkan-loader-1.1.125. I can't check VK_LAYER_LUNARG_api_dump because VK_LAYER_LUNARG_standard_validation isn't working, in the opposite of VK_LAYER_KHRONOS_validation. Layer is present, but it does not generate any console output. I will try different operation system. - Jackalope

2 Answers

0
votes

In the message, one references the pipeline stage used in vkCmdWaitEvents, the other references the stage passed to vkCmdSetEvent.

0
votes

The problem is not present in the VulkanSDK 1.2.131.2, so vulkan-loader-1.1.125 is a bit outdated.