While that one line is incorrect, it’s a fallacy to use that to try and sow the seeds of doubt in the other points. People make mistakes in wording all the time and it’s a low debate tactic to do what you did.

The fact is some frame hitches are gone but obviously not all.

The ones that will primarily be gone or largely mitigated are

- shader compilation hitches, because console versions of games can ship with pre compiled shaders.

- data transfer hitches because the consoles have shared memory and dedicated compression blocks to optimize transfer

- system resource scheduling contention because the OS and other processes won’t start interfering with the game process since they use dedicated resource allocation.

thanks, on an internet forum, you'd expect some leeway, but alas, it seems it's worse than a technical paper ;)

the OS and hardware working hand in hand to help overcome some of the causes for hitches and frame drops is what sets the consoles apart from the DIY PC builds where you simply don't have access to the custom design;

and it's also imho where in this generation Sony has pulled ahead of Microsoft even if both are using similar hardware

> the DIY PC builds where you simply don't have access to the custom design;

On Linux (or Steam Deck) you can precompile shaders for your specific hardware like Switch or PS5. There is nothing about "DIY PC builds" that prevent you from building an experience like this.

The steamdeck is a single known entity of hardware. For all intents and purposes, it can be treated like a console in that regards.

But DIY PC builds, that’s a wide range of hardware to support. And it’s not just hardware, it’s driver versions, OS versions and firmware versions.

So it’s possible to do what Valve does where the first playthrough caches the shader compilations and then stores them by a configuration hash, so subsequent users get it. But the sheer number of hardware and software permutations makes it significantly harder.

It has nothing to do with Linux either.

The shaders are therefore not precompiled in the same way they are for console. It just means that the second playthrough of a section is a shared experience taking advantage of the first users resources.

If a game hasn’t been played first, or you encounter an area of the game that hasn’t been encountered before you, or you’re on a slightly different hardware/software combination than the previous shader cache, you’ll hit the stuttering again.

That's not how Valve caches shaders on Steam. They accommodate those DIY builds by compiling them on-machine with Fossilize, converting them to system-optimized files. For DirectX titles like Elden Ring, this effectively eliminates all shader compilation stutter in-game. It also doesn't rely on fancy "first playthrough" setups, since it's translating and optimizing the original shaders wholesale.

> It has nothing to do with Linux either.

It's an out-of-box feature with Steam on Linux. You can run all of this stuff on Windows too, but you'd have to build it from source and configure DXVK environments for each game by-hand. On Linux it all happens automatically.

It’s a factor of Steam not Linux. They could in theory do it for other platforms too.

Fossilize does require at least one playthrough because shader permutations can be generated at runtime. There’s no static shader setup that’s common to all games. It just means that the first playthrough doesn’t have to be the same person playing it right now

I believe fossilize snapshots the entire pipeline configurations. It can then replay that and generate final hardware-specific binaries, not just SPIR-V, for the cache completely ahead of time.

That's much better because it doesn't matter what hardware the first person used, the data can be used everywhere.

True, the replay aspect does help as long as nothing invalidates the pipeline, which is still a higher possibility on PCs than consoles