NVIDIA Publishes Signed Ampere Firmware To Finally Allow Accelerated Open-Source Support

[mdedetrich]

Well, it isn't elephant. It is design choice. Choice that makes things simpler and easier to maintain. There are good reasons to do this like this. And there is easy solution for this issue - get driver into main kernel tree. It solves all issues.
https://github.com/torvalds/linux/bl...i-nonsense.rst

I understand the reasons behind the design choice, but it is also outdated (a relic from the 90's) and also has severe shortcomings which is what I stated. I mean this is just fact, if you have distributions (which is what Linux has), a monolithic kernel and the fact that new graphics cards get released biannually and often have new features every few years the model that "Linux" uses just doesn't work.

And no, Windows doesn't have stable interface for graphics drivers. Microsoft updates WDDM from time to time and some of those changes can break things. Most people don't care since they use recent drivers and it works without bigger issues, but try to install very old drivers on up to date system or new drivers on old system and see what happens.

WDDM was created during windows Vista and ever since then there hasn't been any breaking API change, and Vista came out like 15 years ago (which is an eternity compared to Linux). Of course there have been changes to WDDM, but they are forwards compatible changes, not backwards breaking changes. Microsoft is very serious when it comes to backwards compatibility.

If you don't believe me you can research it yourself https://en.wikipedia.org/wiki/Window...y_Driver_Model. WDDM is properly versioned which means that as long as you don't remove an implementation for WDDM 1.0 in your driver (for example) it will continue to work. And some quick googling will show you that Windows 11 is compatible all the way back to WDDM 1.0 (i.e. https://nerdschalk.com/windows-11-sy...un-windows-11/)

[tuxd3v]

As a owner of Pascal hardware...
Its possible to have accelerated desktop with nouveau?

because the Idea I have, is that its not possible..
also power management is not possible..

[sinepgib]

You're implying kernel hackers, in case NVIDIA open sources its drivers, will do maintenance. This is a 100% false statement. Both AMD and Intel have their own employees do that. Outsiders barely touch their graphics drivers kernel code. Valve has helped here and there but that's not because Valve is a good company, they have their own interests. Open Sourcing drivers will cost NVIDIA a whole lot more than having their own closed source drivers. Yes, RedHat has nouveau hackers but we are talking at most about three? Five people? This is far from enough to maintain the huge amount of code.

Linux kernel 5.17, drivers/gpu/drm/amd - over 265 megabytes of code. And that's their new driver only.

But Developer12 is right to a degree. The broken interfaces would actually be fixed by the kernel hackers. It's part of the work to grep for uses and update. Yes, the actual improvements in drivers are for the driver maintainers (which would be nvidia employees) to make, as well as bug fixing, but the build won't break because someone else changed the interfaces as it happens with out-of-tree drivers.

[Developer12]

You're implying kernel hackers, in case NVIDIA open sources its drivers, will do maintenance. This is a 100% false statement. Both AMD and Intel have their own employees do that. Outsiders barely touch their graphics drivers kernel code. Valve has helped here and there but that's not because Valve is a good company, they have their own interests. Open Sourcing drivers will cost NVIDIA a whole lot more than having their own closed source drivers. Yes, RedHat has nouveau hackers but we are talking at most about three? Five people? This is far from enough to maintain the huge amount of code.

Linux kernel 5.17, drivers/gpu/drm/amd - over 265 megabytes of code. And that's their new driver only.

In no universe will anyone 100% take over driver maintenance for NVIDIA if they publish an open driver. They're expected to mostly maintain their stuff, despite occasional fixes and improvements posted by others.

HOWEVER, they won't be constantly seeing a river of breakage due to changes in the kernel ABI, which is a significant drain on maintenance resources. It's this constant breakage that is the main way the upstream kernel devs try to coerce projects into getting in-tree.

[birdie]

God, am I talking to deaf people?

Have you actually followed kernel development for any period of time? Unmaintained drivers get removed all the time, even features the entire Phoronix community cried about got removed: the console scrollback buffer. Has anyone stepped up to fix the feature to get it back? Not a single person!! It's been what, two years without it? So much pain and suffering and it's not particularly complex.

Again, you're heavily implying some good Samaritans will keep NVIDIA Linux modules up to date with kernel APIs. Who will do that? Why? Will they have enough skills and expertise? GPU drivers are hellishly complex. Who will do the testing? How do you know a new kernel API update doesn't change modules in slight ways which causes an unintended behaviour/crashes/etc? I'm telling you AMD and Intel do all the work for that, you're trying to convince me with NVIDIA it will be different. We already have two precedents when it's not the case. Don't BS me, don't BS yourself, don't BS everyone else here.

Open Sourcing drivers will cost NVIDIA dearly with very dubious benefits other than being suddenly praised by ~1% gamers who go through circles of Hell to play their ... Windows games on Linux.

[Developer12]

God, am I talking to deaf people?

Have you actually followed kernel development for any period of time? Unmaintained drivers get removed all the time, even features the entire Phoronix community cried about got removed: the console scrollback buffer. Has anyone stepped up to fix the feature to get it back? Not a single person!! It's been what, two years without it? So much pain and suffering and it's not particularly complex.

Again, you're heavily implying some good Samaritans will keep NVIDIA Linux modules up to date with kernel APIs. Who will do that? Why? Will they have enough skills and expertise? GPU drivers are hellishly complex. Who will do testing? How do you know a new kernel API update doesn't change modules in slight ways which causes an unintended behaviour/crashes/etc? I'm telling you AMD and Intel do all the work for that, you're trying to convince me with NVIDIA it will be different. We already have two precedents when it's not the case. Don't BS me, don't BS yourself, don't BS everyone else here.

Open Sourcing drivers will cost NVIDIA dearly with very dubious benefits other than being suddenly praised by ~1% gamers who go through circles of Hell to play their ... Windows games on Linux.

What the fuck are you even talking about? Either:

A) Nvidia continues to publish closed-source binary drivers out of tree, and is forced to keep up with kernel ABI changes

or

B) Nvidia upstreams an open source driver into the kernel+mesa, in which case ABI changes are a non-issue.

