Same issue here. Identical error box, and nothing else.

System Information

• GPU: GeForce GTX 1080 Ti
• Driver/LLVM version: NVIDIA 440.95.01
• Kernel version: 5.4.0-7634-generic
• Link to full system information report as Gist:
• Proton version: 5.0-9

A comment further down noticed that the logs are different if you click "yes" or "no" to sending a report.
Here are logs for both cases:

Log when clicking "no" to sending crash report:
steam-1151640-no_crash_report.log

Log when clicking "yes" to sending crash report:
steam-1151640-yes_crash_report.log

Edit: Out of curiosity I tried with the newest GloriousEggroll/proton-ge-custom release, with seemingly same result.
Log here, in case it helps anyone: proton_5.9-GE-5-ST_steam-1151640.log

Same issue here. Identical error box, and nothing else.
steam-1151640.log
Steam Sys-info

Looking at the logs from everyone, looks like this is common point where error occurs.

warn:debugstr:OutputDebugStringA "An unknown unhandled exception (C06D007Eh) has occurred in thread 'Main' (0) at instruction location 000000007B00FC3Eh\n\nCall stack:\nBase address: 0x000140000000\n 0. 0x00007BCDAC6C RtlVirtualUnwind\n 1. 0x00007BCDAF82 RtlVirtualUnwind\n 2. 0x00007BCDB2FE NtRaiseException\n 3"

I"m having same issue, the same line was also in my proton log, along with the error cpu_context_win.cc:144] non-x64 context

Same issue as mentioned by other users. However, I am still updating my results, incase it helps further to find the root cause.

System Info
steam-1151640_GE_5.9-5_ST.log
steam-1151640_Proton509.log
steam-1151640_Proton509_next.log

same here
System Info

Same issue here.

same here

I think, "error cpu_context_win.cc:144] non-x64 context" is the crash-reporter crashing and not hzd.
When you click on no when being asked to send the error report, you get a much different proton log.
Then warn:debugstr:OutputDebugStringA "Initializing DLMalloc Heap\n" maybe looks like the evil witch, that caused all of this.
steam-1151640.log

It's also dx12 only. That might not help a lot either.

I'm getting the same pop-up.. I tried multiple versions of proton including proton-ge and proton-tkg..

I'm having the same issue

Then warn:debugstr:OutputDebugStringA "Initializing DLMalloc Heap\n" maybe looks like the evil witch, that caused all of this.
steam-1151640.log

It isn't. These logs have a lot of info and possibly not enough.

Point in fact you can look at

fixme:msvcrt:MSVCRT__stdio_common_vsnwprintf_s options 24 not handled
warn:debugstr:OutputDebugStringA "Initializing DLMalloc Heap\n"

and think that could cause a failure. But, it is highly likely a red herring.

Also, stuff like "execute_cfa_instructions", "raise_exception", "dump_unwind_info" can all be present in a working game. Logs can also present other challenges with log entries appearing at different places.

There's also fixme and warnings appearing for dx12 but that may or may not mean anything important as well.

fixme:d3d12_device_caps_init_feature_options1: TotalLaneCount = 3840, may be inaccurate.
fixme:dxgi:dxgi_adapter_QueryVideoMemoryInfo Returning fake video memory info.
fixme:dxgi:dxgi_adapter_SetVideoMemoryReservation iface 0xd97f40, node_index 0, segment_group 0, reservation 0x180000000 stub!
warn:d3d12_device_CheckFeatureSupport: Shader cache features not supported.fixme:d3d12_device_CheckFeatureSupport: Unhandled format 0x55.
fixme:d3d12_device_CheckFeatureSupport: Unhandled format 0x56.
fixme:d3d12_device_CheckFeatureSupport: Unhandled format 0x73.

Its possible this one may take months or more to solve. Just depends on the problems and how many.

Same issue here. Identical error box.
steam-1151640.log
steam-sysinfo.txt

I added some additional debug channels for this log that will hopefully be helpful.

steam-1151640.zip
sysinfo.txt

I added some additional debug channels for this log that will hopefully be helpful.

steam-1151640.zip
sysinfo.txt

That does help a bit. The logs previously I don't think any other logs here show the dialog - the issuer's doesn't and I checked one other making two before this large one you provided.

You get that crash dialog box within [edit: 3k] lines [probably ~2.7 or 2.8k] of the dx12 info I posted above notably

"warn:d3d12_device_CheckFeatureSupport: Shader cache features not supported"
fixme:d3d12_device_CheckFeatureSupport: Unhandled format 0x56

