What is the lifetime of Vulkan objects passed to create functions?

Is it OK to destroy the objects after the create function is called?


VkInstance create_inst() {
  std::string app_name = "my_app_name";
  VkApplicationInfo my_app;
  my_app.sType = VK_STRUCTURE_TYPE_APPLICATION_INFO;
  my_app.pApplicationName = app_name.c_str();
  VkInstanceCreateInfo info;
  info.sType = VK_STRUCTURE_TYPE_INSTANCE_CREATE_INFO;
  info.pApplicationInfo = my_app;
  VkInstance r;
  vkCreateInstance(info, nullptr, r);
  return r;
  // std::string app_name will be destroyed here
  // VkApplicationInfo my_app will be destroyed here
}

Also lists for requirements and validation layers? Better in general, are the required objects (especially strings) copied copied when the create functions are called, or are just the pointers stored?

This is a good question. On my system (nvidia, linux) the VkGraphicsPipelineCreateInfo.pStages[] has a pName which is later displayed in a debug callback.

If I let the pName string expire / go out of scope / be deleted – then the pName pointer is left dangling and becomes invalid.

I went back and looked over the other places in the API where there might be dangling pointers, but I only found these two: VkPipelineShaderStageCreateInfo and VkApplicationInfo

For instance, vkCreateDebugReportCallbackEXT has some arguments that are strings, but they remain valid for the entire scope of the callback so there is no problem.

static VKAPI_ATTR VkBool32 VKAPI_CALL debugReportCallback(VkFlags msgFlags, VkDebugReportObjectTypeEXT objType, uint64_t srcO$
                size_t location, int32_t msgCode, const char *pLayerPrefix, const char *pMsg, void *pUserData)

Any others ?

I attempted to locate a global statement in the Vulkan Docs about what the policy is for object lifetime, but only found VkSystemAllocationScope, which is not really an answer.

From the specification:

So that’s that. All of the pointers you pass in are “application-owned memory” and therefore can be freed after commands that consume it.

Therefore:

On my system (nvidia, linux) the VkGraphicsPipelineCreateInfo.pStages[] has a pName which is later displayed in a debug callback.

If I let the pName string expire / go out of scope / be deleted – then the pName pointer is left dangling and becomes invalid.

If that really happens, then it’s a driver bug. If the driver wants to display that name in a debug callback, then it must copy that data, and it must do so in the duration of the VkCreateGraphicsPipeline call.

The only exceptions to this are obvious ones: callbacks and any data associated with them. This includes the memory allocation callbacks.

As far as the data Vulkan passes back to you, in most cases your code provides storage for them. For example, with vkGetPhysicalDeviceMemoryProperties, you pass a VkPhysicalDeviceMemoryProperties. Even extension querying has you pass in an array of structs that contain strings as fixed-size arrays rather than pointers.

Thanks, Alfonse.

It sounds like I should write up a CTS unit test that:
[ol]
[li]Supplies a VkApplicationInfo with a pApplicationName pointing to “foo”
[/li][li]Supplies a VkPipelineShaderStageCreateInfo with a pName pointing to “bar”
[/li][li]Modifies the memory where “foo” was to say “fob”, and “bar” to “baz” (or something)
[/li][li]Runs as little code as necessary to get the driver to log something to the debug facility with either the application name or the shader stage name – I wonder what’s the easiest way to do this?
[/li][li]Check that the driver’s copy of the name didn’t change…
[/li][/ol]