Yes, any company that upstreams a driver has to maintain it, but if nvidia can play catch up with the kernel ABI I'm sure they can do the much easier task of fixing the occasional in-tree bug instead.

You seem to be arguing some bizzaro case where they open source their driver but don't bother to upstream it.

[birdie]

What the fuck are you even talking about? Either:

A) Nvidia continues to publish closed-source binary drivers out of tree, and is forced to keep up with kernel ABI changes

or

B) Nvidia upstreams an open source driver into the kernel+mesa, in which case ABI changes are a non-issue.

Yes, any company that upstreams a driver has to maintain it, but if nvidia can play catch up with the kernel ABI I'm sure they can do the much easier task of fixing the occasional in-tree bug instead.

You seem to be arguing some bizzaro case where they open source their driver but don't bother to upstream it.

"I want NVIDIA to spend more money by having two separate drivers with no obvious benefits either for itself or its users and nothing will convince me otherwise".

OK, I get you PoV. Peace out.

[sinepgib]

God, am I talking to deaf people?

No. We're talking about a specific subset of driver maintenance and you're talking about the whole, it seems :shrug:

Have you actually followed kernel development for any period of time? Unmaintained drivers get removed all the time

Yes, but they don't get removed for the occasional API/ABI break.

even features the entire Phoronix community cried about got removed: the console scrollback buffer. Has anyone stepped up to fix the feature to get it back? Not a single person!! It's been what, two years without it? So much pain and suffering and it's not particularly complex.

