Vulkan-docs: [SOLVED] pWaitDstStageMask array or why do I keep asking stupid questions

[procedural]

pWaitDstStageMask must be a valid pointer to an array of waitSemaphoreCount

Why pWaitDstStageMask is an array of waitSemaphoreCount?

Can anyone think of a single example where

submitInfo.waitSemaphoreCount = 5;
submitInfo.pWaitSemaphores = someFiveSemaphores;
submitInfo.pWaitDstStageMask = (VkPipelineStageFlags []){VK_PIPELINE_STAGE_VERTEX_SHADER_BIT, VK_PIPELINE_STAGE_GEOMETRY_SHADER_BIT, VK_PIPELINE_STAGE_FRAGMENT_SHADER_BIT, VK_PIPELINE_STAGE_COMPUTE_SHADER_BIT, VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT};

would make any sense to any human being on planet Earth?

[krOoze]

Elaborate.
What is wrong with having multiple semaphores, and waiting on each in different (or same) pipeline stage?

[procedural]

@krOoze there are 0 real world and 0 made up examples of where would you need an array of pipeline stage masks, a stage mask per semaphore?

[krOoze]

@procedural I also do not need multiple Physical Devices, yet it is part of the API, because it is possible. What's your point?

[procedural]

@krOoze I don't want to repeat myself, but pWaitDstStageMask being an array, a pipeline stage mask per semaphore, where one mask of that array can differ from any other mask of that array,

make

absolutely

no

sense

to

any

carbon

based

life

form

[krOoze]

try silicon based life forms

[procedural]

@krOoze we should find one who made pWaitDstStageMask an array inside the Khronos Group :)

[jeffbolznv]

Here's an example that seems reasonable to me: wait on a semaphore from the presentation engine with mask=color write, and wait on a semaphore from a transfer queue with mask=vertex_input.

[procedural]

@jeffbolznv how this will be different from both masks=vertex_input?

[jeffbolznv]

If the transfer queue finishes first, the vertex work can start even if the presentation engine hasn't signaled its semaphore yet.

[procedural]

@jeffbolznv I think I get it, correct me if I'm wrong:

Possibility number 1:

The semaphore with mask=color_write is signaled, but the semaphore with mask=vertex_input is not, nothing will happen and the pipeline will still not proceed to vertex_input and color_write stages, because color_write stage depends on the results of vertex_input stage.

Possibility number 2:

The semaphore with mask=color_write is not signaled, but the semaphore with mask=vertex_input is, pipeline executes all stages up until color_write stage, because presentation engine did not signaled its semaphore yet.

So if both masks were vertex_input, it would mean that pipeline could proceed to color_write stage (edited: actually no, see @krOoze's answer below).

Turns out semaphores in this case are weird cross-queue versions of Vulkan events! I still can't get over the fact that events can't signal cross-queue like on GCN (well, not only me: #771), so Vulkan needs to piggyback on multiple semaphores to do multi stage waits like this.

[krOoze]

So if both masks were vertex_input, it would mean that pipeline could proceed to color_write stage

If both were vertex_input either semaphore could block the pipeline in vertex_input stage.

Turns out semaphores in this case are weird cross-queue versions of Vulkan events!

Or rather Events being weird single-queue host-device semaphores.

[procedural]

If both were vertex_input either semaphore could block the pipeline in vertex_input stage.

Oh, yea, you're right!

Or rather Events being weird single-queue host-device semaphores.

I'm already aware you don't like events, @krOoze :) But if they could cross-queue, there would be absolutely no need for semaphores in Vulkan. And given that, apparently, you can synchronize the host with the device without fences equally well (or not? I'm waiting for a "some hardware implements fences more efficiently than events" answer), there could be no need for fences in Vulkan too.

[krOoze]

But if they could cross-queue

That's one of the ifs preventing me from liking them.
They would not even be part of the portability subset at all. They feel like a fifth wheel. Only current use is "host writes after submit", but even that lacks guarantees (#831).

Would be pretty to have "one sync primitive fits them all". But you can't always get what you want...
Also would be nice to have a The Design and Evolution of Vulkan book to understand the kind of questions you like to ask. But who has time to write that...

[procedural]

@jeffbolznv, @krOoze big thanks to you, guys!