Hi @doitsujin,

With the pack16-formats branch from #476, the title no longer shows the error message, but the title still fails. It appears as running for about 25 to 45 seconds before closing (no window opens as previous). I retested on an Nvidia configuration for both Windows and Proton and both exhibit the same behavior.

Log: DIRT5_pack16-formats_VKD3D.log

Nevermind the apitrace thing since it still requires using Josh's fork and is generally a pain in the arse anyway, I might just look into it in the coming weeks.

I just finished checking it with Josh's forked Apitrace so I'll leave what I got anyway.

The game fails to launch and simply creates an unresponsive window before crashing to desktop when attempting to trace. A trace file is generated. I've attached it just in case.

Trace: https://drive.google.com/file/d/1hGoUd_IeuvC9Gl6aIPGhwTA-zyNUBG_r/view?usp=sharing
Output: d3dretrace_output_dirt5.log

I just realized I copy pasted the System Information, I didn't actually confirm on AMD. As far as it is on Nvidia, enabling dxgi.nvapiHack = False in the DXVK conf and setting WINE_HIDE_NVIDIA_GPU=1 allowed the game to behave exactly as it does on Windows. Apologies, I'll edit my post.

Perhaps this is a bit of a longshot, but would upgrading to the 5.11 kernel change anything, since supposedly Collabora is working on a DRM patch?

