• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Vulkan SER Shader Execution Reordering Shows 40% RT uplift.

Last week's Vulkan 1.4.333 brought a new ray-tracing extension with VK_EXT_ray_tracing_invocation_reorder that was derived from a prior NVIDIA vendor extension (VK_NV_ray_tracing_invocation_reorder). This new extension for Shader Execution Reordering "SER" is showing to deliver some nice performance potential for Vulkan ray-tracing performance.

So Nvidia aren't all evil after all?
 
Last edited:
  • Like
Reactions: ChadD
like this
Oh no they are. :)
MS open sources stuff too. lol
It's all a matter of perspective. If it wasn't for Valve, the driver situation running AMD under Linux would still be a mess - AMD aren't the ones pushing driver development, Valve are. AMD simply can't be arsed when it comes to Linux, and when they could be arsed, their drivers were downright hopeless.

In comparison Nvidia support almost every platform under the sun, they provide day one support under Linux, their drivers are definitely improving at a faster rate under Linux as time advances - and as can be seen they provide useful extensions under Vulkan. The reality is: The Nvidia situation is exaggerated by users that unrealistically believe everything under Linux should be FOSS only, while playing games that are very much proprietary. Linux allows for proprietary drivers as realistically speaking it's a path many manufacturers are going to follow when the need exists to protect their IP - as long as things keep improving and new features keep getting pushed to Linux, as a Linux Nvidia user I'm happy.

Furthermore, Nvidia continue to assist with NVK.

Once the additional Vulkan extensions get merged and support exists under the Nvidia drivers for the new extensions, hopefully the situation regarding VKD3D improves and those pushing the FOSS only narrative will have one less thing to parrot on about.
 
It's all a matter of perspective. If it wasn't for Valve, the driver situation running AMD under Linux would still be a mess - AMD aren't the ones pushing driver development, Valve are. AMD simply can't be arsed when it comes to Linux, and when they could be arsed, their drivers were downright hopeless.

In comparison Nvidia support almost every platform under the sun, they provide day one support under Linux, their drivers are definitely improving at a faster rate under Linux as time advances - and as can be seen they provide useful extensions under Vulkan. The reality is: The Nvidia situation is exaggerated by users that unrealistically believe everything under Linux should be FOSS only, while playing games that are very much proprietary. Linux allows for proprietary drivers as realistically speaking it's a path many manufacturers are going to follow when the need exists to protect their IP - as long as things keep improving and new features keep getting pushed to Linux, as a Linux Nvidia user I'm happy.

Furthermore, Nvidia continue to assist with NVK.

Once the additional Vulkan extensions get merged and support exists under the Nvidia drivers for the new extensions, hopefully the situation regarding VKD3D improves and those pushing the FOSS only narrative will have one less thing to parrot on about.

AMDs in house drivers were not hopeless. I supported professional AMD stuff for awhile. Gaming was just not the priority for Linux development. AMD supported their workstation type stuff (back when they used to sell it) quite well. All long before Valve thought about Linux at all.
AMD made a choice to open source their drivers, in the hopes open source development would happen. IT did. Why would we hold that against them? That is exactly what we were asking them to do for years. Its not like they have 10,000 software developers doing other things or something. AMD developers still contribute to the kernel driver and the MESA project, as well as Vulkan. They just aren't producing competing closed source options anymore. They are still a company and the resources they do have are aimed at non desktop stuff. It really doesn't make sense for a company pushing to keep up with Intel Linux server stacks and Nvidia compute to be putting full time development hours on a Linux gaming driver.

Nvidia at any time could do the same. They have chosen not to. If Nvidia wants to be the only ones to touch anything important in regard to NV hardware that is up to them. It does hold them back on Linux imo. Just like AMD when they were doing proprietary drivers... NVs first priority for their Linux support is workstation, and server applications. Worry about say proper emulation paths for DX12 is just not a priority. (if their driver was open source... well company like Valve could maybe do that work for them, perhaps even consider using NV hardware in their devices)

I don't hate NV. NV is what it it is. They have some good software people. Yes they contribute to open source projects. NV is a company who has priorities, that don't really align with Linux gaming. That's ok its their choice. I also think at some point they might even change course a bit. There is always the outside possibility they decide the best way forward is to properly open source access to at least consumer grade hardware. I mean it sounds like Qcom has actually been playing ball recently.... all it took was Valve buying some hardware I guess.
https://www.phoronix.com/news/Linux-Kernel-Adreno-800-Patches
https://www.phoronix.com/news/Qualcomm-X2-Elite-GPU-Linux-619
If Qcom can decide open source might be a good idea after all. I am not going to count Nvidia out yet, I wouldn't place a large $ bet on it but I do think its highly likely NV decides to go full open source sometime in the next couple years. At some point they will find someone to buy N1X chips or produce a follow up and it will just make sense.
 
Last edited:
AMDs in house drivers were not hopeless.
I think you're confusing just what drivers I'm referring to here, compared to Nvidia's drivers, AMD's own proprietary drivers were undoubtedly hopeless. They were so bad they really weren't even an option. With the advent of Steam under Linux ~2103, Nvidia actually had a developer working at Valve full time working on their drivers in relation to gaming.

AMD made a choice to open source their drivers, in the hopes open source development would happen.
Because up until the point they fobbed their driver development off to OSS devs their own drivers were literally hopeless - Nvidia were literally the only realistic option for quite some time when it came to gaming under Linux. My assumption is that AMD simply don't have the resources to devote to Linux driver development from start to finish.

AMD developers still contribute to the kernel driver and the MESA project, as well as Vulkan.
AMD do their bare minimum, OSS devs do most of the work.

