On 3 July 2017 at 23:58, Ben "Root" Anderson roothorick@gmail.com wrote:
My current plan is to make and submit a patch to wine-staging that implements VK_KHX_external_memory_win32 and the Direct3D/DXGI functionality needed to interact with that extension from Direct3D; this implementation would very probably lean on GL_EXT_memory_object and related extensions. Then, I'd use those interfaces to import the textures into a Vulkan instance, which is then passed to the compositor.
While GL_EXT_memory_object seems to go in the general direction of what you'd need for sharing GPU resources between Vulkan and OpenGL in a generic way, note that GL_EXT_memory_object can only be used for importing external memory objects, not for creating them in OpenGL, or exposing the underlying GPU objects backing OpenGL resources.
It needs to work not with swapchain buffers, but a pair of ID3D11Texture2D objects that are created by the application for the express purpose of being passed to the API I'm wrapping. One or both of these textures may or may not also be presented by the application in its own window through the usual D3D process, but I do not know and am not supposed to know whether they are, and shouldn't care. (Some apps actually render and present a completely separate scene in their window.)
Right, so they're specific resources in practice, but that's not visible to the D3D API.