Just slapping SHARED at everything isn't really a fix, we need to match Windows behaviour. Need to understand what the game is actually doing and what exactly it is that it's trying to access as a shared resource, e.g. whether it is trying to import the D3D12 swapchain back buffer into Vulkan or something like that.
Having some sort of Proton log could already go a long way.
It's possible the game is trying to CreateSharedHandle from the D3D12 swapchain image. We don't handle that, and IIRC it sort of works on Windows (albeit not a documented feature, and IIRC it's known to break on various Windows versions).
initial_layout_transition should not be 1 for shared resources I think. That's probably a lingering bug that happens to work since shared opaque_fd on RADV disables compression.
CIG ended up fixing this on their end and moving to a more Vulkan-centric implementation; patches to VKD3D aren't needed to make the game work anymore.
Since there is a discrepancy between how windows handles this and how VKD3D does I guess it might still be worth taking a look into, but I don't have an easy way to test the efficacy of any patches now.
If you can confirm with the developers that they were doing exactly what I mentioned, we can put it on a TODO, but doing shared present over vkd3d-proton is just completely dumb from our PoV since it's all going through Vulkan anyway.
I don't have a direct line to the developers, but I'll see what scraps I can dig up or get from the in the forums. FWIW the consensus I've seen for why things are done this way is that Windows only offers the lowest latency presentation options to DX12, so that is probably why they're doing this, despite pivoting away from a full DX12 engine and towards Vulkan for the internals a few years ago.
The game now does an environment check during startup; on Windows it still uses the DX12 swapchain for presentation, but if Wine is detected a pure Vulkan (though based on the logs there are a handful of DX12 calls, it's probably just some shared startup code) implementation is used.
With this knowledge, it's also possible to get back to testing this by hiding the Wine exports from the executable, causing it to use the Windows initialisation process.
Is there a specific subset of wine/vkd3d logs that you'd find useful here?
Nothing extracted yet.
Background context: Star Citizen has a new "vulkan" renderer; it uses vulkan internally, but uses DX12 for the presentation layer.
I've been troubleshooting why the new Star Citizen renderer never presents anything other than a purely black screen, but Mangohud still works, menu sound is present, and its possible to navigate into the game world by clicking where buttons should be.
It turns out that vkd3d isn't presenting the same memory that Star Citizen is writing the output image to; if I patch in
heap_flags |= D3D12_HEAP_FLAG_SHAREDwhen the desc includes theD3D12_RESOURCE_FLAG_ALLOW_RENDER_TARGETflag ind3d12_resource_create_committedthis fixes the memory alignment, and vkd3d will now present the same memory the game is updating.Unfortunately, the game also never does the initial layout transition, so the
blank_presentoptimisation indxgi_vk_swap_chain_record_render_passstill causes a blank screen; for whatever reasonforce_initial_transitiondoesn't seem to be sufficient to satisfy this condition (is the logic inverted? ifforce_initial_transitionis NOT set,object->initial_layout_transition = 0, but blank_present is true if it's not zero).The game works fine on Windows, so I suspect there is some implementation quirk that either sets this flag or results in the memory being aligned anyway without it; is it worth upstreaming this fix since it seems to make the application behave more like Windows does? I'm happy to send a PR for this.