Finished Detroit: Become Human and started a second playthrough. It works pretty good on NVIDIA, has some stutters in open areas (not related to shader compilation because it uses Vulkan natively, must be something else in Wine) but otherwise okay. Great interactive story with fantastic visuals and interesting characters!

View this comment - View article - View full comments

Quoting: AwesamLinuxIf anyone has previously played the game with the same GPU and driver version.

I think it's not entirely correct, for Vulkan the GPU and driver version doesn't matter in this case. Steam can grab the platform-independent Vulkan pipelines and serialize them to upload and distribute later, they're the same for any GPU. But to use them, as @DadSchoorse explained earlier, you need to compile them to the native GPU code and it can only be done on the end user machine. This latter option is what has been added in this update and the capture layer existed for a while.

View this comment - View article - View full comments

Quoting: Guest

Quoting: rkfgIf you prefer stutter and freezes every time something new appears on screen then yeah. But I don't think it's worth it. If you play games with a lot of shaders (= AAA games) you'd better invest into a bigger and faster SSD because the rest of your hardware should already be quite good. Honestly, bad first time experience isn't worth the saved disk space.

No, I don’t have that problem. And I have 5TB of SSD for games.

It depends on the game and mostly applies to non-native ones. If you don't play them probably you're fine. But some games stutter much more than the others and if you have plenty of space why not download those caches? Also you will help other players by uploading your cache back. It's like torrents but 100% legal!

View this comment - View article - View full comments

Quoting: GuestWhen they first introduced this shader caching/sharing thing Steam started to download hundreds of megabytes of shaders… not a very slight increase in disk and bandwidth usage, no. So I disabled it right away…

If you prefer stutter and freezes every time something new appears on screen then yeah. But I don't think it's worth it. If you play games with a lot of shaders (= AAA games) you'd better invest into a bigger and faster SSD because the rest of your hardware should already be quite good. Honestly, bad first time experience isn't worth the saved disk space.

View this comment - View article - View full comments

Quoting: DadSchoorse

Quoting: rkfgFortunately, this format is standardized at the spec level so you can use the same shader cache on any GPU, be it AMD, NVIDIA or Intel and you won't need to rebuild it each time you update the driver (remember that pain with OpenGL?). It's not a problem for correctly ported games as the port developer (like Feral) can create a native SPIR-V cache ahead of time so the game just loads the shader it needs directly. That's why Shadow of the Tomb Raider runs so smooth natively and stutters like hell on DXVK.

You are misunderstanding what SPIR-V is. It's not something that the gpu can execute, it still needs to be combined with more pipeline state information and then optimized and compiled to the specific gpu's machine code. This is very expensive to do and causes the stuttering with DXVK. And that's where fossilize comes into play. It collects all pipeline state and all shaders to create the pipelines (basically gpu programs) and then Steam distributes them so that you can compile them for your specific driver and gpu outside of the game. That way the driver can cache the pipelines and doesn't need to compile them from scratch while you're playing.
As for why Feral ports don't stutter like DXVK, D3D11 doesn't give enough information on how a shader will be used before actually using it, that's why DXVK can only compile the pipeline when the game draws something with it. Feral know how shaders will be used since they have access to the game, so that's a big advantage.

Thanks, that's new to me! I thought SPIR-V is executed directly by the underlying driver since it's in the standard. But yeah, the very low hardware level is still different for every GPU so indeed some sort of translation happens under the hood. I didn't know the bottleneck is in the final compilation for the GPU. Good explanation, I was wondering why we need more preprocessing with this new feature if Steam already provides the cache. Now it's more clear.

Also, in the Fossilize README there's this:

The goal for this project is to cover some main use cases:
<...>
Serialize state in application once, replay on N devices to build up VkPipelineCache objects without having to run application.

I think this is exactly what happens because when Steam is doing this new task there's a fossilize_replay process mentioned in nvidia-smi output. Would be really interesting to see how smooth it all is now out of the box, will try with a good-looking F2P game later.

View this comment - View article - View full comments

This is a very interesting tech! I wonder how they implemented it. The D3D shaders are stored in the game resources which can be in whatever proprietary format the developers choose so they can't be automatically extracted and transpiled to SPIR-V (the Vulkan binary shader format). Fortunately, this format is standardized at the spec level so you can use the same shader cache on any GPU, be it AMD, NVIDIA or Intel and you won't need to rebuild it each time you update the driver (remember that pain with OpenGL?). It's not a problem for correctly ported games as the port developer (like Feral) can create a native SPIR-V cache ahead of time so the game just loads the shader it needs directly. That's why Shadow of the Tomb Raider runs so smooth natively and stutters like hell on DXVK.

