Are you running TLD on linux/Radeon?

[Polynomial-C]

As promised in the v1.62 announcement thread here are my current specs.

Hardware:

• GPU: Tonga PRO [Radeon R9 285]
• CPU: 2x AMD Opteron 6328

OS:

• Gentoo Linux (~amd64)
• kernel-4.19.83 (CONFIG_DRM_AMDGPU=y and CONFIG_DRM_AMD_DC=y)
• xorg-server-1.20.5
• xf86-video-amdgpu-19.1.0
• mesa-19.3.0_rc2
• llvm-9.0.0
• libdrm-2.4.100
• vulkan-loader-1.1.125

Vulkan libs are installed but last I checked the game was very sluggish using Vulkan.

I too have that annoying flickering which seems to be gone when using Vulkan.

I play the native Linux TLD versions from GoG.

 

[Guest jeffpeng]

@Polynomial-C Dang. I thought you might have the magical combination nobody of us thought about. But great to see another Gentoo user.

Also: dual 6328? Man that was some sweet hardware back in the day. I'm always surprised how well Piledriver actually holds up despite its age and its questionable reputation. We actually retired our two dual 6344 servers just last year in favor of one dual 7451, and my wife is still running an FX 6300.

As for vulkan .... I've got really good performance on both a 390 (that's Hawaii PRO I believe) and 570, but a horrible shadow issue when too many shadows are cast, which looks to me like something is going haywire with the zbuffer. I'm running a bleeding edge 5.3 kernel, Mesa and vkloader are the same versions, but llvm is 8.0.1. Maybe that's one thing I could still try to maybe resolve that. Also I'm running wayland, but I don't think that has much to say about VK performance.

Anyways: thanks for the feedback.

[stratvox]

@jeffpeng That's exactly what I'm seeing when I'm running the linux version with -force-vulkan. It all looks pretty good except for shadows, which bear a strong resemblance to a really bad trip.

The shadows are the only thing broken about vulkan with TLD, which is a shame.

[Guest jeffpeng]

4 hours ago, stratvox said:

The shadows are the only thing broken about vulkan with TLD, which is a shame.

Yeah but that one I am pretty sure about is outside of HL's capabilities to fix.

[stratvox]

On 11/12/2019 at 3:29 PM, jeffpeng said:

Yeah but that one I am pretty sure about is outside of HL's capabilities to fix.

Aye, I agree completely, which is why I haven't complained. I imagine that if they were to update to a more recent version of the engine that'd fix it, but of course that's a HUGE job for them.

Maybe we'll see it with the December survival update... one can hope

[Guest jeffpeng]

Interesting fact I: running Windows native TLD through wine/DXVK (which is essentially proton) while forcing GL .... results in the same terrain wobble. Which is definite confirmation it's not the linux version that is broken .... it's the entire GL implementation.

Interesting fact II: running Windows native TLD through wine/DXVK while keeping it on DX .... with my fancy Gentoo things and stuff .... runs circles around running Windows native TLD on native Windows. Now here's something to think about. 

[Guest jeffpeng]

Well I guess for convenience sake @stratvoxapproach really is the best, meaning running the windows native version of TLD via Proton from the linux steam client. Still runs circles around my windows version on windows. I mean you can get a few percent of extra performance here and there I guess by running a dedicated wine version on a dedicated wine prefix just for TLD, but that's a lot of work for not a whole lot.

I'm still flabbergasted that we apparently have entered the very weird era in which windows games on linux work better than windows games on windows or linux games on linux. And who would have thought that valve of all people would facilitate this very odd revolution.

--edit: I'm not saying that windows on linux really runs better than native linux binaries. It's just that a lot linux ports are so terrible that running the windows version on wine actually is rather commonly better. A famous example that comes to mind is the amazing Linux port of XCOM: Enemy Unknown that remains garbage status to this day. At this point I wonder if it's really even worth for companies to commit to porting games to Linux, or if they shouldn't just save the money or even better throw it at the wine and vkd3d/dxvk people.

Edited November 15, 2019 by jeffpeng

[stratvox]

A very weird era indeed. I'm thinking of trying it with some of the other games I have to see if it ends up being better.

Interestingly, there was a period of time in the mid-nineties where that was true of some games but with OS/2 taking the place of linux. Descent w/ kali for tcpip networking on OS/2 ran rings around the windows versions. After the leaked quake sources resulted in an unofficial OS/2 port (97 maybe?), quake on OS/2 was also really really good, definitely way better performing than quake with windows 95.

[Asinine]

@jeffpeng I apologise for never replying. Shortly after the post here, Manjaro updated and fubar'd my setup. I completely reinstalled and forgot to come back and check.

I was (and am still) using Steam's "global setting" for Steam Play, which I am unsure runs at either 32- or 64-bit (inform me how to tell?). I actually returned because I have upgraded to the Radeon 5700 XT and have new issues. [SO TO THE OP: I actually have no issues at the moment, except for the startup screen, which I'm not seeing anyone else having so I may just report it.]

