Quoting: chomwittIsn't Proton a patched wine?

Yes but where did you pull that "port" part?

No one ports anything, Wine/Proton usage =! Port

View this comment - View article - View full comments

Quoting: aufkrawallMemory leak (or what would be the appropriate term) with VKD3D-Proton is finally fixed.

Vkd3d master has a workaround for it, so are you sure if driver really fixed it or it is just vkd3d workaround?

https://github.com/HansKristian-Work/vkd3d-proton/commit/403d1f97434b6dbbdb3c8ab9391d6903846fd8d6 [External Link]

View this comment - View article - View full comments

Hopefully Valve will build up a cache for people to download in Steam like other games.

Fwiw, Valve doesn't build those pipelines. It is users.

They play the game, they start to cache them, client collects them from users, once there are enough to ship and validate client downloads them and client starts building shaders in two ways:

1-) Either in the background

2-) Or if it didn't have time to build them and they are still pending to be processed, client goes into full blast mode ( uses all available threads on your cpu) and builds them.

For background processing default value is 1/4 of your threads iirc.

View this comment - View article - View full comments

Quoting: Comandante ÑoñardoThe last "stable" NVIDIA 470.57.02 has memory leaks

Known issue. Reported to Nvidia when 470 was in beta phase. Mostly happens on D3D12 titles.

465 driver is fine. Regression is 470 specific.

View this comment - View article - View full comments

Quoting: gradyvuckovicIs there any advantage to using this over say Lutris for example?

Nope. Lutris is a launcher. What you meant is Lutris Wine builds i assume.

Lutris Wine builds are better in terms of game compat, they are based on TKG Wine and protects users from regressions with hotfixes they include to maintain game compat while providing upstream based builds.

View this comment - View article - View full comments

Quoting: Beamboom... And just to add to this, if we look at the available games on Stadia today:

https://stadia.google.com/games [External Link]

Scroll down to the store titles. Do anyone honestly believe that all those titles are really fully ported to Linux? Seriously? Look at that list.

Maybe a custom library or three are added just to add an API to the controllers or something, maybe, but honestly: It simply doesn't add up for me. There has to be a layer of some sort, with the vast majority of the code running being the original windows binaries.

Yes, all of those got ported to Stadia.

If you want i can throw Doom 2016 Stadia port experiences video from id Software dev, comments from Durante ( PC porter that was previously a well famed modder, also does Stadia ports )on Reddit about his Stadia ports and Stadia port requirements , Bungie's Destiny 2 Stadia port experiences video, Ubisoft's Ac Odyssey Stadia port experiences video.

Why those games ported to Stadia and why they don't see daylight for Linux desktop?

