For the record, I finished the game without crashes/glitches so apart from those occasional slowdowns and stutter it's fully playable from start to finish.

Sorry to cause issues, but Detroit doesn't work for me at all. The demo worked fine, so I bought the full game, but that's completely non-functional for me. I get a black screen, but nothing else ever comes up :(

The Proton log, and my system information, is available in this gist. If anyone can give any advice, suggestions or other help, it would be greatly appreciated!

@mashedkeyboard what's this: Options: {'forcelgadd'}? Do you have something in your launch parameters? If so, try to remove it.

@rkfg I didn't set it - looks like it's large address awareness for Wine, and is default: https://github.com/ValveSoftware/Proton/commit/f96c8d6e6a10725fa50e12a03238e76a817cf5f2

Okay, interesting. Can you try with Proton-GE? Also your VRAM is kinda low, maybe it was enough for the demo but not for the full game.

I've tried with 5.8-GE-2-MF, but I'll try the pre-release and see if that helps. I'm also trying moving it to another drive, to see if perhaps that's the issue.

I'd be very surprised if the VRAM was the issue; my GPU works fine with VR, and the demo ran at or near a solid 60fps, so it would be strange to have a problem with this. I've never had a VRAM issue with any game I've played before.

You can also try to simply delete the game prefix and let it recreate it. I had an issue with a game not starting because I had no internet when I installed it and it couldn't setup DirectX because of that. Also try to verify the files just in case.

Some combination of 5.9-GE-2-MF, moving the drive, and recreating the prefix, seems to have worked! I suspect it was a prefix initialisation issue, like you say - thanks very much :)

AMD Navi10 with Mesa 20.1.2
running the game with proton always causes a complete GPU hang.

@mathew2214 ACO or LLVM or same result on both?

@Leopard1907 ACO hangs my system. LLVM causes the game to hang on compiling shaders 0%. i can kill the game's process while it is stuck at 0% and it has no adverse effects on the rest of my system.
here is my system info:
https://gist.github.com/mathew2214/9c768f049702a3e7888f5d962bbe44e1

i can confirm, AMD 5700xt, got the game to launch the very first time (lots of stutters). 2nd launch and beyond have always hung with the process taking a lot of cpu. Tried LLVM and ACO.

Okay the problem is when using RADV the gpu will hung up and just throw me back to login screen. Using AMDVLK is working fine on the first chapter.

Detroit: Become Human stutter issue still there.

I wonder if it's Linux-specific at all. If anyone with Windows can check and compare I'd be grateful!

Here another log. Maybe you find something. :)
steam-1222140.log

I wonder if it's Linux-specific at all. If anyone with Windows can check and compare I'd be grateful!

@rkfg I heard that the game run better with Lutris (Epic Games Store Version) without any stutter etc.

@Johnnii360 very interesting, I don't use EGS so would be great to confirm or disprove this as well!

I forgot to say that the clothes and hairs - especially from Hank - flicker sometimes (physic based objects).

Played through all the way on linux. Works perfectly in game for me. Only minor issue i had was that the game doesn't close correctly on quit, other than that it ran perfectly - and is also an absolutely epic game

Some people say you have to delete a file after each restart
https://www.protondb.com/app/1222140
~/.steam/steam/steamapps/common/Detroit Become Human/ShaderCache/VkPipelineCache.bin

https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6478

There is a pending fix for Detroit Become Human hang issues on Radv.

I tried playing this game a while ago and the game would freeze every 1-2sec, now you can move but it has huge frame drops that really makes it unplayable ( especially at the park after the first mission ), tried it on w10 and works fine 30fps lock so i don't know what the problem is but i guess i have to play this one on windows :/
steam-1222140.log

Also it only worked with proton GE for me.

I've tried this game with Proton 5.13 Experimental (experimental-5.13-20210126):

