Hi, I’m writing a wrapper of Vulkan which do some validation checks on runtime, and I got a little confused of the “Host Synchronization” parts in spec, for example when I capsule the function vkDestroyInstance, the doc says:
Host access to instancemust be externally synchronized
Host access to all VkPhysicalDevice objects enumerated from instancemust be externally synchronized
For the first rule, does that mean this function will “mutate” the state of instance, so when this function get called, no other thread should do anything with instance?
If so, if a function’s doc didn’t talk about the synchronized rules, then this function can be called in multiple thread, as long as no synchronized function is calling?
If so, then the synchronized part illustrates whether a parameter is mutated or not, but where’s the second rule comes? There’s no parameter of VkPhysicalDevice in vkDestroyInstance.
P.S. about question 3, or does that mean “when calling vkDestroyInstance”, all VkPhysicalDevice created by instance should also not be used in other threads?
P.P.S. Are there any layers which can detect synchronized issue? It seems that “VK_LAYER_KHRONOS_validation” won’t.
Vulkan is intended to provide scalable performance when used on multiple host threads. All commands support being called concurrently from multiple threads, but certain parameters, or components of parameters are defined to be externally synchronized. This means that the caller must guarantee that no more than one thread is using such a parameter at a given time.
That is just a re-wording of the literal text you quoted. Everything in the valid usage boxes pertain to “when calling <insert function here>”.
Yes. Command with externsync is a writer. No other thread may read or write instance at the same time.
If the command is not externsync, then it is a reader. Multiple threads can read the same thing at the same time without disturbing each other.
vkDestroyInstance implicitly destroys (i.e. “kinda writes”) all its VkPhysicalDevices. There’s no dedicated vkDestroyPhysicalDevice command. So there must be nothing reading any of the VkPhysicalDevice at the time they are destroyed.
VK_LAYER_KHRONOS_validation checks this, but might miss some coverage. Instance might be a special case, because the validation needs instance to work. Additionally threading issues may not always be triggered, as sometimes they simply miss the memory hazard by the way they are timed.