The game "stutters" (more like fps decreasing to 2-3) happened randomly, and if I could find a save point, I could back out of the game, then just restart survival (it always/only happened in survival mode). It would then work for a while, from the rest of my game time, or as soon as 5 minutes start up again (though that only happened once).

It hasn't happened since I swapped video cards. I got a video capture of it once, after I slept to save, moved around to show how chunky it was, then backed out and restarted. I've attached so you can compare the before/after.

 

Edit: All your questions... man, I'm pretty new at linux, and I've changed a lot of what was going on at the time of my post. I'm guessing Steam runs native on Wine (it's not specifically stated to run Proton). I did not experience terrain wobble. I had entered some launch options to attempt to fix this issue, but it didn't change anything. Currently, there are none (I assume they got erased with my reinstall). As for your other questions, no clue for Kernel, Mesa, LLVM at the time... Nvidia was at the 4.35 setting. Sorry, I came here to answer those questions and got sidetracked!

in-game-random-lag 2019-11-10 00-09-58.mkv

Edited December 3, 2019 by Asinine

[Guest jeffpeng]

@Asinine I do have those startup screen problems when using openGL, either native or via wine, doesn't really matter. I just didn't mention them to this point since they are .... well .... only affecting the startup screen.

If you are having the option to set Steam Play you are using the native Linux Steam client as running the Windows version of Steam via Wine (which also is possible) doesn't have this option. Then: If you are using the global setting .... Steam will still use native Linux versions unless you specifically tell it to do otherwise. That means you should indeed be running the native Linux version of The Long Dark. Which means ..... you apparently don't have that issue. Which is very, very interesting.

So as long as you don't have that terrain wobble bug currently I would be very interested to see your ~/.config/unity3d/Hinterland/TheLongDark/Player.log

As for your super harsh FPS drop .... no idea. Since it vanishes after reloading I'm inclined to assume that it's a game issue, not a driver issue per se. If it was the driver, for example, inexplicably throttling the card (which is something AMDGPU indeed used to be prone to, at least on Vega), simply exiting and reentering the game wouldn't fix that. I think this is a different beast of a bug. Can you give any information on CPU utilization when that happens?  Or GPU utilization (cat /sys/class/drm/card0/device/gpu_busy_percent) or even current GPU clock (cat /sys/class/drm/card0/device/pp_dpm_sclk) at these instances?

[stratvox]

2 hours ago, jeffpeng said:

As for your super harsh FPS drop .... no idea. Since it vanishes after reloading I'm inclined to assume that it's a game issue, not a driver issue per se.

This could be thermally related. If the 5700(xt) thinks it's getting hot, it'll throttle the card pretty hard.

I've found with my 5700xt that turning on vertical sync results in smoother result overall; the card barely breathes hard rendering this game at 1080p@60Hz, so you just don't see big drops because even when it has to work harder for a particular scene as it's got a lot of thermal headroom available before the card throttles itself.

[Guest jeffpeng]

Well that could be a factor. Then again the entry scene is also rendered - so if its the card rendering itself to death that wouldn't fix that. You can check cat /sys/class/drm/card0/device/hwmon/hwmon0/temp1_input to see the actual temperature of the card (in °mC), at least edge temp. Dunno if the AMDGPU exposes junction temperature, but edge should be sufficient to see if it's thermal related.

[Asinine]

OMFG my post just got eaten. So long story short:

@stratvox, I haven't experienced the drop since upgrading to the Radeon (it's an XT). I was aware of the heat issues beforehand, so I keep a lazy eye on it.