They are still a company and the resources they do have are aimed at non desktop stuff.
And yet they continue to develop desktop 'Windows' stuff.

Nvidia at any time could do the same. They have chosen not to.
Because they don't have to, the OSS mentality under Linux as openly pushed by OSS devs and parroted by a vocal minority of Linux users isn't a hard requirement under Linux despite what OSS devs and the community prefer to claim.

It does hold them back on Linux imo.
The only thing holding them back is the closed mindset regarding OSS devs and the refusal to develop their platform for anything not OSS. As stated in our previous discussion on this matter, OSS devs need to overcome this closed mindset and learn to work with developers of proprietary code if Linux is to advance. The expectation that everything under Linux is to be OSS only is flatly unrealistic.

They are still a company and the resources they do have are aimed at non desktop stuff. It really doesn't make sense for a company pushing to keep up with Intel Linux server stacks and Nvidia compute to be putting full time development hours on a Linux gaming driver.
This makes no sense at all, if anything the push for AI has resulted in Nvidia pushing more resources towards Linux driver development in general, which also means there's more resources dedicated to Linux gaming. Even Linus Torvalds has acknowledged that Nvidia's push for AI is advancing Linux driver development better and faster than ever before.

Lets not forget the neiche Linux has carved in the VFX industry, an industry mostly run on Linux workstations and server farms all using Nvidia hardware.

NV is a company who has priorities, that don't really align with Linux gaming.
And yet Nvidia along with the Khronos group is pushing Vulkan into the next phase whereby it suports descriptors more efficiently under more than just AMD hardware. As a statement, your comment holds no merit whatsoever. I game under Linux using Nvidia and my experience is great - I don't care how many FPS are achieved under Windows, as I have no interest in running Windows, all I care about is adequate performance under Linux (including RT performance and running the latest features) and I'm more than satisfied in that regard running Nvidia hardware/drivers.

The pelief that people should switch to Linux for gaming because it performs better is IMO a bit of a misnomer - people should not be switching to Linux under the belief that perfromance may be better under specific scenario's, peole should be switching to Linux for the freedom and sense of ownership it provides.

I swear, most of these AMD diehards haven't run Nvidia hardware under Linux for two years or more - All the while claiming to know everything about Nvidia under Linux, when realistically speaking they're simply parroting what they've read, or parroting tech tube video's running cherry picked titles to suit the narrative.

There is always the outside possibility they decide the best way forward is to properly open source access to at least consumer grade hardware.
The best way forward is for OSS devs to open the lines of communication to manufacturers regarding propriatery code, because realistically speaking propriatery code isn't going anywhere.

...

As a result of this very discussion, surley you see how this OSS mentality creats an us vs them division within the Linux community Chad, a mentality that's as futile and pointless as it is rediculious. It's not enough we're combating Windows users, we're also combating between ourselves as Linux users.
 
Last edited:
As a result of this very discussion, surley you see how this OSS mentality creats an us vs them division within the Linux community Chad, a mentality that's as futile and pointless as it is rediculious. It's not enough we're combating Windows users, we're also combating between ourselves as Linux users.

You are the one confusing things. :) I didn't say Nvidia wasn't helping out Linux. Sure their development of AI and compute tools. Their work to support GPU parallelization in data centers, and work they do for grace under Linux are huge. BUT its not for gaming, nor does that work really benefit gaming. They aren't tweaking their Linux drivers for individual games they are just copying their windows driver blob. Your confusing 2 very different things. Sure Linux is important to Nvidia. However its more important to Nvidia that their GPUs are only accessed in approved ways then in the best possible ways. NV does a lot of Linux work. True. Little of what they do has anything to do with gaming.

Again remove the idea of GAMING out of your head. AMD HAS solid workstation Linux drivers they have for a very long time. Your just thinking about gaming and doing un official non commercial things like running wine and windows games on Linux. That wasn't the focus of NV or AMD Linux product. Well AMD does have hardware in the deck. But by wisely open sourcing their stack they have allowed their PROFESSIONAL drivers to stand apart... and allowed Valve to get creative with their hardware, in ways they CAN'T with their professional drivers as real high value customers rely on those being 100% uptime and not crashing half way through renders and pre viz work.

Sure Nvidia had the money to have a embedded engineers at gaming companies like Valve. Yet Valve is now purchasing hardware and working directly with AMD and Qcom.

You bring up the niche VFX industry. Your right Nvidia has focused on driver and distrusted rendering drivers and other awesome tech for that industry. NO doubt. What does that have to do with gaming? Yes Nvidia makes a solid workstation driver. True. If your studio is running workstations for say Houdini... your NOT Running open source drivers for AMD either. SIdeFX says run the AMD pro driver. "AMD: 25.Q3 or higher"

