CODEWITHSUNDEEP
vulkan
InsertMemeNameHere
InsertMemeNameHere

Reputation: 2433

Vulkan: vkWaitForFences syncrhonizing access to VkDevice

Is it necessary to synchronize access to the device handle when calling vkWaitForFences? The specification does not mention any need for this, but doesn't mention it being free-threaded, either. In some places, namely most of the vkCreateXXX, mention this as a requirement. Given the explicit nature of the spec, I'd expect more precise wording (rather than none at all in this case).

I suspect the answer is "no", but I am unable to trust my intuition with this API or implementations behind it.

It would be strange (useless, actually), if it is necessary to guard a call to this function.

Upvotes: 1

Views: 498

Answers (1)

Jesse Hall
Jesse Hall

Reputation: 6787

The spec uses the terms "external synchronization" and "host synchronization" to talk about objects/parameters where the application must ensure non-concurrent use. The rules are described in Section 2.5 "Threading Behavior", and in the "Host Synchronization" block after most commands. Anything not listed can be used concurrently.

I'm not sure why you think that the device parameter is supposed to be externally synchronized for vkCreate*, I couldn't find something in the spec to support that. The device object is almost never externally synchronized.

None of the parameters to vkWaitForFences is listed as Host Synchronized. But the fence(s) passed to vkQueueSubmit and vkResetFences are host synchronized, so you can't pass a fence to one of those calls while there is another thread waiting for the fence. But you could have two threads waiting on the same fence, or one thread calling vkGetFenceStatus while another thread is waiting on it.

Upvotes: 4

Related Questions