Implement some horrible Forza Horizon 6 workarounds. - #3033
Conversation
|
@HansKristian-Work Thanks for your work! Your workarounds managed to get me a few seconds in the benchmark before crashing with RT enabled. I am on AMD (9070XT). I played around with LLM starting from this PR to try and see if I could get it to work on my side. I built the dlls with the found workaround and I got it to run the benchmark and not crash (screenshot below). I also played for around 30 minutes with no issues other than reflection/illumination flickering (which I think is unrelated to the issue here). 
The code is here: https://github.com/chrisvblemos/vkd3d-proton/tree/fh6-rdna4-descriptor-padding-fix . I removed the summary from the LLM since, as usual, it most likely contains nonsensical conclusions. What matters is the code that worked for me - even if it is a crime against humanity. |
|
Ran Proton Experimental (bleeding edge) with this package: https://github.com/HansKristian-Work/vkd3d-proton/actions/runs/25965821984. No crashes over 2 hours of playtime. Stutters are less frequent than with Proton-CachyOS but still present. Running on a 5090. Using the Ultra non-RT preset. Compared to Windows, it is still a mess, both performance-wise and stutter-wise, making it quite unplayable with faster cars, but it is a lot better than anything else I tried. Stutters happen only when taking a sharp turn at high speeds; when cruising, it is fairly stable. Before trying this DXVK, it was stuttering every few seconds, no matter the speed. VSYNC does not impact this in any way. |
I really does not want to bash nvidia here now. But even without this pr it is not unplayable on linux. I play on native 4k without any fsr technology with my 7900 xtx and i can drive perfectly fine with my 400kmh car. And yes I do have a 144hz monitor. This should fix a lot problems the game has with RDNA 3 |
|
There's a fix needed for the nvidia driver. |
|
Uhhhh nice! I did not expect that Nvidia actually give game fixes for the Linux
driver. At least they did not do that 4 years ago when I switched to AMD :D
Good for you all ^^
Sent from Proton Mail for Android.
…-------- Original Message --------
On Monday, 05/18/26 at 10:54 shelterx ***@***.***> wrote:
**shelterx** left a comment (HansKristian-Work/vkd3d-proton#3033)
There's a fix needed for the nvidia driver.
https://forums.developer.nvidia.com/t/595-release-feedback-discussion/362561/4
33
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you commented.Message ID:
***@***.***>
|
2724ba4 to
3dd73a9
Compare
|
Hello @HansKristian-Work I just checked last artifacts and without RT on ultra settings with RX7900XTX it cause crash of AMDGPU and game itself PS: I also noticed that FH6 updated today |
|
@serhii-nakon are you saying this is a regression? I.e. that master is fine, but this PR is not? That VA looks like yet another new class of bug that hasn't come up yet. |
|
@HansKristian-Work Seems like regression or something changed in game with last update In both cases changed only vkd3d dll files |
What is latest release referring to here? master or 3.0.1?
Well, you're enabling descriptor heap there. Try https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41680 without heap. |
Yes, 3.0.1, OK I will build Mesa from PR branch but what proton I need to use - like release or from this PR or test both cases? |
|
@HansKristian-Work I built Mesa from PR branch + Artifacts from this PR + Only issue that still bother this strange slow downs of game despite frame rate still acceptable (like 60-40fps with RT and 100-60fps without RT) it still slowdown game - I got similar experience with FH5 on RX5500M - exactly the same... |
|
Forgot to mention that without RT this setup works too |
|
But RT itself pretty strange by some reason - no cars in reflections and no environment in reflections 
|
|
Seems game not fully enable RT but FPS twice lower (or does not enable at all RT) PS: next screenshots - the same place - just opposite side of view to show that it reflect something that not exists at all With preset Extreme+RT With preset Extreme (no RT) |
|
These workarounds seem to work pretty great for me. I cloned the latest proton-cachyos-slr, renamed it and dumped the DLLs from the artifacts in there to maintain an FH6 specific prefix. Not using RT, because I keep reading that it causes issues on NVidia. 
(Heap, NTsync, XWayland, NVAPI, FIFO Latest Ready swapchain. This is also a dual monitor setup.) No stutter whatsoever in the benchmark. I'm running this off XFS, tho, due to the higher IO throughput vs. btrfs. Haven't checked the game itself using e.g. mangohud or whatever, but it feels fluid. --edit: |
|
@glowtape try some high speed car and drive on this speed some time - I still have slowdowns with or without RT no matter - also I use EXT4 on SSD PCIe GEN5 10gbps so it should not be related with IO throughput at all |
|
@serhii-nakon This is probably an AMD-only issue and it is happening on Windows too, see this post. Try setting |
|
@sleepytariq More likely it related with game itself OR with related software - I saw that Nvidia users on Windows has the similar issue |
I replaced the files aswell, did exactly the same, using the same proton. RTX 4080 here. |
3dd73a9 to
8030acb
Compare
Apologies if this is further diverging from the topic of the PR. You can further mitigate the slowdowns by capping your FPS so that your GPU doesn't max out. When I set my FPS limit to 60 (My 9070xt was putting out ~90fps on Extreme at 5120x1440 without a limit) the slowdowns are almost completely gone. |
|
Okay so I noticed that I never used the changes because the dll files from the artifacts got overwritten all the time. I got it to work by replacing the dll files inside proton itself but now FH6 is crashing. What was I supposed to do for installing the changes? I use mesa-git, i downloaded the dlls and i changed the environment variables accordingly to your pr description Edit: Arch linux, KDE, RX 7900 XTX, 5800x |
|
@Polyfish0 https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41680 try this PR - it fixed for me this issue - despite in game RT enabled it seems game itself doesn't render rt by some reason |
|
Try to keep the back and forth chatter out of the PR comments. |
0602e09 to
d1631a1
Compare
| * Also, if we ever transition between the modes, assume we need to resolve the hazard. | ||
| * Sometimes it's possible that RTAS batch gets flushed without appropriate barriers. | ||
| * There is no concrete proof of this being required yet, but it's a useful debug config. */ | ||
| if (VKD3D_CONFIG_FLAG_IS_SET(EXTRA_RTAS_SYNC)) |
There was a problem hiding this comment.
For review: These weren't needed in the end, but I wrote them and might be relevant for Witcher 3 debug, so why not ...
|
@HansKristian-Work I tested and seems it works with RT - but with latest game update they broke reflections at all (I mean even with older Proton GE where SSR worked just perfectly - now it broken partially, RT itself now renders but broken in similar way as SSR after game update...) |
You need to post screenshots or a video. Note that the game has serious RT glitches too on AMD Windows. |
|
@HansKristian-Work Yes here links to YT videos with records where SSR and RT quiet badly works after latest game update |
|
@HansKristian-Work Here also strange FPS drops when I shake camera in game - any rotation even very small cause game to drop FPS - it seems related with those issues where users has game slow downs/stutters |
|
@HansKristian-Work PS: look at reflections on building - here disappear long distance objects from reflections and their quality very low - before update I had quality of real world mirror (even with SSR when object in camera view) |
|
Yes, but Windows AMD also looks just as broken. We did some side-by-side testing of the benchmark to confirm. Only conclusion is game bug where they rely on UB that AMD GPUs don't like. Anyway, there is nothing that should block this PR now. If there are further issues now, please make a new issue with side-by-side comparisons of Windows AMD and Linux RADV. |
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
The aggressive nonuniform isn't enough in all cases. Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Avoid raw buffer <-> image aliasing. The hardware is not actually robust against this for whatever reason despite the HW docs saying it should be, so we have to place them at RDNA2-style 32b offset to avoid the hangs. Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
FH6 seems to rely on this not needing to be synced for some reason ... At the very least, flushing RT batches when doing shading seems like a good idea. Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Same issue, sigh ... Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
7fb43ad to
4b65fc2
Compare
| vkd3d_descriptor_debug_sync_validation_barrier(list->device->descriptor_qa_global_info, | ||
| list->device, list->cmd.vk_command_buffer); | ||
|
|
||
| /* Flush RTAS but don't sync against it, since the chance of false positive is very high. |
There was a problem hiding this comment.
isn't the only possible scenario where this can go wrong going to involve ray queries anyway? Should be easy to work out if we ever need it.
There was a problem hiding this comment.
I'd think so, ye. We flush RTAS but don't sync for graphics, so I figured we should make it orthogonal at least.
I know this PR is merged and closed. |
|
After this PR got merged do we still need to use any environment variables, like descriptor_heap? |
|
Hi! not to necro this but yall are miracle workers. tested this with https://github.com/CachyOS/proton-cachyos/releases/tag/cachyos-11.0-20260521-slr and it works like magic. stutters remain but I can cope with that. an hour and a half in and it has yet to crash ❤️ |
|
Just wanted to also confirm, CachyOS with cachyos-11.0-20260521-slr, Ryzen 9800X3D and a Radeon 9070 XT, I'm able to play with Ultra RT enabled now with FSR 4.0.2 on Quality and hit my preferred target of just over 80 FPS. Great work guys, thank you for all your efforts! 
|
|
Seems after this PR was merged to master in master branch stopped work PROTON_FSR4_RDNA3_UPGRADE=1 from Proton-GE 10-34 |
|
Just wanted to thank you for your work on this; thanks to the descriptor heap fix I have FH6 running stably on Arch Linux/NVIDIA. |
20 participants
This game is extremely broken:
This pulls in the rest of descriptor heap, since it's only reasonable way right now to get working benchmark without rendering glitches on my system. At best, this can be a hotfix branch or something.
Needs more investigation why the 32 + 32 RDNA2 style path doesn't quirk work. But it doesn't hang GPU anymore, so ... yay?
Adds sampler heap robustness too in dxil-spirv by just padding all sampler heaps to the 2048 limit. There is no room to pass down sampler heap size, so just clamp to constant 2047 instead, which is fine in practice. There are no null samplers, so we'll use whatever is there I guess when it's OOB.
Another issue is missing nonuniformEXT in RT shaders which I added force robustness for RT only to avoid crippling unrelated shaders. I only detected issues in this area in RT.
After that, we have the "lovely" bug of bad aliasing between image descriptors and buffer descriptors. The game first writes an image descriptor, then reads that as a plain buffer, which is broken, and on RDNA3/4 we would read the image descriptor at a 16b sliced offset, which breaks. This is the first instance of this causing issues in the wild. It was a known hazard point, but we have easy mitigation strategies on AMD at least. The only solution here that works is to force 64b layout where we can completely firewall off images and raw buffers.
There are also bugs with "use-before-alloc" where the application allocates resources after submit and writing descriptors pointing to them to the descriptor heap while GPU is in flight. Utter insanity, but FH5 had issues in this area too.
It's not been proven to cause a hang yet I think, but
radv_wait_for_vm_map_updates=trueis very likely going to be needed for safety.The final bug around glitched RT was caused by the game forgetting to insert a barrier between BuildRTAS and TraceRaysIndirect ... Because of course.