Your also incorrect on descriptors. ;) AMDS solution is already implemented and superior to the catch up work being implemented for NV and Intel graphics which use heaps. YES it will work with AMD should software be using heaps, but its not a superior implementation to the programmable setup used by AMD, and Qcom. (not saying Qcom is on the same level but their descriptor setup like AMDs isn't heap based in hardware)

Its not about us being Neck beardy. Its about simple facts. AMD NVIDIA... neither give a toss about Linux gaming. Its not a real market. Of course they both do tons of work on windows drivers for gaming. Windows represents 97% of PC gaming. No matter how much we don't like that fact. I am not going to be upset about AMD or Nvidia for focusing on windows gaming when Linux gaming really doesn't exist. THAT is the advantage of AMD (and now Qcom) having open sourced their driver stacks. Valve does care, let them do the work. Nvidias driver setup prevents Valve from being able to do the work for NV. NV cares about LINUX sure... but they have no Rea$on to care about Linux gaming. Not right now anyway. All their work for Linux is for paid Linux users. (That isn't us and our wish to make windows software run on Linux)
 
Last edited:
With respect Chad.

You are the one confusing things. :) I didn't say Nvidia wasn't helping out Linux. Sure their development of AI and compute tools. Their work to support GPU parallelization in data centers, and work they do for grace under Linux are huge. BUT its not for gaming, nor does that work really benefit gaming.
Which I covered in my post above. There is all the evidence in the world Nvidia are pushing resources towards Linux driver development, there's no evidence whatsoever that pushing additional resources towards Linux driver development will not benefit gaming. Even the latest release notes regarding the 580.105.08 release notes specifically state the following:

Fixed a bug that caused Rage2 to crash when loading the game menu:
https://forums.developer.nvidia.com...-the-map-seems-nvidia-specific-problem/169063


https://www.nvidia.com/en-us/drivers/details/257493/

Further reinforcing the fact that Nvidia are actively working on their drivers to the benefit of Linux gaming.

AMD HAS solid workstation Linux drivers they have for a very long time.
And they were shite. As stated, Linux and Nvidia has carved a niche regarding the VFX industry, I personally know someone that supports such systems/networks - None of the workstations or servers making up render farms are using AMD hardware, and most are running some form of Linux.

But by wisely open sourcing their stack they have allowed their PROFESSIONAL drivers to stand apart...
I prefer the term "by lazily offloading...."

As stated, the evidence points to the reality that AMD simply don't have the resources to handle development of their Linux drivers from start to finish - The same isn't true regarding Nvidia, and in the last few years alone Nvidia's drivers have advanced in leaps and bounds as Nvidia push more resources into developing their Linux driver stack. If you want to talk PROFESSIONAL drivers, AMD don't hold a candle to Nvidia and Cuda, OSS or not.

You bring up the niche VFX industry. Your right Nvidia has focused on driver and distrusted rendering drivers and other awesome tech for that industry. NO doubt. What does that have to do with gaming?
VFX relies heavily on OGL as well as Vulkan, with a push towards Vulkan as the predominate API covering real time ray tracing as things advance - Obviously gaming and VFX overlap and many advancements benefiting one also benefit the other.


Yes Nvidia makes a solid workstation driver.
They make a solid driver...Period. I've personally encountered no deal breaker issues in years, even across multiple systems while swapping in/out various Nvidia GPU's. Even the tired argument that Nvidia drivers are unreliable and difficult to install has become a relic of the past with the advent of PPA's and drivers being compiled and supplied along with OS updates. Naturally in isolated cases YMMV, but this is true of any hardware (AMD included).

Your also incorrect on descriptors.
Whether the Chicken came before the egg is moot when descriptor implementation under Vulkan regarding x64 on the desktop has quite obviously been optimized in a way that suits AMD's implementation. No one's disputing that AMD's descriptor implementation is more efficient, but the fact remains that little to no effort has been made to optimize descriptor implementation under Vulkan regarding any other desktop GPU on the market today - and API's are no good if they only work optimally under one specific desktop GPU. The VKD3D issues surrounding Nvidia hardware are predominately a result of this fact - Nvidia implemented graphics heaps and descriptor tables as that's what worked under OGL (as did Intel), however Vulkan was obviously developed in a way that better suited AMD's SGPR implementation.

No one's right, no one's wrong. Assumptions were made, and Vulkan moved the goalposts compared to what was classed as accepted implementation under OGL. I've never stated Nvidia and Intel's implementations were superior, as quite obviously when it comes to Vulkan they oddly weren't. Perhaps Nvidia have an implementation similar to AMD's SGPR's in the pipeline regarding future hardware - who knows when it takes many years for hardware to move from concept, to design, fabbing, and implementation.

However, as stated, Nvidia (the company that apparently doesn't care for Linux gaming) are working with OSS devs as part of the Khronos group to implement additional instructions that improve performance under a range of GPU's as opposed to the current situation whereby Vulkan is optimized to a particular manufacturer.

Once again: There is no evidence that Nvidia do not care about gaming under Linux, in fact as highlighted there is recent evidence to the contrary. In comparison, AMD don't even want to foot the bill to get HDMI 2.1 support under the OSS Linux drivers.

Nvidia making their product perform better is somehow noble?

The article linked doesn't specifically state that the newly implemented instruction only benefits Nvidia hardware, it's context talks about Vulkan in a general sense. The newly implemented instruction was derived from a previous Nvidia extension.

I'm not trying to make the point Nvidia are noble, I'm pressing the point hard that no manufacturer is noble.
 
Last edited:
Make up your mind. Your saying Nvidia doesn't need to open source things, cause they do the work. Then you complain that Valve didn't optimize descriptors for NV hardware... when they don't sell any devices with NV hardware. They don't have access to Nvidia driver software in the way the do for AMD. That is a choice NV made, not Valve. I can't tell you if Valve would have optimized for their descriptor heap sooner if they had open source access or if they wouldn't have. Valve isn't a charity, they "optimized" as you call it for AMD descriptors cause they sell millions of hardware devices that use AMD hardware. Clearly it was logical to implement a feature that results in almost lossless DX12-Vulkan translation on THEIR hardware. I mean its not AMD hardware anymore if Valve is shipping and supporting it in a product they have sold in the millions of units.

As for AMD professional drivers.
https://www.amd.com/en/support/download/linux-drivers.html
No they are not shit. They still exist. They are solid and have always been solid. They just aren't open source and don't play nice with non commercial Linux distros that we like to use as power users. If you have a RHEL or SLES server (probably even Ubuntu) they do exactly what they are supposed to do. Accelerate professional OpenGL and Vulkan workloads reliably with zero crashing. Do we call them shit in relation to AMD Linux gaming? Well ya. Your also not wrong about AMD sales... the last 4 or 5 years AMD has not been focusing on the workstation market. Though those AMD Instinct datacenter cards are out their and they aren't running windows... they are using the AMD pro drivers for ROCM support ect. The AMD pro drivers service the market they are intended to service.... and sadly I agree AMD hasn't been going after workstation stuff for a few years. NV has been cleaning up in that segment. AMD isn't bug fixing games for their Professional Linux drivers. Also as the Linux neck beards its our duty to bad mouth them so new Linux users don't think they better install the AMD driver. ;) (that has mostly passed now but talking new people out of installing the pro driver constantly used to be a thing)

We can disagree on how Nvidia chooses to develop their driver. I don't disagree with you for professional distros like RHEL and so on Nvidia does have great software support. Nvidia is 100% pushing to implement things like their CPU+GPU rendering stacks and such. Yep no doubt. Is Nvidia really 100% behind optimizing and tuning game stuff. Clearly not. The examples you posted of NV fixing linux game bugs include a fix for a game that has been broken since 2021.... I mean that isn't exactly priority bug fixing. ;) Nvidia uses the same driver blob as windows, so yes game fixes transfer over to Linux. If its broken on windows its broken on Linux... so the same fixes apply. Specific Linux issues though can linger for a long time.