Since its mostly garbage in between, its probable that its happening at the dx12 stuff or before (I haven't looked into it yet any further).

The error dialog.

0150:Ret  PE DLL (proc=0x11007bb8,module=0x11000000 L"amd_ags_x64.dll",reason=THREAD_ATTACH,res=(nil)) retval=1
0150:Starting thread proc 0x140375730 (arg=0x4fc5500)
0150:Call user32.MessageBoxW(00000000,141b588b0 L"Unfortunately the game has crashed.\nDo you want to help us fix the issue by sending a crash report?",141b59dc0 L"Error",00040014) ret=1403757c8

So it looks like much of the log is the end result of it crashing. I included the amd dll line in there just because its next to it and it may not mean anything.

I tried the game on Windows 10 too and it also won't run, displaying exactly the same dialog box.

However, before the "Unfortunately the game has crashed..." error, it displays different dialog box that says the game will only run with driver version 27. This is NVidia DirectX driver version and that version supports DirectX12 Ultimate, which I couldn't install on the computer I have running Windows 10 because... reasons...

So, I assume that the reason for this crash on Proton is essentially because there is no DirectX 12 Ultimate support either in Proton, or DX dlls being used in Proton prefix for this game, or because NVidia driver I have on Linux (440.100) does not provide features needed to implement/emulate DX12 Ultimate, or some other place (I'm not really familiar with all the Wine/Proton stack to be able to pinpoint this more precisely).

Just my 2 cents, thought it may help in some way.

So, I assume that the reason for this crash on Proton is essentially because there is no DirectX 12 Ultimate support either in Proton, or DX dlls being used in Proton prefix for this game, or because NVidia driver I have on Linux (440.100) does not provide features needed to implement/emulate DX12 Ultimate, or some other place (I'm not really familiar with all the Wine/Proton stack to be able to pinpoint this more precisely).

Its certainly possible. Though Death Stranding is I believe the only other game that is using this version of the Decima engine and dx12, and it has been working with the Proton next version, although that seems to be iffy and not without problems.

VKD3D is still a work-in-progress but they also note that 440.100 is one that works with dx12 and also a higher version driver may be needed. I'm not sure anyone has tested here with the Nvidia Vulkan developer beta driver as well.

But, it definitely looks possible that everyone may need to wait for VKD3D to improve and to have a driver that will work with it. Should find out in time.

it is most probably a dx12 issue, I get "fixme:d3d12_device_CheckFeatureSupport: Unhandled feature 0x13." before it crashes, in logs.

Looks like we have to wait for vkd3d to progress more.

it is most probably a dx12 issue, I get "fixme:d3d12_device_CheckFeatureSupport: Unhandled feature 0x13." before it crashes, in logs.

Looks like we have to wait for vkd3d to progress more.

You can get rid of these error in a dirty way by adding some lines to vkd3d. It doesn't make a difference. Copying dxcompiler.dll from the tools directory to the executable's directory does make it show the loading screen, but it still crashes with the same message, so it's not really useful.

I noticed doing some debugging that the error message is from a generic exception handler. It doesn't indicate what's happening behind the scenes except that the game crashed.

As @Danacus says, the initial error is likely due to dxcompiler.dll being missing (from @korodarn's log - thank you!):

00bc:Call KERNEL32.LoadLibraryExA(141e94fc0 "dxcompiler.dll",00000000,00000000) ret=1416abd49
...
00bc:Ret  KERNEL32.LoadLibraryExA() retval=00000000 ret=1416abd49
00bc:Call KERNEL32.GetLastError() ret=1416abd57
00bc:Ret  KERNEL32.GetLastError() retval=0000007e ret=1416abd57
00bc:Call KERNEL32.RaiseException(c06d007e,00000000,00000001,0021e290) ret=1416abd9d

If someone who has copied dxcompiler.dll from the tools directory to the executable's directory (and got to the loading screen, as Danacus stated) could provide a WINEDEBUG=+relay,module,seh,timestamp log, it might help find a way around it :) (remember to compress it, otherwise it'll be pretty huge haha)

I don't think it got to loading screen, but log does look a bit different so maybe it will be useful, maybe not.
steam-1151640_2.zip

@korodarn No idea if this will help or not, but try installing the native d3dcompiler_47 (protontricks 1151640 d3dcompiler_47):

73612.804:00bc:Call d3dcompiler_47.D3DCreateBlob(0000022c,0021e360) ret=1401f327e
73612.804:00bc:Ret  d3dcompiler_47.D3DCreateBlob() retval=00000000 ret=1401f327e
...
73612.804:00bc:trace:seh:raise_exception code=c0000005 flags=0 addr=0x1400f0787 ip=1400f0787 tid=00bc

steam-1151640_1.zip
I copied the d3dcompiler_47 into the executable folder as well the run prior to the one I uploaded. I zipped it right before so it is here

*I know this might not do exactly the same thing as the install, since I didn't change the setting so I'm verifying if it used this file and will try re-running after.

I'm guessing this might be related to cause of the crash then:

warn:d3d12_swapchain_set_display_mode: Failed to find closest matching mode, hr 0x887a0001.
...
err:d3d12_swapchain_resize_target: Failed to set display mode, hr 0x887a0001.
...
73337.021:00bc:trace:seh:raise_exception code=c0000005 flags=0 addr=0x1400f0787 ip=1400f0787 tid=00bc

There are also a few warning messages above it, not sure if they're relevant:

fixme:d3d12_rtv_desc_create_rtv: NULL resource RTV not implemented.
fixme:d3d12_pipeline_library_LoadGraphicsPipeline: iface 000000000086E0F0, name "a7c87623f47cdb58f8e2d75445db3985", desc 000000000021E3E0, iid {765a30f3-f624-4c6f-a828-ace948622445}, pipeline_state 000000000021E3A0 stub!
fixme:d3d12_pipeline_library_StorePipeline: iface 000000000086E0F0, name "a7c87623f47cdb58f8e2d75445db3985", pipeline 00000000008EC1F0 stub!
fixme:d3d12_pipeline_library_LoadGraphicsPipeline: iface 000000000086E0F0, name "2537307d2151a4df271e4f83d59bb13a", desc 000000000021E7A0, iid {765a30f3-f624-4c6f-a828-ace948622445}, pipeline_state 000000000021E760 stub!
fixme:d3d12_pipeline_library_StorePipeline: iface 000000000086E0F0, name "2537307d2151a4df271e4f83d59bb13a", pipeline 00000000008ECC80 stub!
fixme:d3d12_pipeline_library_LoadGraphicsPipeline: iface 000000000086E0F0, name "21027ab47f814a59b74aac09a0de8a03", desc 000000000021E7A0, iid {765a30f3-f624-4c6f-a828-ace948622445}, pipeline_state 000000000021E760 stub!
fixme:d3d12_pipeline_library_StorePipeline: iface 000000000086E0F0, name "21027ab47f814a59b74aac09a0de8a03", pipeline 00000000008ED710 stub!
fixme:d3d12_pipeline_library_LoadGraphicsPipeline: iface 000000000086E0F0, name "27b94cf050813cc52a0b50f27d19c573", desc 000000000021E740, iid {765a30f3-f624-4c6f-a828-ace948622445}, pipeline_state 000000000021E700 stub!
fixme:d3d12_pipeline_library_StorePipeline: iface 000000000086E0F0, name "27b94cf050813cc52a0b50f27d19c573", pipeline 00000000008EE1A0 stub!

Patch 1.01 is out, i didn't get to test it yet.

https://www.reddit.com/r/horizon/comments/i9jaa0/horizon_zero_dawn_complete_edition_for_pc_patch/

Still crashes for me.

Suppose its worth nothing and giving intersectRaven a break for the low quality post as the patch includes "Some players are experiencing startup crashes. Patch 1.01 fixes a few, but not all, of these crashes."

That patch should only benefit you when you can run it.

But, it still may need Proton/Wine/VKD3D/etc fixes before this game even runs.

By cherry-picking the some commits from upstream vkd3d into the valve tree you can fix the "unhandled feature" errors, and you can fix the "unhandled format" errors by simply adding the missing formats (not hard, these are supported formats in vulkan you just need to add the correct mapping).
After this the game complains about missing DXIL support. Unfortunately even if you enable dxil-spirv in vkd3d you still can't get further than the loading screen because it fails with an "[ERROR] UNKNOWN unimplemented" which is coming from dxil-spirv. I tried going deeper but this stuff (vulkan/spirv/llvm) is way over my head and I'm not even sure what I did so far is correct. Anyway I think this game needs DXIL and dxil-spirv is not enough yet.

Well, there are bad news and good news. There was a recent update to dxil-spirv and now the graphics initialization seems to be done and now the input that's broken. The game tries to load "Windows.Gaming.Input" and fails to do so. It seems like it's some kind of WinRT/UWP API but I can't find many references to this in wine, not sure what's the next step here.

Edit: found some interesting stuff in wine and made some stubs hoping it would crash later but it's the same, I think this game is now blocked by fundamental missing features from wine.

@nyz93 can you publish your changes you made so far for HZD, maybe i find some time this weekend and add all that missing WinRT/UWP stuff.

@lyra00 you have to install dxil-spirv and build this vkd3d using --with-dxil-spirv. As to how do you get this into proton I'm not 100% sure I'm using an EGS copy, regular wine 5.14-staging and an empty prefix with just vcrun2015 from winetricks.

@nyz93: OK, I think I got your changes implemented in Proton locally(with buildsystem integration). Im currently building and testing it and when its works I create a public FORK on my github account tomorrow. Then i get this WinRT/UWP stuff running. Hopefully that is the last thing missing there.

Have you tried with the vkd3d-proton fork? It has a ton of commits ahead of official vkd3d repository at winehq ever since it was forked.

Interesting vkd3d-proton fork have already dxil-spirv integrated so maybe its better to use it instead of adding it to proton directly.

Hi,

this should be integrated in TKG proton builds already.

https://github.com/Frogging-Family/wine-tkg-git/releases

Comes with the latest devel version of HansKristian & Doitsujin's vkd3d-proton standalone - https://github.com/HansKristian-Work/vkd3d

Ok, I'm working on a Proton HZD Fork, where I'm adding all those changes figured out by @nyz93(a biiiig thanks to him).
I get his vkd3d changes running, but i have troubles building dxil-spirv with the default steam runtime.

@fsyy sadly i couldn't compile TKG Proton(so many merge conflicts O_o), but the only difference to the standard Proton is that "--with-dxil-spirv" is ON as default, so it was not worth for me to following that path any longer.
I'll stick with Proton-5.0-next and cherry picking changes from Wine-5.x when I need to.

Here is a Fork i created, when you have a HZD specific solution you can add a PR.
https://github.com/lyra00/Proton
When we have HZD running we can contribute the changes to the Original Proton.

Things i did, planning to do:

• [x] Fork https://github.com/HansKristian-Work/vkd3d-proton and applying @nyz93 changes.
• [x] Fork Proton, change submodule to the Forked vkd3d-proton
• [x] Add submodule dxil-spirv
• [ ] Integrate dxil-spirv into Proton buildsystem
  > - [ ] Figure out how to get WinRT/UWP running on wine/linux
  or
  > - [ ] Write an "Windows.Gaming.Input" to "DirectInput" Wrapper
• [ ] ...

I hope i can get into the WinRT/UWP stuff next Weekend.

One thing to note with this game is it has a lot of bugs. Even in Windows I had a lot of trouble with it crashing every 10 minutes or so. I finally found out how to get it to stop doing that in Windows thanks to a reddit post, and I'm not sure which part of that really fixed it but I haven't had a crash since I followed this series of things, and thought it might be helpful to note it here

Disable Control Flow guard in Windows Defender only for HZD
Enable Large Pages
If you're on the latest windows build (v2004 or 19041.xxx), ensure you enable HAGS.
There is a program called "Intelligent Standby List Cleaner", which cleans standby memory over time based on certain parameters, get it and ensure it runs in the background.

Of these, HAGS seems to be noted to fix the crashes for others so I'm thinking that might be the most important part. Of course hopefully a patch comes out again in the mean time that makes settings like this in windows unnecessary for more of us.

Thanks to Paul's patches and continuous efforts from Hans-Kristian we're getting somewhere.
https://www.winehq.org/pipermail/wine-devel/2020-August/172365.html
https://www.winehq.org/pipermail/wine-devel/2020-August/172366.html

RADV/ACO:

AMDGPU-PRO:

This is unstable and slow on AMDGPU-PRO, and while it seems stable and perf is pretty good on RADV/ACO it's visually more glitchy (though both are). But hey, it's something.

In case someone's wondering, that was done with current head of proton-tkg, staging 5.15.2r7 (aaea13a1) based.
Edit: There are blocking issues on Nvidia currently.

Congrats lads! So this is using an on-the-fly DX12 to Vulkan (SPIR-V) converter?

@xcom169 https://github.com/HansKristian-Work/vkd3d-proton

Replying to https://github.com/ValveSoftware/Proton/issues/4125#issuecomment-680129597

Now I'm curious to see how it'll look on nvidia GPU. Nvidia drivers are less glitchy than AMDs.

@Galcian79 It's rendering similarly to AMDGPU-PRO. Floating rocks, plants, missing objects etc. but no lines all over. Not sure about the stability though.

doesn't work here, nvidia user, same error as before.

log with a fresh prefix:

https://gist.github.com/fsyy/587f85abfea2a3ca2b993afe531c561e

system specs:

https://gist.github.com/fsyy/b6b4a73f60114d0cd1c40ecef95c83c2

It didn't work for me at first, but compiling vkd3d-proton to a dll and setting a dll override to native did work. I don't know why the native vkd3d-proton from @Tk-Glitch 's PKGBUILD didn't work.

@Danacus The shared library has limited functionalities compared to the standalone dll build. Using the standalone version is needed for various d3d12 games to work at all as it allows to bypass some wine limitations.

@Tk-Glitch Oh okay, good to know. Thanks!

which limitations?

On Wed, Aug 26, 2020 at 4:40 PM Daan Vanoverloop
notifications@github.com wrote:
>

@Tk-Glitch Oh okay, good to know. Thanks!

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

@Tk-Glitch I've used your vkd3d-git PKGBUILD to install vkd3d-proton.
Then I compiled proton-tkg with _use_vkd3dlib="false" and tried HZD again but it still crashes.

I've also tried (as mentioned in https://github.com/ValveSoftware/Proton/issues/4125#issuecomment-680883714) compiling vkd3d-proton and copying the dll's inside system32 and syswow64 inside the wineprefix and adding an override in winecfg for d3d12.dll to native. That didn't change anything either.

Do I need to change something in the wineprefix of HZD? Is it possible that it has something to do with me using mesa-aco-git or amdvlk instead of vulkan-radeon?

Sidenote for the adventurous:
The game requires native d3dcompiler_47.dll (you can run cp ./Tools/ShaderCompiler/PC/10.0.18362.0/x64/d3dcompiler_47.dll . from the game's dir to "enforce" making use of it, as the game doesn't by default).

@D3SOX Apparently current head of mesa-git prevents the game from running. mesa-aco-git should be deprecated by now also. AMDVLK doesn't work with the game afaik (-pro does though, possibly only on Navi as I haven't tested Vega nor Polaris).
Native d3d12.dll should be used by default when building proton-tkg without you doing anything. You also do not require a vkd3d package installed to use the standalone d3d12.dll.

@slapin The need for a wine's side D3D12CreateVersionedRootSignatureDeserializer implementation for example, or being able to use a different dxgi such as DXVK's. Hans-Kristian and Doitsujin know better :stuck_out_tongue:

@Tk-Glitch I switched back to default mesa and replaced amdvlk with vulkan-radeon (and the lib32 packages) and copied the d3dcompiler_47.dll with your provided command. Now the game runs (I see a window from it) but it still crashes

Terminal output: https://gist.github.com/D3SOX/8e2c25b21309f3b8584ef510baca43bd

Try copying dxcompiler.dll as well.

Try copying dxcompiler.dll as well.

I did cp Tools/ShaderCompiler/PC/1.0.2595/x64/dxcompiler.dll . inside /steamapps/common/Horizon Zero Dawn but the same error persists

The dxcompiler.dll worked for me. Thank you so much! :+1:

Hi, would it be possible to sum up the necessary steps in a single newbie-friendly post ? I've been following this thread but I'm a bit out of my depth and the documentation on @lyra00 fork indicate how to build Proton from the ground up, which seems a bit overkill when Steam and Proton are already installed. I imagine I'm not the only one and that it'd be useful to a lot of people. Thanks a lot for the great work !

Hi, would it be possible to sum up the necessary steps in a single newbie-friendly post ? I've been following this thread but I'm a bit out of my depth and the documentation on @lyra00 fork indicate how to build Proton from the ground up, which seems a bit overkill when Steam and Proton are already installed. I imagine I'm not the only one and that it'd be useful to a lot of people. Thanks a lot for the great work !

You don't need to build Proton. For me, it works with TKG's latest Proton build and after copying d3dcompiler_47.dll to the Horizon Dawn executable's directory from the Tools directory inside. Besides there's still a random crashing and artifacting issues which will be addressed by the proton and vkd3d devs.

You don't need to build Proton. For me, it works with TKG's latest Proton build and after copying d3dcompiler_47.dll to the Horizon Dawn executable's directory from the Tools directory inside. Besides there's still a random crashing and artifacting issues which will be addressed by the proton and vkd3d devs.

I can't get it to run this way. Still having this issue mentioned above
I tried uninstalling amdvlk lib32-amdvlk with no success.
I verified the game files with steam and copied the 2 dll's

Launch options: PROTON_USE_WINED3D=1 RADV_PERFTEST=aco %command% (also tried without them)
Proton version: proton_tkg_5.16.r2.gf6495b29.release

Steam System Info: https://gist.github.com/D3SOX/5f08de587b6106c02a2436ba1b81bd99 (IDK if these errors under architectures.i386-linux-gnu.graphics-details.x11/vulkan.messages and architectures.x86_64-linux-gnu.graphics-details.x11/vulkan.messages are a problem)

I get this warning when starting the game:

Clicking on yes gives me

steam Terminal output: https://gist.github.com/D3SOX/6abf189507fa917a3f9834f8bf7104f4

@D3SOX Have you tried building vkd3d-proton and copying the resulting d3d12.dll to the game's folder? Using PROTON_USE_WINED3D is also not required. You might also want to build mesa-git or mesa-tkg (or add a user repository like chaotic-aur and install from there). Note that the game is currently not very playable.

@Danacus Thanks. I removed PROTON_USE_WINED3D, compiled mesa-git and replaced mesa with it. It removed a bunch of other packages I previously installed

I also copied the d3d12.dll from vkd3d-proton/build.64/libs/d3d12/ to the executable's directory.

Same problem.
New Steam System Info https://gist.github.com/D3SOX/639d889140f4c3393b215b495b5dcc89
New steam terminal output: https://gist.github.com/D3SOX/9cebd1c65746d39166345514dee3729d

Thanks @intersectRaven , not working at the moment, with the message

wine: failed to load /home/USER/.local/share/lutris/runtime/steam/compatibilitytools.d/proton_tkg_5.16.r2.gf6495b29.release/dist/bin/../lib/wine/ntdll.dll.so: /lib/i386-linux-gnu/libc.so.6: version GLIBC_2.32 not found (required by /home/USER/.local/share/lutris/runtime/steam/compatibilitytools.d/proton_tkg_5.16.r2.gf6495b29.release/dist/bin/../lib/wine/ntdll.dll.so)

Looks like the latest version libc for Ubuntu is 2.31, does that mean I'm stuck until there's a libc6 2.32 available or can I just go and change the version number wherever its referenced ? (no idea how I would go about doing that though).

Also, it seems all the instructions in this thread are geared towards Archlinux, I don't suppose there's an Ubuntu equivalent for everything that's being used here ? (like building mesa-git for exemple)

If you can some how find version of glibc 2.32 on Ubuntu it should start then.

On Manjaro switching to the unstable branch will then show it in the package manager.

Thanks @mixalis1987 , I downloaded the package for glibc 2.32 and tried to install manually but that didn't go very well. After reinstalling Ubuntu twice I figure it's best if I wait for the official release or a Proton update, whichever comes first.

This is how it looks like on Nvidia,

running on 450.56.06

Plants and Rocks are floating, you cannot progress to that point, you have to hide yourself in high grass that doesnt exist/is not rendered at all

Some of the disappearing rock & grass issues are fixed in this PR: https://github.com/HansKristian-Work/vkd3d-proton/pull/263
Tested on Nvidia RTX 2070

Unfortunately, some things still float and \ or appear in the wrong places.

But it's not even nearly as bad as it was.

The game isn't playable yet.

No issue with Mesa-git + Proton-5.9-GE-6

@Odelpasso where you get Proton-5.9-GE-6 ?
Here https://github.com/GloriousEggroll/proton-ge-custom/releases only Proton-5.9-GE-5-ST are available.

It was a google link available on the VKx discord.

wine-tkg works as well if you follow the steps mentioned in this thread. A very recent commit to Mesa must have fixed the graphical issues.

Edit: In case anyone wants to know, these two lines seem to have fixed all these graphical glitches with Mesa RADV.

@Odelpasso Where?

@Danacus I can't get wine-tkg to build on arch, what steps?

@Odelpasso Where?

@Danacus I can't get wine-tkg to build on arch, what steps?

Proton (posted by GloriousEggroll on the discord): https://drive.google.com/file/d/1OLp74WlIKSnOI6PphiiXwIySLpwOFj5j/view

Wine-tkg:

git clone https://github.com/Frogging-Family/wine-tkg-git.git
cd wine-tkg/wine-tkg-git
makepkg -si

@D3SOX

Proton (posted by GloriousEggroll on the discord)

Oh I see it now, discord search was being.. really odd.

File is in owners trash? Oof. Managed to download it though.

Wine-tkg:

Yeah, thats what I did, wine-tkg does not build. An error in build() and it stops, or using the script it just silently quits.

@DianaNites

Wine-tkg:

Yeah, thats what I did, wine-tkg does not build. An error in build() and it stops, or using the script it just silently quits.

You can add chaotic-aur for prebuilt packages if you like, it's easier than building. I had some issue building wine-tkg myself too.

@D3SOX Hmmm, the Google Drive link seems to be down. It tells me the file got trashed. Can anyone ask GloriousEggroll to post it officially? Though, I imagine he has his reasons not to do that just yet.

Also, I've been playing the game rather extensively, and it seems to randomly freeze, even though I too managed to get it to run without any noticeable graphical issues after joggling around with native vs DXVK dxgi.dll and forcing shaders to recompile.
Sometimes if I have to kill the process because of such freeze, the floating objects thing reappears. Forcing the game to recompile it's shader cache either partly (by messing around with dxgi.dll versions) or entirely (by deleting PSOCache.bin or by overwriting it with a backup) fixes the floating object issue... Well, until the game freezes again at random and corrupts it's cache in the process. Let's hope this too gets fixed. I've been having similar freezing issues in other games that run with VKD3D.

@RoyShapiro You can download with https://gdbypass.host/
But he said

because i made another build earlier today which i was testing this morning
i did not intend for that build to be public, i posted it here for a few people to test with radv yesterday

I'm still trying to get it to launch at all

It starts! It works! So far.. Wait and see!

@DianaNites I dont get it. Do we just need Proton.5.9-GE-6-ST to start the game? No extra DLL stuff or anything?

@mixalis1987

I did the dll stuff mentioned elsewhere in the thread, but didn't test without it, and haven't gotten in game yet due to the insane RAM requirements and other open programs. Once I close the other programs and free some RAM up I'll see how it really works.

@DianaNites Ah thanks. i'll be having a look at that soon.

@DianaNites I dont get it. Do we just need Proton.5.9-GE-6-ST to start the game? No extra DLL stuff or anything?

Without run cp ./Tools/ShaderCompiler/PC/10.0.18362.0/x64/d3dcompiler_47.dll . from the game's dir the game is not working even with Proton-5.9-GE-6

It unfortunately always crashes for me after a short time in the intro or menu (radv & amdvlk-pro, proton-tkg). :(

I got it working! Built Proton-tkg, used the dlls from the tools folder, mesa-git and thats it! Using AMD hardware though, apparently does better than NVIDIA.

Some minor, infrequent visual glitches, a few crashes(but those could be from the game itself?), but by and large IT WORKS! Be prepared to relaunch the game fairly often, though that may simply be the games bugs. A lot of progress has been made to get this working and, IT DOES!

edit:

it keeps crashing at one specific part, soon after the above screenshots, the room with all the dead people in beds. Something from proton, or something from the game?

Amazingly, I managed to fix the crash, using this tip from PCGamingWiki

The game seems to be working amazingly well and I got through the child Aloy part, managed to save at the fire, then the game promptly crashed again. Still, that was a good hour, hour and a half? It'll probably work fine after I restart again, the hex editing seems to have, somehow, fixed that persistent crash.

I should note that the loading screen for after child aloy took an incredibly long time, but did finish. I thought it was hung.

Be warned, however, that after some digging the instructions hex-edited out are possibly intentional to trigger a crash. See here, for example.

edit:

Worked fine after restarting, got another hour or two in before it crashed again. Still hard to tell if the crash is from proton or the game, though.

This was on the new patch 1.04, proton-tkg git master, mesa-git master, both of which did have new commits since yesterday.

edit: also remember to still use the dlls from the tools folder. Copy them over anew, idk if they did change in the patch but they could have

Patch 1.04 is out since 15 min, it aims to fix even more crashes:
https://store.steampowered.com/newshub/app/1151640/view/2905340212273715393

Crash Fixes:
Fixed a crash that could occur when users would create a new game and their save game slots were full
Fixed a startup crash related to temp folder
Fixed an AI crash that could occur during combat
Fixed an AI crash in the EventMessageHandler
Fixed a crash related to WorldData sampling (the callstack would end in WorldMapData::SampleAtPixel)
Fixed a crash when users would instantly back out when changing sliders in the Settings menu
Fixed a crash that would occur when having the “Greetings” option open in photo mode and then exiting
Potential fix for memory corruption in AI routines which could lead to crashes
Potential fix for a GPU hang caused by a threading issue
Fixed a mismatch that would occur on Shader Model 6.0 and 6.1 hardware which could lead to a crash

The game crashes at launch for since the last patch ... Worked correctly with GE-6 + patch 1.03..

Still works for me with proton-tkg! Try switching to that @Odelpasso ?

Patch hasn't helped me, still crashes in menu/intro vid with proton-tkg or -ge. In wine-tkg (with native d3d12.dll vkd3d) it crashes at the very start. Hitman 2 D3D12 works in both cases.

Today's commits to https://github.com/HansKristian-Work/vkd3d-proton/commits/master are causing the game to crash for me (without displaying anything, but, apparently, right prior to that (the game takes some time before crashing). Reverting d3d12.dll to yesterday's version "fixes" the problem. Beware.

If someone else has the same problem, please file an issue with vkd3d (I want to make sure it's not just me first).

Tested again using Proton-GE 5 and 6 with recent updates in VKD3D-Proton and latest VKD3D-Proton crashes so maybe that's your problem @aufkrawall and @RoyShapiro. After bisecting, I found that commits after 3002d52ed404cdd65d2c57193fe9bdbdf683161c are causing the crashes so just perform a git reset to that commit then recompile and copy it to your HZD directory. So far floaty things haven't appeared after shader recompilation on NVidia. Still janky though even on Favor Performance.

@intersectRaven

After bisecting, I found that commits after 3002d52ed404cdd65d2c57193fe9bdbdf683161c are causing the crashes

So NOT just my problem. Thanks for the hint, though, because it means that it's not ALL of today's commits, just after that one.
Still, I think we should let Hans-Kristian know.

They seem to be adding a new feature so it might be buggy for awhile. Don't know if they should be made aware or if they already are since it might be that what they're adding is still in development. Forgot to mention that on GE-5 it still crashes after reaching 100% of the startup optimization. GE-6 is fine. FYI @aufkrawall since you might be using GE-5.

@intersectRaven I see. Still, I've tested the same dll with Control and Resident Evil 2, GE-6, no crash. Appears to affect HZD more specifically than others. I hope they'll notice.

Update: Already noticed, just as you've predicted. https://github.com/HansKristian-Work/vkd3d-proton/commit/cea17b2440de66a9c1c1978ff297e59abddaa4d1 fixed the crashing for me.

This new commit might fix it, the function its in is used by this HZD commit.

Recompiling and testing now

edit:

Can indeed confirm it still works great!

@DianaNites It does, I've just tested.

No avail for me, tried all the suggested and other things (esync/fsync off etc.). :(
Can you guys switch to fullscreen mode without crashing? Crashes instantly for me.

>>> Adding process 2454 for game ID 1151640
Allocator AssetMemory: Creating new region at [0x00000001c0000000:0x0000000200000000]
Installing breakpad exception handler for appid(gameoverlayui)/version(20200903211816)
Installing breakpad exception handler for appid(gameoverlayui)/version(1.0)
Installing breakpad exception handler for appid(gameoverlayui)/version(1.0)
[0908/184711.659545:INFO:crash_reporting.cc(270)] Crash reporting enabled for process: renderer
Installing breakpad exception handler for appid(gameoverlayui)/version(1.0)
[ERROR]: There is no candidate for ladder merging.
[ERROR]: There is no candidate for ladder merging.
RecordSteamInterfaceCreation (PID 2391): SteamUtils009 / Utils
RecordSteamInterfaceCreation (PID 2391): SteamController007 / Controller
RecordSteamInterfaceCreation (PID 2391): SteamInput001 / Controller
movies:mono/MQ1_Intro_at_the_Hovel.bk2 took 106.51017754 ms to start
movies:mono/mq1_intro_at_the_hovel.bk2 took 910.31704427 ms to open
 took 0.00372095 ms to release
pid 2325 != 2324, skipping destruction (fork without exec?)
Game removed: AppID 1151640 "", ProcID 2391 
Game 1151640 created interface STEAMUSERSTATS_INTERFACE_VERSION011 / 
Game 1151640 created interface SteamController007 / Controller
Game 1151640 created interface SteamFriends017 / 
Game 1151640 created interface SteamInput001 / 
Game 1151640 created interface SteamInput001 / Controller
Game 1151640 created interface SteamUser020 / 
Game 1151640 created interface SteamUser020 / User
Game 1151640 created interface SteamUtils009 / 
Game 1151640 created interface SteamUtils009 / Utils
Game 1151640 method call count for IClientUser::BLoggedOn : 1
Game 1151640 method call count for IClientUser::GetSteamID : 2
Game 1151640 method call count for IClientFriends::GetPersonaName : 1
Game 1151640 method call count for IClientUtils::GetAppID : 14
Game 1151640 method call count for IClientUtils::RecordSteamInterfaceCreation : 10
Game 1151640 method call count for IClientUtils::GetSteamUILanguage : 1
Game 1151640 method call count for IClientUserStats::RequestCurrentStats : 1
Game 1151640 method call count for IClientUserStats::GetAchievement : 79
Game 1151640 method call count for IClientUserStats::GetAchievementDisplayAttribute : 158
Uploaded AppInterfaceStats to Steam
Exiting app 1151640
No cached sticky mapping in ActivateActionSet.

Can you guys switch to fullscreen mode without crashing? Crashes instantly for me.

@aufkrawall Yeah changing fullscreen modes an instant crash for me too, but it starts in borderless fullscreen mode anyway so I don't worry too much.

You'll also want to use PROTON_LOG=1 %command% in launch options to get a decent log, it'll be in put your home directory.

Other than that the game works great for me now, and I'm progressing nicely. A crash, maybe every hour or so? Annoying, and with the inability to save everywhere anxiety inducing, but hard to tell if its from the game or from proton.

I did notice an extremely bizarre issue when running the benchmark, though. Even though I had plenty of free RAM, it was allocating to swap like crazy, making benchmark performance even lower than it already is.

It seemed to stop doing that after a reboot, though, going back to the "normal" 12 FPS reported by the benchmark. Actual ingame performance is better than that, though.

Can you guys share your Wine build?

Hint: Turn off V-Sync in-game, it causes low-performance issues on CPU and
GPU even on native Windows.
Try to enable it via. Application Profile in your Graphic Driver.
Cannot tell you how, i'm using Nvidia, you are using AMD.

Am Di., 8. Sept. 2020 um 21:07 Uhr schrieb Diana notifications@github.com:

Can you guys switch to fullscreen mode without crashing? Crashes instantly
for me.

@aufkrawall https://github.com/aufkrawall Yeah changing fullscreen
modes an instant crash for me too, but it starts in borderless fullscreen
mode anyway so I don't worry too much.

You'll also want to use PROTON_LOG=1 %command% in launch options to get a
decent log, it'll be in put your home directory.

Other than that the game works great for me now, and I'm progressing
nicely. A crash, maybe every hour or so? Annoying, and with the inability
to save everywhere anxiety inducing, but hard to tell if its from the game
or from proton.

I did notice an extremely bizarre issue when running the benchmark,
though. Even though I had plenty of free RAM, it was allocating to swap
like crazy, making benchmark performance even lower than it already is.
Screenshots

[image: Screenshot_20200908_132008]
https://user-images.githubusercontent.com/5275194/92517372-8d14a780-f1e4-11ea-908f-85e3bfcc94c4.png
[image: Screenshot_20200908_132338]
https://user-images.githubusercontent.com/5275194/92517377-8e45d480-f1e4-11ea-96c8-d6f9129ca031.png
[image: Screenshot_20200908_131942]
https://user-images.githubusercontent.com/5275194/92517380-8f770180-f1e4-11ea-8618-f30855c8fc62.png

It seemed to stop doing that after a reboot, though, going back to the
"normal" 12 FPS reported by the benchmark. Actual ingame performance is
better than that, though.
Screenshot

[image: Screenshot_20200908_134459]
https://user-images.githubusercontent.com/5275194/92517492-bfbea000-f1e4-11ea-94c1-bf6f08df6cbf.png

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/4125#issuecomment-689077992,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJWSJOPVTOKHFPVXYJLERRDSEZ6HPANCNFSM4PXXJIQA
.

There are several ways to enable V-Sync:

• TearFree option in Xorg configuration
• mangohud can force V-Sync on games
• If you don't mind some latency, a compositor can add V-Sync too

I don’t understand what’s wrong for me ...
I’m the only one with this issue.

@Odelpasso try outputting proton logs like what @DianaNites did so that someone could examine it and maybe point you in the right direction.

steam-1151640.zip
Attached is my proton log for crashing while loading or starting a new game under the unofficial GE-6-ST. The game does load to menu and the logos are displayed, but nothing past that works.

I tried latest release of TKG which was 5.16+ if I recall, and had same result there with game crashing about 2/3-3/4 through loading. I tried compiling tkg myself using script but I get an error during the hotfix patching, mentions 16 out of 76 hunks FAILED -- saving rejects to file patches/patchinstall.sh.rej
Unfortunately I'm not adept enough to navigate getting past that point without a guide and I didn't have time to find if there was one somewhere.

Steps taken so far to reach my log
1) Moved dxcompiler and d3dcompiler_47 into folder with the application exe
2) Used protontricks to set d3d12.dll to native (I didn't do this until after trying without and I got same result both times so I don't know if this made any difference in either direction)

@Odelpasso try outputting proton logs like what @DianaNites did so that someone could examine it and maybe point you in the right direction.

This is my log for the game ....
steam-1151640.log

On Pascal (GTX 1070) using the same proton-tkg-5.16.r12 upgrading Nvidia drivers from 450.56.06 to 450.56.11 has fixed the floating rocks and long grass not rendering thus making it possible to finish the tutorial. Played for an hour without crashing and only stopped due to being unable to get a controller to work.

I managed to run like it should. No artifacts. The solution is the same I applied here for Battlefield V.

My system:
GPU: AMD RX580 8GB
CPU: Intel i7 4770 (Haswell)
OS: Arch Linux
Kernel: 5.8.7-13-tkg-pds
Wine: Frogging-Family/wine-tkg-git

Compile the latest vkd3d-proton d3d12.dll.

@rizzini I did WINEPREFIX=/run/media/nico/DATA_SSD/SteamWindowsLib/steamapps/compatdata/1151640/pfx /usr/share/steam/compatibilitytools.d/proton_tkg_makepkg/dist/bin/winecfg and added d3d12 as Native (Windows)
as in the issue you mentioned.

I'm using
GPU: AMD RX480 8GB
CPU: AMD Ryzen 9 3900X (Zen2)
OS: Arch Linux
Kernel 5.8.8-14-tkg-upds (with fsync)

I also compiled proton-tkg-git (version is 5.16.r19.g88e6b6c6-1) and using it in Steam for the game
As launch arguments I use PROTON_LOG=1 VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/radeon_icd.x86_64.json:usr/share/vulkan/icd.d/radeon_icd.i686.json %command%
(to force it to use RADV since I also have AMDVLK installed)

I'm one step further than ever before because I now see the loading indicator in the bottom left and the custom mouse cursor after I renamed drive_c/users/steamuser/My Documents/Horizon Zero Dawn but now I get this error:

After renaming it back to Horizon Zero Dawn and restarting it, it did some weird stuff in the Saved Game folder and also removed the files inside the save games.

It previously looked like this:

Steam log from home folder:
steam-1151640.log

@D3SOX, you did right, but looking at your log, seems like Proton is still using the d3d12.dll from Horizon Zero Down executable folder. Try to delete it and keep only the one at your 1151640/pfx/drive_c/windows/system32/ folder.

Line 2312 of your log:

2111.427:00bc:00c0:trace:loaddll:load_native_dll Loaded L"Z:\\run\\media\\nico\\DATA_SSD\\SteamWindowsLib\\steamapps\\common\\Horizon Zero Dawn\\d3d12.dll" at 0x6f7c0000: native

Here is mine d3d12.dll. Just in case.

Edit: I never saw those save game errors. Try to backup and delete, just for troubleshooting.

@rizzini I cloned vkd3d-proton and built it “The simple way” so I think my DLLs should be fine
I copied the x64 build into the executable's folder and also replaced it inside SysWOW64.
In System32 I replaced d3d12.dll with my x86 build. So I don't think it's a problem that it loads it from there since it's the same DLL file? Or do I have to copy the x64 build into System32?

For the save games: The problem is that I tried to delete them but then I get the save game error. Without deleting them it only crashes. (I think it might have something to with these files, since I've played the game a bit under Windows)

Nevertheless, I deleted it from the executables dir and it still crashes. Log:
steam-1151640.log

I use mesa-tkg-git version 20.3.0_devel.128249.5e9e4573835-1. Might also be a problem. Which mesa version do you use?

@D3SOX

On a 64-bit computer, 64-bit programs store their files in C:\Program Files, and the system-wide C:\WindowsSystem32 folder contains 64-bit libraries. 32-bit programs store their files in C:\Program Files (x86), and the system-wide folder is C:\WindowsSysWOW64.
Source

Thus, you have to rather counter-intuitively put x64 version to System32, and x86 version to SysWOW64. Also, I don't think Horizon needs x86 version at all (but it's probably good to have it). That said, usually, when the wrong version is used, the game shouldn't work at all (with a different error), not argue about saved games. So I think there might be another problem besides that.

@RoyShapiro Oh, thanks for that clarification. I have simply assumed system32 = 32 bit libraries.
I've swapped them. Still crashing. Log: steam-1151640.log

@D3SOX
Warning: This may help you not. Please, make a backup of the wine (proton) prefix first!
If by crashing you mean actual crashing, and not the save game issue, then I know, it's a long shot, and I'm not sure at all if that will help you any, but...
From the log, I can see that you're using a built in dxgi.dll. Now, that _should_ be totally fine, but I have found that sometimes it works better with the one from DXVK. Disregard the old warning that they don't work together, it has been fixed some time ago. So, probably, you can try installing DXVK (with dxgi) into the same prefix (obviously make a backup of the prefix first, so you don't have to redo anything should it not help), and then set dxgi.dll to native to (if DXVK doesn't set it automatically). It's best to use the latest DXVK version for best compatibility.
And if it doesn't work, just restore your prefix from backup. Again, it _should_ not be necessary and you're doing it on your own risk.
Also, check if the game is updated to the latest version, I've heard the old versions had a save game issue when it couldn't find the saved games path due to weird characters in it. Supposedly non-latin, but who knows what syscalls the game might have used.

@RoyShapiro I compiled DXVK from master and did WINEPREFIX=/run/media/nico/DATA_SSD/SteamWindowsLib/steamapps/compatdata/1151640/pfx ./setup_dxvk.sh install
Opened winecfg in the prefix again and added dxgi.dll as Native (Windows)
Log: proton-dxvk-steam-1151640.log

But after I started the game it noticed it replacing the DLLs with symlinks to the DLLs in /usr/share/steam/compatibilitytools.d/proton_tkg_makepkg/dist/lib64/wine/dxvk/, so I replaced the DDLs inside there with my x64 build and started it again.
Still crashing. Log: steam-1151640.log

How can I check if the game is up to date? I think Steam keeps it automatically up to date and there is no update under Downloads.

@D3SOX It should be automatically up to date if Steam doesn't have any new updates available, unless you've disabled the updates on purpose, i.e. to save bandwidth. Some people do that, and there was a saved games bug in the previous versions, so when going by the scraps like that, it's best to rule such things out.

Yep, the log now shows a native dxgi.dll used.

This is strange. Disregard the previous version of this post, I had some things confused. RADV and AMDVLK, which one is currently used? The Arch Wiki suggests you can switch between the two. Source. Maybe you can try the other one.

@RoyShapiro
I think I'm up to date:

I added the VK_ICD_FILENAMES env variable because @Tk-Glitch said it won't work with AMDVLK. But I don't think it's necessary since when I remove it the log also states AMD RADV POLARIS10 (ACO) and nothing about amdvlk
Current Steam System Info: https://gist.github.com/D3SOX/130e718b1f2df4a17273ff31f1816de9
I don't understand why so many folks got it running and it doesn't even start for me.

@D3SOX This is strange indeed. Have you tried using unofficial GloriousEggroll's Proton version 6 suggested earlier in this thread instead of TKG's? I've heard it works for some people. Yes, it requires the aforementioned GD trick to download, but last I checked it still worked.
We're still in the uncharted territory with all these fixes. Even if you do get the game to work, it tends to freeze-up every now and then, for me it's about every 10-30 minutes, some other folks have reported being able to play up to an hour. But it's still a "campfire-to-campfire fingers crossed" experience.

@D3SOX @RoyShapiro

i had the game running, by just using tkg's proton, and copying d3dcompiler_47.dll to the games root dir, then i decided to start over with the pfx, deleted it and tried to start it again.

Effects: i had the same save game error, fixed by manually creating that directory "Horizon Zero Dawn/Saved Game", but since then it keeps crashing seeing the black loading screen.

@D3SOX

did you try ge-6-st proton already?

you should try it, my game is working since i use it.

@fsyy Did you have to copy any DLL files or just use GE-6-ST as is?

i just use ge-6-st and did copy d3dcompiler_47.dll from ~/.steam/steam/steamapps/common/Horizon Zero Dawn/Tools/ShaderCompiler/PC/10.0.18362.0/x64/ to ~/.steam/steam/steamapps/common/Horizon Zero Dawn.

I didn't copy d3d12.dll to the game dir and also didn't set it as a native library in winecfg.

I'm using an nvidia card (latest beta driver 450.56.11) and still have floating rocks and trees, also the game crashes a lot here (10 - 30 mins), but it starts and is playable, sort of.

@fsyy Ah, thanks for clearing that up. All this stuff with the d3d12 dll is kinda confusing.

@fsyy Yes I tried GE-6-ST and I didn't even start. Probably should test again with a clean wineprefix

if it doesn't run with a fresh prefix, maybe post another proton log here.

@fsyy

you wrote about DXVK in your post above, that doesn't matter, as Horizon Zero Dawn is DX12 only, so you need vkd3d-proton. But that should be already set up in those proton builds.

I've just tried it because @RoyShapiro suggested it

if it doesn't run with a fresh prefix, maybe post another proton log here.

Yes, I'll do it later sometime

@fsyy @D3SOX Just to clarify: I've suggested trying running in a prefix with DXVK installed because while it is true that the game itself doesn't use anything below DX12, the VKD3D-Proton itself does make use of functions implemented in a library called dxgi.dll, which is also used & provided by DXVK. In some use cases the version provided by DXVK may offer more compatibility then the one bundled with Wine \ Proton. For instance, the replacement of this exact library with DXVK's version is exactly what solved the floating rocks problem for me. So, while we do not know what exactly is causing @D3SOX 's problem with the game, there was a decent chance that that could've had a positive effect.

@RoyShapiro

what version of proton (wine) do you use?

@fsyy Currently, Proton-5.9-GE-6-ST. That said, I build d3d12.dll from source, so I don't use the one that comes with Proton-GE, and, as mentioned above, I also have DXVK 1.7.1 manually installed.

@RoyShapiro how we do all That? I already have GE 6 but the custom d3d12 how we get?

@mixalis1987 It's compiled from vkd3d-proton sources.

@intersectRaven Oh right thanks. And that we put in systemc32 and set to native in winecfg..right?

What performance seems to be expected. I can "Play" with GE 6 and d3d12.dll linked previously in the thread and it has been stable however in medium gfx im getting 25fps with Ryz 5 1600 & GTX-1080 and 450.66 drivers (pop_os)

I'd also like to ask if the animations you all experience seem to be on "slow motion" or not? It's playable on my machine as well but that's the only gripe I have but it may be expected since I experienced this before as well with Fallen Jedi before it was fixed.

@intersectRaven Not sure, kind-of. Only some things, grass hair etc. however, i think it is an AA thing as i got the same in ghost-recon wild lands with some AA modes

@botrosco Thanks. I enabled FPS in Steam overlay now and I get 20 - 30fps on my machine as well. I'm playing on a 9750H & RTX2070 so it may be an optimization thing that needs to be addressed with Proton/VKD3D.

@intersectRaven Ah, ok. Good to know its not just me.

Got it to work! Game freeze at cutscene when she becomes an adult and walks out of the hut. Can't get past that.

[System]
OS: Manjaro Linux 20.1 Mikah
Arch: x86_64
Kernel: 5.8.6-1-MANJARO
Desktop: XFCE
Display Server: x11

[CPU]
Vendor: AuthenticAMD
Model: AMD Ryzen 9 3900X 12-Core Processor
Physical cores: 12
Logical cores: 24

[Memory]
RAM: 31.4 GB
Swap: 0.0 GB

[Graphics]
Vendor: NVIDIA Corporation
OpenGL Renderer: GeForce GTX 1080 Ti/PCIe/SSE2
OpenGL Version: 4.6.0 NVIDIA 440.100
OpenGL Core: 4.6.0 NVIDIA 440.100
OpenGL ES: OpenGL ES 3.2 NVIDIA 440.100
Vulkan: Supported

Needed to update nvidia driver to get past the hut when she is an adult. Now I can get past that. Don't know what is with the white borders.

I didn't get that far in the game yet with the slowness and such, but I am using NVIDIA and I too can confirm the same type of non-fullscreen borderless problem as well @mixalis1987 I thought I was the only one with this particular issue. It's borderless, but it's slightly offset exactly like your picture you attached above. Also, as mentioned above, it crashes when I switch to fullscreen. I too am running Manjaro 20 xfce. I haven't had time to mess with it as of late though. Just wanted to say thanks to all the folks smarter than me who are working on this. You all rock!

Got to say, once the random crashes are fixed, I could actually see myself playing all the way till the end. Even with the white border.
@77boaz what are your graphic settings? The game was automatically set to ultimate when I first started and was playing in "slow motion" changing settings to "original" sorted it out for me.

So I dual boot Windows, just mainly for comparison Linux/Windows in Steam. In Linux I can run the game on Original with not too shabby of performance / frame dropping, although I currently broke the game again as of typing this because I was messing with proton-tkg builds, proton-ge builds and stuff... On Windows 10 I can run it at maximum with 1080p... I don't have a 4K monitor as of yet :) The Windows version is way better for the time being but the progress made on Linux in such a short time is epic! Again, shouts out to the folks working it! I will wait to play it in all of it's grandeur on Linux later all the way through :) Patience is a virtue :)

@mixalis1987 I'm already on Original but it's still going on "slow motion" for me. I'm also looking forward to when the random crashes are fixed. After looking into it, it seems to be the same issue with "RE2: VkBufferView creation can overflow available memory #266" in VKD3D's issues. Hopefully it can be addressed soon.

I've managed to revert the hashmap commits and it seems to be freeing the memory correctly now. If anyone wants to try on their own compiled VKD3D-Proton sources, the commits to revert are:

daf9f5c69fb69ab87672e61ee6c71ec2fb16d218
5a9d132b20de854f751d4c606c9546e6c34f5c4c
73d578e5abe5658bd8f9cca330a2f7a8f48e0465
684c658e22930f3f77488f77afb590d6889920a4

Revert them in that specific order so that it'll revert cleanly. So far, this is the longest play I had which hasn't hung on me before I grew tired. This is not by any means a fix. At most it's a method to address issue #266 without rewriting the hash map implementation if you want to play without crashing although even that is not assured.

@intersectRaven I don't understand what we are ment to do with the commits. Just build vkd3d again?

@mixalis1987 Just revert those using git revert <_commit guid_> and then the usual build vkd3d, copy, etc.

@intersectRaven So

git revert -n (commit number you posted) ?

@mixalis1987 Yup.

But just not revert the bad commit 51d2a3bad2dacc40653fd8b9d43dea7ba0109e65 ?

@intersectRaven Finally got to testing your suggestion of reverting commits on HZD specifically. Can confirm that it "works". Been playing for a solid three hours and fifteen minutes straight, caught a freeze in the end. Also caught one after and around forty minutes in and alt-tabbing. Seems without the hashmap the resources the game creates get lost after a long while. And with it they just overflow creating a memory leak. Same situation with RE2, except there it seemingly also causes the framerate to decay over time. So as you said, this is by no means a fix, the hashmap was there for a reason. Yet, it's a pretty good temporary band-aid for making HZD playable until a better solution comes forth, after all playing a game for more or less three hours straight instead of just 10 minutes is usually more than people are willing to put into one playing session anyway. Yet, I hope the VKD3D-Proton team comes up with a proper hashmap implementation refactor soon.

@Odelpasso I just reverted what @intersectRaven posted. 4 commits.

Hello @RoyShapiro,
Can you post your dll? Thanks :)

