OpenGL & Vulkan

[angelcoder]

Hello AMD Community,

I have an issue with the interoperablility functionality.

Small description:

- Create vulkan image and bind it to the memory with external memory functionality.

- Get Win32Handle of it.

- Import the handle to the OpenGL via GL_EXT_memory_object extension

- Create Texture with this memory.

- Attach it to FBO

- make vulkan render call

- Blit imported texture ( as FBO attachment) to the default FBO eg. GL_BACK_LEFT

==> The issue is the blitted image is completely brocken. I can see parts of the resulting image but the image is tolally scrambled.

Here is the link of a simple example:

GitHub - spfuetzner/AMD_external_mem_bug: small example showing problems with external memory and Op... 

Also tried to use imported texture as shader input - the problem remains.

Tried different Hardware (RX 580 to Vega 54) with the newest drivers and on Win10 x64 (1903) same issue. Seems to be driver Problem either on Vulkan or OpenGL side (or both) . Or maybe I am just missing something?

This post could be related to the Vulkan / OpenGL interoperability problems (see last posts)

Thanks for your help in advance!

Side note: The code works properly on the concurrent hardware.

[dipak]

Hi angelcoder‌,

Thank you for reporting the issue. From the above description, our "OpenGL and Vulkan" developer forum looks better place to report it than the driver support forum. Hence I've moved your post to the "OpenGL and Vulkan" forum and also whitelisted you for our DevGurus community. 

Thanks.

[dorisyan]

Thanks for your report! We will investigate this issue as soon as possible!

[dorisyan]

angelcoder‌, the right output should like this?  

[angelcoder]

Hello dorisyan!

Yeah that is exactly how it should look like :-). Can I assume the problem is solved? If so is there a driver version that i could test with?

And thank you very much!

Cheers!

[angelcoder]

And there is another small issue I found:

VkPhysicalDeviceIDProperties::driverUUID returns different values than its OpenGL counterpart. I dont know whether in case VK-OpenGL interoperability this parameter has to match.VK Specs however seems to demand this.

Cheers!

[dorisyan]

Hi angelcoder‌,

Yes, we found the root cause of the issue. As the Vulkan spec 1.1.127 mentions in bullet point #1 of Valid Usage section under VkMemoryAllocateInfo, if a memory object were going to be exported, it should be marked as dedicated.

Valid Usage

• If the pNext chain contains an instance of VkExportMemoryAllocateInfo, and any of the handle types specified in VkExportMemoryAllocateInfo::handleTypes require a dedicated allocation, as reported by vkGetPhysicalDeviceImageFormatProperties2 in VkExternalImageFormatProperties::externalMemoryProperties::externalMemoryFeatures or VkExternalBufferProperties::externalMemoryProperties::externalMemoryFeatures, the pNext chain must contain an instance of VkMemoryDedicatedAllocateInfo or VkDedicatedAllocationMemoryAllocateInfoNV with either its image or buffer field set to a value other than VK_NULL_HANDLE.

You could set up a VkMemoryDedicatedAllocateInfo with the associated image and link it to the pNext of VkExportMemoryAllocateInfo, and try to see if the application could get you an expected result. Please let us know if you still got the wrong output.

Also, thank you so much again for the issue reporting. We will take an investigation into the UUID issue you mentioned above as soon as possible.

Sincerely,

Tianyuan

(solved by Doris's teamates - Tianyuan)

[angelcoder]

Yeah! That was it.  Im very sorry for complaining, that was all my fault.:-)

I had the check, but our pNext chain creator was broken. ( However there is some inconsistency (I guess): Exporting/importing memory from one vkapi instance to another was possible, despite the missing dedicaded allocation create info.)

Thank you for investigation and help!

Cheers!