I think I have said before Maz. I see some upside in the way Nvidia does their Linux driver for gamers. Essentially unifying the windows and linux driver is actually logical and a good good solution for the current state of the industry. What reason does Nvidia really have to push Linux gaming? I mean that seriously. They have NOTHING in the market that it benefits specifically. (you could argue if gamers moved to Linux it would HURT Nvidia marketshare) Valve is clearly on board with AMD (and now Qcom) this is competition. SteamOS doesn't run on NV hardware... Linux gamers your right in general aren't team green. The advantages for NV spending a ton of development resources on Linux gaming are probably not seen as positive for them. I was hoping not long ago that Jensen would want to compete for consumer CPU sales bad enough to have him team up with Valve to bring N1X to some sort of Linux (SteamOS or NvidiaOS) reality. NOW though it looks like Valve has convinced Qcom to open source their hardware drivers. Valve is now going to be pushing AMD in 2 different devices and Qcom hardware in the steam frame, hard to say how that works out sales wise at this point. But if the Frame becomes some sort of minor hit, its putting Valve further in NVIDIA competition territory.

I am genuinely glad that by osmosis of the windows driver blob NV Linux gaming is in not a terrible spot. Your right distros that care to make it work have it working pretty well. PPAs are imo a PITA but they work. Distros like Cachy have went out of their way to make NV drivers painless. Though other popular gaming distros such as bazzite can often be a shit show. I have read it works fine, and then have also read that some people just can't get it to install right on their NV hardware. Nvidia is in a better spot then they have ever been. Still by not really supporting open source development for their hardware, they have it seems sort of siloed themselves from the people really driving Linux gaming. I don't expect Qcom or AMD or Nvidia to really be investing heavy in making Linux gaming work, its not an actual market for any of them. EVERY PC OEM ships windows. The acceptations are small... System76 has 40 employees. Valve ships essentially console hardware. There is no Linux gaming market that produces profit. So yes I wish Nvidia had done what AMD and Intel have done, and what Qcom seems to be in the process of doing. Open source the drivers for CONSUMER hardware (no one is expecting open source drivers for their datacenter or workstation type products) Open source geforce drivers. Let a company like Valve do the heavy lifting... they don't mind quietly backing a bunch of open source projects and folding in the good stuff for commercial product as needed. NV is missing the boat. I think really its mostly Jensen ego at this point. IF Linux gaming is to become a real commercial business, Jensen wants control. (that's my opinion anyway... NV not open sourcing consumer hardware drivers is about a loss of control and ego) As much as we shit on Windows and Microsoft for legit reasons. Nvidia at this point has no reason to see MS fall. As you know NV is winning the lion share of Windows PC GPU marketshare. Jensen wants in on windows ARM, but why does he want to push Linux gaming where Nvidia is not a market leader? Where to do go hard they would really have to give up control? At this point if Linux gaming takes off... its a negative for NV. Which is a shame.

I believe (its my opinion) that we haven't seen a SteamOS ISO yet... 100% because NV is doing their closed open source driver blob thing. I am convinced Valve has been trying to talk NV into open sourcing their consumer drivers. I think they believed NV would come around and maybe do a deal to power a deck2/cube/frame device of some kind. That they have chosen to hold their powder on a ISO download until they could fold NV in. I also am convinced Valve had talks with NV about buying hardware. I also 100% believe Nvidia refused to allow Valve the full access they want for such devices, that and probably asked for a stupid price on silicon. The result I have a feeling Valve is finally going to drop a SteamOS ISO in '26 without any official NV support. I don't think its good for Linux gaming, but I don't see Valve or NV budging. Its starting to look like Linux gaming (SteamOS gaming specifically) isn't just anti MS OS monopoly, it might well be a anti NV monopoly as well. lol (not saying its good it just looks like the reality)
 
Last edited:
Make up your mind. Your saying Nvidia doesn't need to open source things, cause they do the work. Then you complain that Valve didn't optimize descriptors for NV hardware... when they don't sell any devices with NV hardware.

