Question: Is there API to identify DXVK?

[LunaTheFoxgirl]

I'm currently working on a library to allow swapchain image sharing across processes in a cross platform manner. For this to work while running under DXVK I'd need to first detect DXVK, then get the VkImage handles for the underlying Vulkan renderer.

Brute force method would just be to find some DXVK function that generally always exists and using GetProcAddress on it to detect DXVK. But if there's a cleaner way I'd like to know.

[doitsujin]

We have a COM interface for Vulkan interop, see

dxvk/src/dxgi/dxgi_interfaces.h

Lines 312 to 390 in 4c09b00

	/**
	* \brief DXGI device interface for Vulkan interop
	*
	* Provides access to the device and instance handles
	* as well as the queue that is used for rendering.
	*/
	MIDL_INTERFACE("e2ef5fa5-dc21-4af7-90c4-f67ef6a09323")
	IDXGIVkInteropDevice : public IUnknown {
	/**
	* \brief Queries Vulkan handles used by DXVK
	*
	* \param [out] pInstance The Vulkan instance
	* \param [out] pPhysDev The physical device
	* \param [out] pDevide The device handle
	*/
	virtual void STDMETHODCALLTYPE GetVulkanHandles(
	VkInstance* pInstance,
	VkPhysicalDevice* pPhysDev,
	VkDevice* pDevice) = 0;
	/**
	* \brief Queries the rendering queue used by DXVK
	*
	* \param [out] pQueue The Vulkan queue handle
	* \param [out] pQueueFamilyIndex Queue family index
	*/
	virtual void STDMETHODCALLTYPE GetSubmissionQueue(
	VkQueue* pQueue,
	uint32_t* pQueueFamilyIndex) = 0;
	/**
	* \brief Transitions a surface to a given layout
	*
	* Executes an explicit image layout transition on the
	* D3D device. Note that the image subresources \e must
	* be transitioned back to its original layout before
	* using it again from D3D11.
	* \param [in] pSurface The image to transform
	* \param [in] pSubresources Subresources to transform
	* \param [in] OldLayout Current image layout
	* \param [in] NewLayout Desired image layout
	*/
	virtual void STDMETHODCALLTYPE TransitionSurfaceLayout(
	IDXGIVkInteropSurface* pSurface,
	const VkImageSubresourceRange* pSubresources,
	VkImageLayout OldLayout,
	VkImageLayout NewLayout) = 0;
	/**
	* \brief Flushes outstanding D3D rendering commands
	*
	* Must be called before submitting Vulkan commands
	* to the rendering queue if those commands use the
	* backing resource of a D3D11 object.
	*/
	virtual void STDMETHODCALLTYPE FlushRenderingCommands() = 0;
	/**
	* \brief Locks submission queue
	*
	* Should be called immediately before submitting
	* Vulkan commands to the rendering queue in order
	* to prevent DXVK from using the queue.
	*
	* While the submission queue is locked, no D3D11
	* methods must be called from the locking thread,
	* or otherwise a deadlock might occur.
	*/
	virtual void STDMETHODCALLTYPE LockSubmissionQueue() = 0;
	/**
	* \brief Releases submission queue
	*
	* Should be called immediately after submitting
	* Vulkan commands to the rendering queue in order
	* to allow DXVK to submit new commands.
	*/
	virtual void STDMETHODCALLTYPE ReleaseSubmissionQueue() = 0;
	};

.

Please note that the Vulkan swap chain itself can be recreated at any point in time, it's not really safe to export those images, and if you rely on current implementation details, we will break those in the future.

[mirh]

Not sure if it counts as cleaner or dirtier, but FWIW specialk just checks if the loaded api dll product name contains "DXVK".

[K0bin]

I'd say checking the DXVK interop COM interfaces is a lot cleaner, especially since OP needs the Vulkan handles after that anyway.