cancel
Showing results for 
Search instead for 
Did you mean: 

OpenGL & Vulkan

roman380
Adept I

Interop of Vulkan Image and D3D11 Texture

I am trying to figure out how to create a Vulkan 2D image shared with D3D11 texture.

My Windows 10 development system is equipped with Radeon RX 570 Series card which is a primary GPU device with monitors connected to it. I have 19.7.2 driver installed along with Vulkan RT and SDK 1.1.108.

For the record, there is a related topic here, which however does not help me enough.

I have a derivative of Vulkan SDK vcubecpp application which code as described below. This is a branch with code, and this is, separately, a diff which highlights my code edit.

It is worth mentioning that vkGetPhysicalDeviceImageFormatProperties2 gets me VK_EXTERNAL_MEMORY_FEATURE_DEDICATED_ONLY_BIT | VK_EXTERNAL_MEMORY_FEATURE_IMPORTABLE_BIT external memory features with VK_EXTERNAL_MEMORY_HANDLE_TYPE_D3D11_TEXTURE_BIT compatible handle for VK_FORMAT_R8G8B8A8_UNORM image. And this is what I am trying to do: to "import" an existing D3D11 texture for allocation of Vulkan image, if I understand the concept of import right.

Things are not going well at already vkGetImageMemoryRequirements2 step here.

If validation layer is not enabled, I get a memory access violation inside the call.

If however, the layer is enabled, the call passes through, but output VkMemoryRequirements remain uninitialized.

If I attempt to "fix" this by regular vkGetImageMemoryRequirements and use the data for allocation, I seem to be able to complete allocation and binding and the rest of the calls succeed (with still no confirmation whether the copied data got into the texture).

In a more complicated application where I do seemingly the same thing, but the source of the data is coming from image receiving render results, I have a consistent BSOD inside vkQueueSubmit call. Even though the properties of the images look the same, submission of work causes a kernel bugcheck (also attached bugcheck.txt😞

VIDEO_SCHEDULER_INTERNAL_ERROR (119)
The video scheduler has detected that fatal violation has occurred. This resulted
in a condition that video scheduler can no longer progress. Any other values after
parameter 1 must be individually examined according to the subtype.
Arguments:
Arg1: 0000000000000001, The driver has reported an invalid fence ID.
Arg2: 00000000ffb93b0a
Arg3: 00000000000002ea
Arg4: ffffad0f724e7000

...

nt!KeBugCheckEx
watchdog!WdLogEvent5_WdCriticalError+0xe0
dxgmms2!VidSchiVerifyDriverReportedFenceId+0xe803
dxgmms2!VidSchDdiNotifyInterruptWorker+0x291
dxgmms2!VidSchDdiNotifyInterrupt+0xd1
dxgkrnl!DxgNotifyInterruptCB+0x94
atikmpag+0x52960
atikmdag+0x4e0ba8
atikmdag+0x9607d
0x1
0xffffad0f`6a7ac000

In all cases, I don't see any reasonable hints from validation layer and debug output to help with vkGetImageMemoryRequirements2 and BSOD. That is, it brings me into situation where I am not sure what I should do to troubleshoot this further.

I would appreciate help in setting the interop up correctly or possibly an example of image/texture sharing.

0 Likes
8 Replies
dorisyan
Staff

roman380‌, Thanks for your report ! Is there a minimal code that can reproduce your problem?

0 Likes
roman380
Adept I

Thak you for the followup, dorisyan‌. 

A reproducer for vkGetImageMemoryRequirements2 access violation is simple and consistent. I took original Vulkan SDK demo vkcubepp and inserted a block of code in prepare_texture_image. The full project is cloneable from this repo https://github.com/roman380/VulkanSdkDemos/tree/d3d11-image-interop
The block of code in question is lines 2127-2303 with line 2167 here https://github.com/roman380/VulkanSdkDemos/blob/d3d11-image-interop/cube.cpp#L2167 triggering access violation. The block of code and added extensions are also separately visualized here https://github.com/roman380/VulkanSdkDemos/compare/d3d11-image-interop?expand=1
Commenting out vkGetImageMemoryRequirements2 and getting data using vkGetImageMemoryRequirements, I have another similar memory access violation later in call vkBindImageMemory2 in line 2210.
This is meant to be a minimal example, however even though I am copy/pasting code from a bigger project the behavior in bigger project is different:
There is no access violation in vkGetImageMemoryRequirements2 call, and instead it returns silently but without initializing VkMemoryRequirements values. That is, this is also unexpected behavior but without access violation. There is no apparent reason for this difference, validation layer does not emit any messages. Skipping there in that other project, the code passes vkGetImageMemoryRequirements2, vkBindImageMemory2 and then triggers a driver bugcheck in vkQueueSubmit call, once the created image is participating in a copy command.
0 Likes

Hi roman380‌, Thanks for that, I will try to reproduce it.

0 Likes

dorisyan‌, I extracted relevant code into single .cpp file.

  1. clone https://github.com/roman380/VulkanSdkDemos.git at d3d11-image-interop  branch
  2. there is a single .cpp project in BindImageMemory2 subdirectory

It has all the properties mentioned above:

  1. line 154 VulkanSdkDemos/BindImageMemory2.cpp at d3d11-image-interop · roman380/VulkanSdkDemos · GitHub vkGetImageMemoryRequirements2 call returns zeros and does not initialize the output structure members
  2. line 286 VulkanSdkDemos/BindImageMemory2.cpp at d3d11-image-interop · roman380/VulkanSdkDemos · GitHub  vkQueueSubmit freezes the system to dead state - I don't have BSOD (new driver 19.7.3 or another reason) but the system is dead and needs a reset from there.

I thought that cube project behavior could be different because maybe the same code there is executed in the scope of begun command buffer. I assume it could make a difference.

0 Likes

dorisyan‌, I wonder if you have anything to update?

This looked like a tech in active development, so I expected the question to draw some attention.

0 Likes
dorisyan
Staff

Hi roman380‌, Thanks for the provided info, I will give you feed back soon!  (I'm so sorry that I didn't investigate this issue last week)

0 Likes
dorisyan
Staff

Hi roman380‌, I can reproduce your problem on AMD card, but I run your app on NV, there are also some bugs like 'access violation', maybe there is something wrong in your app, could you please have a check again? 

0 Likes

Thanks for looking, I thought my question is dead...

AFAIR I took a working app from Vulkan SDK just to have baseline initialization done. then on top of that I attached an attempt to use BindImageMemory2 and initialize D3D11 interop. Yes it does not work and in a strange way. I am guessing there is nothing wrong with the app itself, just my edit is not functional, and my edit is basically a single block of code ~200 lines in cube.cpp lines 2126-2303 as highlighted here by github in the bottom file: Comparing master...d3d11-image-interop · roman380/VulkanSdkDemos · GitHub 

I will re-check later but I assume the question remains where it was, how to use D3D11 texture interop.

0 Likes