I stated that the evidence points to the reality that AMD simply don't have the resources to handle development of their Linux drivers from start to finish - The same isn't true regarding Nvidia, and in the last few years alone Nvidia's drivers have advanced in leaps and bounds as Nvidia push more resources into developing their Linux driver stack. I stated that OSS devs need to open the lines of communication to manufacturers regarding proprietary code, because realistically speaking proprietary code isn't going anywhere, and I stated that doing so is the best way forward regarding Linux moving into the future - I never complained about Valve optimizing descriptor models to suit one particular manufacturers GPU, I stated that an API should be as optimized as possible regarding all makes of GPU if it is to be an effective model.

That is a choice NV made, not Valve the Khronos group.

Once again, I never stated otherwise. Regarding OGL, graphics heaps and descriptor tables were pretty much the standard, then Vulkan came along and changed was was basically the accepted standard. As stated in my previous post, no one's right, no one's wrong - Assumptions were made, and the adoption of Vulkan as an API moved the goalposts in a way that worked in favor of AMD hardware - But a general API that's optimized in favor of one particular GPU isn't a very effective API. Nvidia along with the Khronos Group and OSS devs are working to improve Vulkan as an API so it works better with hardware not designed around SGPR's. This is a good thing and benefits everyone.

No they are not shit. They still exist. They are solid and have always been solid.

They're solidly shite. Generally speaking, when it comes to professional application, AMD and ROCm don't hold a candle to Nvidia, Cuda and Nvidia drivers. You can't honestly argue with a straight face this isn't the case. Furthermore, should you want to game on your workstation in your downtime (and workstation's can be very effective gaming machines), you need to run multiple drivers as gaming under AMD's proprietary drivers quite simply sucks - Something that's not a problem running Nvidia.

The examples you posted of NV fixing linux game bugs include a fix for a game that has been broken since 2021.... I mean that isn't exactly priority bug fixing.

Further reinforcing my point that Nvidia are pushing more resources to Linux driver development, which includes gaming. Your attempt to discredit Nvidia by arguing they don't care for Linux gaming is futile and not supported by reality, which leads me into the next point:

What reason does Nvidia really have to push Linux gaming? I mean that seriously. They have NOTHING in the market that it benefits specifically. (you could argue if gamers moved to Linux it would HURT Nvidia marketshare) Valve is clearly on board with AMD (and now Qcom) this is competition.

And yet Nvidia 'are' pushing Linux gaming. They've ported DLSS 1,2,3,3.5 and 4 to Linux, they've ported NV Reflex to Linux, they've ported NVENC to Linux, they've ported smooth motion to Linux supporting both the RTX 40 series and the RTX 50 series, they ported 'effective' ray tracing to Linux along with path based RT and Ray Reconstruction well before AMD and OSS devs - They even provide HDMI 2.1 support under Linux, something AMD simply can't seem to allow for in their budget regarding OSS drivers. The more you reply, the more it becomes obvious that you haven't used Nvidia hardware in a really long time under Linux.

Seriously, you need to give up on the perspective that Nvidia don't care for Linux gamer's, as there's a tonne of evidence to the contrary. As stated, the fact they're now working along with the Khronos Group and OSS devs to implement a descriptor model that's efficient under more than just AMD desktop hardware further reinforces that point.


PPAs are imo a PITA but they work.

I've been using that Launchpad Nvidia PPA since it was released and I've never encountered a single problem, and I'm running a distro that is stated as not supporting anything but Nouveau. I started using the PPA back when I was running Mint, that would have been in about 2014 - Based on time alone, I'm pretty sure I'm not just lucky.

In fact, in general, provided I'm installing software built for my specific Ubuntu release - I've encountered little to no issues regarding PPA's. For the record, as someone that also runs an Arch based distro, the AUR isn't exactly perfect either.

Though other popular gaming distros such as bazzite can often be a shit show.

If we're being honest, Bazzite in general can be a shit show. As I've stated many times in the past, I'm still not sold on immutable distro's supporting a range of hardware. The only reason an immutable distro works so well on the Steam Deck is due to the fact that it only has to support a specific hardware configuration. Furthermore, I honestly like Flatpaks and believe they are the future of software packaging under Linux, but they do come with certain compromises in certain scenario's vs native software installs.

I believe (its my opinion) that we haven't seen a SteamOS ISO yet... 100% because NV is doing their closed open source driver blob thing.

To be perfectly honest, I'm not at all interested in SteamOS as a packaged distro available as an ISO - I can see game developers pushing to lock the kernel down as to support root kit AC, and I don't believe that making Linux more like Windows is a positive future regarding Linux as a whole. Sure, we like to believe Valve is all hipster and won't allow such things to happen; but there was a time when we all thought Google was hipster regarding Android vs iOS, and look how that's turning out.

As for the philosophical merits of proprietary code vs OSS, I'm not really interested. OSS development isn't a perfect solution, the number of times I've had to drop a really useful software application because the developer either lost interest, got into some pissy argument with other OSS devs and took his Lego home, or stuffed things behind an unrealistic paywall is actually surprisingly notable. If the price is realistic (and I don't mean 'modern realistic', which is far from realistic) and the support is ongoing and good - I have no problem running proprietary solutions on my system. Insync is one of those solutions, it's well priced, well supported, and works faultlessly.

Are we gonna do another round? Or are we going to do the mature thing and agree to disagree? Because with respect, the more you reply, the more evident it becomes that you haven't used Nvidia under Linux for a long time.
 
I stated that the evidence points to the reality that AMD simply don't have the resources to handle development of their Linux drivers from start to finish - The same isn't true regarding Nvidia, and in the last few years alone Nvidia's drivers have advanced in leaps and bounds as Nvidia push more resources into developing their Linux driver stack. I stated that OSS devs need to open the lines of communication to manufacturers regarding proprietary code, because realistically speaking proprietary code isn't going anywhere, and I stated that doing so is the best way forward regarding Linux moving into the future - I never complained about Valve optimizing descriptor models to suit one particular manufacturers GPU, I stated that an API should be as optimized as possible regarding all makes of GPU if it is to be an effective model.