@intersectRaven Finally got to testing your suggestion of reverting commits on HZD specifically. Can confirm that it "works". Been playing for a solid three hours and fifteen minutes straight, caught a freeze in the end. Also caught one after and around forty minutes in and alt-tabbing. Seems without the hashmap the resources the game creates get lost after a long while. And with it they just overflow creating a memory leak. Same situation with RE2, except there it seemingly also causes the framerate to decay over time. So as you said, this is by no means a fix, the hashmap was there for a reason. Yet, it's a pretty good temporary band-aid for making HZD playable until a better solution comes forth, after all playing a game for more or less three hours straight instead of just 10 minutes is usually more than people are willing to put into one playing session anyway. Yet, I hope the VKD3D-Proton team comes up with a proper hashmap implementation refactor soon.

Yeah. It's just tricky since the hashmap was implemented so as to better utilize memory for reuse. Problem is HZD seems to not like to reuse things. LOL. There's no easy fix to this so this "band-aid" is just that...a band-aid for playing HZD for a few hours without crashing and only for this game. I'm thinking that the solution to this would be more on Guerrila's end rather than VKD3D since it might be an optimization problem with their engine instantiating so many non-reusable objects. Of course, if the VKD3D devs can find another solution then that would also be great since more non-optimized games will benefit.

@intersectRaven I'm afraid Guerilla's hands are already tied up as it is fixing a "bad" port, and while this may in some way be related to some of the crashes they've got on Windows, I doubt they will look into it any time soon. Also, several people here, me included, seem to have the same problem with other games such as RE2, which almost certainly won't get patched, as it is already mature, and the problem seems niche. VKD3D however, or rather VKD3D-Proton specifically was created with the goal of, quoting them, "Performance and compatibility are important targets". So it seems like something they will have to tackle sooner or later. But that's academic. Unfortunately I'm not well versed in the area of Graphics API's or I would gladly lend a hand.

@intersectRaven I'm afraid Guerilla's hands are already tied up as it is fixing a "bad" port, and while this may in some way be related to some of the crashes they've got on Windows, I doubt they will look into it any time soon. Also, several people here, me included, seem to have the same problem with other games such as RE2, which almost certainly won't get patched, as it is already mature, and the problem seems niche. VKD3D however, or rather VKD3D-Proton specifically was created with the goal of, quoting them, "Performance and compatibility are important targets". So it seems like something they will have to tackle sooner or later. But that's academic. Unfortunately I'm not well versed in the area of Graphics API's or I would gladly lend a hand.

Same here. I could only do a cursory investigation of the problem based on the issue that was on VKD3D's issue page. Seems like before the hashmap, the memory would get released immediately after it's used? The hashmap avoids the penalty of instantiation of a new object by having memory already preallocated or something. That's why I had the "vkd3d: Do not ref-count views in descriptor updates." reverted since it seems that one got rid of the view destruction code since hashmaps wouldn't need it. Anyways, I don't know enough to tackle how to replace that so this is just my dirty approach to at least being able to play longer. I'm sure they're working on this behind the scenes since they've already identified it in the issue in the first place which indicates that they are aware of the problem.

@intersectRaven I've taken a look at the code that introduced the hashmap, and it seems like the previous code just instantiated "loose" objects, that is, creating a pointer and then "forgetting" it as the function terminates. As far as I remember this action doesn't exactly free up the memory, since the object still exists, but "hangs loose". Eventually the system's garbage collection routines pick the scent of it, and if nothing references it, mark the memory as unused. (The d3d12_desc_destroy that's edited out in many places in "Do not ref-count views" is a function called on a struct, it seems, not an object destructor, so it needs to be deliberaterly called by the api.) I may be wrong, it's been a while since I wrote anything in C. Using a hashmap allows VKD3D to keep track of all the objects it created, so none of them are loose, hence none are deleted (unless marked for deletion in some way). Thus, memory is never freed, since games like HZD or RE2 do not seem to bother issuing such instructions (apparently the real D3D12 has it's own garbage collection routines, and that's why RE2 doesn't hang up on Windows). And eventually it clogs up. So, if my loose interpretation is somehow right, the "band-aid" works because the loose non-resuseable objects aren't "tied" to anything like with hashmap, and hashmap just needs to be aware of what can be safely thrown away and do so to work correctly. Again, I may be fundamentally wrong.

@mozo78

Hello @RoyShapiro,
Can you post your dll? Thanks :)

Sorry, but I am not sure it is technically legal to post WIP binaries of someone else's projects.

@RoyShapiro,
VKD3D is open source so I think it's legal :)

I think i'm doing something wrong. I'm still getting the crashes often 20-30 minutes
I revert the commits with git revert. Then did

./package-release.sh master /your/target/directory --no-package

To get the dll. Is that right?

@mixalis1987 Did the revert actually work for you? Or did it say something about "error cannot revert commit" in the terminal? You may need to run "git stash" command before any reverting. If this is the case, be ready that on successful revert VIM (a text editor) will pop up on each of the four revert actions, asking you to state a revert reason. If you are not yet familiar with VIM, when it pops up (if you don't know what it looks like, it's a terminal program that looks like some colored code on your screen, so do not expect an actual window) just press esc, write ":x" and then press enter to make it go away, it should appear four times (once for each commit).

Edit: If you default text editor is NANO, and not VIM, you just press Ctrl+X and answer No if it prompts you to save a file.

@RoyShapiro
Ok. this happened.

git revert 5a9d132b20de854f751d4c606c9546e6c34f5c4c
Auto-merging libs/vkd3d/vkd3d_private.h
Auto-merging libs/vkd3d/resource.c
[master e88011a] Revert "vkd3d: Get rid of descriptor spinlocks."
2 files changed, 15 insertions(+)

And the same for the rest of the commits just different files where changed obviously :) NANO showed up and i pressed ctrl+x and exited, but didnt ask me to save anything. Hope thats right.
Do I just run "./package-release.sh master /your/target/directory --no-package" now?

@mixalis1987 If it worked all four times, then yes. Just don't forget that target folder shouldn't yet exist, or it may complain that it's already built, and you want it to build it anew.

@RoyShapiro Yea i always delete the old folder. Thanks.

@mixalis1987 Did the revert actually work for you? Or did it say something about "error cannot revert commit" in the terminal? You may need to run "git stash" command before any reverting. If this is the case, be ready that on successful revert VIM (a text editor) will pop up on each of the four revert actions, asking you to state a revert reason. If you are not yet familiar with VIM, when it pops up (if you don't know what it looks like, it's a terminal program that looks like some colored code on your screen, so do not expect an actual window) just press esc, write ":x" and then press enter to make it go away, it should appear four times (once for each commit).

Edit: If you default text editor is NANO, and not VIM, you just press Ctrl+X and answer No if it prompts you to save a file.

MIght be that you're experiencing a different error that is resulting in a crash. This "fix" was for the:
"vkd3d_create_vk_buffer_view: Failed to create Vulkan buffer view, vr -2."
error message in the proton logs just before the crash which is a crash that results in a frozen screen output. If your HZD crashes directly with an error message, it might be one of the more intrinsic HZD bugs and so will not be influenced by this "fix". Better if you post a log of your run.

Crashes even faster for me with 1.05 during intro/menu.

Crashes even faster for me with 1.05 during intro/menu.

You could try the latest Proton-GE. Since you crash during the intro/menu, it has nothing to do with the band-aid I did with VKD3D and in my experience, GE is a lot more stable with more games. This release also raised my FPS to 40 - 50.

Crashes instantly with 5.9-GE-6-ST and clean prefix here. Everything else has always worked for me in wine-/proton-tkg, 0 crashes of any games that manage to start successfully (which basically comprises every game I tried, at least after a bit of fiddling). It's just this jinxed crap port...

Crashes instantly with 5.9-GE-6-ST and clean prefix here. Everything else has always worked for me in wine-/proton-tkg, 0 crashes of any games that manage to start successfully (which basically comprises every game I tried, at least after a bit of fiddling). It's just this jinxed crap port...