@jeffpeng, I'll post the logs if you're interested. But as I swapped out mboard/cpu/gpu since the issue first popped up (which did not exist on my intel mboard and nvidia card before the Ep 3 release, but did after -- and only in survival, though I didn't like Ep 3 so I played about 10 hours and have been back on survival since. I have attempted a few challenges, but never encountered it there). I believe I got the lag issue once or twice after swapping to my AMD cpu/mboard. The gpu took a few more weeks, but I haven't had the lag issue since.

So while I would have totally attributed it to thermal reasons, I have had 0 issues (with the sudden fps drop) since I got the Radeon.

[stratvox]

14 hours ago, Asinine said:

So while I would have totally attributed it to thermal reasons, I have had 0 issues (with the sudden fps drop) since I got the Radeon.

I was playing the new stuff on an office machine (ssshhhhhh don't tell anyone  ) yesterday and it has my old video card (nvidia 1060), and I was getting them then... at home, not a hint of it (5700xt).

I think they're hitting some limits on those older cards. My guess is VRAM limits on the card, and the slowdown is because it's needing to load textures from system RAM; this 1060 on the machine I'm typing on has 3GB, while my radeon has 8GB.

[Guest jeffpeng]

Just inb4 somebody wasted time and/or bandwidth on this: Nope, still terrain wobble with Errant Pilgrim. Moreso: --force-vulkan now seems not to work anymore, so I guess they removed/masked the vulkan option for this build. Stuff isn't getting better, not at all. How can this exists for months and nobody even cares? Please, just remove the "Linux" tag from the game.

[stratvox]

@jeffpeng:

Try -force-vulkan instead; for some reason they don't have the double dash on that option.

Not unix people I guess

 

Edited December 12, 2019 by stratvox

[Guest jeffpeng]

Just now, stratvox said:

Try -force-vulkan instead; for some reason they don't have the double dash on that option.

DUH xD

Does it fix the zBuffer shadow bug tho?

[stratvox]

9 minutes ago, jeffpeng said:

DUH xD

Does it fix the zBuffer shadow bug tho?

Haven't tried it with the new build yet, because I'll have to do the swaparoo on the files and download something like 3-4GB of data... plus I've seen no indication that they're running a newer version of Unity, which I'm pretty sure is what's going to be required to fix the opengl terrian wobble bug. From what I've been able to glean they're using a very particular custom build of Unity which they needed because of how big some of the regions are. I'm figuring on Proton/Windows version for the time being, and I hope they end up being able to fix up what's wrong at some point this year maybe?

May take a shot at it this weekend; not sure yet. I'll need to tar up the whole works first so I can ensure that I can get back to my current mostly-working setup without too much trouble if it all goes kablooie. Etc.

<ETA> "mostly working" means that the mapping is busted for some reason; all the maps are blank and black and mapping actions don't clear terrain... but the game clearly thinks that it has. I'm basically chalking that up to some weirdness in the translation from linux to Windows config file locations and formats. I haven't reported it because let's be fair, asking them to try to support windows running under linux with the support of a vast array of third party libs etc isn't really reasonable.</ETA>

I'd be very happy to be able to go back to running the linux native executables rather than special environmental kludge land; I spend far more time in this game than any other game I play and it'd be nice to get the performance back.

Edited December 12, 2019 by stratvox
see ETA

[Guest jeffpeng]

I save you the troubles. Vulkan .... has the same issues it used to have. So ..... I'll keep using Proton. 

[Guest jeffpeng]

Also, I'm picking on this from a sole consumer standpoint. The game has a Linux version. The Linux Version is broken since .... Steadfast Ranger? Something before that? No official statement has been made for such a longstanding issue. A simple "wontfix" would be preferable to trying if they maybe fixed it by accident each and every update. 

[Guest jeffpeng]

2 hours ago, stratvox said:

mapping is busted for some reason; all the maps are blank and black and mapping actions don't clear terrain...

I actually don't map, so I went and checked. It works with Proton 4.11.9. (Native Steam, TLD via forced compatibility)

[stratvox]

10 minutes ago, jeffpeng said:

I actually don't map, so I went and checked. It works with Proton 4.11.9. (Native Steam, TLD via forced compatibility)

Hmm. I'll have to look into that further then. I wonder if it's got something to do with the age of some of my saves.....

Thanks for the heads up!

Edited December 12, 2019 by stratvox

[stratvox]

1 hour ago, jeffpeng said:

I save you the troubles. Vulkan .... has the same issues it used to have. So ..... I'll keep using Proton. 

I want to upvote it to say thanks... but I can't. So, thanks

[Polynomial-C]

Perhaps this post doesn't really fit in here but I didn't want to create a new topic for this.

I have some issues with TLD (GoG version) on my two Gentoo Systems since at least v1.62 of the game.

1. On my Notebook (with radeon kernel driver) I cannot start the game with mesa-19.3.0_rc1 or newer. On startup I get a floating point exception and the game stops to run immediately. Going down to mesa-19.2.x "fixes" the issue and I can successfully start the game. This doesn't happen on my Desktop machine with amdgpu kernel driver where I run mesa-19.3 successfully since the first release candidates.
2. On my Desktop (with amdgpu kernel driver) while playing the game I get lots of screen artefacts and minor screen corruptions. I first thought this was mesa-19.3 related but going down to mesa-19.2 didn't fix the issue. Most artefacts can be seen at the player's right hand when holding the rifle or being spread over the whole screen when aiming with the rifle. I didn't check the bow yet though.

 

Here are my current specs:

Hardware Desktop:

• GPU: Tonga PRO [Radeon R9 285]
• CPU: 2x AMD Opteron 6328

Hardware Notebook:

• GPU: AMD FirePro M6100
• CPU: Intel Core i7-3740QM

OS:

• Gentoo Linux (~amd64)
• kernel-5.4.3 (CONFIG_DRM_AMDGPU=y and CONFIG_DRM_AMD_DC=y on Desktop) / (CONFIG_DRM_RADEON=y on Notebook)
• xorg-server-1.20.6
• xf86-video-amdgpu-19.1.0 (Desktop) / xf86-video-ati-19.1.0 (Notebook)
• mesa-19.3.0 (Desktop) / mesa-19.2.7 (Notebook)
• llvm-9.0.1_rc3 (Desktop) / llvm-9.0.0 (Notebook)
• libdrm-2.4.100
• vulkan-loader-1.1.125

Game version:

• v1.67 right now but happened at least since v1.62

 

[stratvox]

I had that problem when I was using the amd supplied driver. Furthermore, I saw similar things in KSP, esp. when running the scatterer mod. They went away when I switched to the open source driver.