在android平台主流是用opengl es,android下vulkan与opengles纹理互通。 而在win平台，主流游戏还用的是DX11，如果只是把结果通过CPU的内存输出，然后接到dx11，这个性能损失太大了，我们就需要Vulkan与DX11交互。 以及完成这个交互后，aoce我就不做dx11模块了，我比较了oeip中的dx11模块与当前的vulkan模块性能相差不大，都比CUDA差，但是通用性更好。
如果有兴趣，可以看下aoce_vulkan/win32/VkWinImage类的实现，dx11与vulkan绑定的逻辑主要在这。
与opengles交互类似，资料不多，主要看到vulkan下有个vulkan_win32的头文件，看到如VkImportMemoryWin32HandleInfoKHR这些结构，用google搜下，
可以看到BindImageMemory有比较完整的交互逻辑，主要就是用DX11Texture共享纹理，注意这里要用NT句柄，就是相关MiscFlags需要包含D3D11_RESOURCE_MISC_SHARED_NTHANDLE，而在cuda/dx11交互里用cudaGraphicsD3D11RegisterResource用NT句柄 会失败，所以最好用个标志表示是否需要NT句柄，NT句柄需要自己CreateSharedHandle，从NT句柄得到相应shader buffer需要通过ID3D11Device1拿到，余下的逻辑和非NT句柄差不多了，相关代码aoce_win/DX11/Dx11SharedTex查看具体实现。
然后就是按照cuda/dx11交互那样，vulkan最后输出结果到绑定dx11texture上的那个vkImage,然后在dx11渲染的另外一个线程把上面的dx11texture结果输出来就行，想的应该是这样，然后就开始不断启动就报device lost，然后启动几次后机器卡死/死机蓝屏，最开始我想的肯定是同步问题，继续在vulkan_win32的头文件找，找到如下VkWin32KeyedMutexAcquireReleaseInfoKHR结构，这个结构不就是 dx11不同线程交互的同步API的AcquireSync/ReleaseSync，根据这个结构搜索到dx11-vulkan-keymutex根据这里的逻辑改下，然后发现还是卡死/死机，我开始根据新增加代码一行行屏蔽测试，不断死机/蓝屏，最后我忽然想到解决动态启用/关闭层时遇到的一个问题，其中把运算结果复制给绑定dx11资源的vkImage，用的是vkCmdBlitImage，改成vkCmdCopyImage，然后问题解决，以前我因为vkCmdBlitImage里源和目标纹理不需要同样大小就一直用的这个，我猜测这个API应该是需要渲染管线与交换链那一套的， 在这里我只有计算管线所以会导致问题，后面有时间验证下这个问题。
这个问题解决后，可以正常运行了，但是，你不动窗口运行多久没问题，但是一动窗口vulkan就报timeout，而这timeout一看就是VkWin32KeyedMutexAcquireReleaseInfoKHR上面的， 我猜测在移动窗口时，导致绑定dx11texture上的那个vkImage那个资源一直被dx11渲染占用着，所以就有这个问题，而我设计输出层时，设计要求运行线程与输出线程没有等待关系，二个线程可以分别以自己桢率运行 ，就和我在cuda交互里的处理，设置timeout为0，检查锁，如果锁timeout，就马上放弃复制，线程继续运行，而在这，我并不能通过这个接口实现这种逻辑。
最后想了想，vulkan运行线程中，我可以用vkFence知道是否在执行commandbuffer,那么在二次执行中先复制结果一个临时dx11纹理中， 这样也不需要针对这个临时dx11纹理与vulkan执行线程同步，把原来的绑定dx11texture上的那个vkImage的MiscFlags中的D3D11_RESOURCE_MISC_SHARED_KEYEDMUTEX改成D3D11_RESOURCE_MISC_SHARED，然后把相关的 VkWin32KeyedMutexAcquireReleaseInfoKHR代码去掉，vulkan执行comandbuffer执行完成后，使用vkFence等待，等待完成后把绑定dx11texture上的那个vkImage输出到临时dx11纹理中。
最后在Dx11的渲染线程中，把临时dx11纹理结果拿出来渲染，现在移动窗口正常了。
原文：https://www.cnblogs.com/zhouxin/p/14387603.html