I can name plenty of games that will crash on it lol. Not every game works with Wine you know. There's a lot of issues here on Proton git if you look. No need to rip the game. The devs are patching it. The rest of the problems are with Proton/Wine and all relative to that. Most games aren't even dx12 only. This is new for Wine and it will have plenty of problems that the game isn't responsible for. Its a side effect of using Wine.

Just don't be too surprised if this simply turns out to be one of the many crash issues that always populate the game's patch notes.

Just don't be too surprised if this simply turns out to be one of the many crash issues that always populate the game's patch notes.

Definitely possible for specific issues.

The stuff discussed above in this issue kind of explain there are problems on the Wine/Linux side though so.

The fact that one person seems to get it running well means there could be issues on either side but I would lean on Wine/Linux being at fault if the exact problem doesn't happen on officially supported OS(s).

Gameplay and tests on Ubuntu 20.04.1 with driver Nvidia 450.66 on Proton 5.9-GE-6-ST - GTX 1650 4GB
https://youtu.be/8KVrk5GTl1Q

Maybe someone will need it:

1. USE Proton 5.9-GE-6-ST
2. do not use borderless mode causes graphics errors, flying trees and rocks.
3. I use Nvidia (beta) driver 450.66 from website
4. If the game looks like a slideshow, change the graphics quality to Orginal. you will get a stable 30 FPS on 1920x1080
5. If the game doesn't start, just click Play again.

@ArturWroblewski I'm currently on Linux Mint 20, and I've tried everything you listed, as well as upgrading the kernel to 5.8 from 5.4, but the game still won't even launch, with the same error like the one at the start of this issue.

If it's the same as the start of issue, it has something to do with running on a 32-bit context. 64-bit is required for this game according to its system requirements.

@intersectRaven Ah, interesting - I'm on a 64-bit machine, so is it the case that the wine prefix is configured wrong? How would I go about changing the context to 64-bit?

Also, just in case this is a tangent that doesn't need to be gone down when I meant error I meant the error box comes up saying "unfortunately the game has crashed", I haven't seen any error logs, nor do I know how to access them.

@intersectRaven Ah, interesting - I'm on a 64-bit machine, so is it the case that the wine prefix is configured wrong? How would I go about changing the context to 64-bit?

Also, just in case this is a tangent that doesn't need to be gone down when I meant error I meant the error box comes up saying "unfortunately the game has crashed", I haven't seen any error logs, nor do I know how to access them.

It's better if you post your logs since it's hard to see what the actual problem is with just the generic crash message. If you're using Steam, in the Properties of the game click on Set Launch Options and enter:

PROTON_LOG=1 %command%

The log will be at your home directory. If you're not using Steam, I'm unfamiliar with how to output logs.

Thank you! Here's my log, same thing happened again:
steam-1151640.log

Thank you! Here's my log, same thing happened again:
steam-1151640.log

Can you try installing winbind? I'm seeing an error I've seen before related to it but I'm not sure if it's the cause of your crash.
err:winediag:SECUR32_initNTLMSP ntlm_auth was not found or is outdated. Make sure that ntlm_auth >= 3.0.25 is in your path. Usually, you can find it in the winbind package of your distribution.

Nope, that didn't fix it, although that error isn't in the log anymore. Here's the new log just in case:
steam-1151640.log

@drwhut
I have a similar error when I change my screen display from Borderless to Full Screen. (he's in the video near the end) Do you know how to change window mode to full screen by changing an entry in the config file?

Sorry for not being able to help too moncosely.
I just read on protondb that the game is not working and I wanted to check if it was true and it just started :)

Sorry for the long video, if someone wants to see the optimal settings, please see:
https://www.youtube.com/watch?v=8KVrk5GTl1Q&t=2423s Gameplay with Full Screen, Orginal Preset , 1920x1080, Game Works Fine !!!

And if you want to see flying stones and trees, please click here:
https://youtu.be/8KVrk5GTl1Q?t=1779

Almost everything I tested is in video.

=========================

Additional information not directly related to the game:
While installing the Nvidia drivers, my system broke. And I had to reinstall ubunu so I have a test done on a clean install.

Sequence of actions:

• Installing a new Ubuntu 20.04.1 installation
• Installing new drivers from Nvidia 450.66 website

I installed Lutris (https://lutris.net/)

Execution of standard commands to run nintendo Swich emulators and Steam:

sudo add-apt-repository multiverse
sudo apt update
sudo apt install steam
sudo apt-get update -y
sudo apt-get install -y libudev-dev
sudo apt-get install -y libinput-tools
sudo apt-get install -y libinput-dev
sudo apt-get install libglu1-mesa-dev freeglut3-dev mesa-common-dev
sudo apt-get install libqt5webenginewidgets5
sudo apt-get install -y libzip-dev

Copy from Proton 5.9-GE-6-ST https://github.com/GloriousEggroll/proton-ge-custom/releases

Installing the game and launching it

And the rest is on Video

Nope, that didn't fix it, although that error isn't in the log anymore. Here's the new log just in case:
steam-1151640.log

Do you have 450.66 NVidia drivers? I'm seeing version feature unsupported as well in your logs so it may be that you're using outdated GPU drivers.

Yeah, I have those drivers installed:

@drwhut
I have a non-game question. More with my problems. How do you install Nvidia drivers from the site?

Something goes wrong quite often. Here's what it does to install a new driver:

Download NVIDIA-Linux-x86_64-450.66.run
Mark as executable

sudo systemctl isolate multi-user.target
ls
cd Downloads
ls
sudo ./NVIDIA-Linux-x86_64-450.66.run
reboot now
sudo reboot now
nvidia-smi

And if I manage to install it, I can't log in more than once. The computer is standing at the login screen.

Nope, that didn't fix it, although that error isn't in the log anymore. Here's the new log just in case:
steam-1151640.log

Do you have 450.66 NVidia drivers? I'm seeing version feature unsupported as well in your logs so it may be that you're using outdated GPU drivers.

I noticed that it's using the built-in D3DCOMPILER_47 dll as well. Can you try copying the one in the Tools directory to the HZD executable directory?

Just to add, using Linux Mint 20, Nvidia 450.66 from the graphics-driver ppa, Proton 5.9-GE-6-ST and the game crashes on start.

steam-1151640.log

@ArturWroblewski I installed them from the PPA:

sudo add-apt-repository ppa:graphics-drivers/ppa
sudo apt update
sudo apt install nvidia-driver-450

Nope, that didn't fix it, although that error isn't in the log anymore. Here's the new log just in case:
steam-1151640.log

Do you have 450.66 NVidia drivers? I'm seeing version feature unsupported as well in your logs so it may be that you're using outdated GPU drivers.

I noticed that it's using the built-in D3DCOMPILER_47 dll as well. Can you try copying the one in the Tools directory to the HZD executable directory?

OH MY GOD that worked!!! Thank you so much! It's gotten to compiling the shaders, I'll reply with what happens afterwards!

Just to add, using Linux Mint 20, Nvidia 450.66 from the graphics-driver ppa, Proton 5.9-GE-6-ST and the game crashes on start.

steam-1151640.log

Your error MIGHT have something to do with this line:
err:vkd3d_bindless_state_init: Insufficient descriptor indexing support.

Unfortunately, I have no idea on what to fix with that one. Also, have you copied the d3dcompiler thing I mentioned above?

@drwhut Lucky guy. I has the same GPU (1650) but laptop one, unable to launch the game. If I leave the launch option empty, there is only the error message window shown. If I use prime-run to launch it, the error message show with the black game window.

@drwhut Lucky guy. I has the same GPU (1650) but laptop one, unable to launch the game. If I leave the launch option empty, there is only the error message window shown. If I use prime-run to launch it, the error message show with the black game window.

Not sure if this makes a difference or not, but I don't have a 1650, I have a 2070 Super.

@drwhut Sorry, I mistook you for @ArturWroblewski

@intersectRaven
I have only one problem with this game. I can't turn my full screen back on. You can see at the end of my video.
https://youtu.be/8KVrk5GTl1Q?t=3178

Would you be able to help me? Interestingly, I managed to do it once, but now I don't know how :(

steam-1151640_nor.log
steam-1151640.log

I'm just going to leave this here for anyone who might wonder upon it to try and get the game working:

• Use Proton 5.9-GE-S-ST, instructions on how to install it are here.
• If you use the NVIDIA drivers, update them to version 450.66. If you are on Ubuntu, you can use the graphics-drivers PPA to get them:

sudo add-apt-repository ppa:graphics-drivers/ppa
sudo apt update
sudo apt install nvidia-driver-450

• Copy Horizon Zero Dawn/Tools/ShaderCompiler/PC/10.0.18362.0/x64/d3dcompiler_47.dll to Horizon Zero Dawn/d3dcompiler_47.dll, next to the executable.
• Optional: I'm not sure if this actually affects anything, but I have also upgraded my kernel from 5.4 to 5.8.

However, as of right now for me:

• The performance at 1080p for me on Ultra is literally a slideshow.
• The game starts off in borderless mode, but trying to switch to fullscreen mode just results in crashing for me at the minute.
• Others have also said that borderless is quite glitchy at the minute (e.g. flying rocks and trees), so the current workaround is to switch to windowed mode.

@intersectRaven
I have only one problem with this game. I can't turn my full screen back on. You can see at the end of my video.
https://youtu.be/8KVrk5GTl1Q?t=3178

Would you be able to help me? Interestingly, I managed to do it once, but now I don't know how :(

steam-1151640_nor.log
steam-1151640.log

Can't help you there. As far as I know, the settings file is a binary file in the game's save directory so you can't manually modify it. As for me, I just ran on borderless which required about 1 or 2 runs before all the floaty things disappear until I reboot my PC again. Your idea about the floating things being related to borderless makes me want to reboot my computer after setting it to windowed so I can test if the floaty things disappear entirely. It should eliminate the need to run it 1 - 2 times if your idea holds.

@ngoquang2708 It seems to me that I have the same problem @drwhut and he found a solution
Problem:

@ArturWroblewski I'm currently on Linux Mint 20, and I've tried everything you listed, as well as upgrading the kernel to 5.8 from 5.4, but the game still won't even launch, with the same error like the one at the start of this issue.

Post @drwhut
I'm just going to leave this here for anyone who might wonder upon it to try and get the game working: ...................................

@drwhut
I would add that if in the borderless mode have you" flying stones and trees", please change mode to Window (swipe left in option from borderless to window)

@intersectRaven
I would never have thought that running several times would reduce floating objects.

What if I copied the configuration file from the windows version with Full Screen set. Because I know that my full screen was working. I have it on record. https://youtu.be/8KVrk5GTl1Q?t=2102

And there are no flying stones and trees :)

Can you share your file please? I don't have Windows and I can't switch to fullscreen.

@mozo78 I don't know if this will work. But if it works, of course, I will share the file it uses and describe the location.

Give it to me and I'll try :)

It looks like with latest radv mesa (possibly not released yet) or latest nvidia driver from yesterday that one or more possible issues could or really should be fixed.

https://gitlab.freedesktop.org/mesa/mesa/-/issues/3460 "Horizon Zero Dawn graphics corruption with with radv", "spirv: fix emitting switch cases that directly jump to the merge block "

https://www.nvidia.com/download/driverResults.aspx/163518/en-us "Fixed a bug in a SPIR-V optimization that may cause conditional blocks to not execute."

455.23.04 doesn't fix the flying oblects for sure.

@ArturWroblewski
Still waiting for your profile.dat, please.

@mozo78
Sorry for the delay but I have a problem with running the game on windows. The game works. in the thumbnail on the bar, I see that it works because the mini screen changes. But the picture from the game cannot be full screen. He's not even in the window. As if he was on the second monitor. but I don't have a second monitor. I cannot activate this game window.

Weird. testing on Windows 10 Ryzen 1700 + GTX 1650

@ngoquang2708

drwhut Lucky guy. I has the same GPU (1650) but laptop one, unable to launch the game. If I leave the launch option empty, there is only the error message window shown. If I use prime-run to launch it, the error message show with the black game window.

Maybe you should try Prime Render instead of bumblebee. Bumblebee is for opengl, wine uses vulkan for dx12 (vkd3d). With prime render, you don't even need to add anything to the game's startup options, because with vulkan the system automatically selects the video card (nvidia instead of intel). Tested with other games via proton, HZD not yet.

@mozo78
Sorry for the delay but I have a problem with running the game on windows. The game works. in the thumbnail on the bar, I see that it works because the mini screen changes. But the picture from the game cannot be full screen. He's not even in the window. As if he was on the second monitor. but I don't have a second monitor. I cannot activate this game window.

Weird. testing on Windows 10 Ryzen 1700 + GTX 1650

Hmm, it's funny - on Linux it works, on Windows doesn't :)

@mozo76
Here are the resolution files. But it doesn't do anything.

Make a copy of your file or you may not start the game.

Out of curiosity, I recommend that you copy the file from the "First Run Orginal" directory. The game starts in the left side bar and you need to make a full window.

profile.zip

I managed to get the game bordlerless on full screen again and then it works ok (but I don't know how I did it and it depends), no flying objects. Just like you run in windowed mode and then change to borderless during the game, I also don't have flying stones. How are you with flying stones?

Thank you very much! Unfortunately, the files doesn't help as you say :(
Yes, I have flying plants and stones. I think it's a NVIDIA problem.

I have flying plants and stones but they are fixed when I restart the game. I have Nvidia.

Previously, when encoutering flying objects after loading a saved game i tried the following:

1) Deleting PSOCache.bin in LocalCacheDX12 and letting the game redo the "optimization".
2) Loading a previous enough save via "load game" menu right after the game is launched doing so until the flying objects are gone and then reloading the newest save.
3) Running the game with different versions of dxgi.dll (say from DXVK 1.7, then from DXVK 1.7.1 and vice versa).

However, after reading posts by @intersectRaven, as stated here:

I just ran on borderless which required about 1 or 2 runs before all the floaty things disappear until I reboot my PC again.

and @mixalis1987 as stated here:

I have flying plants and stones but they are fixed when I restart the game. I have Nvidia.

it turned out, that just restarting the game several times, e.g. loading save, seeing flying objects, quitting the program and starting again several times until the flying objects are gone seems to help every time.

It would seem, that the flying objects most often appear if the game wasn't terminated properly, which may happen either because it froze and you killed the process, or at random, when it appears that the game did quit cleanly, but in reality it just silently crashed while exiting.

If anyone else encountered flying objects, and solved the issue in a different fashion, please, share your experiences with us!

Yes, I just reloaded the game and now everything is fine!

@mozo78 @RoyShapiro Please confirm that it is the same for you.

Flying objects are only in Borderless mode.

I never saw flying objects in Windowed mode.
Even after restarting my computer and starting the game in Windowed mode, I don't have any flying objects.

The video shows the first run after restarting the PC.
https://youtu.be/OPPQXeRI_rg
I loaded save 3 times to make sure that nothing appears.

My last screens are with Borderless mode, hmm...

@mozo76 I admit that when I start the game on Windowed mode and then change to Borderless Mode, I don't have these flying objects either.

I'm afraid to switch to Windowed mode for the game sometimes is stuck with a frame around it and doesn't want to cover the full screen. It was hard to run it stretched.

@mozo78
I admit that I also sometimes have a problem with switching between modes. as in the picture below. Therefore, when switching, I set the parameters as in the video above.

After restarting the game, does the game start in full screen? Because I always run in the windowed mode and then switch to borderless mode. To avoid the screenshot effect not full screen.

Yes it's the same effect. I can't run in full screen on Mint Cinnamon 20.0. The game runs fine in most cases on Arch with KDE. Running first with Windowed mode and then switching to Borderless doesn't help on my end. It's a hit and miss on Arch and never works on Mint Cinnamon.

For me, the transition from Windowed mode to Borderless works only with this configuration. I do not know why. But if I change any of the parameters to something other than in the photo, I have a frame with the previous image.

I'll try this tomorrow :)

It looks like with latest radv mesa (possibly not released yet) or latest nvidia driver from yesterday that one or more possible issues could or really should be fixed.

https://gitlab.freedesktop.org/mesa/mesa/-/issues/3460 "Horizon Zero Dawn graphics corruption with with radv", "spirv: fix emitting switch cases that directly jump to the merge block "

https://www.nvidia.com/download/driverResults.aspx/163518/en-us "Fixed a bug in a SPIR-V optimization that may cause conditional blocks to not execute."

Nice catch. I didn't see that when I did a quick read through of the NVidia BETA changelog. I'll try this driver on my machine.

@ArturWroblewski Haven't seen any floating objects after switching to fullscreen yet, but can not yet confirm. Could have easily been a fluke. I do not get them every single time, only after the game crashes, and even then, not every time. It did crash once in fullscreen mode, so it doesn't affect that, but no floating objects so far.

It looks like with latest radv mesa (possibly not released yet) or latest nvidia driver from yesterday that one or more possible issues could or really should be fixed.

https://gitlab.freedesktop.org/mesa/mesa/-/issues/3460 "Horizon Zero Dawn graphics corruption with with radv", "spirv: fix emitting switch cases that directly jump to the merge block "

https://www.nvidia.com/download/driverResults.aspx/163518/en-us "Fixed a bug in a SPIR-V optimization that may cause conditional blocks to not execute."

I just fired up HZD on 455.23.04 and floaty things appeared after all the shader recompilation. Also, this was on windowed mode so didn't fix it. Seems to have a bit more vibrant color though. Seems to not be quite optimized though since I've experienced some stuttering during some quick movements but that can be attributed to it being BETA still.

Yeah I'm with 455.23.04 and there are flying objects too.

@leao666 I already known that this game only use DX12 which in turns only use Vulkan in Linux. I use prime-run just to be sure. It doesn't relate to Bumblebee. It is just a command to "force" PRIME Offload rendering for both OpenGL and Vulkan. Some OpenGL-only game need that command to use PRIME offload rendering, otherwise it will use the iGPU for OpenGL.

That's interesting if it makes it worse lol. At least it shows the driver is heavily affecting it.

Profiles with all modes. Useful when someone changes to Fullscreen and cannot start the game. Just copy the selected profile with the resolution and settings of displaying the image from zip file to path, e.g .:

/home/user_name/.steam/debian-installation/steamapps/compatdata/1151640/pfx/drive_c/users/steamuser/My Documents / Horizon Zero Dawn / Saved Game / profile

Horizon Zero Dawn Complete Edition profile.dat.zip

Just want to repost, if you're experiencing crashes after a few minutes of play and there is an error in your proton logs mentioning:
"vkd3d_create_vk_buffer_view: Failed to create Vulkan buffer view, vr -2."

Just compile the vkd3d code I pushed to my Github marked as the personal branch. It has the reverts there already if you don't know how to revert yourself.

Also, use:

git clone --recursive

to clone so that the subprojects are fetched as well.

It doesn't build:
meson.build:41:0: ERROR: Include dir ./subprojects/Vulkan-Headers/include does not exist.

It doesn't build:
meson.build:41:0: ERROR: Include dir ./subprojects/Vulkan-Headers/include does not exist.

Issue a:

git pull --recurse-submodules

This occurs when you only clone the main project.

Yes it works, thank you :)

Hi,
I've been trying to follow instructions but it looks like things are now more broken than when I started (used to launch the game with Proton 5.9 GE 6 ST and crash after compiling the shader and now won't launch at all).

From what I understand I have 2 (related ?) problems :

• Wine (using wine-5.17 staging) won't let me add d3d12.dll as native to my prefix (I DL'd and build vkd3d-proton, had some troube because Vulkan Headers were too old but I updated them manually and that seems to have worked ). From what I understand wine should detect that it's installed on its own but doesn't. (Installed through package manager, should I clone the repo and build it from the ground to add vkd3d support ?)

• According to Proton log (can't post the log, not sure why), I'm missing dxgi.dll as well as d3d12.dll, I assume the d3d12.dll problem would be fixed once I get Wine to add it, not sure about dxgi.dll

12980.305:00bc:00c0:err:module:import_dll Library dxgi.dll (which is needed by L"M:\\xavier\\.steam\\debian-installation\\steamapps\\common\\Horizon Zero Dawn\\d3d12.dll") not found 12980.305:00bc:00c0:trace:loaddll:load_so_dll Loaded L"C:\\windows\\system32\\msvcrt.dll" at 0x7f0525370000: builtin 12980.305:00bc:00c0:err:module:import_dll Library d3d12.dll (which is needed by L"M:\\xavier\\.steam\\debian-installation\\steamapps\\common\\Horizon Zero Dawn\\HorizonZeroDawn.exe") not found 12980.305:00bc:00c0:err:module:import_dll Library dxgi.dll (which is needed by L"M:\\xavier\\.steam\\debian-installation\\steamapps\\common\\Horizon Zero Dawn\\HorizonZeroDawn.exe") not found

Using Pop!_OS 20.04 focal, Ryzen 5 3600X, AMD Radeon RX 5700 XT, Mesa 20.3.0-devel.

Thanks !

Hi,
I've been trying to follow instructions but it looks like things are now more broken than when I started (used to launch the game with Proton 5.9 GE 6 ST and crash after compiling the shader and now won't launch at all).