- Google pays small fortunes to get those ports on their platform.
- Supporting Stadia as a platform is lot easier than supporting desktop Linux; one driver, one set of hardware, no user input/choice that can cause different behaviour between instances. It is essentially a console but on cloud.
-While in house ports does exists and if they are confident about their Vulkan work it ends up in PC build ( such as Rockstar's RDR2,Vulkan is default api for RDR2 on PC) ; most of those ports were outsourced to porting houses such as QLOC ( Ported Cyberpunk 2077 to Stadia ) with basically zero tests being done on actual PC hw combinations. So neither build itself or VLK backend itself won't end up on PC for such cases.

PS: DXVK-native is also being used for some Stadia ports. Just like how Portal 2, Left 4 Dead 2 Linux ports are using DXVK-native. DXVK-native is meant for usage as a native library. Just name containing DXVK doesn't make it not native.

Stadia doesn't use Wine/doesn't rely on Wine.

View this comment - View article - View full comments

Quoting: BielFPs

Quoting: LeopardIt is not the fault of game devs; those popular engines has second class citizen support for anything that is a non MS graphics api.

Hence the point of my post: first ask for Vulkan then latter for a native version.

Yes, a Vulkan backend that got all dev time on a PC build is vastly better than having a port that translates from D3D code.

With source code access that is also ok ( for example like it happened with SoTR port of Feral) but usually that is not the case.

With having first class citizen Vulkan backends on PC ( Windows ) Proton should be much more viable.

It takes time and money to port an engine to another platform, so Proton can take care of this part.

View this comment - View article - View full comments

Quoting: BielFPsI said this before and I will say it again: Before ask developers to support Linux we need to ask them to support Vulkan first, in order to make them create better games with the api.

Every game made with Directx in mind is a potential "Proton only" game, which will result in cases like Trine where even if they have a native version it's different/worse than their windows counterpart, but more games made with Vulkan in mind means better performance, which means more chances to have a (good) linux native version.

Quoting: STiATOn other games (Valheim in example), the Linux port is so bad performance whise (OGL and Vulkan) that it's actually better to play using Proton,

Exactly, my last refunded game had a native port too (Last Epoch) where the game wouldn't even start in my machine, so what was the point of a native version for me in this case?

In case of Valheim I notice this too, and the cause is not Vulkan being worse than Directx, but probably because the developers are more comfortable at working with dx, because dx has more support (easier to work with) than Vulkan right now, hence why it's important to encourage more developers to work with Vulkan even if their games will be Windows only.

Valheim is a Unity title.

For Unity; GL is basically deprecated ( even if they don't call it that way) and Vulkan is there for mobile purposes.

Same goes for Unreal Engine too. Nearly all dev time+money goes into D3D side.

It is not the fault of game devs; those popular engines has second class citizen support for anything that is a non MS graphics api.

So Metal also shares the same fate.

View this comment - View article - View full comments

Quoting: GuestActually their statement is worse in my opinion: native or not, no support at all for running their games on GNU/Linux by any means. I doubt anyone can take a platform seriously if there's no support for it.
A depressing statement. Not that Trine3 ever ran (at all) for me, but Trine and Trine2 were great.

What makes this even worse is that Trine 4 is on Stadia.

They stated they are using a translation layer on Stadia build, so it is not native Vulkan there.

https://steamcommunity.com/app/690640/discussions/0/1842440600620771518/?ctp=2#c4768721849830898948 [External Link]

Likely DXVK but they didn't disclose it.

So far games that are confirmed to be using DXVK on Stadia:

-YS8 ( Confirmed by Durante on Reddit )
-Metro Exodus ( DXVK is mentioned in credits screen, game is native Vulkan on Steam Linux build. It has raytracing on Steam Linux build also)

Google also said they will include translation layers in their SDK to ease porting process, for DX9/10/11.

That is also likely DXVK.

View this comment - View article - View full comments

Quoting: 1xok

Quoting: vipor29i know some want ports and those will never go away from the indie developers but when it comes to the AAA stuff we can usually run those titles anyway. with anti cheat being worked on it will get even better so this is not all doom and gloom.

I remember a statement by the DXVK developer that games with a lot of different shaders (I think it was Tomb Raider) are difficult for DXVK. See:

https://www.youtube.com/watch?v=p53sVKwSqZ4 [External Link]

Has anything changed in this regard? After all, it's these games that will push the Steam Deck to its limits. I'm hoping more that with the Steam Deck and Proton the Gordian knot will now be cut. And that there will be many more ports for Linux in the future. Preferably day one releases.

It's not just about the renderers, but ultimately also about the middleware, which is still different under Linux. It also reduces dependencies. Of course, they have to be high-quality ports. But that is precisely what Ferral is known for.

Difficult as in it will stutter like crazy.

Steam has Fossilize for this very reason. It works in multiple ways:

-If a user with same hw, same driver combo cached those shaders on their gameplay client collects them and ships to other users matching those criterias.

-Steam client also creates Fossilize pipelines. So even if you are on newest driver before anyone else, Steam client will compile shaders for you at background/before going into game. By default background caching uses 1/4 of your threads, when you still have pending compile work and press play it will go full blast which will use all of your threads.

-Steam client will also ship transcoded video files with that system. Ones that you are currently seeing a test screen when you encounter such videos where it is not possible for Valve to transcode them on runtime due to licensing issues.

View this comment - View article - View full comments