We'll have to disagree on that one. Your view is that hardware MFGs should develop 100% of their Linux drivers. AMD choose (as has Intel) to only develop closed source Linux drivers for Professional grade hardware. AMD does still develop Linux drivers. Including the consumer Radeon drivers. Yes they are open source. YES AMD contributes, they control the OSS project. Just because they publish the code and accept suggestions and work from outside sources that doesn't make not AMDs project. :)

On the Vulkan specific driver ok there was some confusion AMD didn't get a project started fast enough and someone else ended up doing for them. AMD has now fully gotten behind AMDVLK though so that is in the past now.

Once again, I never stated otherwise. Regarding OGL, graphics heaps and descriptor tables were pretty much the standard, then Vulkan came along and changed was was basically the accepted standard. As stated in my previous post, no one's right, no one's wrong - Assumptions were made, and the adoption of Vulkan as an API moved the goalposts in a way that worked in favor of AMD hardware - But a general API that's optimized in favor of one particular GPU isn't a very effective API. Nvidia along with the Khronos Group and OSS devs are working to improve Vulkan as an API so it works better with hardware not designed around SGPR's. This is a good thing and benefits everyone.

On this one we disagree. Vulkan didn't come along and rewrite a "Standard" as you put it. Just because Nvidia does it one way and not another that doesn't make it a standard. Qualcom and broadcom both do descriptors the same way AMD does. Also descriptor buffer stuff your talking about was added YEARS after AMD turned mantle over to Khronos. It wasn't something baked into Vulkan. It was just an extension that YES AMD had added to Vulkan a few years back. Valve used the extensions that were present. Just like Valve uses RT extensions added by NV. There is nothing nefarious or anti NV. If anything this should prove to you how bad having closed source drivers for things like gaming can be. Valve sees the Vulkan API... they can also see the actual AMD/INTEL/Qcomm driver code to see how the hardware deals with those extensions. With Nvidia all they can do is use the extensions (which are part of the spec) and assume Nvidias driver knows what to do with them. Nvidia isn't showing their home work. If calling a standard vulkan extension isn't dealt with in an efficent way by the driver that isn't on Valve or Khronos. its on Nvidia, cause they alone have accepted the responsibility of everything hardware side. Perhaps if Valve had seen how the NV driver dealt with those extensions calls. They could possibly have found a end round or at least added a *SKIP IF NVIDIA* line.