From what I understand I have 2 (related ?) problems :

• Wine (using wine-5.17 staging) won't let me add d3d12.dll as native to my prefix (I DL'd and build vkd3d-proton, had some troube because Vulkan Headers were too old but I updated them manually and that seems to have worked ). From what I understand wine should detect that it's installed on its own but doesn't. (Installed through package manager, should I clone the repo and build it from the ground to add vkd3d support ?)
• According to Proton log (can't post the log, not sure why), I'm missing dxgi.dll as well as d3d12.dll, I assume the d3d12.dll problem would be fixed once I get Wine to add it, not sure about dxgi.dll

12980.305:00bc:00c0:err:module:import_dll Library dxgi.dll (which is needed by L"M:\\xavier\\.steam\\debian-installation\\steamapps\\common\\Horizon Zero Dawn\\d3d12.dll") not found 12980.305:00bc:00c0:trace:loaddll:load_so_dll Loaded L"C:\\windows\\system32\\msvcrt.dll" at 0x7f0525370000: builtin 12980.305:00bc:00c0:err:module:import_dll Library d3d12.dll (which is needed by L"M:\\xavier\\.steam\\debian-installation\\steamapps\\common\\Horizon Zero Dawn\\HorizonZeroDawn.exe") not found 12980.305:00bc:00c0:err:module:import_dll Library dxgi.dll (which is needed by L"M:\\xavier\\.steam\\debian-installation\\steamapps\\common\\Horizon Zero Dawn\\HorizonZeroDawn.exe") not found

Using Pop!_OS 20.04 focal, Ryzen 5 3600X, AMD Radeon RX 5700 XT, Mesa 20.3.0-devel.

Thanks !

Very odd since the Proton distro's (GE, TKG, Steam) usually have those. Maybe you need to have the prefix used by Proton reset. Someone above posted where it usually is so you can try deleting that and have Proton recreate it for you.

Thanks for the tip @intersectRaven , it's running now, it took several tries to go through the initial cutscene without a crash but I reached the first checkpoint.

Big thanks to @ArturWroblewski for sharing its profile data, game wouldn't start with the default settings.

Apparently switching to fullscreen crashes the game though. I'm running Borderless but still have a titlebar (??) and it my xbox controller isn't recognized even though I activated xinput with protontricks. So it's playable but far from optimal.

steam-1151640.log

(Finally found out that NoScript was preventing me from uploading my log file before)

@Chipsse, I am very happy that I could help.
I also had this problem. The window bar did not disappear in borderless mode.
You can see this video. https://youtu.be/8KVrk5GTl1Q

The correct switch from windowed to borderless can be seen in this video (at the end).
https://youtu.be/OPPQXeRI_rg

I run the game in windowed mode (with settings from video ) and then switch to Borderless mode . Then I have the full screen correct. For me it's the only way so far to have a full screen good.

If someone figured out how to fix it or what it depends on, I am asking for information.

And as for the Controllers, I haven't checked yet. I just didn't think to check. :)

This link looks really shady to me! Any mods here to check this out and delete the post? @kisak-valve

I still have several random crashes. Anyone figured out a way to deal with those?

Thanks @ArturWroblewski , unfortunately it didn't work for me, I'm still getting the titlebar at the top. :(

I tried to force the controller use in the Steam setttings but that doesn't seem to have changed anything. My log mentions a failure to start wineusb service, but since the game receives input from my mouse and keyboard I assume the problem lies elsewhere.

220.187:005c:0068:err:ntoskrnl:ZwLoadDriver failed to create driver L"\\Registry\\Machine\\System\\CurrentControlSet\\Services\\wineusb": c0000142 220.203:0030:0034:fixme:service:scmdatabase_autostart_services Auto-start service L"wineusb" failed to start: 1114

Turns out the titlebar was a Gnome issue, I fixed it with an extension ( https://github.com/poehlerj/no-title-bar , in case someone else needs this).

Still no idea how to get the controller to work but I made it through the prologue in one go and 0 crash, no floating rocks or grass that I noticed. The benchmark absolutely murders my FPS but actual in-game perf is pretty good (55/60 FPS at 1440p). Strangely, I get better results benchmarking with the "high quality" preset than the "original".

Thanks again for the help ! And if someone finds out what's causing the controller issue, I'd be happy to know the fix.

Would hazard a guess that focusing on wineusb entries there would not be it.

Just to add, using Linux Mint 20, Nvidia 450.66 from the graphics-driver ppa, Proton 5.9-GE-6-ST and the game crashes on start.
steam-1151640.log

Your error MIGHT have something to do with this line:
err:vkd3d_bindless_state_init: Insufficient descriptor indexing support.

Unfortunately, I have no idea on what to fix with that one. Also, have you copied the d3dcompiler thing I mentioned above?

yep, copied the dll, still no change.
the vkd3d_bindless_state_init error persists

I'll give up on it, apply for a refund and wait till this one is running without so many issues ;-)

For me it's running on Mint 20 and 450.66. Very strange...

After some toying around, it looks like I still get a titlebar in Borderless mode, UNLESS :

• Game resolution matches monitor resolution before launch
• Game is launched through Steam, not Lutris
• No other app is fullscreened
• Graphic preset needs to be at "Original" at launch, but can be changed once game is running.

Still no luck with controller, which is really weird. Steam sees the controller, pressing the central "guide" button displays a message in terminal that it's loading a control file, and (in Nioh at least) I can even use the controller in the launcher before the actual game and rumbling when I get hit. But nothing when I press the controller buttons.

I don't understand what I'm missing or doing wrong. Previously I got it to work building proton-tkg and copying the dlls, but now using _Proton-5.9-GE-6-ST_ I can no longer get the game to even launch. (e.g. I'm back to the original crash screen) I'm running manjaro and I previously installed mesa-git for the mentioned above which got rid of the floating rocks problem... :(

@77boaz I had this problem when I changed the resolution / settings to the wrong one and the game could not start anymore. Solution:

Try copy the selected profile with the resolution and settings of displaying the image from zip file to path, e.g .:

/home/user_name/.steam/debian-installation/steamapps/compatdata/1151640/pfx/drive_c/users/steamuser/My Documents / Horizon Zero Dawn / Saved Game / profile

Profile to download:
https://github.com/ValveSoftware/Proton/files/5250675/Horizon.Zero.Dawn.Complete.Edition.profile.dat.zip

I recommend checking the profile:
1920x1080 Windowed 50hz Orginal

Thanks that did it! Funny, I actually nuked the whole pfx folder to try to start clean... I am also dual booting Windows to compare etc.. I guess the steam cloud saves the settings from Windows? Steam cloud is great! except when you are going between the two?? :)

@77boaz In fact, the cloud synchronizes the save directory, and that there is resolution information, it synchronizes. hehe :).
But it's a bit dangerous because if you have several pc at home, what if you run on 4k in one and in the other you can't run on 4k or it's a bit messy.

But only for synchronization of configurations between computers.

Ahh.. Duh You're correct. I know some games sync all and some only sync the saves. Anyways it's running now thanks! I can't wait until there's a fix for the fullscreen issue. I will still go between them both.. I just like seeing the progress made etc.. Again thanks to all for working it! :)

Happy to report that the game can be played from start to finish, and is rather enjoyable at that I might add, including the DLC.
I would like to thank everyone, who contributed for making this possible!

I am using Proton-5.9-GE-6-ST. Without copying d3dcompiler_47.dll into the game folder, I still able to launch the game for the first time (I was never able to launch it before) using the profile.dat file uploaded by @ArturWroblewski. Thanks!
I use First Run Original profile.dat file, the game started in Windowed mode. Whenever I try to switch the settings to Fullscreen the game crash. I guess there is something to do with the Fullscreen mode.
My GPU is GTX 1650, driver version 450.66.

Hi all,
I've noticed that the game re-compiles the shaders when my graphic drivers get an update. Is that expected behavior ? Or is it something that can (should ?) be fixed ?

Hello @Chipsse, that's universally true for all software that uses a video card.

Thanks @kisak-valve , sorry about the off-topic.

I solved my controller issue so I figured I'd share in case someone else runs across the same issue, Steam Overlay was the culprit. I keep it disabled it globally in the Steam options since it tends to cause problems and I never use it anyway, but the controller apparently doesn't work without it in this case. Not sure if that's a HZD or Proton issue.

@mozo78 do you have libraries compiled from intersectRaven ?
If you have them, could you share them?

I use this library and the game is working:

https://u.pcloud.link/publink/show?code=XZLm95XZTtQmPGRIeP8odYUhu8SbdBswa1AV

@mozo78

1. The game works great with DualShock 4 V2. Immediately after turning on the controller, it is detected by the game. No problems.
2. My game still crashes every 15 to 20 minutes. Where did you replace this file? in the game / prefix directory or in the proton directory 5.9. For version 64 or regular? Please write the path where I should copy it because I do not see any difference.

if you copy to the prefix proton will overwrite it again.
afaik it has a script to copy those dll's over to the prefix. if this helps, then you should put it into proton, so it gets copied over.

I placed this library in the root directory (where's the game's exe).

@fsyy
I agree with you. If I copied the folder to the prefix. after running the file was restored to the original one.
So I replaced the file in the proton 5.9-ST-6 folder ... But my game keeps crashing :(

@mozo78
I will try. I hope it will help me. Does your game crash anymore?

I think RoyShapiro wrote so .

Thank you for the hints.

Besides, the game freezes. It works very smoothly for me. And it's fun to play.

@ArturWroblewski
Hi!
You seem to report that the game both "crashes" and "freezes" for you. These are two different things, and may induce confusion.

I should probably clarify that by "freezes" I mean that the same picture keeps hanging on the screen indefinitely (so it doesn't "unfreeze" on it's own), while the sound goes on, and no error message appears, thus the game's process must be killed manually. It is this kind of freezing that the "reverted" file helps delay (but NOT eliminate, unfortunately).

If, instead, you see an actual error message, this is a completely different problem, that is, as far as we currently know, beyond the scope of anything changed by the reverts, and likely not VKD3D related. Oftentimes, it may indicate a problem with the game itself, it's still really buggy. The reverts do not help with these.

Alas, you may very well have both. If you have a dual boot setup, check to see if it crashes for you in Windows too. If so, the game may have a problem with your hardware, and you'll need to wait for an update to the game. If not, it may have to do with the Proton. Meanwhile, you can try updating the game, the drivers, all the usual stuff.

@RoyShapiro You are right with what I wrote, I could have misled you. The game freezes. And audio continues.
Sorry for the confusion.

I run the game in windowed mode without any problems. and the game freezes after 20 minutes. While the game works, it works very well, I can't really complain about anything.
I am currently playing with PS4 gamepad on Ubuntu 20.04.1

Just to report - the game runs stable with Proton GE 5.9-6, on a 2080 Ti with driver 450.66.

The only issue I have is when switching to fullscreen, the game crashes. Any workaround and/or way to run it as such?
Also, I managed to run the benchmark fullscreen, hence I imagine is just something minor causing this crash when switching to fullscreen.

I don't think there's any difference between fullscreen and borderless inside Wine, apart from alt + tab behavior. Compositor is told to turn off/unredirect in both cases and page flipping for proper vsync is triggered. So you shouldn't be bothered by it, unless that weird smeared upscaling bug of the game happens more frequently with borderless for some reason.

I don't think there's any difference between fullscreen and borderless inside Wine, apart from alt + tab behavior. Compositor is told to turn off/unredirect in both cases and page flipping for proper vsync is triggered. So you shouldn't be bothered by it, unless that weird smeared upscaling bug of the game happens more frequently with borderless for some reason.

Technically G-Sync/Free-Sync only work with fullscreen/fully borderless, I'm afraid H:ZD is not fully borderless, hence there is a difference.

@ArturWroblewski
It should be noted, that the game freezes anyway, the questions are really "when" and "how often". With the correctly "reverted" file, depending on your luck, the game will run anywhere from 10 minutes to 8+ hours before freezing. So try again and again, and you may get 20 minutes, then an hour or so, then 5-7 hours, then 20 minutes again, but mostly hours+. Without the "reverted" file, it almost always freezes within 10-15 minutes. Some folks have reported being able to play up to an hour without the reverts, but I haven't been able to reproduce that. We have not determined exactly why this is so, but since the bug is generally related to resource allocation, things like the general amount of free RAM and VRAM your system has available at any given moment may or may not be a factor.
AFAIK, you did NOT revert & compile d3d12.dll yourself. If it freezes within 20 minutes every time almost without variation, you've very probably got the wrong file. Whoever gave you the file might have uploaded the wrong one. While you can ask the person to make sure they gave you the freshly compiled one, the only way to be certain at the moment is to compile it yourself. Using @intersectRaven 's fork \ repo is the easiest way (no need to revert anything).

Edit: The Path question!
The file needs to be written to "System32" folder, then needs to be set to "native" in Wine (Proton) configuration. Otherwise Proton won't "see" it. If it overwrites the file, place it in a location, where it will overwrite the "System32" version (For GE 6 the default is /dist/lib64/wine/vkd3d-proton). The binary itself should be x64 -- this IS confusing.
If this doesn't work, try placing it in the game's directory as @mozo78 suggested, but some people have reported, that this causes the game to hard-crash for them, so be advised. It may work, but it's not the correct solution. The correct is to place it in "System32".

Reporting more issues - got rocks and other props flying, the game is unplayable (because you can't hide :) ) - and this happens randomly. Furthermore the _borderless window_ doesn't fill the whole screen, hence it doesn't use G/Free-Sync.

I'm afraid it's too unstable, this is a refund for me - waiting for better support possibly.

Running on 2080 Ti, 450.66 - Ubuntu 18.04.3 - 3440x1440.

Here's a repackage of the Proton-5.9-GE-6-ST binary release with intersectRaven's vkd3d fixes built and included. You should be able to just use this Proton with HZD and be good to go.

Fedora 32 users w/ AMD cards may also appreciate this Mesa git rebuild using the official Fedora spec files, with the source from master yesterday, that fixes a lot of graphical glitches and performance problems.

I made some instructions if you could use them. With both of these applied, HZD is running really great for me. Still crashes, usually with the graphical freeze others describe above. Restarting GDM resolves it without a reboot most of the time, sometimes it's a much harder crash than that. Playable for pretty long periods of time in between, though, with graphical settings tuned up from Original a little on my 5700XT at 1440 ultra-wide.

Obviously be careful trusting random downloads from strangers on the internet. I guess if you're into it, though.

Edited to add: using X11, starting game with fullscreen windowed/borderless I am able to change workspaces away and back again to get the game to properly go borderless.

Edit 2: I just realized I didn't update the .vdf for Steam to recognize a different name before uploading. I was just manually monkeypatching GE-6-ST. :) The link above is fixed.

When posting binaries, could you please also post link to the patches?
Apologies but a bit hesitant running binaries w/o seing diffs (or that I could rebuild myself).

I didn't successfully get a full rebuild of Proton-GE to work due to drift in Wine since his last update of his patch set, and bisecting takes so long that I didn't bother. That's just intersectRaven's personal branch rebuilt and the d3d12.dll's swapped in for GloriousEggroll's own Proton-5.9-GE-6-ST binary release.

The Mesa rebuilds are exactly Mesa git master w/ the F32 .spec patches on the repo those releases are from.

I updated the above post to be more clear, hopefully.

@solacelost

1. Thank you for Proton 5.9 Solance Edition.
   I admit that the game is not frozen for me yet on Proton 5.9 Solance Edition. But I have flying objects all the time. I restarted the game 30 times and still have flying objects. If not immediately after starting the game, then after 5 minutes they appear.

1. When using Proton-5.9-GE-6-ST Flying objects disappear after 2 reboots maximum. And they I have no flying objects, all the time of the game (until the game freezes after about 20 minutes)

3.I tried to switch between Proton-5.9-GE-6-ST and Proton 5.9 Solance Edition.
Many times. And when I turn on the Proton 5.9 GE-6-ST , the optimization takes a short time and I have no flying objects (Perfect) . After switching to Proton 5.9 Solance Edition, Optimization takes about 10 minutes and I have lots of flying objects.

@solacelost

1. Thank you for Proton 5.9 Solance Edition.
   I admit that the game is not frozen for me yet on Proton 5.9 Solance Edition. But I have flying objects all the time. I restarted the game 30 times and still have flying objects. If not immediately after starting the game, then after 5 minutes they appear.
2. When using Proton-5.9-GE-6-ST Flying objects disappear after 2 reboots maximum. And they I have no flying objects, all the time of the game (until the game freezes after about 20 minutes)

3.I tried to switch between Proton-5.9-GE-6-ST and Proton 5.9 Solance Edition.
Many times. And when I turn on the Proton 5.9 GE-6-ST , the optimization takes a short time and I have no flying objects (Perfect) . After switching to Proton 5.9 Solance Edition, Optimization takes about 10 minutes and I have lots of flying objects.

As far as I can tell from the posts above, this is related to Nvidia hardware and has been present since people have gotten it running. I don't know how to help you there, as Nvidia drivers are proprietary binary blobs and nobody in the community can do anything about it.

@solacelost I was interested in your version of Proton, to test @ArturWroblewski complaint of flying objects not going away on an NVidia card, but the download link is not working for me (connection timeout) for some strange reason. Can you reupload it somewhere else?

@solacelost I was interested in your version of Proton, to test @ArturWroblewski complaint of flying objects not going away on an NVidia card, but the download link is not working for me (connection timeout) for some strange reason. Can you reupload it somewhere else?

@RoyShapiro
https://random-crap-29179.s3.us-east-2.amazonaws.com/Proton-5.9-solace-edition.tgz

Guys, did somebody filed an issue on NVIDIA bug tracker?

@solacelost

Seems like Proton 5.9-GE-6-ST causes the game to freeze.

Solance does not but causes flying objects.

@solacelost

I'm seeing the same. Proton-GE-6-ST causes freezes after a short play time.

Solance version has no freezes but the stones and other stuff start to float after a while.

At the moment, the best solution is to copy d3d12.dll from Proton 5.9 Solance Edition and replace the one in Proton 5.9 GE-6-ST with it.

Replace

Proton-5.9-GE-6-STdist\lib64\winevkd3d-protond3d12.dll

With

\Proton-5.9-solace-editiondist\lib64\winevkd3d-protond3d12.dll

Then load up HZD with Proton-5.9-GE-6-ST packing the replaced d3d12.dll.

This fixes the freezes and in most cases, has no issues with floating rocks etc, assuming on 1st load, you have no such issue.

Kudos to Artur_W in Reddit for the workaround suggestion.

@Cxpher
I confirm. So far the game has been running continuously for 4 hours without freezing and without flying objects (stones and trees). Thanks to mixing Proton 5.9-GE-6-ST with d3d12.dll from Proton 5.9 Solance Edition

Download Proton 5.9-GE-6-ST with d3d12.dll at link:
https://drive.google.com/file/d/1MjaifwahNgnw6tQ1jv6OqaWv94eRKoR6/view?usp=sharing

Proton-5.9-GE-6-STdist\lib64\winevkd3d-protond3d12.dll

Proton-5.9-GE-6-STdist\lib\winevkd3d-protond3d12.dll

Can we link the DLL only?

I am having a weird issue where the menu works fine after turning VSync off, but once I load into the game I get about 5FPS on every graphical setting. This happens with or without VSync on (with it on the menu is at about 10FPS). This is in Wayland on GNOME 3.36.

In GNOME Xorg, the game loads up with about a 20 pixel border around it showing my desktop, and when I load into my save, X is frozen, forcing me to grab another TTY to kill it.

R7 3800X and an RX 5600 XT, mesa-git and amdgpu. Only using the pulse 60 msec launch option from Steam. 5.9-GE-6-ST (about to add the .dll and see if that helps anything).

d3d12.dll from Proton 5.9 Solance Edition

Proton-5.9-GE-6-STdist\lib64\winevkd3d-protond3d12.dll
Proton-5.9-GE-6-STdist\lib\winevkd3d-protond3d12.dll

https://drive.google.com/file/d/12a5mlHJfrr_MynPDmJe6wwEn7gAb0Jfb/view?usp=sharing
Tested on Nvidia graphics card. I have not checked how it works on AMD.

The DLL swap did not fix my issue, although I wasnt sure that it would in the first place. I notice my CPU nor GPU scale up very far when trying to render the game, as if something is blocking it or not "connecting" in a way and thats why im experiencing these low FPS numbers. Not sure what to check to see why its happening however, proton log?

Update to my specific issue (and maybe this is mentioned here somewhere). Setting a frame limit makes the frames go nuts. I set them to unlimited and was able to play fine. However, even after replacing that DLL I still get random black screens that lock up my entire session forcing a hard reboot (cannot alt tab, etc). Same thing happens on X or Wayland (happens faster on X, as in when the game finally loads it completely locks up, but I can TTY to kill the gnome session and relaunch it on X where I cannot do that on Wayland).

The game has been running continuously for 4 hours without freezing and without flying objects (stones and trees).
Thanks to mixing Proton 5.9-GE-6-ST with d3d12.dll from Proton 5.9 Solance Edition
Gameplay as proof at the link: https://youtu.be/xjokkb0WypE

Download Proton 5.9-GE-6-ST with d3d12.dll at link:
https://drive.google.com/file/d/1MjaifwahNgnw6tQ1jv6OqaWv94eRKoR6/view?usp=sharing
Proton-5.9-GE-6-STdist\lib64\winevkd3d-protond3d12.dll
Proton-5.9-GE-6-STdist\lib\winevkd3d-protond3d12.dll

If you don't want to download the entire 250MB Proton, you can only download d3d12.dll from Proton 5.9 Solance Edition
https://drive.google.com/file/d/12a5mlHJfrr_MynPDmJe6wwEn7gAb0Jfb/view?usp=sharing

Tested on Nvidia graphics card. I have not checked how it works on AMD.

I've tried the above Proton with the d3d12 dll and I can run the game for first time since bought, but with glitches and low fps.

System Information

GPU: AMD Navi 10 Radeon RX 5700 XT
Driver/LLVM version: RADV 20.1.7
Kernel version: 5.8.6-1

Full steam system info:
https://gist.github.com/QUASARFREAK/45d9f21fed44212ef156797f1627d221

Screenshots:
https://imgur.com/a/cYFWP0Z

@QUASARFREAK do you still get crashes after so many minutes of playing, or just glitches and low FPS? I have VSync off, no frame limit, and settings on about medium (motion blur off) and frames are consistently 65-80, but I get a hard crash anywhere between 10-20 minutes even with the d3d12.dll replacement and using 5.9-GE-6-ST.

Hi there, I have tried some things now, still its crashing after a few seconds: https://www.youtube.com/watch?v=o9ToF7PzXh
Built proton-ge myself and used the prebuilt 6 and 7 version. Built vkd3d and put them into proton-ge/dist/lib and lib64 folders. Put them into system32 (64-bit) and SysWOW64 (32-bit) in the prefix as well, tho dont know if that was necessary. Started the game with Mangohud on and pulseaudio set to 60 msec, otherwise I have an echo in the sound. Tried aswell the profile.dat archive for testing out different resolutions.
Everytime its running and crashing after a bit then.

Did I miss something or went wrong somehere?
System is a Ryzen 9 3900X / Vega 64 - mesa-stable Manjaro Budgie

Just to add, my fork is mainly for NVidia GPUs. For AMD GPUs, the fix for the graphics corruption is in latest mesa-git so you need that as well in order to not have the graphics corruption.

I'm with NVIDIA and the floathing objects are here very often. I tried stable and beta Vulkan driver. I'm glad to hear it's finaly fixed for AMD.

@mozo78 Odd. It should stabilize after one or two restarts of the game. Anyways, we'll have to wait for VKD3D devs to fix it permanently then.

I'm curious whether it's a driver or VKD3D problem.

Solved my issue, its working flawless now: had to update to mesa-git !

Hence the problem is in NVIDIA's driver.

Btw, here's my compiled d3d12.dll you can copy to the HZD directory. Please inform of floaties since I'm trying to work around things during SPIRV translation in VKD3D.

https://cloud.intersectraven.tech/s/GpnzKo264mqwoCP

For now it's ok. It may be by accident but I'll watch it :)

So far, I haven't been able to start HZD, it crashes on start.
I am using mesa-git, Proton-5.9-GE-6-ST, built vkd3d-proton-master and overwrote the x64- and x86-d3d12.dll in Proton-5.9-GE-6-ST/dist/lib(64)/wine/vkd3d-proton

Please inform of floaties since I'm trying to work around things during SPIRV translation in VKD3D.

@intersectRaven I'm not sure why do you even bother, Hans-Kristian confirmed it's a bug in Nvidia's driver around monday and the last Vulkan dev beta driver explicitly mentions this bug to be fixed in its changelog:

Fixed a bug in a barrier optimization that allowed some back-to-back copies to run unordered

So, anyone who's trying to play HZD on Nvidia should either upgrade to 455.22.04 or wait until this fix reaches stable branch.

So far, I haven't been able to start HZD, it crashes on start.

@TheHooly Do you have d3dcompiler_47.dll (and possibly also dxcompiler.dll) symlinked/copied next to the game's executable? Also consider posting the log created with PROTON_LOG=1, otherwise guessing what's wrong will take a long time.

I had the built d3d12.dll (x64) in the game folder, forgot to remove it from there after mistakenly copying it there, removed it now.
I've copied the d3dcompiler_47.dll from Proton's lib64 folder and dxcompiler.dll from the game itself Horizon Zero Dawn/Tools/ShaderCompiler/PC/1.0.2595/x64 unfortunately no difference yet.
http://ix.io/2zCB

Please inform of floaties since I'm trying to work around things during SPIRV translation in VKD3D.

@intersectRaven I'm not sure why do you even bother, Hans-Kristian confirmed it's a bug in Nvidia's driver around monday and the last Vulkan dev beta driver explicitly mentions this bug to be fixed in its changelog:

Fixed a bug in a barrier optimization that allowed some back-to-back copies to run unordered

So, anyone who's trying to play HZD on Nvidia should either upgrade to 455.22.04 or wait until this fix reaches stable branch.

So far, I haven't been able to start HZD, it crashes on start.

@TheHooly Do you have d3dcompiler_47.dll (and possibly also dxcompiler.dll) symlinked/copied next to the game's executable? Also consider posting the log created with PROTON_LOG=1, otherwise guessing what's wrong will take a long time.

Good to know. Where did he post it by the way? In the future I'll just suggest to everyone to update to 455.22.04 or wait for official drivers. My personal branch will still exist though but only for resolving the memory crashes due to the hashmap thing exhausting the memory. :smiley:

Also, to those using AMD, the fix has been backported to Mesa 20.1 and is included in the Mesa 20.1.9 release so once your distros update to that you shouldn't need to compile mesa-git. :smiley:

Can confirm the game is playable with Mesa 20.2.0 on Gentoo with fsync. d3dcompiler_47.dll including native override and Proton-5.9-GE-6-ST are needed.
I'm getting approx. 30-60fps depending on the situation in 1440p ultra on RX Vega 64 with a hefty overclock and a 3900X. My xbox one controller refuses to work with this game, so does mangohud for some reason.

@TheHooly d3dcompiler_47.dll from Proton almost certainly won't work, copy the one shipped with the game itself (it's somewhere in Tools just like dxcompiler.dll). However, the log doesn't mention it being loaded at all anyway, so the game probably dies before even attempting to use it.

Assuming you are on AMD, there is a known issue with ACO, but it causes fully-blown GPU hangs and not just simple crashes on startup. I'll try to take a better look at your log tomorrow, but I'm on Nvidia myself and I probably won't be able to help you, sorry.

Where did he post it by the way?

@intersectRaven On the VKx Discord server.

Game opens a black window and spins the loading symbol in the bottom left for me, but then crashes:

Ubuntu 20.04.1
Proton-5.9-solace-edition
dxcompiler.dll and d3dcompiler_47.dll copied from the HZD tools directories
1920x1080 windows 50hz profile in use

raevol@jabberwock:~$ glxinfo | grep version
server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
    Max core profile version: 4.6
    Max compat profile version: 4.6
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.2
OpenGL core profile version string: 4.6 (Core Profile) Mesa 20.0.8
OpenGL core profile shading language version string: 4.60
OpenGL version string: 4.6 (Compatibility Profile) Mesa 20.0.8
OpenGL shading language version string: 4.60
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 20.0.8
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
    GL_EXT_shader_implicit_conversions, GL_EXT_shader_integer_mix, 
raevol@jabberwock:~$ lshw -c video
WARNING: you should run this program as super-user.
  *-display                 
       description: VGA compatible controller
       product: Ellesmere [Radeon RX 470/480/570/570X/580/580X/590]
       vendor: Advanced Micro Devices, Inc. [AMD/ATI]
       physical id: 0
       bus info: pci@0000:01:00.0
       version: c7
       width: 64 bits
       clock: 33MHz
       capabilities: vga_controller bus_master cap_list rom
       configuration: driver=amdgpu latency=0
       resources: irq:135 memory:c0000000-cfffffff memory:d0000000-d01fffff ioport:e000(size=256) memory:dfd00000-dfd3ffff memory:c0000-dffff
WARNING: output may be incomplete or inaccurate, you should run this program as super-user.

log: https://gist.github.com/mickeylyle/375dbefe65a2c67b28ac0f6e37842803

Hello @mickeylyle, as mentioned in the couple comments just before yours, please use mesa 20.1.9 or newer with this game. You can use a PPA like oibaf or kisak-mesa to get an updated mesa build for your system.

VKx

Thanks. I was looking for their discord so I can see how their development was going. :smile:

Thanks @kisak-valve sorry for missing that!

I installed your PPA, and tried the game on both Proton-5.9-solace-edition and Proton-5.9-GE-6-ST. Both get me through the SIE and Guerrilla logos, and the latter even lets me see a few frames of what I assume is the menu background, but both crash immediately after.

https://gist.github.com/mickeylyle/699fcbe5f136178edccabab2d6c08ca3

Since my last comment, the game received a 2GB update (Shader-Pre-Caching), now I can see the loading screen briefly before it crashes.
New log, I saw an entry that it now loads d3dcompiler_47.dll from the game's root folder:
http://ix.io/2zFK

@TheHooly This looks quite suspicious (the first and the last message):

264:warn:d3d12_swapchain_acquire_next_vulkan_image: Failed to acquire next Vulkan image, vr -1000001004.
264:warn:select_vk_format: Failed to find Vulkan swapchain format for DXGI_FORMAT_R10G10B10A2_UNORM.
264:warn:d3d12_swapchain_create_vulkan_swapchain: Buffer count 2 is not supported (3-16).
264:warn:d3d12_swapchain_create_vulkan_swapchain: Swapchain dimensions 1920x1080 are not supported (3828-3828 x 2129-2129).

Maybe try with DXVK's dxgi.dll?

I wouldn't be surprised if some window geometry or buffer shenanigans by the game would be responsible for the "unexplainable" crashes (if it's not the unreasonable resource management), as the game e.g. still has the weird blurry upscaling bug on Windows at times. I basically tried everything imaginable and every other game like WoW D3D12 or Hitman 2 D3D12 work without crashes, afaict. But this thing just always crashes after a few seconds in the menu.

