Open pprotonrep opened 6 years ago
I've tested it as well (or actually the Directors Cut version, not sure what differs) and it hangs on exit for me.
Try minimizing and killing the process (without selecting exit in game), if that works then its probably just a usual exitgame hang issue which happens sometimes.
Can't test right now, but would imagine it works since that is the solution I have to cleanup the hang. (i.e. only the game hangs, gnome shell is still alive and happy).
Agree it is a common issue with a lot of games actually. Hoping someone has a fix that could be added or handled in the proton layer.
On Ubuntu 18.04, works very well, stable during game and gamepad present. But hangs at exit.
FWIW: https://bugs.winehq.org/show_bug.cgi?id=44567 and https://steamcommunity.com/app/28050/discussions/0/620712364030989802/
So i guess we are on par with Windows, no? :smile:
Deus Ex: HR - DC is working very well with AMD Radeon RX 470 (POLARIS10)
Small issues:
The hang on exit is an issue with the game:
https://steamcommunity.com/app/28050/discussions/0/620712364030989802/
https://bugs.winehq.org/show_bug.cgi?id=44567
This is with the original version, not sure about Director's Cut.
Director`s Cut hangs for me for about 2-3 mins on exit, then closes. Otherwise works great. Arch (4.18) and Nvidia 396.51.
I've tested the directors cut on Arch and run into a couple issues.
Otherwise everything seems to run fine.
On my system, Arch Linux with AMD Vega 64, I'm getting the following error:
wine: Call from 0x7bc541f1 to unimplemented function vulkan-1.dll.vkGetInstanceProcAddr, aborting
wine: Unimplemented function vulkan-1.dll.vkGetInstanceProcAddr called at address 0x380023:0x7bc541f1 (thread 0029), starting debugger...
Any help would be greatly appreciated... :/
(Fixed, see below)
Fixed my own issue: Had to install lib32-vulkan-icd-loader and lib32-vulkan-radeon packages (already had the non-lib32 versions)
Directors Cut also works for me on Arch Linux, with the same hanging on exit issue. I initially had no sound, but a system update and reboot seemed to fix that. I did have to do the Windows registry modifications listed here to fix some frequent stuttering issues, after that, game play is smooth.
Working on Debian 10
My Specs: Distro Debian 10 Driver: NVIDIA Corporation GeForce GTX 1070 Ti/PCIe/SSE2 Driver Version: 4.6.0 NVIDIA 390.77
I noticed the hang on exit too. When trying to exit via game menus, It hangs for about 2 minutes and then it exits normally (video memory is released and desktop back to normal). Other than that, just a few milliseconds delay here and there in some cut-scenes. The sound was perfect, everything else perfect.
Installed everything from Debian repository or default, I have not added any extra config or parameter.
Here is the link to my Steam system info: https://gist.github.com/snarvaezsoft/dd0a970ce0b9ba8ed19a6c91022d2a50
Is anyone else getting poor framerates? I'm averaging around 20 FPS compared to 60 FPS with Windows on the same hardware.
When I loaded an old save (from Windows) there were no hand models (just the gun floating in mid air). Didn't have that issue when starting a new game (doing so also fixed the old save).
Had some hiccups trying to launch the game too. At first I was running Steam using native system libraries, and it worked fine. Then the game refused to launch until I ran it with the Steam Runtime.
Performance was decent overall, but not very smooth. Framerates would be over 100 in most cases, but there were massive drops and some stuttering. Framedrops were most noticeable when first loading into a level or looking at a new area, and seemed to alleviate after a while. Using PROTON_NO_ESYNC made the framedrops less severe.
Directors Cut also works for me on Gentoo Linux,GeForce GTX 970M, nvidia-drivers 396.54, with the same hanging on exit issue. I did have to do the Windows registry modifications listed here to fix some frequent stuttering issues, editing in steamapps/compatdata/238010/pfx/user.reg Thanks @ottopasuuna
Game won't let me go above 60hz refresh rate on a panel capable of, and configured for, 120hz.
Hello @BloodyIron, you're most likely encountering #1623.
@kisak-valve sounds about right!
Characters are invisible when close up, their models disappear but are still searchable and dragable on Proton 5.13
The game also needs to be forced to quit to exit or it hangs on exit
UPDATE: Turning off DX11 in the game video advanced settings fixes the disappearing character models problem, but it runs much slower without DX11 turned on
The game also needs to be forced to quit to exit or it hangs on exit
Happens on some Windows systems too, so I would assume it's a game bug
The game also needs to be forced to quit to exit or it hangs on exit
Happens on some Windows systems too, so I would assume it's a game bug
Never noticed it on Windows 7, but that's not a big deal, just kill it by force quit
The problem I see is the disappearing models on DX11 setting in the game, but gone when it's off, pity as it runs smoother with DX11 enabled in the game, I am on the low latency kernel and I get sometimes the odd freeze spike as it loads up more of the level I guess, not sure if that's related to being on the more preemptive low latency kernel rather than throughput or not but I tend to use low latency kernels because of more desktop interaction required and other stuff
Deus Ex: HR keypad support buggy
Issue transferred from https://github.com/ValveSoftware/Proton/issues/5677. @stixholder posted on 2022-03-13T04:15:22:
The keypad keys are not entirely recognized as KP_0 to KP_9 and so on, most only show as '???' in the keyboard settings menu. Some keypad keys, that e. g. also act as arrow-keys, DELETE and so on (depending on NUM LOCK status), seem not to be distinguished correctly from corresponding keys, during gameplay, although differently named in the settings menu. This is a huge problem, if you want to use keypad for gaming. For instance, KP_ENTER will not work for jumping either.
Just play the game
Deus Ex: HR - erratic view jumps
Issue transferred from https://github.com/ValveSoftware/Proton/issues/5676. @stixholder posted on 2022-03-13T03:58:24:
Moving the mouse to look around causes erratic viewing jumps/skipping of larger parts, i. e. your're turning 90° instantaneously instead of what would be expected according to the mouse movement; the effect gets worse near complex graphic content with many objects.
Just play the game.
@stixholder commented on 2022-03-13T13:01:37:
UPDATE: I've found a similar issue here, maybe the same problem #590 The game is unplayable under Linux in this state.
UPDATE2: I was mistaken there - it's not simply a duplicate of https://github.com/ValveSoftware/Proton/issues/590 and seems not to be a mouse issue in the first place. The problem seems to be, that visual data is not (pre-)processed in time during movement and also occurs while only using the keys to move, even if not as bad. It's pretty serious and in no way playable anyways. Changing all video settings to lowest/off (also DirectX11) won't help. The graphic 'hickups' also come with short sound echos. To some small extent, also video cutscenes are affected.
UPDATE3: The exit freeze bug described in https://github.com/ValveSoftware/Proton/issues/47 hits me EVERY time btw. If I don't task-switch -> rightclick -> close the frozen game timely, it will sometimes exit in an unclean way, leaving all kinds of wine libs and dependencies running, which then require manual kill each.
UPDATE4: The keypad keys are not entirely recognized as KP_0 to KP_9 and so on, most only show as '???' in the keyboard settings menu.
Some keypad keys, that e. g. also act as arrow-keys, DELETE and so on (depending on NUM LOCK status), seem not to be distinguished correctly from corresponding keys, during gameplay, although differently named in the settings menu. This is a huge problem, if you want to use keypad for gaming. For instance, KP_ENTER will not work for jumping either.
UPDATE4
Tried again with much better results on: Linux Mint 20.3 Una (base: Ubuntu 20.04 focal) Kernel: 5.4.0-104-generic x86_64 compiler: gcc v: 9.3.0 Desktop: Cinnamon 5.2.7 wm: muffin dm: LightDM
Here, the erratic video skips while moving/looking with mouse is not entirely gone, but much less intrusive.
Exiting the game takes a few long seconds, then the UI vanishes, but the game still is marked as running in the library and needs to be stopped manually.
The problem with buggy keypad support remains.
UPDATE 5: I've encountered a new mouse issue behavior (probably related to those problems mentioned by others above, including corresponding patches already deployed).
After some time playing without any problems (5 to 15 min.), rendering suddenly gets choppy, whenever I move the mouse, but not from key movements.
In hacking mode, the mouse pointer gets delayed, too, and button pressing often takes several attempts, until node capturing or other actions are commenced.
It's necessary to quit from the game completely and restart it, to fix the problem (temporarily) - just exiting to menu won't help. The problem might be related to encountering complex graphical content / complex lighting situations.
The extremely long game exiting procedure might be related to Steam's 'online' mode and savegame synchronizing set active.
UPDATE 6: A correction to the previous post - movement by keys does also result in choppy rendering, as soon as the problem kicks in (which it does on an random, yet annoyingly regular basis), only to a much lower degree. The choppyness may occur in anything from 5 min. to 15 min. of playing, but it's inevitable to eventually show, forcing a restart of the game.
Another side-effect of the choppy state is, that grabbing and dragging bodies will not work reliably anymore. The initial grab will succeed, but it'll let go in a random manner, as soon as you start dragging the body, dropping it again. It does not seem to occur with other objects.
This might indicate, that it's probably not a graphical issue at all, but instead a glitch in the game routines or even the CPU core load distribution (I remember of a similar issue with Windows and AMD multi-cores some years ago).
Since I could only observe a freezing of the game on exiting, when Steam cloud synchronization and network is active, this seems to confirm my prior assumption, of the problem being connected to cloud synchronization. Whether this is caused by Steam's cloud functionality itself, or by the game not applying some kind of timeout, I can't tell.
@staff: What are the chances, of those problems being addressed at some point, let alone in a timely manner?
Does the frame timing show spikes when the issue occur? If you have dxvk hud on? If so it sounds a bit like https://github.com/doitsujin/dxvk/issues/2371 . But there it's not also certain it's a graphical issue and seems like IO. Trying to reproduce it on another game. But might be a different issue.
Well that certainly sounds like the same issue. FWIW, YellowOnion happens to use the same GC as I do (AMD RX 580), but I don't know about the OS and drivers. DXVK will also show a tremendous drop in the framerate when moving, as soon as the problem manifests, just as described in the other bug (down to 17-25 fps).
I have a system with a R9 380 which i will try to reproduce the issue with. Tho i don't have much technical knowledge to be able to bisect it much. I sometimes have issues in some games where i have fps drops or stutters when moving the mouse, but that usually happens instantly after starting it not first showing after some play time. Launching in game mode usually solves it in those cases, but i don't suspect that would solve it here. And my linux setup is also run on a external ssd through usb 3.0, so maybe that plays a role in my case.
@stixholder Do you launch the game with feral gamemode enabled? If not can you try launching with it and see if it makes a difference to the stuttering that occurs after 5-15 min? I've tried reproducing the issue, but not luck to so far
@Blisto91 I'm uncertain, of what you mean by "feral gamemode", or where to activate that? If you mean, if I'm currently using a deviating compatibility mode, then no.
@stixholder Can you try to disable Steam Overlay and run the game using launch options like this?
env LD_PRELOAD='' DISABLE_VK_LAYER_VALVE_steam_overlay_1=1 %command%
Last time I encountered FPS drops on mouse/keyboard input it was caused by Steam Overlay and disabling it solved my issue in a few other games.
@stixholder This here :) It does stuff like setting IO priority, hardware performance mode etc. It's usually available in the distros package manager.
@Saancreed Does that variable actually disable overlay? I was messing with it on windows because of another issue and when you use it only seems to make it so it doesn't show on dxvk games (vulkan games i guess) but still works on regular steam games. The overlay log is also acting like it's still active as you can see it's registering events. Not sure. Tho if it works it works and the above is just me being curious 😁
@Blisto91 To be exact it prevents the overlay libraries from being injected into the game process. Not sure if it works by itself so I'd recommend also unchecking "Enable Steam Overlay while in-game" but when used together there should be no trace left if Steam Overlay being active. I expect that this will also break Steam Input.
Obviously, this launch options doesn't work on Windows.
What do you mean by the overlay log though? Is there any file that I can check to see if the overlay is active or not? None of the files I have in ~/.local/share/Steam/logs
appears to be related and I don't know where else should I look.
@Saancreed since disabling Steam overlay and using your launch args, the stuttering hasn't occurred anymore... whether that's coincidence, or not, time will tell. Next, I'm gonna remove the args / use only that, to verify. So it would seem, it's a Steam issue, as multiple games are affected... I'm gonna report the issue, but I'm curious, if Steam will do sth. for their money for once and fix that problem anytime soon. Anyway, many thanks, I'll keep you updated!
Interesting! Yes please do keep us updated. Saancreed is truly the hero we need :grin: Maybe the issue will solve itself if the steam client and tools gets a update to bring it closer to the steam deck.
@Saancreed Ye it was on Windows, i was testing a dxvk issue relating to the steam overlay. On Windows there's a couple of logs in the steam folder itself called GameOverlayUI.exe.log
& GameOverlayRenderer.log
. I think the former wouldn't fill out when playing dxvk games using the env variable, but the latter one would still show shortcut registering and other info even tho the overlay wouldn't show.
I see they are not present on linux, at least not by the same name. But it probably isn't important anyway and that the first one isn't updated might mean it was shut off properly for vulkan stuff.
I can confirm, that, after prolonged gaming sessions of several hours, neither the stuttering appeared, nor did the game crash once.
I further need to check, if this also applies to "Deus Ex - Humankind divided". So, for now, it seems that the problem could be solved by the starting parameters Saancreed provided.
What's interesting even more, is, that only using the starting parameters will work, not disabling the 'Steam Overlay' in the 'General' game settings, nor disabling it generally in the Steam client's 'In-game' settings.
@Saancreed Many thanks, this saved more than just the day for me!
Otherwise, the game would've seemed to be broken to me in Linux and obviously neither Valve, nor Feral Interactive, nor the Developer Eidos care about fixing bugs related to the series anymore (they do, however, surely not mind getting money for new copies, meanwhile).
I'll file a bug against Steam UI and keep you updated.
@Saancreed - btw., how did you learn about the starting parameters required to work around this problem?
DISABLE_VK_LAYER_VALVE_steam_overlay_1=1
can be found by checking Vulkan layer JSONs for Steam overlay (usually they live in ~/.local/share/vulkan/implicit_layer.d/
), they contain fragments like "disable_environment": { "DISABLE_VK_LAYER_VALVE_steam_overlay_1": "1" }
.
LD_PRELOAD
is the standard shared object preloading mechanism provided by Linux's dynamic linker / ld.so
and it's how Steam injects gameoverlayrenderer.so
into each game it starts. This one can be found just by inspecting environment variables of any running game:
$ sudo strings /proc/$(pgrep $game)/environ | grep ^LD_PRELOAD=
LD_PRELOAD=:/home/saancreed/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so:/home/saancreed/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so
So, by setting it to an empty string we prevent that shared object from being injected.
(And also by reading some discussion about this issue on LGD Discord server :see_no_evil:)
Thanks for the info, Saancreed. Still, did you worm yourself through the various config files and found out about those parameters by experimental 'try & error'? Or did you have some other documentation resource guidance?
I can confirm, that the stuttering also occurs in 'Deus Ex: Humankind Divided', similar to the predecessor game, that applying the start parameters seems to circumvent the problem, by the way, and I've contacted Steam support again.
FWIW, the game 'only' crashed once in several hours of gaming lately and the 'no hair bug' mysteriously vanished, since I've re-installed the game and been running it with standard Proton 7.x.
Whether system updates did solve the no-hair problem, or Valve applied some undocumented patches, or some game files might have been corrupt, I cannot tell. But checked game file integrity several times, prior to deletion.
Still, there's no decent information to gain from Valve, about whether this 'stuttering' is a known problem to them, whether somebody works on the issue and when to expect a fix, nothing. This certainly is no good.
Maybe if the steam UI and it's tools is getting a rework based on some of the steam deck work it will solve it self. Tho dunno if that has been confirmed for desktop. At least kisak-valve follows all of these topics like a hawk so I'm sure some are aware 👀
Proton 7.0-2 got released half a day ago if that helped. Or maybe it got better before that?
Well, I wouldn't count on that. Either way, keeping secrecy about bug tracking and fixing status, leaving users completely in the unclear, is a very bad habit in software development. It may be convenient for the company to keep up an 'It's done when it's done' policy - which may be within days, or never - but it's an absolute disaster for customers.
I've been using 'Proton Experimental' with 'Deus Ex: MD' for the time being, btw.
I tested Deus Ex: Human Revolution and it worked perfectly fine for me, including sounds, controller input and effects.
System information from steam