I also had severe freezes in Halo 2 at the level start and often when you get to a new area, it's not just stutter but a full freeze for 2-3 seconds. That's how bad it is. Interestingly, Steam downloaded the shader updates several times even though I didn't play the game at the time! If I played it I could explain it as a shader cache "corruption" from the Steam point of view, like I compiled some more shaders and it found differencies and updated it. But that wasn't the case. And the file was bigger and bigger every time so something definitely is going on behind the scenes.

Still, the only way I see to eliminate this stuttering that's caused by shader transpiling is to actually play the game so it loads the shaders and causes DXVK to process and cache them. So how do Valve do that? Do they have a dedicated employee that plays non-native games from start to finish to cause it to load all the shaders it has? I doubt that's the case. If you look at the %STEAMROOT%/steamapps/shadercache/%appid%/ directory it's pretty interesting. Let's take a look at Halo (976730):

 
976730
├── DXVK_state_cache
│   └── MCC-Win64-Shipping.dxvk-cache
├── fozpipelinesv4
│   ├── steamapp_pipeline_cache.foz
│   └── steam_pipeline_cache.foz
├── nvidiav1
│   └── GLCache
│       └── ad4b934e19c9451ee3bd46c449bff6c8
│           └── 30d616d94318fb8e
│               ├── steamapp_shader_cache0.bin
│               ├── steamapp_shader_cache0.toc
│               ├── steam_shader_cache.bin
│               └── steam_shader_cache.toc
└── swarm
    └── steam_shader_cache
        ├── bucket_1695.swarc
        └── bucket_211696.swarc
Ok, the usual DXVK cache is there but it's really small, only 3.1 Mb. steamapp_pipeline_cache.foz is 51 Mb, steam_pipeline_cache.foz is 285 Mb. Probably that's the main one. GLCache is smaller (64 Mb in total, probably the same stuff you can find in your ~/.nv directory; weird, I have no idea why there's even any mention of OpenGL when all I use is DXVK) but the suspicious directory is swarm (313 Mb, the individual files are 287 Mb and 26 Mb). That's a p2p-like name and I suspect Steam uploads players caches to their servers and combines them into a shared cache to push it back to everybody later. That's how they might crowdsource the shaders.

I couldn't find any information regarding this system and it would be very interesting to read how it all works.

Edit: oh well, it says it right there, lol:

View this comment - View article - View full comments

Quoting: keanThese programs are basically useless, I gave up on Rust and PUBG, because it was still full of cheaters.
I wish these will support Proton in the future, I would like to play some competitive FPS with my friends while sticking to Linux.

Feels to me like the point of those "anticheats" is not to get rid of cheaters at all... I wonder what their real purpose could be 🤔

View this comment - View article - View full comments

Quoting: PatolaI hope they succeed specially if they let go of these ridiculous monetization schemes, but I couldn't help but start chuckling incontrollably when I read these news. Frankly speaking, I think it's too late to recover from the failure.

It's exactly too late for people to remember the failure so the timing is right. They can essentially relaunch the game so that it looks almost like nothing from before. Make it F2P, give some bonuses (like battle pass) to those who bought the game before and fix the most glaring issues. They had plenty of time for that, although I'm pretty sure they only recently started working on Artifact because they were busy with Underlords and HL:A before. I'm optimistic about Artifact, Valve learned a lot and they can make it right this time attracting new audience as well. Many people never even heard about the game before or didn't want to buy it due to the high price or pay-to-win mechanics.

View this comment - View article - View full comments

Why do you think AMD is more secure? Sure, their CPUs/chipsets don't have these exact Intel technologies but they have other things that might be vulnerable. Also, many of those CPU data leaks were not Intel-specific.

View this comment - View article - View full comments

Quoting: Liam Dawe

Quoting: rkfg

Quoting: Liam Dawe

Quoting: rkfgTwo notes:
1) The XBox live login can't be remembered between sessions so you'll need to login every time you launch the game. Fortunately, if you use Google or GitHub account for that you won't need to enter your login/password every time, just select the method.

Doesn't happen to me, I linked my account and now I just click my bit and I'm right in the main menu.

But you still have to select GitHub/Google, correct? I expect to get to the menu instantly after launching the game and it doesn't happen. I suppose it remembers whatever token is used to authenticate me but it still requires to choose the auth method for that or enter the username/email.

No, I literally open the game, click my user on the XBL screen [External Link] and then I'm in. What Proton version are you using? I remember the update that fixed it mentioned you needed to use the Steam Beta Client if you're on an older distribution too as it needs a newer version of gnutls.

Hmm, that's weird then. I use Proton 5.0-3, after I launch the game it always says "Let's get you signed in". The gnutls issue was more serious, it didn't allow you to sign in at all (or even launch the game, don't remember) due to a missing function. I'll try to switch to Steam Beta just to check.
EDIT: looks like when I login with email and password it remembers me. I don't need to enter these details after restart anymore. I used GitHub login because there were troubles with login on the release before Wine has been patched and I got tired entering the long password over and over. Now it just works.

View this comment - View article - View full comments