It doesn't crash, it runs perfectly well. You have to follow the instructions carefully.

There basically are no instructions to follow with a clean prefix and recent Proton-GE, thanks to protontricks. Anyhow, I read every comment in this thread and tried every suggestion. It has even gotten worse with game patches. It can crash even earlier when using the "wrong" config with respect to resolution/window mode, but thanks to ArturWroblewski's efforts this does not seem to be the reason why it ultimately fails here.

Proton log:
steam-1151640.log

Here are instructions to follow:
https://software.kaminata.net/linux-wine-games/horizon-zero-dawn-linux-wine/

Thanks, but nothing there what I would have missed.

Btw. no difference between mesa-git and amdvlk-pro, games crashes entirely the same before reaching the menu (or in the menu).

If you deleted your prefix and you have a cloud save, sometimes you need to create the Horizon Zero Dawn directory in the prefix user's My Documents folder or else the game will crash. I don't see that part commonly cited but I've experienced it personally. :smile:

Yes, thanks. I stumbled over this a few times, thus I disabled cloud sync for HZD and deleted the prefix afterwards.

Have you tried creating the folder anyways?

Well, the game could successfully create it with the current clean prefix and there I've tested all configs provided by ArturWroblewski. :(

I saw someone mention a weird blurry upscaling bug on Windows. I also encountered it, and it was solved by "Disable display scaling on high DPI settings" or similar (e.g. "Override high DPI scaling behavior" set to "Application") setting in the compatibility tab of executable's properties.
The game really does use a strange approach to window management, such as invoking an "SetProcessDpiAwarenessContext" system routine to set it's DPI awareness, when according to good practices it should instead use an app manifest for that.
That said, has anyone having issues with Fullscreen \ Borderless Window tried to enable "Emulate Virtual Desktop" in Wine \ Proton settings?

I just wanted to comment on the success of running this game on my system. I'm currently running mesa 20.3.0_devel.128992.447cef4a71d-1 with Proton-5.9-GE-6-ST. The only thing I had to do was copy "Horizon Zero Dawn/Tools/ShaderCompiler/PC/10.0.18362.0/x64/d3dcompiler_47.dll" to the root "Horizon Zero Dawn" folder.

I should mention that I'm running all amd hardware. The Ryzen 9 3900XT and Radeon RX 5700 XT. I haven't noticed any floating textures, crashes, or anything like that.

Based on @Develon5543's report, removing dxcompiler.dll that I had copied from Tools and the profile.dat that I had installed from previous instructions in this thread got me a few more frames into the menu! But then crashed again.

https://gist.github.com/mickeylyle/db6e2476d901c8ccc8b6310fe58356d6

@Develon5543 you shouldn't even have to copy d3dcompiler_47, there is a protonfix built into my build that does it for you (its the same thing as running winetricks d3dcompiler_47), but you need wine and winetricks installed on your system for protonfixes to work in my builds.

Unrelated:
Tested on Nvidia 1660 Super with 455.23.04 driver and can confirm no more floaties.

@GloriousEggroll sorry to butt in, I'm following along trying to get mine working. I didn't know winetricks was needed, so I just installed that. I also was running wine-stable so I just upgraded to wine-devel. Now instead of just crashing, my game does lots of fun unpredictable things, like hanging on a black window indefinitely, or fully crashing steam.

Is there a recommended Wine version to run? I'm on Ubuntu 20.04.1 to save you a scroll.

Also is there a way to "start fresh"? I know I can uninstall the game, but does that remove the prefix? Can I get a fresh start without re-downloading 60 GB of game data?

@GloriousEggroll sorry to butt in, I'm following along trying to get mine working. I didn't know winetricks was needed, so I just installed that. I also was running wine-stable so I just upgraded to wine-devel. Now instead of just crashing, my game does lots of fun unpredictable things, like hanging on a black window indefinitely, or fully crashing steam.

Is there a recommended Wine version to run? I'm on Ubuntu 20.04.1 to save you a scroll.

Also is there a way to "start fresh"? I know I can uninstall the game, but does that remove the prefix? Can I get a fresh start without re-downloading 60 GB of game data?

No, uninstalling the game usually doesn't remove the prefix. Install "protontricks" however you want (basically protonised winetricks), then use "protontricks --gui" in a terminal. Choose the game you want, in this case, Horizon. Then choose the "default wineprefix", then "remove prefix", in the menu after that.

I've rebased my fork on latest VKD3D-Proton for the hashmap revert. Played for more than 20 minutes running around the map and killing Grazers so I should've done the revert properly. :pray: You can download here:

https://cloud.intersectraven.tech/s/gMLxRTxirraFEN9

@GloriousEggroll I tested with rtx 2080 and 455.23.04. With Proton-5.9-GE-7-ST the game crashes immediately. With the configuration from here https://reddit.com/r/linux_gaming/comments/j1xeup/horizon_zero_dawn_complete_edition_works_on/ I have floaties everywhere and the game is unplayable. What else did you configure besides the d3dcompiler_47.dll file?

@Saancreed the vulkan beta driver didn't fix anything.

Update - the save actually saves the floating objects too. I restarted the save with the 'solance edition' and the floaties disappeared.

Update2 - floating rocks are still there but most things are on the ground now.

@trialism Can you try the 455.22.04 Nvidia drivers? I'm not sure about whether the fix is 455.23.04 since that driver was released for 3000 series support so maybe the fix hasn't been properly applied there yet. Or if you can't update (or downdate or whatever since the versions are weird with those beta releases :smile:), try the d3d12.dll I posted before yesterday's that wasn't based on latest VKD3D-Proton.

@trialism I used a clean prefix with those drivers on a 1660 super and it ran ootb without any issues. I did not use any custom configurations. To further note, I continued from a save and had no floating rocks.

-edit- I just tried again with my release build that was made -after- the d3d12 change to intersecraven's git from yesterday and am also facing a crash. looking into it now.

-edit2- just tried on my amd rig with a clean prefix and fresh download and it fired up right away. absolutely no issue. going to double check the nvidia drivers on my nv rig

-edit3- it's related to some patch update in my latest release that nvidia drivers dont like. I tested both driver versions and no luck. Reverted to GE-6 and it fired up. Looking into the cause now.

-edit4- found the bad patch. it's one of the pending upstream wine patches. Ill let the auther know and update my release

Hello. I have successfully failed to run HZD using the instructions provided by mozo78 (for which I am grateful). I have attached the log. Specifically I am getting the crash after the black loading screen once the text SONY ENTERTAINMENT begins to fade.

I would also like to add that I used kisak-mesa. glxinfo is giving me a mesa version of 20.1.5. If this is insufficient than I request assistance updating it further.

Thank you.

steam-1151640.log

Updated my GE build, Tested and working on both nv and amd:
https://github.com/GloriousEggroll/proton-ge-custom/releases/tag/5.9-GE-7-ST

AMD users need mesa 20.1.9 or higher, Nvidia users 455.22.04 beta or higher

@GloriousEggroll 455.23.04
You can edit the NVIDIA driver version. It have to be Vulkan beta 455.22.04 not 455.23.04.
Thanks for the new amazing release!

Updated my GE build, Tested and working on both nv and amd:
https://github.com/GloriousEggroll/proton-ge-custom/releases/tag/5.9-GE-7-ST

AMD users need mesa 20.1.9 or higher, Nvidia users 455.22.04 beta or higher

Dang! I forgot to push the merge I did this morning where HansKristian fixes the fullscreen option! Anyways, I pushed it to my fork just now so anyone who wants to compile it can do so. Again, use the PERSONAL branch. :smile:

@GloriousEggroll 455.23.04
You can edit the NVIDIA driver version. It have to be Vulkan beta 455.22.04 not 455.23.04.
Thanks for the new amazing release!

Either version works, tested both.

I tested 455.23.04 and actually there are floating objects. The bug is fixed in Vulkan beta 455.22.04.

Maybe 455.23.04 just had a "partial" fix which greatly reduces the chances of the floaties happening? I remember I experienced it once but never again after that so I'm inclined to believe that the fix is already in 455.23.04 ever since I read from the VKx discord that the corruption can be saved on the save file. Dunno for sure though. What I'm sure of is with 455.22.04 it NEVER happened with whatever scenario I could simulate it before. :smile:

I tried the 455.22.04 driver with the latest 5.9-GE-7-ST and it worked, thanks! It also works with fullscreen and freesync, altabbing is ok and there were no visual artifacts. I only experienced one issue: after 20 minutes my VRAM leaked away and the game stopped working.

I tried the 455._22.04_ driver with the latest 5.9-GE-7-ST and it worked, thanks! It also works with fullscreen and freesync, altabbing is ok and there were no visual artifacts. I only experienced one issue: after 20 minutes my VRAM leaked away and the game stopped working.

Hmmm... I left out a part in the destroy since the supporting code was ripped out and I wasn't keen on reimplementing it so maybe that's needed for some devices which I ASSUME has low VRAM. How much VRAM do you have just to verify? insert the usual programmer excuse of "it worked on my machine" here :laughing:

I tried the 455._22.04_ driver with the latest 5.9-GE-7-ST and it worked, thanks! It also works with fullscreen and freesync, altabbing is ok and there were no visual artifacts. I only experienced one issue: after 20 minutes my VRAM leaked away and the game stopped working.

@trialism can you try this if it improves your situation? Just copy the relevant dll to your HZD directory so that you don't overwrite the one bundled with GE.
https://cloud.intersectraven.tech/s/wG9eyH8eScxJeQ5

@intersectRaven I have 8GB. I will try to run HZD with that DLL for a bit.

@intersectRaven no crashes after an hour of gameplay at 1440p and 100% resolution scale! The VRAM did creep up from 6.9GB to 7.7GB but it was still working.

There are two things I observed(not related to crashes): the game will lose vsync temporarily if I alttab while it's running but it doesn't happen if I pause it before switching windows. After losing vsync(blit vs flip mode) I can regain it if I pause the game and alttab twice.
The other thing is the cpu bottlenecking - most of my dips to 50-60Fps is from heavy single core utilization. The game is not using most cores but it pushes my ryzen 3600 which is usually reaching 4.4ghz.

@intersectRaven no crashes after an hour of gameplay at 1440p and 100% resolution scale! The VRAM did creep up from 6.9GB to 7.7GB but it was still working.

There are two things I observed(not related to crashes): the game will lose vsync temporarily if I alttab while it's running but it doesn't happen if I pause it before switching windows. After losing vsync(blit vs flip mode) I can regain it if I pause the game and alttab twice.
The other thing is the cpu bottlenecking - most of my dips to 50-60Fps is from heavy single core utilization. The game is not using most cores but it pushes my ryzen 3600 which is usually reaching 4.4ghz.