On Nvidia, the game starts just fine for me when disabling nvapiHack (through dxvk.conf), with latest Proton experimental and latest vkd3d-proton (didn't chech with anything else now). The game depends on consistent GPU identification through different sources and crashes if can't match the adapters due to PCI ID mismatch (which happens when nvapiHack is on but winex11.drv/vulkan/whatever still reports real PCI ID). I initially had a hang when trying to start the actual game after intro movie (d3d12 complaining about not able to create Vulkan swapchain, and Nvidia driver fault in dmesg) but that didn't happen on the third attempt.

On AMD, the game doesn't start exactly the same way as it was earlier with this game: doesn't find any device with feature level 0xc000:
04:warn:d3d12_device_create: Feature level 0xc000 is not supported, not sure if that is right for AMD RX 580
The game crashes in its code after that. I am not sure if the missing feature level on RX 580 is right or not, but this looks like the reason for the crash.

@gofman Feature level 0xc000 (12_0) on AMD GPUs requires Mesa/RADV 21.0-rc or git currently for sparse resources.

Yes, indeed, with the git Mesa this error is not there and the game loads for me on AMD, while hangs on the initial screen with the log spamming:
216:warn:d3d12_command_list_ResourceBarrier: Issuing split barrier(s) on D3D12_RESOURCE_BARRIER_FLAG_END_ONLY.
I suppose this is something to be debugged on vkd3d-proton side, as the hang doesn't happen on Nvidia and looks likely d3d12 related.

I was inaccurate regarding the conditions which make it work though. It doesn't start on AMD right away because it wants to load atiadlxx.dll library (proprietary AMD driver extension). I did not notice at once because unfortunately had leftover dxvk.conf file in the game directory which was spoofing a Nvidia GPU.
We have a stub implementation for atiadlxx in Proton which is disabled by default. Running with WINEDLLOVERRIDES="atiadlxx=b" with Proton Experimental and latest vkd3d-proton allows the game to start both on Nvidia and AMD (minus the hang on the initial screen mentioned above) without any further tweaks. On Nvidia matching the device ID actually doesn't matter, it is atidlxx which it wants to load if sees AMD from dxgi. With the mentioned override the game looks playable on Nvidia (started the turorial successfully).

The use of atiadlxx can maybe explain the problems with vkd3d-proton on Windows, while I am not sure how interesting debugging that on Windows since the thing mostly works in Proton.

UPDATE: The game is Denuvo protected, so it is better to avoid switching Proton versions when working with it to avoid 24h ban. Repeatedly replacing d3d12.dll will most likely not trigger Denuvo though.

Note that dxvk's dxgi spoofes an nvidia card since https://github.com/doitsujin/dxvk/pull/1926.
Edit: nvidia, stupid brain

Split barriers aren't really an issue other than perhaps for performance; Vulkan doesn't really support an equivalent feature so we issue barriers immediately. This will never prevent a game from running, though.

I didn't assume that the split barriers is the issue, I just quoted that as the indication game still tries to do something with d3d12 while hanging. I've got no reasons to be really sure this is a d3d12 issue so far, but given that it works on Nvidia I think the [easier] starting point for debugging the hang is vkd3d-proton.

Note that dxvk's dxgi spoofes an amd card since doitsujin/dxvk#1926.

I am not sure we necessarily need to do that. We do already enable atiadlxx override for a few games in Proton and since the stub helps here as well adding DIRT5 to that list looks like the easiest option. However, spoofing Nvidia on AMD works here too (along with disabling nvapi hack on Nvidia).

Okay, I'm just trying to understand what you guys are getting at. You're basically saying, at least on NVIDIA cards, the game can run doing the following:

1. Use Proton Experimental
2. Compile the latest DLL files from vkd3d-proton and put them in ~/.local/share/Steam/steamapps/common/Proton - Experimental/dist/lib (and lib64)/wine/vkd3d-proton
3. Get a copy of dxvk.conf from doitsujin's repository, place it inside the DIRT 5 installation directory, uncomment line 39 and change the value of dxgi.nvapiHack to False
4. Add WINEDLLOVERRIDES="atiadlxx=b" as a Steam launch parameter for the game

Is that how it goes?

Yeah, just step 3 is redundant, WINEDLLOVERRIDES="atiadlxx=b" should do, no need for dxvk.conf. Also, I was debugging that with 460.56 drivers on GTX 1080, not sure if it works with earlier drivers.

Huh...I'm using the same driver version on a 1660 and the game still instantly crashes. Well, at least there's good news someone else has been able to try it.

@cow-killer Actually, the game doesn't pickup the d3d12.dll from that location in your point 2, there is also a tar file... I think the easiest option is to just copy the new d3d12.dll to the game directory (where DIRT5.exe is). Maybe that is the problem.

Tried using both the 32- and 64-bit versions of the file, no success.

I don't know then what can be the difference, can you maybe attach the log with WINEDEBUG=+pid,+timestamp,+loaddll,+seh,+atiadlxx,+dxgi,+file PROTON_NO_FSYNC=1 WINEDLLOVERRIDES="atiadlxx=b" %command%, with 64 bit new d3d12.dll in the game directory, what if it give some ideas.

UPDATE: And do you see any message box or it just closes?

Here's the log. Game closes a minute or two after the "Preparing to launch DIRT 5" screen; nothing else shows up.

This looks like the immediate reason for the crash from the log:
228:err:vkd3d_dxil_log_callback: dxil-spirv: Must have an expected type for forward references!
...
Assertion failed: value, file ../../../Programs/vkd3d-proton/subprojects/dxil-spirv/dxil_converter.cpp, line 2133

But that looks a bit weird to me that it is not reproducible here. Are you sure you had up to date submodules when were building vkd3d-proton? That is, did 'git submodule update --recursive' after pulling the latest git?

Are you sure you had up to date submodules when were building vkd3d-proton? That is, did 'git submodule update --recursive' after pulling the latest git?

After doing that I got one step further. The game will no longer close automatically, but it still won't launch (no new windows appear). Attaching another log, but beware, this one's pretty huge.

This time it looks possible you haven't waited long enough for it to load, seems like you killed it while it was loading. It might take a while before it shows a window, it takes some time even on Windows (I saw some users complaining it takes a minute for them). You can try it without the logs for the first time, might be a bit quicker.

Yes! It works, albeit vibration support isn't there. Thanks so much. Think I'll write a quick tutorial on how to get this game to work over on Boiling Steam.

Regarding the vibration, improving controllers support have been receiving a lot of work in Proton lately. I personally don't have hands on this stuff (or controller collection to test this), but if you open an issue on Proton's github mentioning the problem and your hardware details (https://github.com/ValveSoftware/Proton/issues) there is a chance it will get attention. If you @ mention me there I will make people working on it aware of the issue.

Just ran another test, game seems to work fine on Proton 5.13-6 as well. Don't want to risk ban though due to the apparent DRM, so I won't be testing older versions of Proton until later.

Launch failure has been resolved for a little while. I've confirmed the title launches on both Nvidia and AMD with Proton-Experimental.

Remaining issue was reported here: https://github.com/HansKristian-Work/vkd3d-proton/issues/662

Closing, fixed.