They're solidly shite. Generally speaking, when it comes to professional application, AMD and ROCm don't hold a candle to Nvidia, Cuda and Nvidia drivers. You can't honestly argue with a straight face this isn't the case. Furthermore, should you want to game on your workstation in your downtime (and workstation's can be very effective gaming machines), you need to run multiple drivers as gaming under AMD's proprietary drivers quite simply sucks - Something that's not a problem running Nvidia.
Well first off we are I hope arguing about gaming. ROCM and CUDA don't apply to that. Also ROCm and CUDA are for compute not general workstation use. General workstation use AMD has always had solid Linux drivers. Compute yes Nvidia has spent a lot of money to make CUDA the standard. No one is denying that. But If I'm not mistaken we are really arguing about gaming. NEITHER companies professional Linux drivers are really Gaming first. For gaming AMD has imo very correctly split off their consumer drivers from their professional line of drivers. The pro drivers are for people running instinct cards and ROCm yes. YES those drivers are solid. You can claim CUDA+NV hardware is better and I won't even argue. Overall that is true. Not in every use case though... and its not like ROCm is crashing or being unreliable in anyway, your talking about performance now. Plenty of companies using Instinct and AMDs drivers for them with zero complaints. None of that stuff applies to you and me or anyone buying a deck cube or installing Linux on their gaming PC with a NV GPU.

Further reinforcing my point that Nvidia are pushing more resources to Linux driver development, which includes gaming. Your attempt to discredit Nvidia by arguing they don't care for Linux gaming is futile and not supported by reality, which leads me into the next point:
Again we simply disagree NV isn't spending much of anything on Linux gaming. They are researching things sure, they are contributing to projects like Vulkan obviously... it was the point of this thread. lol Are they really really supporting Linux gaming? Not imo. No. They have setup a opensource loader for the same driver blob they use in windows. IMO (and it is my opinion) that is a inferior way to go. I think the proof is in the sales at this point Linux gaming makes very little money. Valve sells decks, a few small fry companies do ship Linux desktops. As far as I know there is almost zero hardware with NV GPUs shipping from any OEMs with Linux pre installed. Valve has shipped millions of decks and they will probably ship millions of Cube (if they don't screw the pricing up bad). AMD use among Linux users is > then NV Linux market share. NV IMO doesn't seem to be all that serious about changing that. Valve is going to start shipping ARM based hardware as well... and they didn't choose NV hardware. I think its a very safe assumption to make, that IF Nvidia a year or two ago had decided to open source their consumer hardware (OR at least officially support the current existing open source project) the odds that Valve shipped a Frame powered by NV would have been probably pretty high. Instead they are going to make Qcomm work. I know its early days for ARM gaming, I do think NV may come to regret letting Valve team up with Qcomm. The last month has been a flood of Qomm open source announcements. Valve is clearly hard at work "optimizing" for Qcomm hardware. [though to be fair... NV may be smart to let Qcomm be the first, if things don't work out its not a NV fail and their mind share is strong enough that if they did jump with a product of their own or even a Frame2 NV edition its probably no big deal]

And yet Nvidia 'are' pushing Linux gaming. They've ported DLSS 1,2,3,3.5 and 4 to Linux, they've ported NV Reflex to Linux, they've ported NVENC to Linux, they've ported smooth motion to Linux supporting both the RTX 40 series and the RTX 50 series, they ported 'effective' ray tracing to Linux along with path based RT and Ray Reconstruction well before AMD and OSS devs - They even provide HDMI 2.1 support under Linux, something AMD simply can't seem to allow for in their budget regarding OSS drivers. The more you reply, the more it becomes obvious that you haven't used Nvidia hardware in a really long time under Linux.

Seriously, you need to give up on the perspective that Nvidia don't care for Linux gamer's, as there's a tonne of evidence to the contrary. As stated, the fact they're now working along with the Khronos Group and OSS devs to implement a descriptor model that's efficient under more than just AMD desktop hardware further reinforces that point.
They didn't port anything. The unified driver blob supports those things. You make a good point though. That is another advantage of using a unified driver blob. Yes if WIndows has support for it so does Linux. I mean its the same driver. I do get Nvidias reasons for keeping their driver a closed source blob. I still don't agree its the best solution but I get why they do. HDMI isn't about $... its about HDMI demanding closed source for DMA purposes. Honestly F HDMI. ;)

I've been using that Launchpad Nvidia PPA since it was released and I've never encountered a single problem, and I'm running a distro that is stated as not supporting anything but Nouveau. I started using the PPA back when I was running Mint, that would have been in about 2014 - Based on time alone, I'm pretty sure I'm not just lucky.

In fact, in general, provided I'm installing software built for my specific Ubuntu release - I've encountered little to no issues regarding PPA's. For the record, as someone that also runs an Arch based distro, the AUR isn't exactly perfect either.
I have owned NV GPUs. I have never said anyone on [H] can't make it work. No Maz your not going to have any issues installing and using NV drivers even if you have to hand install them and bolt them on yourself. I think you have to admit though if you hunt through non [H] support forums and such you can see how many people do 100% have issues. Go to the Mint forums and see how far you have to scroll back to find someone asking how to fix something they pouched with a PPA. It won't be far.
I also stipulate that since Nvidia has adopted the open source Driver blob loader system, most distros have implemented it properly and NV drivers are a lot less hassle then they used to be. Come on now we can both agree on that. AMD and Intel still just work as they are supposed to work for consumers with any distros base kernel install. Its not really a question. Yes a handful of 1000s of possible Linux distros have included tools and install time hardware scanning to properly install the closed source NV blob.

If we're being honest, Bazzite in general can be a shit show. As I've stated many times in the past, I'm still not sold on immutable distro's supporting a range of hardware. The only reason an immutable distro works so well on the Steam Deck is due to the fact that it only has to support a specific hardware configuration. Furthermore, I honestly like Flatpaks and believe they are the future of software packaging under Linux, but they do come with certain compromises in certain scenario's vs native software installs.
To be honest I have never installed it myself. It sounds like a shit show honest. Think we are agreed on that distro. Keep hearing about it all the time. Like you say I guess it ticks the boxes for the timid switchers. Immutable ya ya can't F up that's good. :) Also can be limiting if their hardware detection doesn't work or whatever other issues they seem to randomly have with some peoples installs.

To be perfectly honest, I'm not at all interested in SteamOS as a packaged distro available as an ISO - I can see game developers pushing to lock the kernel down as to support root kit AC, and I don't believe that making Linux more like Windows is a positive future regarding Linux as a whole. Sure, we like to believe Valve is all hipster and won't allow such things to happen; but there was a time when we all thought Google was hipster regarding Android vs iOS, and look how that's turning out.
I think we are fairly agreed on that one. I too worry Valve might decide to go along with kernel level anti cheat concessions or some other BS. I also have no use for a immutable gaming distro. (though If I end up buying a cube I doubt I would bother changing the OS) IMO Valve has a long history now of 100% siding with the open source option every time. They have tired to solve anti cheat issues but so far have never caved. Legit concern though. Really my hot take on it is I'm ok with them never doing a proper ISO for anyone. Publish rebuilt images for deck cube frame and other OEMs shipping SteamOS, leave the after market Linux to the community. My fear is if Steam does a ISO and say a million people in the first year install it and 3/4 of them are on NV hardware and have a less then great experience or really anything bad happens. Its a big black eye. I'm old enough to remember Corel Linux. lol https://en.wikipedia.org/wiki/Corel_Linux I remember being a lot younger and being stocked that a major respected softtware company was going to properly take on MS. OK its 26 years later... but the expectations of SteamOS may not match the reality for people installing it on their 5090 super rigs, and bad word of mouth for Bazitte or Nobara or Cachy sets Linux gaming back a lot less then if everyone is bad mouthing the SAVIOR Valve and SteamOS.

As for the philosophical merits of proprietary code vs OSS, I'm not really interested. OSS development isn't a perfect solution, the number of times I've had to drop a really useful software application because the developer either lost interest, got into some pissy argument with other OSS devs and took his Lego home, or stuffed things behind an unrealistic paywall is actually surprisingly notable. If the price is realistic (and I don't mean 'modern realistic', which is far from realistic) and the support is ongoing and good - I have no problem running proprietary solutions on my system. Insync is one of those solutions, it's well priced, well supported, and works faultlessly.

Are we gonna do another round? Or are we going to do the mature thing and agree to disagree? Because with respect, the more you reply, the more evident it becomes that you haven't used Nvidia under Linux for a long time.
I won't argue that OSS is the only and always best solution to software development. Hey Gimp is still not photoshop. The same types of issues do happen with commercial software though... or worse your happily using a paid commercial software and then the company gets sold off, or the company sells the software to a big. How many smaller photo editing companies have been bought up by Adobe as an example.

