Problems with Vulkan/DXGI on AMD GPU

[SaltyBet]

According to these:

• DXGI Swapchain on Opengl and Vulkan Games
• Vulkan AMD? #141

... I understand Vulkan/DXGI interop should work on AMD?

Tested RPCS3 using Vulkan and colors are broken when trying to enable HDR.

Logs:

logs.zip

[Kaldaien]

This is a known problem, unfortunately.
Special K fully works around their driver interop in OpenGL games.

In the Vulkan case, what's happening is SK is changing the D3D12 SwapChain format, and through a mechanism I don't know, they're copying the Vulkan image over to the D3D12 SwapChain without accounting for format mismatch.

It's difficult for me to develop a fix for this problem without getting my hands on an AMD GPU. I expect if they were doing the copy D3D12-side, SK would already be able to detect the format mismatch and correct it.

So it's either Vulkan-side or some proprietary thing in their driver that is exempt from validating image format :) I'm leaning heavily toward it's something in the driver I probably can't see. If it were being done D3D12-side and not accounted for, the format mismatch would be caught by the driver and the game would instantly crash.

Tl;Dr:

I think HDR is out of the question on AMD systems using Vulkan for now. Probably the only saving grace here is SK can enable HDR in D3D11 before DXVK translates it to Vulkan.

For native Vulkan software, I have no estimate if/when this will be fixed.

[SaltyBet]

Hi, @Kaldaien.

Over at GPUOpen-Drivers/AMD-Gfx-Drivers#24 (comment), AMD staff asked for the following:

From reading that thread it seems to be an issue in the vulkan application layer validating image format when translated from D3D12 SwapChain. Can you provide your system specs and a minimally compilable code source that reproduces this issue?

I provided them my specs and referenced the latest version of the SK source as of right now, but maybe you'd like to provide more details over there.

[SaltyBet]

Comments from AMD staff:

Are you able to provide full runtime of the issue? That's the source for the SK dll that does the injection from application to driver. Which could be the source of the issue, meaning it's not driver related, rather an application issue requiring a SK developer to dig into further. It doesn't seem like there's evidence that it's a driver issue currently.