Nice to hear. I think the vsync concern you have will be addressed in the next PR in VKD3D-Proton by HansKristian. After it's merged I'll also merge it in my fork.

No, uninstalling the game usually doesn't remove the prefix. Install "protontricks" however you want (basically protonised winetricks), then use "protontricks --gui" in a terminal. Choose the game you want, in this case, Horizon. Then choose the "default wineprefix", then "remove prefix", in the menu after that.

Any non-protontricks way to do that? Not interested in screwing with some pipx hackwork.

No, uninstalling the game usually doesn't remove the prefix. Install "protontricks" however you want (basically protonised winetricks), then use "protontricks --gui" in a terminal. Choose the game you want, in this case, Horizon. Then choose the "default wineprefix", then "remove prefix", in the menu after that.

Any non-protontricks way to do that? Not interested in screwing with some pipx hackwork.

You can always manually delete the prefix's folder.

You can always manually delete the prefix's folder.

Thanks, I appreciate it! Trying the new GE build now. "Optimizing the game" step is running way faster.

Still no luck here. Crashes after the logos.

steam-1151640.log

Hi all

I have arch linux latest kernel and wine staging 5.18 on a lower end system using a ryzen 5 2400g and a rx480 4gb gpu

I also use the latest mesa-git drivers and have tried all the options above

GE build 5.9-7
GE build 5.9-6
Tkg-proton 5.18.r3

i have tried getting this game to run and no matter what proton build i use it displays the sony logo then the guerilla logo starts to play the intro movie then crash with the error box. sometimes it twill crash back to desktop or even freeze then throw me out to login screen.

steam-1151640.log
i have attached my steam log and hopefully this may help.

Hi all,

Using Pop!_OS 20.04, Mesa 20.2.99, and AMD, I created a new pfx file using Proton 5.9-GE-7-ST and @intersectRaven 's d3d12.dll

The game is working for the most part, no floating rocks or anything and FPS is pretty stable, but I still get freezes that puzzle me. It seems to happen randomly but almost always only when I'm in the inventory or the map. What's strange is it doesn't look like the kind of freeze I'm used to, the sound doesn't endlessly loop but keeps playing normally, I have a visible mouse cursor that I can control but Mangohud informs me that my FPS is somewhere between 0 and 2 and my latency is off the charts. So it looks like rather than freezing suddenly, my system grinds to a stop, at least graphically.

I can't post my Proton log because it's over 100MB (!!??) but I have about 30 000 lines of

264:fixme:d3d12_swapchain_present: Unimplemented flags 0x200.

Followed by a section repeating some more thousands of lines of

252:fixme:d3d12_swapchain_present: Unimplemented flags 0x200. 216:warn:d3d12_resource_init: Ignoring optimized clear value. 216:warn:d3d12_resource_init: Ignoring optimized clear value. 216:warn:d3d12_resource_init: Ignoring optimized clear value. 216:warn:d3d12_resource_init: Ignoring optimized clear value. 216:fixme:d3d12_swapchain_present: Unimplemented flags 0x200. 216:fixme:d3d12_swapchain_present: Unimplemented flags 0x200. 368:warn:d3d12_pipeline_state_init_graphics: Unused input element 1. 368:warn:d3d12_pipeline_state_init_graphics: Unused input element 2. 368:warn:d3d12_pipeline_state_init_graphics: Unused input element 3. 372:warn:d3d12_pipeline_state_init_graphics: Unused input element 1. 372:warn:d3d12_pipeline_state_init_graphics: Unused input element 2. 372:warn:d3d12_pipeline_state_init_graphics: Unused input element 3. 216:warn:d3d12_pipeline_state_init_graphics: Unused input element 1. 216:warn:d3d12_pipeline_state_init_graphics: Unused input element 2. 216:warn:d3d12_pipeline_state_init_graphics: Unused input element 3. 216:warn:d3d12_pipeline_state_init_graphics: Unused input element 1. 216:warn:d3d12_pipeline_state_init_graphics: Unused input element 2.

and then lines 37 000 to about 1,2 million are repeats of

252:warn:d3d12_command_list_OMSetRenderTargets: RTV descriptor 2 is not initialized. 264:fixme:d3d12_pipeline_state_get_or_create_pipeline: Extended dynamic state is supported, but compiling a fallback pipeline late! 256:fixme:d3d12_swapchain_present: Unimplemented flags 0x200. 268:warn:d3d12_command_list_OMSetRenderTargets: RTV descriptor 0 is not initialized. 268:warn:d3d12_command_list_OMSetRenderTargets: RTV descriptor 1 is not initialized. 268:warn:d3d12_command_list_OMSetRenderTargets: RTV descriptor 2 is not initialized.

Not sure what's going wrong there, any advice would be greatly appreciated !

@Milas227 and @mickeylyle :

Have you tried placing @ArturWroblewski profile.dat in your wine prefix HZD directory ? (instructions higher in the thread), for me and I think many others the game crashes on fullscreen, which is I believe the default setting. Replacing the profile data allow starting in windowed or borderless mode and avoiding this specific crash. I'm not 100% sure that it's what's causing yours, but it's worth a shot if you haven't tried that yet.

What @Chipsse is having is the same issue I am having, but im on Arch and GNOME 3.38 Wayland (happened the same on 3.36).

Was just about to post the proton log myself and saw your post. Same errors in mine.

@Chipsse my game is already running in windowed mode, so I don't think that's an issue. I tried the profile.dat before and it didn't make a difference.

I tried adding @intersectRaven 's d3d12.dll to @GloriousEggroll 's Proton-5.9-GE-7-ST and I'm still crashing in the same place. It did re-run the "optimizing the game" step though.

Hi all.
I have been having great difficulty getting the game to launch after trying to update mesa. Currently the game does not open. When I click play the audio clicks but the screen does not change. I am stuck staring at the steam library until the game closes on its own. I do not get a crash report. I have tried a fresh re-install of the game, wine, kisak-mesa. Prior to this I was able to reach the games loading screen prior to the game crashing with a crash report. Could anyone assist me in getting back to where I started?
steam-1151640.log

To all, if ever you are thinking to upgrade your driver to 455 stable, don't as floaties have appeared again. Stick to 455.22.04 Vulkan beta. Restarted HZD 3 times before the floaties disappeared. I was suspecting this since the issue:

Fixed a bug in a barrier optimization that allowed some back-to-back copies to run unordered

Was not specified in the release notes.

Yes this is exactly my observation. I checked the change log carefuly and I didn't found barrier optimization fix, so it's a good idea sticking to 455.22.04 for now.

@intersectRaven I upgraded to 455.28 and I have no floaties. I played the game twice for 3 hours. Just an idea: I didn't play from the start but maybe you did and that's where the floaties start to appear?

@trialism I usually continue from my last playthrough and after the 3rd restart of the game was the only point I had no floaties which is an indicator of the barrier issue.

@intersectRaven I upgraded to 455.28 and I have no floaties. I played the game twice for 3 hours. Just an idea: I didn't play from the start but maybe you did and that's where the floaties start to appear?

I actually don't play the game. I always load the same save after the cave :)

@Chipsse thank you for the suggestion i have tied proton-ge 5.9-7 in a clean prefix and unfortunately using @ArturWroblewski profiles did not help.

however when it froze it threw me out to login screen and when i checked my xsession log i had this error

amdgpu: Not enough memory for command submission

i think the games eating all the vram and casing the game to crash the amdgpu driver , checking on horizons twitter feed they have said that patch 1.06 is being worked on.

Yes this is exactly my observation. I checked the change log carefuly and I didn't found barrier optimization fix, so it's a good idea sticking to 455.22.04 for now.

I can confirm that the occurrence of floating items has increased with the update to driver 455.28. It doesn't happen every time, but sometimes is more frequent than other times. I'll revert back again to driver 455.22.04.

Is there a fix for this?

Those glitches follow the camera, even in photo mode. Happens on all proton versions, Proton-5.9-GE-7-ST and proton-tkg.

[System]
OS:              openSUSE Tumbleweed
Arch:            x86_64
Kernel:          5.8.14-1-default
Desktop:         KDE
Display Server:  x11

[CPU]
Vendor:          AuthenticAMD
Model:           AMD Ryzen 9 3900X 12-Core Processor
Physical cores:  12
Logical cores:   24

[Memory]
RAM:             31.3 GB
Swap:            3.7 GB

[Graphics]
Vendor:          X.Org
OpenGL Renderer: AMD Radeon RX 5700 XT (NAVI10, DRM 3.38.0, 5.8.14-1-default, LLVM 10.0.1)
OpenGL Version:  4.6 (Compatibility Profile) Mesa 20.1.8
OpenGL Core:     4.6 (Core Profile) Mesa 20.1.8
OpenGL ES:       OpenGL ES 3.2 Mesa 20.1.8
Vulkan:          Supported

It's probably Mesa, so I wait for an update and report back.

@HolySoap

Mesa 20.1.8

As mentioned multiple times in this thread:

AMD users need mesa 20.1.9 or higher, Nvidia users 455.22.04 beta

@GloriousEggroll
Ups sorry about that, but anyway, thank you!

For some reasons, the game will perform a free space check on the root of the drive on which it is installed (Z: per default in the case of Proton), which correspond to / or the root partition on Linux through a standard Proton/Wine environment.

If you have less than 2 GB space on that partition (most probably root partition), even though it is unlikely the game uses it (as opposed to it checking space for the directories it may truly use), the game will refuses to launch displaying a message similar as this:

storage fatal 2gb

@GloriousEggroll I can confirm Proton-5.9-GE-8-ST fixes the fullscreen crash, but I'm still getting the crash after the logos.

I'm on an AMD CPU (and GPU) so I tried your clearcpuid kernel boot paramenter, but that didn't have any effect. The attached log is without it. I did notice my memory usage went from 50% to 100% right before it crashed.

steam-1151640.log

@GloriousEggroll I too have tried proton-5.9-ge-8 and also getting the crash after the logos.

i too also tried clearcpuid kernel boot option but also did not have any affect.

however when i checked my system logs i did notice a kernel run out of memory error just before the crash. not sure if it helps but all info is good info.

my system is ryzen 5 2400g , rx480 4gb vram , 16gb ddr4.

@Milas227 can you post PROTON_LOG? It's more possible for someone to actually pinpoint the problem with logs rather that without as there are too many variables to account.

@intersectRaven my bad !! sorry

attached log as requested
steam-1151640.log

So who got the chance to test it with newest Proton release?
https://github.com/ValveSoftware/Proton/releases/tag/proton-5.13-1b

Haven't tested my "sure-fire out-of-memory error method" since I've continued on my quest inside a metal world. I am using it right now while I finish this Deathbringer so it's playable. I'll test the crash if it still occurs later.

Can confirm it still crashes for me in the same place with 5.13.

steam-1151640.log

edit: I only have 4gigs of video ram and 8 gigs of system ram. Could this be the issue?

Does anyone exprience gameplay as slowmotion with Proton GE 5.9 ST 8? Cannot play the game at all with that.

It works for me with proton 5.13, but I've got around 15 fps. i've got a GTX 960, so it's a bit outdated, but still better than the min spec (GTX 780). The results are the same in low or medium settings. So it's quite unplayable for the moment.

@Skiski A GTX 960 is on par with (if not slightly slower than) a GTX 680/770. A GTX 780 is faster in most cases. On top of that, the game runs pretty poorly overall, and atm the situation is worse on nvidia compared to native. Your results seem to be pretty much as expected.

Just installed it and trying to run with Proton 5.13-1, but I get the error:

err:module:import_dll Library mfc140.dll  (which is needed by L"Z:\\disk3\\SteamLibrary\\steamapps\\common\\Horizon Zero Dawn\\HorizonZeroDawn.exe") not found

Should I try to reinstall proton 5.13? Isn't Proton supposed to download required VC runtimes when missing?

Update I

Copied such files (_mfc140.dll_ - both 32 and 64 bit version) and then the game runs.
I'm playing 3440x1440, details _Ultra_, on 2080 Ti, 455.23.04, 64 GiB of RAM and I7-8700k - on Ubuntu 20.04.

These are the issues:

• The audio crackles, and the voice of characters gets easily out of sync during animated scenes
• After usually 15 minutes the game hard crash (looks like allocates more than 8 GiB of VRam and then it stops) steam-1151640.log. This also happens when running the benchmark and using less VRAM, hence not VRAM related.
• Using the PS4 pad is ok, but the haptic device is instead detected as a _mouse_ hence the game thinks I'm using my keyboard - workaround, use the key 'M' on the keyboard to get to the map.

Unfortunately due to the hard crash, the game is unplayable (you can't progress unless you save every 15 minutes)

Below performance on Ultra on my pc:

@Emanem Try using @intersectRaven's d3d12.dll, see above, there was a download link in one of his recent posts, copy it to System32 (make a backup of yours first), and set to native in Proton's wine settings. This should randomly extend your playtime before the crash to generally playable amounts (it depends on your hardware and other random things, but in good cases it usually is upwards of hours most of the time). If it doesn't work for you, just restore your backup and put the setting back where it belonged.
P.S. Some users have reported Proton overwriting their custom files. Please, refer to their posts above on how to solve this matter.

@RoyShapiro Thanks for the hint, not sure I would want to download a _dll_ from the internet and blindly replacing a file on my pc.
@intersectRaven Would you be able to share a diff/patch of your changes? Happy to recompile it myself.

In general I'm also ok to wait for official fix from Valve (or Nvidia if it's a drivers' issue), given most gamers use Nvidia and this game is now part of "_the list_".

@Emanem Sorry to get ahead of @intersectRaven , but check out his page, you can compile his fork vkd3d-proton repository. I didn't immediately mention it, because a lot of people seem to just want to be able to play the game and may not know how to build stuff themselves.

@Milas227 can you post PROTON_LOG? It's more possible for someone to actually pinpoint the problem with logs rather that without as there are too many variables to account.

Hi @intersectRaven,
I experienced exactly the same occurrence of game crashes, but for me they are random (time to crash goes from a minimum of 15 mins to a max of 2 hours). Here attached my latest steam-1151640.log. Not sure if my report can be helpful.

Here below my specs:
Proton: Proton GE 5.9 ST 8 (no tweaks applied post-install)
OS: Debian GNU/Linux bullseye/sid
KERNEL: 5.8.7
CPU: AMD Ryzen Threadripper 2990WX 32-Core
GPU: NVIDIA GeForce GTX 1080 Ti
GPU DRIVER: NVIDIA 455.22.04
RAM: 64 GB

@LordDaveTheKind your crash seems exactly the issue I experience. Have you already downloaded my dll or compiled from my repo's personal branch? It should at least extend your minimum to more than 15 minutes.

@intersectRaven - First of all, thanks for looking into this. I take we should compile the branch named _personal_? Which build should we execute? _native_ or _cross for d3d12.dll_?

Also, may i kindly ask to summarize the changes you've made? Again, I'm just an amateur in terms of Vulkan and graphics, would like to understand more this _fix_.

@Emanem yes. Just use the simple way. Basically, I traced the error to implementation of hashmap caching for the view object creation so I reverted that. The devs are having difficulty fixing it since they can't replicate it. That's basically the only blocker here. If HansKristian can replicate it, this error will be gone in a night or so.

@Emanem yes. Just use the simple way. Basically, I traced the error to implementation of hashmap caching for the view object creation so I reverted that. The devs are having difficulty fixing it since they can't replicate it. That's basically the only blocker here. If HansKristian can replicate it, this error will be gone in a night or so.

@intersectRaven Do we need to build a _dll_ or _so_? I guess we should compile as _dll/PE_, right?

Thanks for the explanation - knowing how _easy_ it is to make it crash, not sure why "_The devs are having difficulty fixing it since they can't replicate it._".
Do we have modified sources with additional logging which could help the devs?

update

Managed to setup a virtual machine to build the dlls, took me 1 hour... Will try to test the DLL, but looks like proton scripts decide to overwrite my custom libraries... as per above will need to figure it out... and yes, got _floaties_ :)

update 2

Created a new Proton profile to use your libraries and testing. Can confirm that with Proton 5.13-1b libraries the game crashes consistently every 15 mins. Will report later on with your libs...

update 3

Confirmed with your patch the game doesn't crash as frequently as with vanilla Proton 5.13-1b.
I have created a simple custom Proton 5.13-1b with custom d3d12 if people are interested to using it.

Do we need to build a _dll_ or _so_? I guess we should compile as _dll/PE_, right?

You _have to_ compile as dll/PE, because HZD requires OpenExistingHeapFromAddress (or at least it used to in 1.01) which cannot be implemented for .so builds.

Managed to setup a virtual machine to build the dlls, took me 1 hour...

You can cross–compile them using mingw-w64 toolchain, check if your distro provides it (Arch has most packages in official repos except mingw-w64-tools; this one is required because it provides widl, but it's available in AUR). Lesser headache than a VM for sure.

looks like proton scripts decide to overwrite my custom libraries...

The easiest solution to that is to copy d3d12.dll next to HorizonZeroDawn.exe and set WINEDLLOVERRIDES to d3d12=n. This way it will be loaded before whatever Proton copies into your prefix' System32 directory. No need to create separate copy of Proton just to replace one library :stuck_out_tongue:

and yes, got _floaties_ :)

Yeah, Vulkan Dev driver is still required to fix that.

But you probably knew most of that already. Also you could try using DXVK's dxgi.dll (WINEDLLOVERRIDES='dxgi=n', separate multiple overrides with ;), it _might_ help improve the stability.

Myself, I'm trying to play on AMD Ryzen 7 3750H and GTX 1660 TI Mobile, it's fairly stable now and while 6 GB of VRAM is… not much for this game, on "Favor Performance" preset usage is around ~4-5 GB but HZD's built–in benchmark tool still claims that CPU is the bottleneck here. Except the game seems to limit itself somehow because CPU utilization is only around 50%. Any ideas why is that happening? Or is this fully intended and for you guys the game also uses only half the CPU's processing power? Fwiw I'm using Proton 5.13 but _outside_ Soldier Runtime.

@LordDaveTheKind your crash seems exactly the issue I experience. Have you already downloaded my dll or compiled from my repo's personal branch? It should at least extend your minimum to more than 15 minutes.

hi @intersectRaven,
I compiled and deployed your version of vkd3d-proton, and it actually seems to work fine. I haven't had the chance for extensively testing it though so far. I'll keep you posted of course.

Cheers,
Dave

@intersectRaven Does the crash happen on both Nvidia and/or AMD and/or Intel?
If yes, then perhaps is the cache itself - or the drivers may not like re-using of cached elements (amongst multiple threads?).

Had a quick look at the cache code (latest from github) and unless there is an issue with the key elements to do the lookup (i.e. not using all the inputs to Vk functions as _key elements_), this may be a drivers' issue?

@doitsujin @HansKristian-Work (tagged folks whom have committed the hash lookup code) @intersectRaven

First let me write I have huge appreciation for Valve/Codeweavers developers - I'm just an amateur and I hope the below can help.

It is incredibly easy to reproduce the crash with H:ZD; if you run on Nvidia 455.23.04 (my case 2080 Ti on a 3440x1440 resolution) and Ubuntu 20.04 (18.04 too), just run the game-integrated benchmark with _Ultimate Quality_ settings and the second time it will most likely crash/get stuck.
The _good news_ (if we can call it as such) is that this doesn't seem to be a threading issue, but simply a resource (?driver?) related issue - in fact adding below logs in such critical piece of code, slightly slows it down but the issue happens no matter what.

I have added a _cache_ log to the master version of vkd3d (see vk_cache_log.patch.txt - just replace the hardcoded log file with a path of your choosing). This prints out accessing the cache and the hashes plus underlying key data to try understanding what is going on. Furthermore it also prints out behaviour in case of misses (i.e. need creation of resources) or cache hits.

• The cache seems to be effective (at least with H:ZD). When running the benchmark, we get 86% hits, which is _not bad_ at all
• The crash appears to happen related to the creation of a buffer view inside _vkCreateBufferView_, when we pass a very large offset (41514912)
• Slightly before the crash, there is a set of similar failures in creating a buffer view on the same vkBuffer with similar parameters - looks like another thread tries to create multiple views on the same buffer but it fails, nonetheless it tries ~10 times
• It's worth noting that the call that crash/blocks asks to create a view but with a different format than the ones which fail before (the latter do return _false_ but the code carries on, this one just blocks this rendering thread)
• The same thread that fails (208 in the log), manages to acquire a cached vkBufferView right before the last call
• There is a small bug in one exit condition in the function vkd3d_view_map_create_view, when we return NULL; but we don't release the lock before - again this is _not_ the issue, but a minor defect

Question: although the cache has a very high hit ratio, is it worth performance wise? Is the cost of locking and managing the hash map worth it?

I've attached both the full compressed log (700 MiB uncompressed vkd3d.log.tar.xz.zip - it's an xz file, not zip) and the last 10000 lines (vkd3d-tail.log)

I hope this can help and if you believe this is rubbish, apologies for the time wasted.

UPDATE I

