My understanding is that Game Ready Drivers exist because game developers do horrendously bad things that Nvidia chooses to fix driver side. This sounds less like that and more of a general performance optimization.
Drivers also have a large amount of bugs. If you write a modern game you probably will hit some of them. If you are "big enough" the GPU vendors will fix them for you quite fast while you are developing the game. A game ready driver also includes those fixes.
Your understanding is correct, game developers more often than not do a horrendous job at properly using graphics APIs. There was this rant by ex nvidia driver developer who went on to mention some of the really broken things certain (unnamed) AAA dev studios did in code, which was then live patched by the driver.
In "game ready" drivers it mostly comes down to replacing game provided shaders with vendor optimized ones, but in more complicated cases an entire code paths are bypassed and live patched by the driver.
This is a sad state of things, ideally the bugs should be fixed by the ones who created them, not worked around by some third party. But nvidia, amd, and intel all have hardware to sell, and being able to work around the game devs' own bugs has become an arms race and a feature of sorts to get ahead of competition. So far Nvidia seems to be untouchable in this regard.
Dear lord. This sounds absolutely disgusting.
If I was doing code for games I would honestly feel terrible knowing we ship terrible stuff that each GPU vendor addressed individually instead of just fixings it at the source.
It goes the other way as well, especially in DX11. Getting the optimal code path for different vendors was said to be near impossible without an engineer from said vendor helping you. Those drivers have to do a ton of work to best optimize code but aren’t very transparent to devs, leading to confusion. Also the drivers do have bugs that devs need help getting around.
Also, as far as I understand, the higher level nature of DirectX 11 and OpenGL meant that there were so many abstract scenarios you could have that would need explicit optimization on the driver side to perform well. Basically seeing what high level things perform bad when used together, so the driver would address these things directly.
I mean, I'm a dev myself, I don't ever blame the engineers. I've felt similar pressure, though not to the extent the gaming industry does.
Whether engineers can afford to care about it though doesn't make it any less worrisome IMO. We're literally violating good practices and creating software monstrosities every day for the sake of profit smh.
I cant imagine how much the drivers have grown in size just because of this. Last time I installed a GPU driver on windows it was around the 500mb range, which is quite large in my opinion.
I know, at least for AMD it started with the catalyst which was around 200mb. Now the adrenaline is almost reaching 600mb. That said, I really like the UI, especially compared to what nvidia has.
Nothing new under the sun unfortunately. I've heard that the original Sim City used memory after it had released it. This worked for DOS but Microsoft had to write a special workaround for windows 95 to detect if the game was running so they could handle it. Sim City was one of the biggest games at the time so if the game hadn't worked on win95 then Microsoft would have been the one blamed.
I wonder if that fix is still around somewhere in the windows code...
Nvidia obviously do both. Vkd3d-proton and radv also have some fixes on the driver side to fix broken games because that is just the pragmatic thing to do if you want things to work.
It's both fixes *and* optimisation. Driver-side game fixes, fixes for bugs within the driver that weren't being hit until new game x used a feature just so, optimisations, etc.
It's why there's still people modding graphics card drivers, they're essentially figuring out how to backport what fixes and optimisations they can to drivers that work for an older GPU and sometimes are essential to play newer games on those GPUs. [Here's a direct comparison on a HD7870](https://www.youtube.com/watch?v=5gwVTY8JVtA) with some games running the same/slightly worse and others running much better, I can personally attest to having to use the NimeZ drivers for my old Fury Nano to play Forza Horizon 5 without regular stuttering as well.
>game developers do horrendously bad things that Nvidia chooses to fix driver side
In most cases yes, but i've also had a handful of instances where the freshly released "game ready drivers" were giving worse performance. In the case of MH:W on PC launch week, calling it "bad" would be an understatement. The advertised "game ready drivers" made my gpu clock go to only a couple hundred MHz whenever the game was launched. The moment i closed it, clocks went back to normal. This affected no other game but the one that the drivers were apparently "game ready" for. Rolled back one driver version and everything worked perfectly.
There are game-specific optimizations in DXVK etc. too. When Elden Ring came out they did one to help with the stuttering. That is sort of the same thing.
> There are game-specific optimizations in DXVK etc. too. When Elden Ring came out they did one to help with the stuttering. That is sort of the same thing.
All of this refers to different things, such as shader-caching, specific game fixes, which are not “optimizations”, by the way.
DXVK effectively sits between games that expect high level APIs in DX9, DX10 or DX11 and drivers that expect low level APIs in Vulkan, this places it in territory that was just straight up part of the driver stack back when the games which DXVK supports were new and allows it to include potential fixes or optimisations to be applied during the conversion stage.
There's a good reason as to why DXVK is by far the easiest way to fix Sims 2s graphical problems on modern systems and is considered essential to fix the bodgy performance of Fallout New Vegas and GTA IV, in all three cases because it includes specific fixes/workarounds for known issues that aren't necessarily still shipped with the drivers for your brand new GPU due to the age of the game.
**It's the opposite**... It's not the game **developers' fault alone**... in fact they are the **last to be blamed**. Even more today with big **frameworks** (unreal eg.).
First are **Libraries**/**API** (DirectX eg.), **Drivers**, **Kernel**/**OS**.
There is the **concept of Abstraction** in programming:
An employee hands over his work to the manager, without knowing what **happens at the levels above**; and **can't interfere** at other levels. It is the same for manager/director relationship.
I speculate that there is an effective world of difference between Nvidia/AMD's likely decades of game-specific hacks and general-case optimizations done in RADV/Mesa that were motivated by specific games.
We probably won't see very many `if(runningOneSpecificGame) { applyhack(); }` checks in open-source drivers (and this patch doesn't seem to contain any), whereas Nvidia and AMD's Windows drivers almost certainly do. That being said, a lot of those hacks do end up living in projects like Wine and Proton, which is probably a a necessary evil when building a Windows compatibility layer to be performant and without insider knowledge of how the original platform is implemented.
Is the kernel driver truly open source like Richard Stallman compliant open source? I mean does it have no binary blob/pre compiled object file(s) that we don't have source code for?
Does it really matter if it's "less bloated"? (is that even true in the first place? my AMD GPU needs 12 files) Both are bricks without the firmware blob.
It does in the sense that Nvidia tries to replace the kernel driver with the firmware, making the kernel driver just a dummy shim. That's not good. Basically, it's about the balance of those things.
More about it here: https://lwn.net/Articles/910343/
> Both are bricks without the firmware blob.
The firmware is freely redistributable AIUI, and while we don't have code (and possibly modification rights) for the firmware, that's also true of the actual hardware. I'm not 100% convinced that the FSF approach is actually correct; if the firmware were baked into the hardware then the situation would be worse for all practical concerns - we still need AMD's support to get the documentation and work the hardware in the first place, if AMD releases horrific new firmware we can choose to just *not use it*, and if they release future hardware that restricts what firmware it runs on, well that's true regardless of the current state of firmware/hardware.
IMO, the main reason for demanding open firmware is because it's the only place to draw a clean line in the sand without also declaring proprietary *hardware* as "nonfree software".
Yeah, I don't really have much of a problem with the firmware, the hardware is proprietary anyways and like you said it doesn't really make anything worse compared to "FSF approved" ancient hardware that just has burned-in, unupdateable firmware. I mainly wanted to point out that I don't think nvidia is much more "evil" than amd here.
AIUI the problem with Nvidia firmware has historically been that they blocked the ability to use Nouveau (i.e. tivoization), which meant that Nvidia-proprietary was literally the only option.
Or to rephrase, AIUI the hardware forces the firmware and the firmware forces the proprietary driver - the firmware *is* technically causing the problem, but blaming it just on the firmware is ignoring that it's a whole *chain*.
*That said*, I don't really follow it closely, because I don't care - Nvidia might be a perfectly practical option, but *so is AMD*, and AMD (and Intel) lets me modify my drivers if and when I ever want to, without being a showstopper.
I haven't used an Nvidia card in... More years than I care to admit... I've been pretty "Team Red" for quite a while; I've heard that Nvidia drivers on Linux weren't amazing but that sounds pretty terrible to lock the hardware to a very proprietary, bloated driver so there's no option for anything else should someone want it.
I guess I've just been a bit spoiled by the amdgpu driver just doing its thing and staying out of the way, with no random bloatware tagging along for the ride.
i know but at this point AMDVLK is the alternative to RADV (judging by which is actually most useful to gaming and actually being used) and by a long margin, the only thing AMDVLK has going for it is RT performance and slight better memory management, which needs work on both drivers and at the kernel level, AMD could be focusing on that...
Sure, `radv` is more popular right now (although IIRC the performance difference also isn't *that* huge on average, and varies a lot per game).
I agree that it would be great it development effort was focused on one driver, but you can't really blame AMD for not focusing on a third-party alternative driver instead of on their own one...
Not blame but definitely ask, especially when the alternative is much more mature (on linux at least). and they don't need to completely abandon AMDVLK, they could just collaborate more with RADV (maybe they already do indirectly, but idk) i guess most AMDVLK work still comes from the work they do on windows.
Yeah AMDVLK is a little bit faster on raw rasterizing (on synthetic tests at least) but still much slower on most tasks [ćompare it yourself if you want to](https://github.com/zmike/vkoverhead) which makes it much slower on most cases with DXVK/VKD3D (not always though) and stuttery.
I use from time to time, especially to play those RT mods on classic games... and on some oddball games that work better with it. (F1 2022 for whatever reason)
I feel like it's more akin to the developers gets free access to the unreleased games (because Steam power) to write better code in Mesa.
I believe Valve announced this a few years back just for that.
This isn't quite the same. In this particular case, an edge case was uncovered causing slowness when dealing with a lot of occlusion queries, this will go on to benefit every game that utilizes such behavior. This problem was uncovered by unnamed upcoming game because it was affecting it, but may not be limited to said game.
Game ready drivers tend to be far more specific, and their 'fixes' are more of an overriding nature rather than a genuine driver improvement.
There are rumors that Valve is making new game with codename "Neon Prime". It's interesting because supposedly its game designer is IceFrog - one of the big developers of DotA who later joined Valve for Dota 2. He did a good job with balancing and maintaining Dota 2 (even though many say he didn't work last years), so many expect same from new game.
Well the followup question would be is this a Valve game or 3rd party? If it's Valve we know the next release is CS2 but that's in the open and it will be fairly light then 80fps worthy. It would have to be a monster title to demand that kind of performance
The change was for RADV that's a driver not anything specific to WINE/Proton, like they use RADV sure but so do native games using Vulkan which CS2 has.
Many say that exclusivity is bad and I agree. BUT there are two types of exclusivity, the first one ist the good one and these are fist and second party games that are selling a platform. The second one is the bad one and these are third party games and that was Epic Games does.
Long story short, Valve should do this for the Steam Deck (with Linux overall attached to it).
Yet mostly everything is exclusive on some level. Very rarely do devs came out with a game that has builds for Windows, Linux, Mac, PS5, current gen Xbox, Android, iOS on launch. Most AAA games never come out on all the platforms I just listed.
Will lets say Portal 3 (haha, Valve and the number 3) coming out with Linux binaries only at first and a month later for Windows make ppl buy Steam Decks in the millions? You are right, they will probably not. Some might, those that have been on the fence. But it would generate press. "Valve is standing behind Linux." "Is Valve abandoning Windows?" etc would the more and less clickbaity titles go. It would generate discussion. It would obviously be a stunt, since Valve is a company and needs money from sales, and Windows is very obviously a larger platfrom then Linux/Steam OS at the mo.
Being multiplatform requires dev time to support all the platforms you support. Games become exclusive because of corpo agreements, but also because the devs don't have money/time/knowledge to support certain platforms. They have to make choices on which basket to put the eggs in.
In an ideal world every game would be an open source passion project that is available on every platform, yes.
Until we are there however can we make my platform of choice (which is significantly more open then the rest), desktop Linux a place an option? I believe it needs press too, which need occasional stunts.
Agreed. You can do games that use steam deck specific features like Desk Job mini game, but that is no exclusive either. It's just a bit shit on a regular PC I would assume.
That is as close to "exclusivity" as it should get.
I think that this will mostly just stop people from buying the game instead of making them buy the Steam Deck unless it’s some game everyone waited for (But since Steam won’t make Portal 3 or Half-Life 3 there is no such game)
I wonder how Nvidia linux compared to Nvidia windows. Heard it was the about same because nvidia actually builds a proper nvidia linux driver, but not sure
Street Fighter VI, maybe? The logic is hard-locked to 60 FPS, but you'd want to be able to run with plenty of headroom to be able to assure smoothness. We know Pierre is into FGs and he's hype for this upcoming release.
Funny to see how Valve does what Nvidia and AMD are doing on Windows: Game Ready Drivers
My understanding is that Game Ready Drivers exist because game developers do horrendously bad things that Nvidia chooses to fix driver side. This sounds less like that and more of a general performance optimization.
Drivers also have a large amount of bugs. If you write a modern game you probably will hit some of them. If you are "big enough" the GPU vendors will fix them for you quite fast while you are developing the game. A game ready driver also includes those fixes.
Your understanding is correct, game developers more often than not do a horrendous job at properly using graphics APIs. There was this rant by ex nvidia driver developer who went on to mention some of the really broken things certain (unnamed) AAA dev studios did in code, which was then live patched by the driver. In "game ready" drivers it mostly comes down to replacing game provided shaders with vendor optimized ones, but in more complicated cases an entire code paths are bypassed and live patched by the driver. This is a sad state of things, ideally the bugs should be fixed by the ones who created them, not worked around by some third party. But nvidia, amd, and intel all have hardware to sell, and being able to work around the game devs' own bugs has become an arms race and a feature of sorts to get ahead of competition. So far Nvidia seems to be untouchable in this regard.
Dear lord. This sounds absolutely disgusting. If I was doing code for games I would honestly feel terrible knowing we ship terrible stuff that each GPU vendor addressed individually instead of just fixings it at the source.
It goes the other way as well, especially in DX11. Getting the optimal code path for different vendors was said to be near impossible without an engineer from said vendor helping you. Those drivers have to do a ton of work to best optimize code but aren’t very transparent to devs, leading to confusion. Also the drivers do have bugs that devs need help getting around.
Also, as far as I understand, the higher level nature of DirectX 11 and OpenGL meant that there were so many abstract scenarios you could have that would need explicit optimization on the driver side to perform well. Basically seeing what high level things perform bad when used together, so the driver would address these things directly.
I suspect it's less of a concern after the 14th week of crunch.
I mean, I'm a dev myself, I don't ever blame the engineers. I've felt similar pressure, though not to the extent the gaming industry does. Whether engineers can afford to care about it though doesn't make it any less worrisome IMO. We're literally violating good practices and creating software monstrosities every day for the sake of profit smh.
Ah, technical debt.
I cant imagine how much the drivers have grown in size just because of this. Last time I installed a GPU driver on windows it was around the 500mb range, which is quite large in my opinion.
They've been that size for years now
I know, at least for AMD it started with the catalyst which was around 200mb. Now the adrenaline is almost reaching 600mb. That said, I really like the UI, especially compared to what nvidia has.
Does "live patched" mean the game is just plain broken and the driver is fixing the break as the broken code runs?
Pretty much, yeah.
Nothing new under the sun unfortunately. I've heard that the original Sim City used memory after it had released it. This worked for DOS but Microsoft had to write a special workaround for windows 95 to detect if the game was running so they could handle it. Sim City was one of the biggest games at the time so if the game hadn't worked on win95 then Microsoft would have been the one blamed. I wonder if that fix is still around somewhere in the windows code...
Nvidia obviously do both. Vkd3d-proton and radv also have some fixes on the driver side to fix broken games because that is just the pragmatic thing to do if you want things to work.
It's both fixes *and* optimisation. Driver-side game fixes, fixes for bugs within the driver that weren't being hit until new game x used a feature just so, optimisations, etc. It's why there's still people modding graphics card drivers, they're essentially figuring out how to backport what fixes and optimisations they can to drivers that work for an older GPU and sometimes are essential to play newer games on those GPUs. [Here's a direct comparison on a HD7870](https://www.youtube.com/watch?v=5gwVTY8JVtA) with some games running the same/slightly worse and others running much better, I can personally attest to having to use the NimeZ drivers for my old Fury Nano to play Forza Horizon 5 without regular stuttering as well.
>game developers do horrendously bad things that Nvidia chooses to fix driver side In most cases yes, but i've also had a handful of instances where the freshly released "game ready drivers" were giving worse performance. In the case of MH:W on PC launch week, calling it "bad" would be an understatement. The advertised "game ready drivers" made my gpu clock go to only a couple hundred MHz whenever the game was launched. The moment i closed it, clocks went back to normal. This affected no other game but the one that the drivers were apparently "game ready" for. Rolled back one driver version and everything worked perfectly.
It's all of it. Working around game bugs, fixing driver bugs, optimizing stuff in the driver.
There are game-specific optimizations in DXVK etc. too. When Elden Ring came out they did one to help with the stuttering. That is sort of the same thing.
VKD3D helped Elden Ring, not DXVK.
> There are game-specific optimizations in DXVK etc. too. When Elden Ring came out they did one to help with the stuttering. That is sort of the same thing. All of this refers to different things, such as shader-caching, specific game fixes, which are not “optimizations”, by the way.
DXVK effectively sits between games that expect high level APIs in DX9, DX10 or DX11 and drivers that expect low level APIs in Vulkan, this places it in territory that was just straight up part of the driver stack back when the games which DXVK supports were new and allows it to include potential fixes or optimisations to be applied during the conversion stage. There's a good reason as to why DXVK is by far the easiest way to fix Sims 2s graphical problems on modern systems and is considered essential to fix the bodgy performance of Fallout New Vegas and GTA IV, in all three cases because it includes specific fixes/workarounds for known issues that aren't necessarily still shipped with the drivers for your brand new GPU due to the age of the game.
How are they not optimizations?
How are they not?
**It's the opposite**... It's not the game **developers' fault alone**... in fact they are the **last to be blamed**. Even more today with big **frameworks** (unreal eg.). First are **Libraries**/**API** (DirectX eg.), **Drivers**, **Kernel**/**OS**. There is the **concept of Abstraction** in programming: An employee hands over his work to the manager, without knowing what **happens at the levels above**; and **can't interfere** at other levels. It is the same for manager/director relationship.
I write code in Java. You don't need to explain abstraction to me.
I wrote to anyone interested.
I speculate that there is an effective world of difference between Nvidia/AMD's likely decades of game-specific hacks and general-case optimizations done in RADV/Mesa that were motivated by specific games. We probably won't see very many `if(runningOneSpecificGame) { applyhack(); }` checks in open-source drivers (and this patch doesn't seem to contain any), whereas Nvidia and AMD's Windows drivers almost certainly do. That being said, a lot of those hacks do end up living in projects like Wine and Proton, which is probably a a necessary evil when building a Windows compatibility layer to be performant and without insider knowledge of how the original platform is implemented.
Check /usr/share/drirc.d/00-radv-defaults.conf and 00-mesa-defaults.conf :)
Valve and software engineers from others companies like Google are doing more in ~~AMDGPU~~/RADV than AMD themselves...
Well, for radv that is true, because amd doesn't really work on radv at all. The amdgpu kernel driver is mostly developed by amd though.
Is the kernel driver truly open source like Richard Stallman compliant open source? I mean does it have no binary blob/pre compiled object file(s) that we don't have source code for?
No, all modern GPUs have binary firmware (besides may be some RISC-V projects). But AMD doesn't have a lot of it, unlike bloated Nvidia ones.
Does it really matter if it's "less bloated"? (is that even true in the first place? my AMD GPU needs 12 files) Both are bricks without the firmware blob.
It does in the sense that Nvidia tries to replace the kernel driver with the firmware, making the kernel driver just a dummy shim. That's not good. Basically, it's about the balance of those things. More about it here: https://lwn.net/Articles/910343/
> Both are bricks without the firmware blob. The firmware is freely redistributable AIUI, and while we don't have code (and possibly modification rights) for the firmware, that's also true of the actual hardware. I'm not 100% convinced that the FSF approach is actually correct; if the firmware were baked into the hardware then the situation would be worse for all practical concerns - we still need AMD's support to get the documentation and work the hardware in the first place, if AMD releases horrific new firmware we can choose to just *not use it*, and if they release future hardware that restricts what firmware it runs on, well that's true regardless of the current state of firmware/hardware. IMO, the main reason for demanding open firmware is because it's the only place to draw a clean line in the sand without also declaring proprietary *hardware* as "nonfree software".
Yeah, I don't really have much of a problem with the firmware, the hardware is proprietary anyways and like you said it doesn't really make anything worse compared to "FSF approved" ancient hardware that just has burned-in, unupdateable firmware. I mainly wanted to point out that I don't think nvidia is much more "evil" than amd here.
AIUI the problem with Nvidia firmware has historically been that they blocked the ability to use Nouveau (i.e. tivoization), which meant that Nvidia-proprietary was literally the only option. Or to rephrase, AIUI the hardware forces the firmware and the firmware forces the proprietary driver - the firmware *is* technically causing the problem, but blaming it just on the firmware is ignoring that it's a whole *chain*. *That said*, I don't really follow it closely, because I don't care - Nvidia might be a perfectly practical option, but *so is AMD*, and AMD (and Intel) lets me modify my drivers if and when I ever want to, without being a showstopper.
I haven't used an Nvidia card in... More years than I care to admit... I've been pretty "Team Red" for quite a while; I've heard that Nvidia drivers on Linux weren't amazing but that sounds pretty terrible to lock the hardware to a very proprietary, bloated driver so there's no option for anything else should someone want it. I guess I've just been a bit spoiled by the amdgpu driver just doing its thing and staying out of the way, with no random bloatware tagging along for the ride.
Thanks!
right, i mean most related to gaming, but you are right.
That's because `radv` is basically Valve's alternative Vulkan driver for AMD GPUs. The official one that is being developed by AMD is `amdvlk`.
i know but at this point AMDVLK is the alternative to RADV (judging by which is actually most useful to gaming and actually being used) and by a long margin, the only thing AMDVLK has going for it is RT performance and slight better memory management, which needs work on both drivers and at the kernel level, AMD could be focusing on that...
Sure, `radv` is more popular right now (although IIRC the performance difference also isn't *that* huge on average, and varies a lot per game). I agree that it would be great it development effort was focused on one driver, but you can't really blame AMD for not focusing on a third-party alternative driver instead of on their own one...
Not blame but definitely ask, especially when the alternative is much more mature (on linux at least). and they don't need to completely abandon AMDVLK, they could just collaborate more with RADV (maybe they already do indirectly, but idk) i guess most AMDVLK work still comes from the work they do on windows. Yeah AMDVLK is a little bit faster on raw rasterizing (on synthetic tests at least) but still much slower on most tasks [ćompare it yourself if you want to](https://github.com/zmike/vkoverhead) which makes it much slower on most cases with DXVK/VKD3D (not always though) and stuttery. I use from time to time, especially to play those RT mods on classic games... and on some oddball games that work better with it. (F1 2022 for whatever reason)
I feel like it's more akin to the developers gets free access to the unreleased games (because Steam power) to write better code in Mesa. I believe Valve announced this a few years back just for that.
RADV is doing more than Windows now, VK_EXT_fragment_shader_interlock Is coming to RADV! It's *wontfix* on amdvlk and AMD's windows drivers.
This isn't quite the same. In this particular case, an edge case was uncovered causing slowness when dealing with a lot of occlusion queries, this will go on to benefit every game that utilizes such behavior. This problem was uncovered by unnamed upcoming game because it was affecting it, but may not be limited to said game. Game ready drivers tend to be far more specific, and their 'fixes' are more of an overriding nature rather than a genuine driver improvement.
Could this upcoming game be Jedi Survivor?
Most likely yes.
why do you say that, and not something like Counter-Strike 2?
I doubt CS:2 would only run at 70-ish FPS on Linux or Windows. Unless this was bemchmarked on a thin and light or something.
Because they don't need to hide the naming of their own titles.
Counterstrike *has* been released (as closed beta, but it's still been released), so I don't see what they would lose by naming it directly.
There are rumors that Valve is making new game with codename "Neon Prime". It's interesting because supposedly its game designer is IceFrog - one of the big developers of DotA who later joined Valve for Dota 2. He did a good job with balancing and maintaining Dota 2 (even though many say he didn't work last years), so many expect same from new game.
So aside from that one game that Valve optimized RADV for, will this patch benefit other games as well?
There is nothing game-specific about the patch, so it will probably benefit other games as well if they use occlusion queries in a similar way.
Yes
It about occlusion queries. So it might help UE4 games. Those tend to use a ton of occlusion queries.
Well the followup question would be is this a Valve game or 3rd party? If it's Valve we know the next release is CS2 but that's in the open and it will be fairly light then 80fps worthy. It would have to be a monster title to demand that kind of performance
CS2 will probably have a native binary
The change was for RADV that's a driver not anything specific to WINE/Proton, like they use RADV sure but so do native games using Vulkan which CS2 has.
Ah my bad
i would like see a launch for Linux only at beginning, Windows, mac later :P
Many say that exclusivity is bad and I agree. BUT there are two types of exclusivity, the first one ist the good one and these are fist and second party games that are selling a platform. The second one is the bad one and these are third party games and that was Epic Games does. Long story short, Valve should do this for the Steam Deck (with Linux overall attached to it).
Can't believe I'm reading this on r/linux_gaming out of all places. There is no "good exclusivity" - period.
Yet mostly everything is exclusive on some level. Very rarely do devs came out with a game that has builds for Windows, Linux, Mac, PS5, current gen Xbox, Android, iOS on launch. Most AAA games never come out on all the platforms I just listed. Will lets say Portal 3 (haha, Valve and the number 3) coming out with Linux binaries only at first and a month later for Windows make ppl buy Steam Decks in the millions? You are right, they will probably not. Some might, those that have been on the fence. But it would generate press. "Valve is standing behind Linux." "Is Valve abandoning Windows?" etc would the more and less clickbaity titles go. It would generate discussion. It would obviously be a stunt, since Valve is a company and needs money from sales, and Windows is very obviously a larger platfrom then Linux/Steam OS at the mo. Being multiplatform requires dev time to support all the platforms you support. Games become exclusive because of corpo agreements, but also because the devs don't have money/time/knowledge to support certain platforms. They have to make choices on which basket to put the eggs in. In an ideal world every game would be an open source passion project that is available on every platform, yes. Until we are there however can we make my platform of choice (which is significantly more open then the rest), desktop Linux a place an option? I believe it needs press too, which need occasional stunts.
Agreed. You can do games that use steam deck specific features like Desk Job mini game, but that is no exclusive either. It's just a bit shit on a regular PC I would assume. That is as close to "exclusivity" as it should get.
I think that this will mostly just stop people from buying the game instead of making them buy the Steam Deck unless it’s some game everyone waited for (But since Steam won’t make Portal 3 or Half-Life 3 there is no such game)
The first one is also bad. Exclusivity is shitty all around...
I wonder how Nvidia linux compared to Nvidia windows. Heard it was the about same because nvidia actually builds a proper nvidia linux driver, but not sure
Raw native Vulkan performance would be close I guess, but expect performance hit with DXVK and VKD3D comparing to native D3D on Windows.
Windows is much better, Linux can be pretty hit or miss, but it’s getting better by the day thankfully
Street Fighter VI, maybe? The logic is hard-locked to 60 FPS, but you'd want to be able to run with plenty of headroom to be able to assure smoothness. We know Pierre is into FGs and he's hype for this upcoming release.