When it comes to the plumbing though. The kernel, the drivers .... basically EVERYTHING hardware. I am 100% sold. OSS is the only way forward. Frankly even on the big iron commercial side. We all know the BIG players get special access to closed source code. I mean even NV makes cut outs when companies spend money. I picture Jensen with a Tony Stark like case of booze. Free driver code access with every 10 Billion spent. lol

Anyway I am not anti closed source software at all. Closed source software is needed, software development is expensive it doesn't work without financial gain. When it comes to things that control HARDWARE. In that regard I am 100% against hardware companies deciding to call themselves software companies and selling the two hand in glove. F that BS. In that regard NV is pure evil. ;)

PS Quite the back and forth books we have going. We crazy buddy. ;)
 
We'll have to disagree on that one. Your view is that hardware MFGs should develop 100% of their Linux drivers. AMD choose (as has Intel) to only develop closed source Linux drivers for Professional grade hardware.

And in the professional space they're insignificant compared to Nvidia. Furthermore, as stated, should you want a workstation that you can game on - You have to run multiple drivers, something that's simply not a problem regarding Nvidia. Furthermore, I never stated MFG's should develop 100% of their drivers, if that's what you believe then you missed my point entirely.

They didn't port anything. The unified driver blob supports those things.

If that was the case, DLSS support, Nvidia Reflex support, DLSS FG support, and Smooth Motion support would have appeared under Linux at the exact same time it did under Windows, which was most definitely not the case. It's only in the last few years as a result of Nvidia pushing more resources towards Linux driver development that such features have been ported to Linux in a more timely manner compared to Windows.

Linux is not Windows, desktop compositing is nothing like Windows. Yes, Nvidia do their best to unify their driver base, but make no mistake - I see no evidence such features are not ported to Linux.

its about HDMI demanding closed source for DMA purposes

It's a licensing issue, and licensing isn't free. Any time you see that HDMI logo on a device, the DTS logo on a device, or the Dolby logo on a device - You are very much paying for that logo and the support of the associated standard. Under AMD, you're paying for that standard, but AMD simply don't want to extend the licensing to OSS drivers.

The same types of issues do happen with commercial software though... or worse your happily using a paid commercial software and then the company gets sold off, or the company sells the software to a big.

It can happen, but it's not common. The problem with OSS devs is the fact they're almost all 'pissy', every dev thinks they know more or are somehow more important than the next, while many unpaid devs simply develop a small blob of code that specifically essentially suits their own use case - Sure, the code gets merged as it may have other uses, but there are unpaid devs that code to suit their specific use case and openly admit to doing so - and the use case of one developer doesn't necessarily suit the use case of your average Linux user as a collective.

Point in case: Vulkan and SGPR's. As stated by yourself, optimizing Vulkan to suit one manufacturer's hardware suited Valve ideally - but considering Linux as a whole, it made Vulkan as an API less than ideal running anything but that specific manufacturer's hardware, and an API that only runs efficiently on the hardware of one manufacturer isn't an effective API.

Hey Gimp is still not photoshop.

Personally, GIMP actually suits my use case perfectly, there's no way I'd every pay for an Adobe product (in the same sense, there's no way I'd ever pay for GIMP). Once again: I'm pressing the fact that no manufacturer is noble; but if a software package is well priced, well supported, and works perfectly - I have no problem paying a fee for that software.

However, going back to GIMP as an example, I find very little OSS software is actually worth paying for.

When it comes to the plumbing though. The kernel, the drivers .... basically EVERYTHING hardware. I am 100% sold. OSS is the only way forward.

And you're entitled to that opinion. However, as I've stated in the past, if 100% OSS is the only way for Linux to progress, than Linux has already failed - and a big part of that is a lack of effective communication on behalf of proprietary and OSS devs.

In that regard NV is pure evil.

Big tech is pure evil - Period. AMD is certainly no exception, their lack of resources simply worked in their favor by fobbing the bulk of their Linux development onto Valve and OSS developers. Honestly, the reality is that both Nvidia and AMD essentially trade blows under Linux in terms of performance and features. When it comes to RDNA4, the gains under Linux really aren't as great as the gains under RDNA2 & 3 due to the fact that RDNA4 still sees active Windows development.

When it comes to VKD3D performance under Linux: Sometimes AMD's faster, in some cases Nvidia is faster, in many cases it all depends on resolution. In situations where Nvidia see's a 30% performance variance compared to Windows, AMD also see's a 20% performance variance compared to Windows, and that's not even taking into consideration the obvious advantage Nvidia often holds over AMD under Windows. Overall, as a combined average, Nvidia is only ~11% behind AMD in terms of VKD3D performance ignoring the advantage Nvidia sees over AMD running a number of titles under Windows.

But I stand firm by the belief that switching to Linux for increased performance when gaming is somewhat of a misnomer. People should not be switching to Linux under the assumption they'll see increased performance, people should be switching to Linux for the privacy and sense of ownership Linux provides - It's that simple. I don't care about Windows performance, as I don't care for Windows - As long as my performance is adequate and the feature set is essentially on par with other operating systems under the OS of my choosing, I'm happy.

And I'm very happy.
 
Last edited:
And in the professional space they're insignificant compared to Nvidia. Furthermore, as stated, should you want a workstation that you can game on - You have to run multiple drivers, something that's simply not a problem regarding Nvidia. Furthermore, I never stated MFG's should develop 100% of their drivers, if that's what you believe then you missed my point entirely.

Not being able to game on a workstation is a feature. :)
 
Back
Top