Trying to interpret these myself, but I'm not as proficient as perhaps you are, so please help me in clarifying the validation errors. The following log snippet is from an API dump.
#Need help with more Synchronization errors...
ripe tartan
pseudo chasm
@nocturne willow You once said that a validation error which can't be understood is a bug 😛
ripe tartan
i'm most concerned about the semaphore one because i changed nothing about my code but after a driver update it started happening
nocturne willow
<@174739405825769472> You once said that a validation error which can't be under...
Yes, still stand by that!
nocturne willow
i'm most concerned about the semaphore one because i changed nothing about my co...
vkQueueSubmit2(): pSubmits[0].pWaitSemaphoreInfos[0].semaphore queue (VkQueue 0x1d9532dba80[]) is waiting on semaphore (VkSemaphore 0x301e6c0000000022[]) that has no way to be signaled.
Did you mean this part?
ripe tartan
vkQueueSubmit2(): pSubmits[0].pWaitSemaphoreInfos[0].semaphore queue (VkQueue 0x...
yes, that is what i'm referring to
nocturne willow
this one might need Artem's help, the sync code (and Vulkan sync in general) is too much for me to dig into right now
maiden cave
I can see two type of messages, regular validation and syncval (SYNC-HAZARD). We can probably ignore syncval errors for now because syncval should be run when core is fixed (it's likely that core error produces false-positive in syncval)
pseudo chasm
Ah yeah, so the first error is saying that you did a vkQueueSubmit with semaphore X as a 'wait' semaphore, but semaphore X wasn't used previously as a 'signal' semaphore anywhere.
maiden cave
Right, it should be a missing signal situation, signal should be submitted (in the previous submits or in current one in the previous batches) before current wait.
pseudo chasm
VkQueue's are way more serialized than people imagine, and so the vkQueueSubmit blocks the queue indefinitely (aka deadlock)
What is annoying is translating the 'serialness' of VkQueue's into a legible error message without being a rehash of the spec text.
ripe tartan
i'm not even sure what the error is referring to because the semaphore pointer given wasn't part of the submission structure
maiden cave
The error message mentions semaphore 0x301e6c0000000022, but I can't see it in the API dump, it could be the problem happened in previous frames or on a different queue.
ripe tartan
i'll check my asset queue api dump
maiden cave
Oh
ripe tartan
there is no semaphore being used on the asset upload, only a fence
maiden cave
I can recognize something, the handles in error messages have this form - 0x301e6c0000000022 (many zeros), but in API dump we have more complex numbers - 000001D95E415710.
It probably means that Validation Layer runs with Handle Wrapping option enabled, and API dump do not
you might try to disable Handle Wrapping in vkconfig to see the same handles
maiden cave
which version of sdk do you have?
ripe tartan
ah i think something stupid happened on the install
ripe tartan
you might try to disable Handle Wrapping in vkconfig to see the same handles
i don't see this in the configurator
maiden cave
ripe tartan
sufficiently blind then lol
pseudo chasm
I can recognize something, the handles in error messages have this form - 0x301e...
Yes, apidump does not wrap handles.
(just wanted to confirm)
ripe tartan
i forgot to clean up the log a bit 1 sec
it technically logs twice because API dump is printed on top of typical validation
also for some reason this time the program didn't have the write after write error (I changed nothing except reinstalling vulkan sdk)
maiden cave
In general recommendation is to disable synchronization validation until core validation error messages (such as VUID-vkQueueSubmit2-semaphore-03873) are fixed. Syncval relies on error-free core validation.
But regarding error message it's basically what we wrote before in the sense what does it mean. What happens actually in the app it's a different question. One thing to check, that even after handles are in sync (I can see that semaphore handle has expected format), the API dump uses different VkQueue handle than in the error message. So it looks like the error happened on a different queue and this is not captured by api dump.
ripe tartan
ngl i think it's some strange driver issue
because nothing else would explain why it would show up when it wasn't there before recently (no engine or api version changes)
pseudo chasm
Can you try disabling all implicit layers? maybe there is a new implicit layer doing shenanigans behind your back?
ripe tartan
errors remained the same
