this post was submitted on 23 Jun 2024
3 points (100.0% liked)
PCGaming
6472 readers
44 users here now
Rule 0: Be civil
Rule #1: No spam, porn, or facilitating piracy
Rule #2: No advertisements
Rule #3: No memes, PCMR language, or low-effort posts/comments
Rule #4: No tech support or game help questions
Rule #5: No questions about building/buying computers, hardware, peripherals, furniture, etc.
Rule #6: No game suggestions, friend requests, surveys, or begging.
Rule #7: No Let's Plays, streams, highlight reels/montages, random videos or shorts
Rule #8: No off-topic posts/comments
Rule #9: Use the original source, no editorialized titles, no duplicates
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
A 60fps limit in 2024 is pretty shit on its own without going into DLSS and ultrawide support missing
I remember on the original release it was so poorly optimised that valve stepped in to basically patch the game themselves on the steamdeck, yielding the kinda funny situation that the steamdeck was outperforming much beefier hardware until FS patched it themselves.
They really need to look like they're at least trying, or they'll quickly end up on the game developer shit list
Valve didn't do anything in particular for Elden Ring.
The way running windows games works on Linux just meant that compiled shaders got cached, so that when they were needed again, the game wouldn't freeze for a split second while they were recompiled.
This process is necessary on the windows side as well, when using DirectX 12 or Vulkan. Most games will do this shader compiling in advance (during a loading screen), and cache them for later so that the GPU can run full tilt generating frames during gameplay, instead of pausing to compile shaders.
Elden Ring didn't do this. It compiled shaders as they were needed mid-gameplay, then immediately discarded them instead of caching them. This meant it was constantly freezing to compile shaders as materials that used different ones appeared on screen. And it would keep happening as it didn't keep compiled shaders around for the next time they were needed.
Only on Linux, there was an external cache in the system that was translating the games DX12 calls to Vulkan (VKD3D), which would just go "oh I already have that, here you go" essentially making the game work as if the constant compiling could be done instantly whenever needed.
Valve did provide the cached shaders as a download, compiled in advance, as otherwise you'd still get compilation stutters each time something on screen needed a particular shader for the first time. But Valve does this for all games.