vulkan api version problem

vulkaninfo says that the version of vulkan is 1.0.5, which is equal to the definition of VK_API_VERSION in the header file(the actual value is (1<<22)|(0<<12)|(5)=4194309).

However, when I put it back to VkApplicationInfo.apiVersion, then vkCreateInstance returns VK_ERROR_INCOMPATIBLE_DRIVER.

So I tried 1.0.0, 1.0.1, 1.0.2, 1.0.3, 1.0.4 for apiVersion, then it retured VK_SUCCESS.

Does it mean that vulkaninfo is not reliable? Or did I make any mistake?

When you say “version of vulkan”, do you mean the one at the beginning
or the one in VkPhysicalDeviceProperties: driverVersion.

If the former, you made a mistake.
In newer versions of the spec, the patch version (last number) won’t matter at all in the ApplicationInfo, but not yet in 1.0.4 (=your driver Vulkan version it would seem).

Correction: I meant VkPhysicalDeviceProperties: apiVersion
not driverVersion

I read somewhere (I think in the LunarG site…) that it wasn’t recomendable to use the exact API number, or you’d have these kind of problems, you can use just 1.0.0 for now, until, perhaps, vulkan 1.1.0, and as a rule of thumb, stay lower than the highest version the video driver suports, or the API version, which ever is smaller. I am sticking to 1.0.5 right now because that is the highest version of the driver NVidia has released, (oficially)

^ Perhaps in the spec or ref-pages:

apiVersion must be zero, or otherwise it must be a version that the implementation supports, or supports an effective substitute for

That most of the time means: requested ≤ driver-supported.

AIS, it will be a non-issue as soon as the drivers(aka implementations) catch up with the spec. The X in 1.0.X will be ignored, so everyone would be able to pass something like 1.0.1337 .

It is probably best to set VK_API_VERSION_1_0 in VkApplicationInfo.apiVersion for most applications.

An exception would be the case where a version of the spec came out that added a new feature and your app really needs to use it and it needs to use a driver that implements that feature. If the version for this feature was 1.0.42, then you’d use VK_MAKE_VERSION(1,0,42) in the application. You would get the incompatible driver message unless the driver implemented 42 or better.

Part of the motivation for this approach is that new versions of the Vulkan spec are coming out weekly at this stage. The VK_HEADER_VERSION gets incremented each time the spec is updated as well, whether or not any changes are made to the header. Between this fast pace and changes being made that may not affect drivers, the drivers are not going to keep up with header versions. So, if you compile your app so that the VK_HEADER_VERSION is used to make the third (patch) number, and you use the latest header, you’ll almost always request a version that is newer than the driver supports.

To be on the safe side, I think that most drivers are going to support apps that are <= the version supported in the driver. (Here, “support” means allow a Vulkan Device to be created.) There’s always a chance in the future that a spec change will be made that requires the driver to behave differently and drivers will probably always check and not allow the API version to be > than the driver version, in the event that something unforeseen comes along.

An exception would be the case where a version of the spec came out that added a new feature and your app really needs to use it and it needs to use a driver that implements that feature.

FYI: patch versions are not allowed to have new features. Only major and minor versions can.

@karlschultz Third time’s the charm: the patch version is ignored (since 1.0.11 I think), so your 42 would happily be ignored and you would get no such message.

Since some time VK_API_VERSION_1_0 is now defined as 1.0.0 so it is reasonable to use it, but it wasn’t always so, causing exactly those INCOMPATIBLE_DRIVER messages. Best to be explicit: VK_MAKE_VERSION(1,0,0).

Yes, you are right. I just tried 42 and it worked fine. And the spec says all this as well.

In the early days of Vulkan, pre-1.0 and soon after, some drivers were looking for exact matches. This was more important at the time because the specs were changing a lot and the drivers just had to match the headers more closely for things to even work at all. There were a lot of b/c-breaking changes going on before 1.0.

Also around 1.0, the Vulkan header was set up to encourage the applications to request an apiVersion that was directly derived from the header file version. Some drivers tended to reject connections from applications that asked for a patch > driver_version, and so this became a headache for apps that used a header that was newer than the driver. Apps then quickly changed to not use the version from the header, and use something like 1.0.0 instead. And it seems that drivers are now ignoring the patch level as well.

Yes, that was added to the header fairly recently. And I think it would be safe to depend on VK_API_VERSION_1_0 being there, else it would be a pretty bad breaking change. But the explicit approach is fine too.