Supporting Vulkan 1.1

[syoyo]

Vulkan 1.2 supported environment is not yet widely available(as of Jun, 2020), so adding support of 1.1 would be nice.

Apparently, required modification seems small. I could run VkInline on 1.1 driver(NV Linux, AMD amdgpu-pro Linux) by simply replacing 1.2 -> 1.1 and VK_KHR_buffer_address stuff to VK_EXT_buffer_address.

@fynv Is there any concern to support Vukan 1.1? When no further changes required, I can send a PR to support 1.1.

[fynv]

Yes, you are right. I recalled that the reason I had to use VK_KHR_buffer_address was because VK_KHR_ray_tracing forced me to do so in another project. So it is not the case in this project, not util I start to look at the ray-tracing pipeline.

Just had a try to down-grade to vulkan 1.1, basically as you said:

• Setting version to 1.1
• Removed VK_KHR_get_memory_requirements2, not needed
• Replaced VK_KHR_buffer_address stuff to VK_EXT_buffer_address stuff.

Currrently, the only issue I have is a validation error, like:
validation layer: Validation Error: [ VUID-vkBindBufferMemory-bufferDeviceAddress-03339 ] Object 0: handle = 0xf8ce070000000002, type = VK_OBJECT_TYPE_BUFFER; | MessageID = 0x44a78781 | vkBindBufferMemory(): If buffer was created with the VK_BUFFER_USAGE_SHADER_DEVICE_ADDRESS_BIT_KHR bit set, memory must have been allocated with the VK_MEMORY_ALLOCATE_DEVICE_ADDRESS_BIT_KHR bit set. The Vulkan spec states: ...

The thing is that, VK_BUFFER_USAGE_SHADER_DEVICE_ADDRESS_BIT_KHR and VK_BUFFER_USAGE_SHADER_DEVICE_ADDRESS_BIT_EXT are the same value. If I don't set this bit, there will be another validation error.

Any idea how I can fix this?

[syoyo]

@fynv combining VK_KHR_ray_tracing to VkInline should be nice!

https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_KHR_buffer_device_address.html

I found buffer_device_address feature is still optional to Vulkan 1.2, so we'll need

• For Vulkan 1.2, check bufferDeviceAddress capability
• For Vulkan 1.1, Check if VK_(KHR/EXT)_buffer_device_address is available

The thing is that, VK_BUFFER_USAGE_SHADER_DEVICE_ADDRESS_BIT_KHR and VK_BUFFER_USAGE_SHADER_DEVICE_ADDRESS_BIT_EXT are the same value.

This is a bug of ValidationLayers and it seems it was fixed recently.

KhronosGroup/Vulkan-ValidationLayers#1661

[fynv]

This is a bug of ValidationLayers and it seems it was fixed recently.
KhronosGroup/Vulkan-ValidationLayers#1661

Yes, the validation error is gone after I updated my SDK to 1.2.141.0!
It sound a little bit messy to me to decide the extension-set dynamically. I'm fine with sticking to vulkan 1.1 for now. Will come back to this when I start to do VK_KHR_ray_tracing. Before that, I will explore the rasterization pipeline first, which will take some time.

Btw, are you trying this with a AMD GPU? Are there other issues? Is "VK_EXT_scalar_block_layout" supported there? I haven't had a chance to try this with anything other than Nvidia. The only other Vulkan device I have is a Qualcomm smartphone, which seems hopeless to support the extensions I need..

[syoyo]

Btw, are you trying this with a AMD GPU? Are there other issues? Is "VK_EXT_scalar_block_layout" supported there?

I have some AMD GPUs(Hawaii, VEGA, Navi, Rad VII) and NV GPUs(Pascal, Volta, 2080 Ti).

VK_EXT_scalar_block_layout seems supported for most AMD and NV GPUs, where as VK_EXT_buffer_device_address is not supported on AMD Hawaii and NV server(P100) GPUs.

For more information, you can take a look at this: http://vulkan.gpuinfo.org/listdevices.php

I'm not seeing any other issues yet.

[fynv]

Thanks for the valuable information. Haven't been able to find P100 in the list though.
Just wondering, there is not a case where VK_KHR_buffer_device_address is supported but not VK_EXT_buffer_device_address, is there?

[syoyo]

P100 in the list though.

You can use Google Colab to test with P100(Colab GPU will assign P100 or T4)

VK_KHR_buffer_device_address is supported but not VK_EXT_buffer_device_address, is there?

I meant VK_EXT_buffer_device_address is not available in some older AMD/NV GPUs with Vulkan 1.1(So no VK_KHR_buffer_device_address support)

[fynv]

About this issue, I think I'm coming close to an ultimate solution after the last few commits.
The project file now generates 2 different dll files, PyVkInline.dll and PyVkInlineEX.dll, using the same code-set.
PyVkInlineEX.dll is built using an additional marco _PyVkInlineEX. With _PyVkInlineEX, PyVkInlineEX.dll initializes a Vulkan 1.2 context instead of a Vulkan 1.1 one.
In Python layer, VkInline first tries to load PyVkInlineEX.dll. If the initialization fails, it will then try to load PyVkInline.dll.
Note that the latest NVIDIA (alpha) driver supports Vulkan 1.2, but doesn't support VK_KHR_Raytracing. In this case, VkInline will also fall back to the Vulkan 1.1 path.
Now I'm starting to implement the ray-tracing part.