This, for example, had absolutely 0% to do with broken interfaces and 100% with outstanding bugs that never got fixed. Nobody is arguing that bug fixing and optimization and upbringing of new hardware will obviously be up to nvidia to do. But interface changes (except from major ones that tend to be versioned, such as the creation of DRI3) get updated as part of the changeset, simply because no patch that leads to a kernel build break will get accepted.
Now, if they drop the code and disappear, of course, eventually there will be some DRI8 and DRM maintainers will want to drop the decades old versions and the driver will get dropped. But nobody is saying otherwise.

Again, you're heavily implying some good Samaritans will keep NVIDIA Linux modules up to date with kernel APIs.

The person who sends the patches to change interfaces is mandated to update in-tree code that would otherwise break to get the patches accepted. That's just part of the process.

Who will do that? Why? Will they have enough skills and expertise? GPU drivers are hellishly complex.

You don't need to know a lot of nvidia's drivers specifics for this particular issue. If you change a memory allocator API, you need to know how that memory allocator works and fix its usages, nothing more.

Who will do testing?

Test farms and users of release candidates most likely, but in the end nvidia will need its own infrastructure for this part. Something they already need for their proprietary driver, but now running many times fewer combinations because there's only one version of the driver that run on a given kernel. Now, because it's decoupled, proper testing for all supported variants should end up in a vector product.
API and ABI breaks most likely break builds only, and the one sending the patches will need to make simply a smoke test.

How do you know a new kernel API update doesn't change modules in slight ways which causes an unintended behaviour/crashes/etc?

That's fair.

Open Sourcing drivers will cost NVIDIA dearly with very dubious benefits other than being suddenly praised by ~1% gamers who go through circles of Hell to play their ... Windows games on Linux.

We agree here. There's a lot of hidden costs, and if they can't open source the exact code they use now they'd be maintaining two drivers, one for Linux and one for everyone else, which is commercially unfeasible. But the API breakages would get solved, which is the only point :shrug:

EDIT: and that would effectively mean they open source the driver for everyone, and even in that "best case scenario" they might have issues with release engineering between the userspace parts and the kernel parts, as userspace would be shared with other OSes, etc. It's really not as simple as some paint it.

Regarding good Samaritans making significant fixes (rather than keeping stuff just building but untested), I've lost all faith in the current community.
Once upon a time people did fix their drivers and software when things failed. Now we just cry and scream because nobody is doing that for us.
The quality might have been poor due to lack of funding tho.

[Developer12]

"I want NVIDIA to spend more money by having two separate drivers with no obvious benefits either for itself or its users and nothing will convince me otherwise".

OK, I get you PoV. Peace out.

Two? Which two are you counting? Because if you think they can REALLY share code between their proprietary windows and linux drivers, I've got news for you:

Mesa is MIT licenced. They can run their linux graphics drivers on windows however they please, only having to develop an equivalent kernel shim for windows's NT kernel. (with it's famously stable ABI) They could share code between both drivers WITHOUT having to constantly chase the linux ABI as an out of tree driver.

Really, do you know anything about this at all?

[sinepgib]

Two? Which two are you counting? Because if you think they can REALLY share code between their proprietary windows and linux drivers, I've got news for you:

Mesa is MIT licenced. They can run their linux graphics drivers on windows however they please, only having to develop an equivalent kernel shim for windows's NT kernel. (with it's famously stable ABI) They could share code between both drivers WITHOUT having to constantly chase the linux ABI as an out of tree driver.

Really, do you know anything about this at all?

OK. Let's say they no longer need to maintain two drivers in that scenario. They would still need to write a new one from scratch and make it match the performance and features of the current one, with all the investment that implies.
There's also another interesting fact, which is they'd be losing some independence to call the shots. Releases would basically be stuck with whatever Mesa decides as a group, design would require discussion with multiple actors, the needs of many would have to be taken into account, etc. With their proprietary driver they make all the decisions, that's valuable for a business.
It's certainly not obvious that they'd win more than they'd lose by doing that.