简体   繁体   中英

Can Vulkan Layers change at Runtime?

So I was wanting to make a library to make Vulkan programming easier. You can see it at Github , but don't expect anything big soon ;). I want to make a function called getInstanceLayerProperties which returns all the layer properties (obviously). Seeing as this could be slower, I wanted to optimize it. My idea is simple: store it as an pre-calculated array. All I need to know is: Can the Vulkan layers change during Runtime. For example, say I cached the values of vkEnumerateInstanceLayerProperties . Can new layer properties be removed, added, or changed so that if I call that function again, I would get different results?

The vkEnumerate*Properties return information about the state of the system as it exists at the time the call was made. That seemed pretty obvious to to us as we were writing the spec, but I can see how that may not be as obvious to someone new to Vulkan.

As the layers are defined outside Vulkan, they can change over time. Not likely, but they can. That is one of the reasons these calls can return VK_INCOMPLETE. A typical use would be to first make the call to get the count, allocate space for the result and then get the data. If the list grew between those two calls, the app would see VK_INCOMPLETE and know that something changed.

First of all, I would note that this is a perfect way NOT to optimize code. It is not and semanticaly even can't be a hot-spot.
You can't even make use of the cached information unless you destroy your old instance/device and create a new one.

Now to answer:

Spec-wise there is no statements that explicitly prevent result invalidation.

UPDATE2: Therefore those may change anytime. Though that would be rare. Only definitive result is wheter vkCreateInstance() returns VK_SUCCESS or VK_ERROR_LAYER_NOT_PRESENT .

(Actually I kinda dislike, that practically all vkGet* and vkEnumerate* commands do not state the nature of invariability of their results. But then I somewhat forgot to raise that as a GitHub Issue...UPDATE2: did that now, before I forget again)

Implementation-wise code doing that should be open source. This should be part of official "The Loader" (also being part of the LunarG SDK). I may investigate later. Though it is reasonable to assume new set of layers is read every time from the registry (on Windows, that is). Admittedly, that is somewhat useless information anyway, since they may decide to change that behavior.

UPDATE: I just scanned it only quickly, but indeed it seems the layers are scanned anew on each call of the vkEnumerateInstanceLayerProperties : https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/blob/74d013a5438f47a66a77d5375d1cdeef3f0beca7/loader/trampoline.c#L227

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM