cancel
Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

particlepeter
Adept II

Extensions VK_KHR_surface and VK_KHR_win32_surface have disappeared

The mentioned extensions have disappears suddenly, unfortunately I am not sure why and when. I installed two things before I noticed the issue:

- Driver Crimson Edition 16.3.2

- LunarG Vulkan SDK 1.0.11.0

I doubt the later one is responsible, I tried all the other SDK versions without success, but who knows. Today I installed the Crimson Edition 16.4.2 Hotfix, but the problem remains.

The LunarG Vulkan Samples exit with a Missing extension error code. I confirmed within my own project that exactly the two mentioned extensions are missing. I had four extensions available on my system, VK_KHR_swapchain and VK_EXT_debug_report are still present.

I think the last driver which exposed all extensions was the beta driver Non-WHQL-64Bit-Radeon-Software-Crimson-16.4.2-Win10-Win8.1-Win7 from April the 20th.

Installing this driver over the current one does not solve the problem. I must admit that I am not sure if this is a driver bug at all, but what else could it be ?

As a side Note (some more fishiness): Even though yesterdays hotfix (16.4.2) is installed, the radeon settings window is convinced that Driver 16.3.2 (WHQL) is newer than the hotfix and suggest it to be installed. I tried that as well, didn't solve the problem either.

My System: APU: A10-7800, OS : Win 8.1 x64

Edit:

Meanwhile I installed Win 10 x64 as dual boot on the system and updated the drivers to Crimson Edition 16.4.2 Hotfix Win 10 x64. The problem does not exist on there, all four extensions are listed.

BUT (!!!) on Win 8 the implementation WAS listing 3 Queue Families, one of them a compute queue family with 4 queues.

Now, on Win 10 the implementation IS still listing 3 Families, but the compute queue exposes only 1 queue.

What's going on dear AMD engineers?

Message was edited by: Peter Particle

0 Likes
1 Solution

Actually I rather post a summary of two correct answers:

Update: After some experiments and a lot of web searching I figured that Crimson 16.5.1 Driver Version 16.15.2401.1002 is the latest for APUs and the right one for me in conjunction with LunarG VulkanSDK 1.0.8.0 and LunarG Vulkan Run Time Libraries 1.0.8.0.

As mentioned above about this driver, instance extension Extension: VK_KHR_swapchain is missing. That is because now it is device extension and works just fine.

I thought for a long time that even this driver is wrong, as calling vkCreateSwapchainKHR returned VK_ERROR_INITIALIZATION_FAILED.

The issue stems from  VK_LAYER_GOOGLE_unique_objects. The implementation lists it as available layer, but using it leads to the mentioned VK_ERROR. Without the layer everything is fine.

Is there any place where I get the information which Driver Version works with which LunarG Vulkan SDK? It was quite painful to figure this out with trial and error.

And the solution to the VK_LAYER_GOOGLE_unique_objects issue is:

Jon from LunarG did. While I was commenting on that issue I found additional references where people had also difficulties with that layer and the solution is that VK_LAYER_GOOGLE_unique_objects must be enabled as instance AND device layer. This might be the case for the other layers as well, but VK_LAYER_GOOGLE_unique_objects was the first one that complained in my case (I didn't enable any device layer).

View solution in original post

0 Likes
12 Replies
dwitczak
Staff

Hi Peter.

It seems like you're reporting two different issues here:

1) Extensions going missing in 16.3.2, but coming back in 16.4.2
2) Number of command queues reported for the compute queue family being different, depending on the OS version.

If I understand correctly, 1) is no longer relevant, because it's gone with the newer driver version, correct?

Regarding the second bullet, I will need to check internally.

0 Likes

1) No it is not gone. Even with driver update 16.4.2 on the Win 8.1 OS I am missing the extensions.

I have installed Win 10 into another partition of the same computer. On this OS the problem does not exist with driver 16.4.2.

2) I would agree that this is a different issue, I just noticed it while comparing the implementation compatibility on both the systems and wanted to share the insights. I just reported a bug via the amd bug report form.

0 Likes

I installed driver Crimson Edition 16.5.1 Hotfix and the problems have shifted:

On Win 8.1 VK_KHR_surface and VK_KHR_win32_surface are back, but VK_KHR_swapchain is missing, pure compute queues 7

On Win 10: VK_KHR_swapchain is missing as well. (VK_KHR_surface and VK_KHR_win32_surface did and do exist), pure compute queues 1

Additionally, on both systems all my three queue families report VK_QUEUE_TRANSFER_BIT (previously with driver 16.4.2 only on one queue family)

On Win 10 (didn't try on Win 8.1) I was not able to reinstall driver 16.4.2 over 16.5.1 (!!!) a system restore was required.

Dear AMD Engineers, I am willing to report and test you're drivers on my system, but just not through the driver bug report form. Please get in touch.

Here is some detailed Data which I extract programmatically from the implementations:

Driver Hotfix 16.4.2 Win 10

Instance Extensions

    Extension: VK_KHR_swapchain, version: 67

    Extension: VK_KHR_surface, version: 25

    Extension: VK_KHR_win32_surface, version: 5

    Extension: VK_EXT_debug_report, version: 2

GPU count 1: AMD Radeon(TM) R7 Graphics

    API Version       : 1.0.3

    Driver Version    : 36864

    Vendor ID         : 4098

    Device ID         : 4879

    GPU type          : VK_PHYSICAL_DEVICE_TYPE_INTEGRATED_GPU

Queue Family 0

    Queues in Family         : 1

    Queue timestampValidBits : 63

    VK_QUEUE_GRAPHICS_BIT

    VK_QUEUE_COMPUTE_BIT

    VK_QUEUE_SPARSE_BINDING_BIT

Queue Family 1

    Queues in Family         : 1

    Queue timestampValidBits : 63

    VK_QUEUE_COMPUTE_BIT

    VK_QUEUE_SPARSE_BINDING_BIT

Queue Family 2

    Queues in Family         : 2

    Queue timestampValidBits : 63

    VK_QUEUE_TRANSFER_BIT

    VK_QUEUE_SPARSE_BINDING_BIT

Driver Beta 16.5.1 May3 Win 10

Instance Extensions

    Extension: VK_KHR_surface, version: 25

    Extension: VK_KHR_win32_surface, version: 5

    Extension: VK_EXT_debug_report, version: 2

GPU count 1: AMD Radeon(TM) R7 Graphics

    API Version       : 1.0.8

    Driver Version    : 36864

    Vendor ID         : 4098

    Device ID         : 4879

    GPU type          : VK_PHYSICAL_DEVICE_TYPE_INTEGRATED_GPU

Queue Family 0

    Queues in Family         : 1

    Queue timestampValidBits : 64

    VK_QUEUE_GRAPHICS_BIT

    VK_QUEUE_COMPUTE_BIT

    VK_QUEUE_TRANSFER_BIT

    VK_QUEUE_SPARSE_BINDING_BIT

Queue Family 1

    Queues in Family         : 1

    Queue timestampValidBits : 64

    VK_QUEUE_COMPUTE_BIT

    VK_QUEUE_TRANSFER_BIT

    VK_QUEUE_SPARSE_BINDING_BIT

Queue Family 2

    Queues in Family         : 2

    Queue timestampValidBits : 64

    VK_QUEUE_TRANSFER_BIT

    VK_QUEUE_SPARSE_BINDING_BIT

Driver Beta 16.5.1 May3 Win 8.1

Instance Extensions

    Extension: VK_KHR_surface, version: 25

    Extension: VK_KHR_win32_surface, version: 5

    Extension: VK_EXT_debug_report, version: 2

GPU count 1: AMD Radeon(TM) R7 Graphics

    API Version       : 1.0.8

    Driver Version    : 36864

    Vendor ID         : 4098

    Device ID         : 4879

    GPU type          : VK_PHYSICAL_DEVICE_TYPE_INTEGRATED_GPU

Queue Family 0

    Queues in Family         : 1

    Queue timestampValidBits : 64

    VK_QUEUE_GRAPHICS_BIT

    VK_QUEUE_COMPUTE_BIT

    VK_QUEUE_TRANSFER_BIT

    VK_QUEUE_SPARSE_BINDING_BIT

Queue Family 1

    Queues in Family         : 7

    Queue timestampValidBits : 64

    VK_QUEUE_COMPUTE_BIT

    VK_QUEUE_TRANSFER_BIT

    VK_QUEUE_SPARSE_BINDING_BIT

Queue Family 2

    Queues in Family         : 2

    Queue timestampValidBits : 64

    VK_QUEUE_TRANSFER_BIT

    VK_QUEUE_SPARSE_BINDING_BIT

0 Likes

New Insights:

I installed LunarG SDK 1.0.13 on my working Win 10 System. After that VK_KHR_surface and VK_KHR_win32_surface were not available any more.

Installing Crimson Edition 16.5.3 Hotfix on my Win 10 System didn't solve the issue.

I am not sure how AMD does interact with the LunarG SDK and obviously not so sure any more if my problem is a driver bug at all, I just don't know what to do about it.

Anyway, could you please check if the connection with the LunarG loaders is working properly from your side? I will create an issue at LunarG as well.

As a side note, I took a look at the registry based on this Article: http://av.dfki.de/~jhenriques/development.html

Don't know its relevence as its about layers and not extensions, however, the keys in "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Khronos\Vulkan\ExplicitLayers" list only layers, their paths point to the Bin32 version of the LunarG SDK. Shouldn't this be Bin on Win 10 x64 ?

0 Likes

Even more Insights:
The issue stems from "Vulkan Run Time Libraries" from the publisher "LunarG". These libraries get installed with the AMD drivers and LunarG VulkanSDK.

After I uninstalled everything from LunarG VK_KHR_surface and VK_KHR_win32_surface extensions are back and I have a total of four extensions (see above).

But this also removes almost all layers (but VK_LAYER_RENDERDOC_Capture and VK_LAYER_VALVE_steam_overlay).

As additional test I reinstalled the current AMD driver Non-WHQL-64Bit-Radeon-Software-Crimson-16.5.3-Win10-Win8.1-Win7-May21. This also reinstalled  Vulkan Runtime Libraries 1.0.11.0 which in turn removed extensions VK_KHR_surface and VK_KHR_win32_surface, but adds back all layers.

This is my work around to get all extensions and all layers:

1.) Uninstall any Vulkan Runtime Libraries, but keep LunarG VulkanSDK installed (I tested with 1.0.11.0, but I guess others will work as well).

2.) Create an environment variable VK_LAYER_PATH which points to %VULKAN_SDK%/Bin or Bin32 (I am using Bin for now). I figured this from article: http://av.dfki.de/~jhenriques/development.html (Building the layers yourself as explained in that article might be even better)

Now the ultimate question, what are the Vulkan Runtime Libraries good for?

0 Likes

This is my work around to get all extensions and all layers:

1.) Uninstall any Vulkan Runtime Libraries, but keep LunarG VulkanSDK installed (I tested with 1.0.11.0, but I guess others will work as well).

2.) Create an environment variable VK_LAYER_PATH which points to %VULKAN_SDK%/Bin or Bin32 (I am using Bin for now). I figured this from article: http://av.dfki.de/~jhenriques/development.html (Building the layers yourself as explained in that article might be even better)

This didn't work to well in the end, I had lot of crashes here and there. In the end the only config that works reliable for me is:

Crimson 16.5.1 Driver Version 16.15.2401.1002 with LunarG SDK 1.0.8.0 and without activating available layer VK_LAYER_GOOGLE_unique_objects. More to that in my next post bellow.

0 Likes

Update: After some experiments and a lot of web searching I figured that Crimson 16.5.1 Driver Version 16.15.2401.1002 is the latest for APUs and the right one for me in conjunction with LunarG VulkanSDK 1.0.8.0 and LunarG Vulkan Run Time Libraries 1.0.8.0.

As mentioned above about this driver, instance extension Extension: VK_KHR_swapchain is missing. That is because now it is device extension and works just fine.

I thought for a long time that even this driver is wrong, as calling vkCreateSwapchainKHR returned VK_ERROR_INITIALIZATION_FAILED.

The issue stems from  VK_LAYER_GOOGLE_unique_objects. The implementation lists it as available layer, but using it leads to the mentioned VK_ERROR. Without the layer everything is fine.

Is there any place where I get the information which Driver Version works with which LunarG Vulkan SDK? It was quite painful to figure this out with trial and error.

Thanks a lot for the feed-back!

I'm sorry to haven't been much of help with this issue. What I can definitely do right now is taking your observations back to the driver team and suggest to include the recommended SDK version in future driver releases. This should prevent developers from encountering similar issues in the future.

0 Likes

One more thing. Would you consider opening a ticket @ Khronos-ValidationLayer GitHub project so that engineers behind the VK_LAYER_GOOGLE_unique_objects layer can have a look and see if they believe this behavior to be a problem?

0 Likes

Jon from LunarG did. While I was commenting on that issue I found additional references where people had also difficulties with that layer and the solution is that VK_LAYER_GOOGLE_unique_objects must be enabled as instance AND device layer. This might be the case for the other layers as well, but VK_LAYER_GOOGLE_unique_objects was the first one that complained in my case (I didn't enable any device layer).

0 Likes

Sounds like the problem is solved. Please consider marking the question as answered, thanks!

0 Likes

Actually I rather post a summary of two correct answers:

Update: After some experiments and a lot of web searching I figured that Crimson 16.5.1 Driver Version 16.15.2401.1002 is the latest for APUs and the right one for me in conjunction with LunarG VulkanSDK 1.0.8.0 and LunarG Vulkan Run Time Libraries 1.0.8.0.

As mentioned above about this driver, instance extension Extension: VK_KHR_swapchain is missing. That is because now it is device extension and works just fine.

I thought for a long time that even this driver is wrong, as calling vkCreateSwapchainKHR returned VK_ERROR_INITIALIZATION_FAILED.

The issue stems from  VK_LAYER_GOOGLE_unique_objects. The implementation lists it as available layer, but using it leads to the mentioned VK_ERROR. Without the layer everything is fine.

Is there any place where I get the information which Driver Version works with which LunarG Vulkan SDK? It was quite painful to figure this out with trial and error.

And the solution to the VK_LAYER_GOOGLE_unique_objects issue is:

Jon from LunarG did. While I was commenting on that issue I found additional references where people had also difficulties with that layer and the solution is that VK_LAYER_GOOGLE_unique_objects must be enabled as instance AND device layer. This might be the case for the other layers as well, but VK_LAYER_GOOGLE_unique_objects was the first one that complained in my case (I didn't enable any device layer).

0 Likes