Vulkan Instance Creation getting Failed

I have two different process that are trying to create Vulkan instance one after the other . The first process is able to create Vulkan Instance but the second process fails in creating the instance . Also they are calling same function in which the instance creation code is written.

My doubt here is : Is it failing because both the process are using the application name in VkApplicationInfo structure or is there any other reason?

Thanks in advance.

Using the same values in the application info structure should work fine as this is merely a hint for the implementation. An application should be able to create an arbitrary number of Vulkan instances.

But what error code does the failed vkCreateInstance actually return? Do the validation layer hint at any problems? Are the processes that create the instances synchronized?

The error code returned is -7. The validation layer does not give any hint. No, the processes are not synchronized. I have included all the validation layers using VK_LAYER_LUNARG_standard_validation .

Also , is synchronization the main reason for the vkinstance creation getting failed?

[QUOTE=Soorya;41128]The error code returned is -7. The validation layer does not give any hint. No, the processes are not synchronized. I have included all the validation layers using VK_LAYER_LUNARG_standard_validation .

Also , is synchronization the main reason for the vkinstance creation getting failed?[/QUOTE]

I’d guess so. Make sure that one instance has finished creation before the other thread creates an additional instance e.g. using a mutex. I’m pretty sure that instance creation wasn’t made with simultaneous creation in mind and as such you have to care for synchronization (as is stated in the specs).

okay i will check that … also is there anything like if one process has used the extensions and layers for creating instance then another process will not be able to use that . Because when i tried to print the count of the enabled layers and extension for first process it showed the values as 7 and 4 respectively . But for the second process it shows only 0 and 1 for layers and extensions enabled.

-7 is VK_ERROR_EXTENSION_NOT_PRESENT.

@SW Wait, where does it say vkCreateInstance has to be synchronized. There’s no Host Synchronization block and otherwise it is said:

All commands support being called concurrently from multiple threads, but certain parameters, or components of parameters are defined to be externally synchronized.

[QUOTE=krOoze;41131]-7 is VK_ERROR_EXTENSION_NOT_PRESENT.

@SW Wait, where does it say vkCreateInstance has to be synchronized. There’s no Host Synchronization block and otherwise it is said:[/QUOTE]

But why do i get different count values while printing the extensions and layers in the two different process.

No idea.
I tried to run 5 processes (through bat) in Windows 10 and seems to work fine.

It is not exactly illegal to return different set of layers and instance extensions. But sure is unusual. What platform you are on? Do you have latest SDK?

Can you perhaps post some minimal repro source?

[QUOTE=krOoze;41133]No idea.
I tried to run 5 processes (through bat) in Windows 10 and seems to work fine.[/QUOTE]

I did the same on Linux (Ubuntu 16.04) with Nvidia card and things worked fine.

If running on Linux and if using an environment variable (e.g., VK_LAYER_PATH) to locate the layers, then it is possible that one process has this set correctly and another does not.

Yup, need more info here.

I am running on Ubuntu 16.04 with Nvidia card and am using VK_LAYER_PATH to locate the layers.

@karlschultz how did you locate the layers/ extensions?

If you are using the LunarG SDK, you’ll need to follow the instructions on the LunarXchange web site in the Linux Getting Started doc: https://vulkan.lunarg.com/doc/sdk/latest/linux/getting_started.html

This will tell you how to set the VK_LAYER_PATH and LD_LIBRARY_PATH to locate the layers.

Here’s an example terminal session showing the building of the SDK examples, setting the SDK env vars, and then running multiple instances of cube with validation layers loaded:

karl@cartman:~ cd sdk/VulkanSDK/1.0.26.0/ karl@cartman:~/sdk/VulkanSDK/1.0.26.0 ./build_examples.sh

  • pushd examples
    ~/sdk/VulkanSDK/1.0.26.0/examples ~/sdk/VulkanSDK/1.0.26.0
  • cmake -H. -Bbuild
    INC_DIR = /home/karl/sdk/VulkanSDK/1.0.26.0/x86_64/include
    BIN_DIR = /home/karl/sdk/VulkanSDK/1.0.26.0/x86_64/bin
    LIB_DIR = /home/karl/sdk/VulkanSDK/1.0.26.0/x86_64/lib
    – Configuring done
    – Generating done
    – Build files have been written to: /home/karl/sdk/VulkanSDK/1.0.26.0/examples/build
    ++ nproc
  • make -j4 -C build
    make: Entering directory ‘/home/karl/sdk/VulkanSDK/1.0.26.0/examples/build’
    make[1]: Entering directory ‘/home/karl/sdk/VulkanSDK/1.0.26.0/examples/build’
    make[2]: Entering directory ‘/home/karl/sdk/VulkanSDK/1.0.26.0/examples/build’
    make[2]: Entering directory ‘/home/karl/sdk/VulkanSDK/1.0.26.0/examples/build’
    make[2]: Entering directory ‘/home/karl/sdk/VulkanSDK/1.0.26.0/examples/build’
    make[2]: Leaving directory ‘/home/karl/sdk/VulkanSDK/1.0.26.0/examples/build’
    make[2]: Leaving directory ‘/home/karl/sdk/VulkanSDK/1.0.26.0/examples/build’
    make[2]: Leaving directory ‘/home/karl/sdk/VulkanSDK/1.0.26.0/examples/build’
    [ 20%] Built target vulkaninfo
    [ 60%] Built target cube
    [100%] Built target tri
    make[1]: Leaving directory ‘/home/karl/sdk/VulkanSDK/1.0.26.0/examples/build’
    make: Leaving directory ‘/home/karl/sdk/VulkanSDK/1.0.26.0/examples/build’
  • popd
    ~/sdk/VulkanSDK/1.0.26.0
    karl@cartman:~/sdk/VulkanSDK/1.0.26.0$ export VK_LAYER_PATH=/home/karl/sdk/VulkanSDK/1.0.26.0/x86_64/etc/explicit_layer.d/
    karl@cartman:~/sdk/VulkanSDK/1.0.26.0$ export LD_LIBRARY_PATH=/home/karl/sdk/VulkanSDK/1.0.26.0/x86_64/lib/
    karl@cartman:~/sdk/VulkanSDK/1.0.26.0$ cd examples/build
    karl@cartman:~/sdk/VulkanSDK/1.0.26.0/examples/build$ ls
    CMakeCache.txt cmake_install.cmake cube-frag.spv lunarg.ppm tri tri-vert.spv
    CMakeFiles cube cube-vert.spv Makefile tri-frag.spv vulkaninfo
    karl@cartman:~/sdk/VulkanSDK/1.0.26.0/examples/build$ ./cube --validate &
    [1] 14678
    karl@cartman:~/sdk/VulkanSDK/1.0.26.0/examples/build$ ./cube --validate &
    [2] 14681
    karl@cartman:~/sdk/VulkanSDK/1.0.26.0/examples/build$ ./cube --validate &

(It turns out that for these SDK examples, the cube example is linked with an RPATH to the SDK lib directory, so setting LD_LIBRARY_PATH isn’t needed for cube since it was built this way)

I think I showed that in my previous post. Install the SDK and set the VK_LAYER_PATH and LD_LIBRARY_PATH.