• Performance seems good but auto detection selected quality a bit too high (reduced quality and resolution, and set 60 FPS instead of 30, works smooth now)
• Audio works just fine
• The game detects my HOTAS (Thrustmaster T16000 with stick, throttle, and paddles) as a gamepad which makes it impossible to play the game properly without unplugging it (the game thinks I'm pressing triggers and moving the right thumb stick all the time), moving the joystick actually moves the player character but joystick buttons are non-functional (probably because they are not BTN_A ... but BTN_1 ... in evdev)
• The game loses input events all the time, with dpad presses not detected or becoming stuck for a while, the same happens for stick movements and trigger/button presses but it was most perceivable with the dpad in the main menu already
• The game doesn't handle all the trigger axes properly, I've seen similar behavior on a Windows system of a friend (looks like a calibration issue) so this may not be a Proton issue

Since the game seems to lose input events also in keyboard mode, it's currently unplayable for me.

Today i tested this again with the new proton 6.3 / experimental and my problem is still the same, huge stutters/jumps and framedrops making the game unplayable on proton.

Tried disabling Esync/Fsync, deleting the shader file on the game folder, disabling some cores as some user reported on protondb but none of this helped.

Proton:
https://www.youtube.com/watch?v=eI2vkJA7M_0

Windows:
https://www.youtube.com/watch?v=iTevwxK7U-8

Sys info:
https://gist.github.com/NikoBellicRU/6079f881a76ac9a3b75950e87e85aa6f

System Information

• GPU: RX 5700
• GPU Driver: 21.1.0 - kisak-mesa PPA
• Kernel version: 5.8.0-50-generic
• Distro version: Mint 20.1 (64bit) (Cinnamon)
• Proton version: 6.3-3
  system_info.txt

Compatibility Report

I'm getting good performance with recent Proton versions (everything maxed at 1440p game rarely drops below 60fps)

Now only remaining a couple of minor issues for me:

• The hair on the character named "Hank" is rendered incorrectly (first seen in Chapter 6: Partners). Everything else in the game looks correct from what I can tell.
  

• Controller input seems a bit off, particularly when having to push up or down (I don't have a point of reference though as I have only played it on Linux/Proton), it is sometimes like the analog stick does not go all the way. Like the controller is not properly calibrated, but having checked with utilities calibration looks correct.

For example the site gamepad-tester.com reports "Axis 4" 1.00000 or -1.00000 when pushed all the way up or down on the right analogue stick, that seems correct.

This is with a 8BitDo Pro 2 controller (set to X-Input mode)

steam-1222140.log

hi @AwesamLinux Ive played this on linux and windows. And I can vouch that the issue of the steam controller not going all the way I also had on windows. Indeed it becomes frustrating enough I switched to an xbox controller to get past certain scenes.

Good catch on the hair issue though.

@AwesamLinux The hair issue should be fixed by https://gitlab.freedesktop.org/mesa/mesa/-/commit/729ebe4b17f0905f87f41c0ffe004e042f3c55f6

@hakzsam I can confirm, I'm no longer seeing any graphical issues.

GPU: RX 5700
GPU Driver: 21.2.0-devel (git-fda4eaf 2021-05-29 focal-oibaf-ppa)
Kernel version: 5.8.0-53-generic
Distro version: Mint 20.1 (64bit) (Cinnamon)
Proton version: Proton Experimental

Did anybody experience graphic corruption in this game like in the picture below?

It only happens in this game and it only affects my screen, screen recordings are not affected. Seems to mostly happen when the screen is jumping in cutscenes or when the camera is moved quickly.

Proton log: steam-1222140.log
Steam system info: https://gist.github.com/DomiStyle/a0054e9380c85c49dadc94085b92fd2b

I tried with Proton 6.3-6 and Experimental but same result.

@DomiStyle Did you just try a version from Glorious Eggroll?

@Johnnii360 Just tried with Proton-6.16-GE-1 but same issue.

@Johnnii360 Just tried with Proton-6.16-GE-1 but same issue.

Hmm... How's your Monitor connected to your graphics card? If you are use a Display Port connection disconnect the power cable and wait 5 Minutes to drain the residual current. Then reconnect again and try.

This issue look like a GPU or VRAM failure to me but if it's only on this game it's maybe a compatibility issue or bug.

Loose connection or GPU failure was the first thing I was thinking as well but since it's only this game I'm not sure that's the case. Resident Evil Village works flawlessly at the same time.

I will try switching between X11/Wayland and disabling/enabling Freesync, maybe that helps.

Ah yes, Freesync can maybe a issue. But you are using a Display with over 120Hz, so why you are use Freesync? :) Freesync is like Vsync to avoid tearing and when you play with or over 120Hz you really don't need Vsync or Freesync.

So it seems to happen with both X11 and Wayland also with Freesync disabled and enabled.

Freesync is like Vsync to avoid tearing and when you play with or over 120Hz you really don't need Vsync or Freesync.

Freesync also helps with frame rate fluctuations and frame rates which are not divisible by the display frame rate, which is quite common on high refresh rates.

Replying to https://github.com/ValveSoftware/Proton/issues/4003#issuecomment-813446260

Retested the game again today and i still have horrible performance with any proton version i use.

I can't reproduce the issues mentioned in https://github.com/ValveSoftware/Proton/issues/4003#issuecomment-924736819 on a 6700XT with Proton Experimental and latest Mesa, also using freesync on x11. Performance seems fine as well. Does this still happen for you @DomiStyle? Still, I'd rather suspect some display issues and not a RADV/Mesa bug.

@Oschowa Just downloaded the game to test it again and it seems like the issue is gone now.

I can't reproduce the issues mentioned in [#4003 (comment)](https://github.com/ValveSoftware/Proton/issues/4003#issuecomment-924736819) on a 6700XT with Proton Experimental and latest Mesa, also using freesync on x11. Performance seems fine as well. Does this still happen for you @DomiStyle? Still, I'd rather suspect some display issues and not a RADV/Mesa bug.

I really cannot understand this, i just upgraded to a 2700x and yet the problem remains the same what differs from my specs?

I tried everything at this point like other distros with clean install, flatpak / not flatpak, gamemode, manualy changing cpu governor, kernels like tkg / liquorix / xanmod and different schedulers, disable my cpu / ram overclock settings in bios but nothing change and it is just in this game so i don't get it . . .

In the cases of games like these, is it helpful at all to run in game shader compilation when running with proton? Aren't those shaders completely ignored for the ones VKD3D will generate?

They'd be completely ignored because this game doesn't even use D3D, it uses Vulkan natively so no API emulation needed. And it compiles its own shaders on first start by itself.

For me the game seems to freeze whenever a mission is completed, i can only view the last part of the chapter and because it's entirely frozen only an xkill command was able to close the game.
The missions run pretty smooth, except for the times the game randomly overloads all cpu threads for a half second.

Stat info:

• CPU: Ryzen 1600
• GPU: Nvidia GTX 1050 ti
• OS: Arch (linux-zen)
• WM: i3
• Ram: 8gig

I would be happy if the game wouldn't freeze everytime i complete a mission.

Bonus Info:
Typically I have 4gig zram swap but for this game I have to set the zram to 16gig, because the game tends sometimes to eat up 23 gig of ram making my system feel like a zip-bomb went off. (if the game doesn't get it's initial ton of ram for shader precache it just crashes)

with my 7900 XTX RADV (23.1 git) has about 60-70% of performace if compare to AMDVLK (2023.Q1). Also interesting thing that my previus 3070 TI has about 1.5x - 2x better performance in this game, but 3070 TI is about 2x as weak compare to 7900 XTX

Hello @BearsPunch, https://gitlab.freedesktop.org/mesa/mesa/-/issues/8032 seems relevant.

yes. I don't have so bad situation as man in gitlab has. In the same room with ultra settings and 1440p I have more than 100 FPS. But It jumps bw 100- 170 fps. But worst situation when start second chapter. When girl look at you I have 30-40 fps, when my 3070 TI had 90 fps. With AMDVLK have about 50-60 fps, but it still not good for so powerfull gpu. Tested on Windows - similar situation. Better than Linux (AMDVLK) but still not good as 3070 TI was.

The game seems to no longer start at all, just a quick black screen flash, then back to desktop, does anyone have this issue?

Edit: Never mind, I reinstalled the game and it starts now.

I'm getting a lot of polygon glitches on Fedora 38 using Proton 8.0-3 on an RX 6600.

Not every scene has them, but notorious scenes are the dumpster scene where Markus crawls for parts, and the scene where Markus frees Androids at the plaza and fights policemen.

@acerspyro you should make a mesa issue for graphics issues in a native vulkan game like this.

The game runs normally for me. Then after a few minutes (sometimes hours) it just turns into the above. Partial black screen. Nothing seems to fix it. It still renders the game normally on the small left shiver.
I have tried a bunch of proton versions (7, 8, experimental, GE) happens on all of them. what the hell is happening

Runs flawlessly on:

• Ryzen 7 7840U iGPU
• 32GB DDR5 RAM 6400 MT/s
• Nobara Linux w/ kernel 6.6.8
• Proton 8.0-4
  via my GPD Win Mini

Detroit Become Human has a lot of intermittent stuttering for me :(

This happens even though the FPS is mostly >100 with a full AMD build. Doesn't matter if you use MESA or AMDVLK:

• CPU: Ryzen 9 5950X
• GPU: Radeon RX 6800 XT
• Mem: G.Skill Trident Z Neo 32 GB (2 x 16 GB) DDR4-3600 CL14 Memory
• Kernel: 6.7.0-3
• Distro: Arch Linux
• MESA: 24.1.0_devel.183265.e84aa455e55-1
• AMDVLK: 2023.Q4.3-1
• FCLK: 1800
• CPU SCHED: pstate active (EEP) + performance
• GPU SCHED: 1 3D_FULL_SCREEN
• CPPC: enabled
• CPPC Preferred Cores: disabled

I don't think it's related to shaders since the lag spikes are re-occurring

Tried using these:

• Steam: Proton 8.0-4
• Steam: Proton experimental-8.0-2024011
• Steam: GE-Proton8-27
• Bottles: Caffe 8.21
• Bottles: Wine: 9.0rc4.r14.g4054795ff19-1

I've tried disabling/enabling the following:

• Steam > Settings > Downloads > Shader Pre-caching > Enable Shader Pre-caching
• Steam > Settings > Downloads > Shader Pre-caching > Allow background processing of Vulkan Shaders
• FSYNC
• ESYNC
• Ingame VSYNC
• Ingame Frame limit
• Gamemode
• MangoHud

Deleting every possible cache doesn't make any difference:

rm -rf "~/.cache/mesa_shader_cache/*"
rm -rf "~/.steam/steam/steamapps/shadercache/*"
rm -rf "~/.steam/steam/steamapps/common/Detroit Become Human/ShaderCache"

@GrabbenD Can you check your cpu usage with MANGOHUD_CONFIG=full when those stutters happens?

Does it look kinda similar to this?

Thanks a ton for taking a look @Leopard1907

You're in exactly the same game location as me! I'm getting 140-144 FPS in this room while standing still but as soon as I walk around I get lag spikes/stuttering as seen below. The intensity of the lag is random and causes the FPS to drop slightly (but it's still high in my opinion):

New framegraph screenshot: https://gitlab.freedesktop.org/mesa/mesa/-/issues/8032#note_2240997

• The MangoHud part of the screen is black since I have a ultrawide monitor and the game is locked to 16:9.
• My display has OSD for refresh rate which confirms that VRR is working.

Yes, so 32 threads cpu being at roughly 40 percent cpu usage adds up with my 16T 80 percent cpu usage. (7800X3D cpu)

I've been "playing" this game for a week now, i noticed this high cpu usage as well and checked various other results from YT Windows system videos and this video also exhibits a rather high cpu load overall but main difference is; it doesn't seem to cause those nasty stutters.

https://www.youtube.com/watch?v=NMlWqPoaA_s

12:07 and onwards shows the same location, A New Home chapter.

I've also tested with AMDVLK and while it has lower performance overally it also suffers from same high cpu load variancy and this leading to stutters as well.

I'm somehow inclined to believe this is a Wine/Proton issue, rather than game being that stuttery.

If it stutters while moving, you could try using Ferals gamemode and use its feature of pinning/masking CPU threads which would otherwise cause inefficient L2 cache usage. This can help for many AMD CPU architectures, and also help for some hybrid-core Intel CPUs (masking the E-cores from the game). Maybe it helps.

Thanks @kakra

I made the game process' affinity share the same CPU L3 Cache (within the same Core Complex (CCX) to avoid L3 misses and inside the same Core Chiplet Die (CCD) to further reduce latency):

$ lstopo for my Ryzen 9 5950X

• Logical Cores 0-7 (HT 16-23) = 8 Physical Cores (with SMT) in CCD0
• Logical Cores 8-15 (HT 24-31) = 8 Physical Cores (with SMT) in CCD1 (slower by design)

This gives us the following Gamemode confg:

# /etc/gamemode.ini
[cpu]
park_cores=no
pin_cores=0-7,16-23

After launching the game I've verified GameMode works with MangoHud:

GAMEMODE ON

Furthermore CPU pinning was done successfully as seen here:

$ taskset -pc $(pgrep Detroit)
pid 11510's current affinity list: 0-7,16-23

$ gamemoded -s
gamemode is active

I've also verified that Gamemode 1.8.1-2.1 is installed correctly:

$ whoami
game

$ groups
games realtime gamemode plugdev video input audio wheel game

$ gamemoded -t
: Loading config
Loading config file [/etc/gamemode.ini]
: Running tests

:: Basic client tests
:: Passed

:: Dual client tests
gamemode request succeeded and is active
Quitting by request...
:: Passed

:: Gamemoderun and reaper thread tests
...Waiting for child to quit...
...Waiting for reaper thread (reaper_frequency set to 5 seconds)...
:: Passed

:: Supervisor tests
:: Passed

:: Feature tests
::: Verifying CPU governor setting
::: Passed
::: Verifying Scripts
::: Passed (no scripts configured to run)
::: Verifying GPU Optimisations
::: Passed (gpu optimisations not configured to run)
::: Verifying renice
::: Passed (no renice configured)
::: Verifying ioprio
::: Passed
:: Passed

: All Tests Passed!

Unfortunately it made no difference :(
Please correct me if I've done something wrong!

If it stutters while moving, you could try using Ferals gamemode and use its feature of pinning/masking CPU threads which would otherwise cause inefficient L2 cache usage. This can help for many AMD CPU architectures, and also help for some hybrid-core Intel CPUs (masking the E-cores from the game). Maybe it helps.

I guess you've missed the part that says " i noticed this high cpu usage as well and checked various other results from YT Windows system videos and this video also exhibits a rather high cpu load overall but main difference is; it doesn't seem to cause those nasty stutters.".

So cpu itself being an issue is not likely, which if that was the case same would expose itself in many other games as well. But no; issue is specific to this game.

There's some new performance enhancements which alleviates the stuttering

Feel free to test it using this:
https://gitlab.freedesktop.org/mesa/mesa/-/issues/8032#note_2265887

@GrabbenD I tried but no.

Try my save games here.

INTER_1.tar.gz

Might be INTER_3 for Steam copies.

This train sequence here, no input needed. Just click continue.

That stuttery stuff doesn't happen on Windows, if you check first post of the issue same issue basically present since 2020 on NV this time, same issue also exists on Steam Deck as well there are gameplay videos on YT.

Pretty much a Wine/Proton exc issue that drivers are not likely the culprit imo.

@Leopard1907 Latest AMDVLK might help

https://github.com/GPUOpen-Drivers/AMDVLK/releases/tag/v-2024.Q1.2

Performance optimization for Detroit become human

Just noting I completed this for the first time, on vanilla Proton 9.0-4, over the last few days. I noticed nothing broken, no glitches or crashes, a very pleasant experience in terms of stability. Kubuntu/X11 with amdgpu.

Does it look kinda similar to this?

@Leopard1907 @GrabbenD I also get stuttering similar to what you've described using current Proton Experimental or 9.0-4 (Ubuntu 24.04, 5700X3D, 7800XT, 32GB RAM). I've found dropping "Texture Quality" to Medium flattens the frame time graph out in parts of the game where it occurs. I've also verified that the same problem doesn't happen in Windows 11 on the same machine (I can use Ultra "Texture Quality" with no stuttering), so I agree that it looks like it could be a Proton issue.

EDIT: I also found a conversation (involving @GrabbenD) around using RADV_PERFTEST=transfer_queue. That did improve things somewhat for me, but I still need to drop textures to Medium to completely remove the frame timing stutters.

You can also try to simply delete the game prefix and let it recreate it. I had an issue with a game not starting because I had no internet when I installed it and it couldn't setup DirectX because of that. Also try to verify the files just in case.

The game wouldn't launch for me (after running fine the previous day) with a Vulkan 1.1 error until I deleted the prefix. Might be related to the new NVIDIA 590 drivers and shader cache?

On steam machine the game sometimes shifts the render over 90% offscreen to the left (UI like the pause menu doesn't render but the tiny sliver of actual game render you get does work) and sometimes that sliver also gets a corrupted look before the game crashes