Extended the log to print out right before the call to vkCreateBufferView and this is the result:

ThID: 248   Got it: 0000000055E69648
ThID: 248   map:000000000084CDD8    hash: 3513745393    key: VKD3D_VIEW_TYPE_BUFFER 140231365012824 000000006F980F98 10306000 262144
ThID: 248   Got it: 00000000562F8AE8
ThID: 248   map:000000000084CDD8    hash: 3513745393    key: VKD3D_VIEW_TYPE_BUFFER 140231365012824 000000006F980F98 10306000 262144
ThID: 248   Got it: 00000000562F8AE8
ThID: 248   map:000000000084CDD8    hash: 3513745393    key: VKD3D_VIEW_TYPE_BUFFER 140231365012824 000000006F980F98 10306000 262144
ThID: 248   Got it: 00000000562F8AE8
ThID: 200   map:000000000084CDD8    hash: 236646252 key: VKD3D_VIEW_TYPE_BUFFER 140231365012824 000000006F981890 0 1703936
ThID: 200   Got it: 000000005683EA18
ThID: 200   map:000000000084CDD8    hash: 3744403955    key: VKD3D_VIEW_TYPE_BUFFER 140231365012824 000000006F981890 24863000 96256
ThID: 200   Proceeding to create
ThID: 200   vkCreateBufferView(284069520, {140231365012824, 140230682214498, 24863000, 96256})

and can confirm it's a drivers lock-up (the function call vkCreateBufferView does not return).

My guess is that we would be running out of memory/resources to keep track of all the buffer views. At that time we have 483951 cached buffer views and 166261 specifically for that buffer (32771 for that buffer and particular format) - I wouldn't be surprised if we're hitting a hard limit in the driver - and right before this happens we can see in the log the calls to vkCreateBufferView start returning != VK_SUCCESS (see attached log vkd3d-detailed.log - 11 of those fail and then the lock-up).

I think we should control the cache and limit it, perhaps?

Have anybody experienced crash on H:ZD startup when vulkan shaders are
generated?
For me it consumes all RAM and dies together with steam.

On Wed, Oct 21, 2020 at 3:23 PM Emanem notifications@github.com wrote:

@doitsujin https://github.com/doitsujin @HansKristian-Work
https://github.com/HansKristian-Work (tagged folks whom have committed
the hash lookup code)

First let me write I have huge appreciation for Valve/Codeweavers
developers - I'm just an amateur and I hope the below can help.

It is incredibly easy to reproduce the crash with HZ:D; if you run on
Nvidia 455.23.04 (my case 2080 Ti on a 3440x1440 resolution) and Ubuntu
20.04 (18.04 too), just run the game-integrated benchmark with Ultimate
Quality settings and the second time it will most likely crash.
The good news (if we can call it as such) is that this doesn't seem to
be a threading issue, but simply a resource (?driver?) related issue - in
fact adding below logs in such critical piece of code, slightly slows it
down but the issue happens no matter what.

I have added a cache log to the master version of vkd3d (see
vk_cache_log.patch.txt
https://github.com/ValveSoftware/Proton/files/5415675/vk_cache_log.patch.txt

• just replace the hardcoded log file with a path of your choosing). This
  prints out accessing the cache and the hashes plus underlying key data to
  try understanding what is going on. Furthermore it also prints out
  behaviour in case of misses (i.e. need creation of resources) or cache hits.

• The cache seems to be effective (at least with HZ:D). When running
  the benchmark, we get 86% hits, which is not bad at all
• The crash appears to happen related to the creation of a buffer view
  inside vkCreateBufferView, when we pass a very large offset
  (41514912)
• Slightly before the crash, there is a set of similar failures in
  creating a buffer view on the same vkBuffer with similar parameters - looks
  like another thread tries to create multiple views on the same buffer but
  it fails, nonetheless it tries ~10 times
• It's worth noting that the call that crash/blocks asks to create a
  view but with a different format than the ones which fail before (the
  latter do return false but the code carries on, this one just blocks
  this rendering thread)
• The same thread that fails (208 in the log), manages to acquire a
  cached vkBufferView right before the last call
• There is a small bug in one exit condition in the function
  vkd3d_view_map_create_view, when we return NULL; but we don't release
  the lock before - again this is not the issue, but a minor defect

Question: although the cache has a very high hit ratio, is it worth
performance wise? Is the cost of locking and managing the hash map worth it?

I've attached both the full compressed log (700 MiB uncompressed
vkd3d.log.tar.xz.zip
https://github.com/ValveSoftware/Proton/files/5415679/vkd3d.log.tar.xz.zip
) and the last 10000 lines (vkd3d-tail.log
https://github.com/ValveSoftware/Proton/files/5415676/vkd3d-tail.log)

I hope this can help and if you believe this is rubbish, apologies for the
time wasted.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/4125#issuecomment-713530577,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAABPU6GAI7HBC4OGKYLFVTSL3HFLANCNFSM4PXXJIQA
.

Have anybody experienced crash on H:ZD startup when vulkan shaders are generated? For me it consumes all RAM and dies together with steam.
…

Same happening to me. Just disabled the Vulkan Shaders and it worked perfectly.

@LordDaveTheKind your crash seems exactly the issue I experience. Have you already downloaded my dll or compiled from my repo's personal branch? It should at least extend your minimum to more than 15 minutes.

I can confirm it is more stable. Working without any crash or interruptions for hours.
Performance is 40~50fps at 1440p with 70% of Resolution Scaling in the game Graphic Settings.

Anyone working on the post-logos crash? Please feel free to reach out to me, I'd be happy to assist with any debugging or testing.

@intersectRaven Hi! There was a recent pull request to vkd3d-proton (https://github.com/HansKristian-Work/vkd3d-proton/pull/318) that is said to have fixed the hashmap issue, and it's now marked as closed. However, while I'm seeing improvements in Resident Evil 2, HZD still freeze-crashes for me (RTX 2070, 456.71 driver), just the same way it did before this update (after 10-30 minutes of playtime). Can you please retest and confirm?

Yeah. I've already mentioned this on their Discord so the devs are aware. Did it improve playtime though? For me, although it still crashed, it did improve as I was able to play longer on my "sure crash ride route". HZD is really a pain to debug for them.

@intersectRaven I can imagine... Alas, even if it improved at all, it is within the margin of error. I've done three tests, different settings, all crashed within 15 minutes.

The PR should indeed have eliminated the need to create and maintain VkBufferView objects for raw buffer types. I guess it's still possible that the game is spamming unique typed buffer views (need to verify), which must still use VkBufferView. If this is truly the case, there isn't much we can do. The older descriptor implementation (and only viable "fix") was extremely slow on CPU to the point that we were getting 30% GPU utilization.

@HansKristian-Work Hello, thanks for looking into this issue. Unfortunately, if one AAA game, even if it is an admittedly low-quality port, does that so may the others, and considering there will only be more DX12 exclusive titles, this is a serious problem, IMHO, worth solving. While it may not be considered viable by project standards, many console Emulators include "Hacks" options for stubborn games, that have fringe cases like this one. May I in good faith suggest, that if no graceful solution can be found, there can be an option to implement "fringe case fixes", or "hacks" or something similar as a sort of add-ons to vkd3d, that make specific games work at the expense of optimization relative to the specific game? I specifically not suggesting forked builds of vkd3d, as in this case, they will have to be rebased each time the core codebase gets updated, which will prevent them from using other newer features of updated builds that do not relate to said "hacks".

P.S. Do I understand correctly, that if the above case is true, then the game spams buffer views that do not follow the following statement:
((desc->Format == DXGI_FORMAT_UNKNOWN && desc->Buffer.StructureByteStride) || !!(desc->Buffer.Flags & D3D12_BUFFER_SRV_FLAG_RAW))
yet, in theory, should be?

Yes, if that condition fails, it is a typed buffer view, and we are forced to create a new VkBufferView (and keep it alive until the end of time unless we can prove it is not possible to access anymore, which is a hard problem without introducing ~30k+ locks per frame) if the offset/size/formats have not been seen before. I'll need to verify if this is what triggers the issue, and hopefully we can find a workaround where we somehow asynchronously garbage collect unused VkBufferViews. Not sure how this is going to work though ...

@HansKristian-Work Thanks for the confirmation. I was thinking of a garbage collection solution. My initial thoughts were to keep some non-obtrusive statistics of how many buffers of what kind had been created such as an array and using DXGI_FORMAT enumeration as index (provided it doesn't go beyond documented values). Also see how many buffers of what kind are created per frame / second. Then have a threshold value, kind of like those used in anti-DDoS prevention mechanisms. If too many buffers of a certain kind are created, they can be further investigated. So no need to lock anything, until we have a value we deem suspicious (buffers of certain kind keep being rapidly created but are not getting deleted within some timeframe) as "proof" that certain kind of buffer may need checking. Sorry if that solution sounds naive, this topic is new to me.

Actually, there is the offset buffer system that could be used here as well. Guess it's not so bleak after all.

Actually, there is the offset buffer system that could be used here as well. Guess it's not so bleak after all.

The game _does_ indeed create 10s of thousands of VkBufferView very quickly; the cache gets full and there is a driver lock-up, the only way is indeed with offset buffer system. I hope you guys managed to get that one out, _H:ZD_ is one hell of a game! :)

Ps. current @intersectRaven patch does work, but the game needs resetting every 1 hour or when moving around too much, otherwise it becomes sluggish.

https://github.com/HansKristian-Work/vkd3d-proton/pull/349 is a PR in flight which should fix the OOM issue. I hate every thing about this, but guess we have no choice. I get no view spam anymore, and appears to renders correctly.

This also plagued Death Stranding (go figure), and that game sees no spam either.

@HansKristian-Work Complied this PR, RTX 2070, 456.71 driver, 50+ minutes in + Alt-tabbing included (used to make the issue happen faster), no problems so far! Great job! Thank you!

Edit: This PR also seems to greatly reduce micro-stuttering, that was very prevalent just after game recompiles it's cache.

Will this be merged with the main code or compiling the newest git code is enough? I don't know how to compile just this PR...

The intention is to merge this, yes. Pending review and more testing.

Thank you :)
Will be happy somebody to share his lib :)

@mozo78 vkd3d-proton-standalone-r2836.9f01ff72-1-x86_64.pkg.tar.gz

Extract the package and take d3d12.dll from usr/share/vkd3d-proton/x64. Also, if you're on Arch, you can simply install this package with pacman -U for use in normal Wine prefixes, just like one would with DXVK.

Thank you very much!

HansKristian-Work/vkd3d-proton#349 is a PR in flight which should fix the OOM issue.

This moved my crash from after the Guerilla logo to during the Sony logo. But the game doesn't take up all my memory before crashing anymore! :)

steam-1151640.log

@mickeylyle
In your log there's this entry:
2171.498:00bc:00c0:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\D3DCOMPILER_47.dll" at 0000000014C60000: native
Did you copy d3dcompiler_47.dll from HZD's Tools\ShaderCompiler\PC\10.0.18362.0x64d3dcompiler_47.dll to game's root?
I.e. to where HorizonZeroDawn.exe is located? It would seem that proton is trying to load it's default d3dcompiler_47, rather than HZD's own, a known issue. If not, try doing so.
_If_ that doesn't help, then intuition tells me, you might have a problem with media playback (i.e. prerendered bink movies), that the game uses for logos and menu background.

Compiled the branch and the game has been running without crashes for a good 3 hours back to back (2080 Ti with 455.23.04).

I got some frame drops in some locations, but I'm playing 21:9@1440p everything maxed out... it's almost 60% of 4K in terms of rendered pixels.

Is HZD really problematic with Nvidia 455.28?
I can't find a proper way to install any other versions starts with 455.
AFAIK, Ubuntu based distros will not install drivers downloaded from Nvidia website.

Here I run the Epic Games version of HZD and still stuck at the crash dialog as posted by OP.

You can install NVIDIA Vulkan beta drivers on Ubuntu too.

Is HZD really problematic with Nvidia 455.28?
I can't find a proper way to install any other versions starts with 455.
AFAIK, Ubuntu based distros will not install drivers downloaded from Nvidia website.

Here I run the Epic Games version of HZD and still stuck at the crash dialog as posted by OP.

Yes. There's still a chance of artifacting on it (ie floaties). Just wait for the newer 455.38 to be released for your distro. That has the full barrier fix.

Did you copy d3dcompiler_47.dll from HZD's Tools\ShaderCompiler\PC\10.0.18362.0x64d3dcompiler_47.dll to game's root?
I.e. to where HorizonZeroDawn.exe is located? It would seem that proton is trying to load it's default d3dcompiler_47, rather than HZD's own, a known issue. If not, try doing so.

Didn't fix it, see attached log.

_If_ that doesn't help, then intuition tells me, you might have a problem with media playback (i.e. prerendered bink movies), that the game uses for logos and menu background.

Previously I have gotten past the logos to see the first few frames of the menu background. Any way I can test/debug this?

steam-1151640.log

(Disclaimer - Linux noob at work)
Did all steps I've seen in here.
Copied the DLL's tot he game root folder.
got the mesa stuff in place. (found a guide in here somewhere)
Proton versions I've tryed out:
5.0-9 (this version crashes HZD on startup)
5.13-1 (This version runs HZD for 20 secs ish)

The 5.9-GE-6-ST, 5.9-GE-7-ST, 5.9-GE-8-ST also downloaded, however I can't find them in the droppdown menu in steam settings -> Steam-Play or in the game properties -> Force the use of a specific *

I've copied these Proton folders into the .steam/steam/compabilitytools.d aswell as into the /steamapps/common folder (I found a Proton 5.0 folder there so I thought why not) However I cannot find it when i'm in steam, and yes I did restart steam aswell as the whole pc several times.

Also got the windowed mode preset file.

The game started up and configured the first time, let me play about 40 minutes - then crashed with that crash popup window.
After this I've been able to start the game and continue playing for 20 secs. (every 3-4 times I've started it up as it tends to crash on loading screen)

System:
Pop!_OS
Ryzen 5 1600x
8GB ddr4
Radeon RX 580 8GB
MSI gaming plus max B450

@nodrugz

Did you extract the packages you downloaded ? If you just dropped the tar.gz in the folder, it will not work.
If yes, do you have Lutris installed ? Depending on how you installed Steam, you might have two installs, most likely under /home/USER/.steam/debian-installation and under /home/USER/.local/share/lutris/runtime/steam . Lutris will use the one in its runtime directory and this one won't see the files in the other installation directory if you put them there.
Also, if you're running Winesteam via Lutris, it is considered a different install still.

@Chipsse
Packages are extracted and put into
/home/USER/.steam/debian-installation/compabilitytools.d/
and
/home/USER/.steam/steam/steamapps/common/

I do not have lutris installed.
Should I ?

Also: kernel 5.8 if that makes any difference.

@nodrugz

It's not necessary but it's really helpful to organize games and easily tweak settings, especially if Steam is not your only source for games, there are also instructions on Glorious Eggroll Proton fork page to use it with Lutris ( https://github.com/GloriousEggroll/proton-ge-custom )
Some more things you can try :
Did you follow all the instructions of Glorious Eggroll, and do you have all the necessary dependancies ?
Did you install the Linux native version of Steam or the Wine version ?
If you follow the link /home/USER/.steam/root, where does that take you ?

@nodrugz don't forget to move the contents of the dist folder into one level below your custom Proton folder, so you'll have paths like:

• compabilitytools.d/Proton-5.9-GE-8-ST/bin
• compabilitytools.d/Proton-5.9-GE-8-ST/lib
• etc.

@nodrugz

Sorry about the long response time, what's in the compatibilitytools.d that's in the directory the .steam/root/ links takes you ? Is that the same folder where you already placed the ProtonGE files ? If not, try placing them here. You can also try reinstalling Steam through the Pop!_Shop and see if that helps.

@Chipsse

No worries, since last update I've wiped my hd and installed majaro, then steam, then proton-5.6-GE
Got steam to recognize it and got HZD "running".
The starter movie stuttered along and smoothed out.
Starting game play there was tons of graphics anomalies.

now I need to find the guide for installing mesa drivers and VKD3D from HansKristian-Work, tho I find the gudes a little incomplete for a beginner.

Question tho:
Proton-5.9-GE doesn't it contain the same as Proton-5-6-GE and more updates?

Installing GPU Driver with DXVK support

nVidia GPU
sudo pacman -S nvidia nvidia-utils lib32-nvidia-utils nvidia-settings vulkan-icd-loader lib32-vulkan-icd-loader

AMD GPU
sudo pacman -S lib32-mesa vulkan-radeon lib32-vulkan-radeon vulkan-icd-loader lib32-vulkan-icd-loader

Intel GPU
sudo pacman -S lib32-mesa vulkan-intel lib32-vulkan-intel vulkan-icd-loader lib32-vulkan-icd-loader

Installing Wine
sudo pacman -Syu
sudo pacman -S wine-staging giflib lib32-giflib libpng lib32-libpng libldap lib32-libldap gnutls lib32-gnutls mpg123 lib32-mpg123 openal lib32-openal v4l-utils lib32-v4l-utils libpulse lib32-libpulse libgpg-error lib32-libgpg-error alsa-plugins lib32-alsa-plugins alsa-lib lib32-alsa-lib libjpeg-turbo lib32-libjpeg-turbo sqlite lib32-sqlite libxcomposite lib32-libxcomposite libxinerama lib32-libgcrypt libgcrypt lib32-libxinerama ncurses lib32-ncurses opencl-icd-loader lib32-opencl-icd-loader libxslt lib32-libxslt libva lib32-libva gtk3 lib32-gtk3 gst-plugins-base-libs lib32-gst-plugins-base-libs vulkan-icd-loader lib32-vulkan-icd-loader

Install Lutris
sudo pacman -S lutris

Install Steam
sudo pacman -S steam

found this in https://www.youtube.com/watch?v=ibge7-4sitQ

mabye this can help others.

steam-1151640.log

anyone see anything helpful in there?
or rather, what should I look for?

I am getting a crash at the startup logos, the popup for sending a crash report is showing. I am running Arch Linux with the LTS kernal and mesa-git drivers. My hardware is an Intel i9 CPU and an AMD RX 580 GPU. I have copied d3dcompiler_47 to the same folder as the executable. My proton version is Proton-5.9-GE-8-ST.

steam-1151640.log

Thank you to all involved in making the game playable now (last time I checked we just about got the game to boot)! As far as I can tell, the remaining issues are performance issues (like the spamming of buffers and the FPS being low in general), am I correct in saying that? How is progress going on resolving the remaining issues?

@Zephranoid Have you tried the latest Proton, as in 5.13-1? There's been a bunch of fixes merged in as far as I can tell.

@drwhut Proton 5.13-1 crashes without displaying any window at all and doesn't display any error message. Here is the log from that:
steam-1151640.log

Thank you to all involved in making the game playable now (last time I checked we just about got the game to boot)! As far as I can tell, the remaining issues are performance issues (like the spamming of buffers and the FPS being low in general), am I correct in saying that? How is progress going on resolving the remaining issues?

Game still crashes after the logos for me.

Thank you to all involved in making the game playable now (last time I checked we just about got the game to boot)! As far as I can tell, the remaining issues are performance issues (like the spamming of buffers and the FPS being low in general), am I correct in saying that? How is progress going on resolving the remaining issues?

Game still crashes in <2mins here on AMD (5700XT), most runs, due to the OOM issue - but this is known.

NVidia fares better: I get around 30mins on my 2060 until the FPS dives from ~45 to ~16.

Game still crashes in <2mins here on AMD (5700XT), most runs, due to the OOM issue - but this is known.

Not for me, HZD is just one example that causes my whole PC to crash after some time, but this is due to buggy Mesa Vulkan drivers and its going to be fixed with 20.3.

Now its run for in original environment. No github hack at all.
Linux Mint 20.0 Mate
Kernel: 5.4.0-53
GTX 1070 with nvidia-driver: 455.38
Valve-Protonversion: 5.13-1
Steam Beta Client with better support of Linux games. I don't know the version.
...but i play only a short moment (the little girl go into the cave). Because i don't have good hardware (20-25 fps) i have to decrease the hardware option in the game.
I really didn't think it was possible to run the game on Linux. I'm so happy.

Works perfect with 5.13-2; great job guys!

Nvidia 2080 Ti (455.38), Ubuntu 20.04.

I just bought the game after the report just above and it works for me too. Was able to play for 2 hours, zero crash or problems.
Nvidia 1650, Arch Linux latest stable kernel and drivers (everything up-to-date), Proton 5.13-2. No customization.

Unfortunatly the game still crashes for me. The crash was right after the logos before, now I'm able to reach the menu for a few seconds. RX570 (4GB), latest stable kernel and Mesa 20.2.2, Proton 5.13-2.

using proton 5.13-2 and mesa 20.2-2 i can now get past the logos and a little into the movie cut screen before it crashes however i do now have an error "vkd3d cannot allocate memory defaulting to system memory" so i guess thats why all my system memory gets eaten and the game crashes ?

rx480 (4gb)
16gb ddr4 3200