Inconsistent behavior when signaling exported timeline semaphore (VUID-VkSemaphoreSignalInfo-value-03259)

[jerry411]

Environment:

• OS: Windows 11
• GPU and driver version: Nvidia RTX 3070Ti; 551.86
• SDK or header version if building from repo: SDK version 1.3.283.0
• Options enabled (synchronization, best practices, etc.): Validation configuration with Standard preset

Describe the Issue

I have a really weird issue with VK_KHR_external_semaphore. All I want to do is a simple test. As a setup, I:

• create an exportable timeline semaphore on one VkInstance
• export the semaphore's handle (vkGetSemaphoreWin32HandleKHR with VK_EXTERNAL_FENCE_HANDLE_TYPE_OPAQUE_WIN32_BIT), - and import it on another instance.

Then I want to:

• query both semaphore's counter values (vkGetSemaphoreCounterValue)
• signal the first semaphore (with greater value),
• query both their counter values again and see whether those values match (as I expect they should since the second semaphore references the payload of the first one).

However, when signaling a semaphore, I get a validation layer error: "VUID-VkSemaphoreSignalInfo-value-03259" - "value must be less than the value of any pending semaphore signal operations". But there are not any pending signal operations! All operations I do in this simple test are mentioned above.

But wait, it gets weirder! When I do NOT call the first "vkGetSemaphoreCounterValue" (the one before signaling), no validation layer error appears! And if I DO call vkGetSemaphoreCounterValue but don't get a handle to the first semaphore, it is fine as well. Only a combination of getting handle and getting counter value triggers this validation layer error. As a cherry on top, if I query for counter value BEFORE creating a handle, it is all fine. At this point, I think this is a bug in the validation layers.

To summarize:

• create semaphore -> get a handle -> get counter value -> signal - throws aforementioned validation layer error
• create semaphore -> get counter value -> get handle -> signal - is fine
• create semaphore -> get handle -> signal - is fine
• create semaphore -> get counter value -> signal - is fine

Expected behavior

I think I should not get this validation layer error at all. And even if it is correct (I would love to know the reason because I really do not understand it at this point), it should be consistent. Changing the order of "get a handle" and "get counter value" operations should not affect a validation layer error being thrown when signaling a semaphore.

Valid Usage ID

VUID-VkSemaphoreSignalInfo-value-03259(ERROR / SPEC): msgNum: 1227785937 - Validation Error: [ VUID-VkSemaphoreSignalInfo-value-03259 ] Object 0: handle = 0xead9370000000008, type = VK_OBJECT_TYPE_SEMAPHORE; | MessageID = 0x492e86d1 | vkSignalSemaphore(): pSignalInfo->value (124) must be less than value of any pending signal operation (123) for semaphore VkSemaphore 0xead9370000000008[]. The Vulkan spec states: value must be less than the value of any pending semaphore signal operations (https://vulkan.lunarg.com/doc/view/1.3.283.0/windows/1.3-extensions/vkspec.html#VUID-VkSemaphoreSignalInfo-value-03259)

[artem-lunarg]

@jerry411 thanks for the report, we need to check this, definitely can be a bug. One comment what you can expect when an external resource is used (semaphore, fence). Validation of the external objects is more limited comparing to non-external objects. It's not possible to precisely track state of the external object because it can be changed by the external actor at any time and Vulkan API does not provide a way to communicate those changes (for example, external app signals the semaphore - VVL won't register a signal).

The limited state tracking should not cause false-positive validation errors though. It's a bug if this happens. The expected behavior that validation is skipped if there is not enough information to do it.

[jerry411]

@artem-lunarg Great. Thanks. And yes - I am aware that validation layers are quite limited at catching problems with external objects, simply due to their nature.

[artem-lunarg]

@jerry411 this shoud be fixed in the latest code