A Nouveau graphics driver update | Hacker News Reader

A Nouveau graphics driver update

lwn.net

127 pointschmaynard129 comments

There are a number of disadvantages too, though. The firmware provides no stable ABI, and a lot of the calls it provides are not documented. The firmware files themselves are large, in the range of 20-30MB, and two of them are required for any given device. That significantly bloats a system's /boot directory and initramfs image (which must provide every version of the firmware that the kernel might need), and forces the Nouveau developers to be strict and careful about picking up firmware updates.

Is 20-30Mb of /boot space really a concern for someone running an nvidia graphics card?

“Every version” probably means 20-30 MB for each GPU series that can potentially appear in the PCI-e slot after power on (if still supported by the driver). Or the user has to juggle the firmware before hardware change (or the driver has to implement the juggling instead).

I don't get why this has to be in the initrd. Just run in legacy text mode until the root partition has been mounted and then load the firmware from there.

They worked hard to make boot nicer, at least for Intel GPUs: https://fedoraproject.org/wiki/Changes/FlickerFreeBoot

Also, the earlier I get the GPU up, the better. My monitor won't display some resolutions used in BIOS screens and text modes.

You can do better than text too before the driver load, even Grub uses high res and has a background image these days.

My /boot partition is 256MB because that was the default in the Ubuntu installer way back when I installed it. I can't easily resize it because my primary partition starts right after it. I am constantly running out of space in /boot because Apt doesn't fully clean up after old kernel versions automatically. An extra 20-30MB (per kernel version, at least) is absolutely a huge deal.

I am in the same boat as you. I still haven’t found a solution for keeping it clean in an automated and safe way.

However, you could consider shrinking your main partition using gparted live. Then put a new /boot at the end. Of course, you'd lose the original /boot partition space, however.

I don't know if any tools support moving partitions, but you can use "dd" to move a partition backwards if you are very careful. I'm not recommending this on any system that you don't have good backups for, but it is possible.

gparted supports this and it's relatively easy to do after shrinking the original partition

Why not just use gparted to move the partition instead? Just three steps

1. Shrink the main partition 2. Move the main partition to the right, leaving free space between it and /boot 3. Resize /boot to fit into the newly freed space

That's what I did at one point to make my /boot 2gb or so, haven't had issues since.

Does moving the main partition like that have potential weirdness with some filesystems, or does this gparted approach rewrite the entire partition to a new (offset) location?

I've never ran into anything weird, since it moves the whole partition's address rather than the filesystem within the partition or anything like that.

Yes, that works, but I didn't suggest it because it's riskier and takes way longer.

The whole filesystem has to be moved, instead of just the excess data.

Although this is usually successful, my advice would be: don't have a power outage if you're moving the whole filesystem.

NixOS

I run out of space on /boot semi-regularly on one of my nixos machines; if anything, I would argue that it's worse at handling the situation if you don't regularly delete old generations

It does that on its own, set a reasonable limit on generations and enable auto gc.

I moved my /boot to a USB thumb drive when I ended up in a similar situation.

Perhaps Ubuntu and its derivatives but mine (now Mint) has been removing the fourth kernel for probably five years.

May need to run autoremove (haha) however.

I swear Debian only keeps two versions ie current and the previous. Is keeping four a Ubuntu thing?

Keeps three and when the fourth arrives the oldest gets the heave-ho. Probably configurable.

You can resize your primary partition, move it to a larger offset, then resize /boot. You can also move /boot to the end of your disk. gparted supports this stuff pretty well.

There's no way. You cannot just relocate a Linux partition while it's running like you can macOS, unless gparted somehow supports moving a live system into a tmpfs while the operation is performed.

Windows software that does this has to completely reboot into a dedicated executable that does the work before the system is actually started.

Not while it's running obviously... you boot into gparted live and do it.

And btw, yes you can move partitions while linux is running.

> you boot into gparted live and do it.

This is not the same as simply running gparted from the partition to be resized.

> And btw, yes you can move partitions while linux is running.

Not your root partition, unless you can manage to unmount it without having a fatal system crash.

> This is not the same as simply running gparted from the partition to be resized.

Nobody said you have to run it from that filesystem/partition?

> Not your root partition, unless you can manage to unmount it without having a fatal system crash.

You can resize your root partition using fdisk/partprobe without unmounting it, then move /boot to be after root.

I'm sure there are many other ways to do it as well (pivot_root, etc).

You just need to run off a live distro to do it.

That's my point. You can't just download and run gparted to resize your root partition, you need to boot from somewhere else in order to do that.

You can also set up gparted live to be bootable from GRUB from the same drive.

That's true, it's not uncommon for me to install Linux by flashing the installer to a small partition on the same disk as the actual install destination. Quite useful for dual/triple-boot without actually requiring any USB flash drives.

Is it really that hard to boot from external media on the odd occasion of doing stuff like this?

No, no it's not.

Ubuntu is configured that way. Most other apt-based systems are configured correctly.

You can still create and use an XBOOTLDR partition.

These tiny boot partitions are such a self-inflicted wound in linux distributions. I do agree there's a lot of people in the same boat, but maybe the solution is to offer some sort of migration out of that state.

What would that migration look like? The traditional route, which is being discussed in this thread, involves moving your entire root partition around so you have enough room to grow the boot partition. But that's not exactly a process I would want to run on any system without current backups, to put it lightly. The other thought that occurred while I was reading here was that you could create a new boot partition at the end of the disk, which might work if you synchronize everything perfectly and can shrink the rest of the partitions to give you enough room, but we're still talking about fairly delicate tinkering with the boot process and I'm just not seeing a way to do that that's not dangerous at any significant scale.

>What would that migration look like?

  cp -r /boot /boot2
  umount /boot
  mv /boot2 /boot

I'm pretty sure unless you just forgot to write the part where you fuss with the partition flags and possibly EFI variables, you just rendered the machine unbootable.

Also, where did boot2 come from? Because a lot of these machines don't have free space sitting around, and some of them are still using MBR partitions and don't even have the ability to create a new partition. (You might well object that nobody even makes machines with bios boot anymore and surely everybody must be using GPT, at which point I get to gesture at the astonishing number of cloud virtual machines that are somehow not even capable of UEFI booting)

Edit: s/on bootable/unbootable/

>you just rendered the machine unbootable.

Only because Linux bootloaders suck as they completely fall over when misconfigured. It was implied that you update the configuration of the bootloader to be able to find the new partition that holds /boot. You would also want to format the former boot partition so that you can reuse for other stuff.

>Also, where did boot2 come from?

The cp command creates it

I don't think we're understanding each other. A cp command can populate a filesystem, but it won't create a new partition (or filesystem), which is what I was asking about. You can't just handwave away "make a new boot partition", because part of the problem is that systems in the wild are unlikely to have free disk space sitting around for you to create a new partition in.

> Only because Linux bootloaders suck as they completely fall over when misconfigured.

Have you got a bootloader that doesn't do awful things when it has no configuration? I mean, I guess you could write a bootloader that searched through available filesystems and tried to find something it could boot, but that seems like a great way for unexpected surprises on boot (what, you didn't want to default to booting this 6-month-old backup kernel?)

(And it's not just the bootloader config that you have to deal with - like I said, you have to do something to tell the firmware to even run that bootloader)

>I don't think we're understanding each other.

Then let me explain with English:

Move all of your files from the boot partition into the main partition. Then setup the system to boot from the main partition. Since there is likely gigabytes to terabytes free you will not need to worry about a few 30 MiB files being added to the /boot directory.

That restricts you to using root filesystem that the bootloader can read, which excludes many modern filesystems, btra, f2fs, etc.. Also you would then need a separate efi partition instead of a combined boot and efi setup as is typical these days.

So use a bootloader that can read them then.

You still have an extra partition, and there just plain aren't any bootloaders that can load those filesystems. You'd pretty much be stuck with ext4 as your most modern filesystem option. Really the kernel should have a better system for loading firmware from the root drive after the bool state that the root drive becomes accessible. Not for everything of course, but many of the biggest firmware blobs are fine as late loaders

>You still have an extra partition

Which can be reused to store other files.

>You'd pretty much be stuck with ext4 as your most modern filesystem option.

What do you mean? You can grub boot from a partition that even uses LUKS and ZFS.

Bootloaders support all the common root filesystems now, and even less common like zfs & btrfs. Just leave the bootloader where it is and use a directory in root for the kernel & initramfs.

Most of my systems avoid a boot partition, boot process is BIOS/UEFI -> grub (from EFI partition or MBR block) -> linux (from /boot in root).

However I do got one where UEFI boots the linux kernel directly, /boot is the EFI parition. And there it feels like a bit of a waste to have to expand /boot or insert a bootloader into the boot process because initramfs is getting bloated with files that aren't critical to mounting root.

It does sound sort of elegant to me too, but then I remember that the EFI partition is FAT32 and the desire to use it fades.

i just set mine to 1gb on creation and have never had space issues besides one time when i had to have an obscene number of different kernels bc reasons. not sure why distros default to spending less than 0.1% of disk space on a boot part.

Well, I look forward to benefiting from this nice work when the next Debian Stable release comes around.

I still don’t understand why it’s so damn hard to use a NVIDIA GPU on Linux vs Windows. The NVIDIA drivers are closed source for both. Once deep learning took off, I expected things to change, but the other day I tried to install drivers for a new card and my Bluetooth and WiFi stopped working.

The main difference is probably that Linux has a dozen+ desktops and (even ideally) multiple desktop implementations to support. Windows has just one, and they update it continuously (not to say it works perfectly either).

In the end, Windows has more users that report bugs on fewer setups. That makes fixing things much easier than Linux.

I... Don't think either of those is true? Driver support is once for all of Xorg and once for all of Wayland AFAIK; it's not like you have a different driver for each desktop environment. And I was rather given to believe that Linux users were far disproportionately likely to report bugs compared to Windows users, though I suppose there are so many more Windows users that they might still manage a higher absolute number of bug reports.

The driver API in the windows kernel changes about once a decade. And they're not actively hostile to loading closed source drivers.

Poor multi-trillion company unable to support open source drivers

Their business plan seems to be working out for them.

Ok?

Companies won't do anything unless it makes them money, there's no other factor like pride or social pressure. A human might be motivated to change by being looked down upon, but not a corporation.

Who are you trying to argue?

Poor us. The multi-billion dollar company is doing just fine.

Maybe they should contribute their drivers to the kernel instead of fighting it at every turn.

There's always AMD

https://news.ycombinator.com/item?id=38418278

They are, they released an open driver and it’s being upstreamed into the kernel.

https://github.com/NVIDIA/open-gpu-kernel-modules

People still search for reasons to shit on it because they don’t like the company in general and want to back AMD. Nothing is or ever will be good enough for the haters.

http://www.paulgraham.com/fh.html

It's software development, if you're searching for a reason to be discontented, you're always going to find one, it's clearly an unfalsifiable situation for people who just dislike the company on personal grounds.

that driver is not being upstreamed and never will be as long as it can only work with the proprietary userspace. It's being used as a reference implementation to improve nouveau.

I've got nothing against nvidia at all. I just don't like running proprietary software on my computer. Looks like they're finally improving and I'm definitely happy about that. However, the driver has not been upstreamed yet.

I just wish they'd let the nouveau developers do their thing.

It seems likely that in the course of installing your gpu driver via your package manager you installed additional updates that effected other functionality. It is plainly impossible for your GPU driver to effect your wifi.

Its been painless to install closed source nvidia drivers for 20 years so long as your distro provides a package.

I can think of a dozen ways for a GPU driver to affect Wireless NIC. They're both kernel mode so good ol' fashioned SW bugs is a start. Then you could have bad firmware tables causing one driver to trample on the wrong device. All the way too the GPU interfering directly on the bus.

If this was so you would be able to trivially reproduce in 60 seconds by rebooting with the in kernel driver in place of the NVIDIA driver. Then you can write a blog post exploring the nature of a bug as likely as you finding out you were the secret love child of Elon Musk and the direct descendant of the Lindbergh baby.

Nvidia targets Windows, not Linux. It's as simple as that

They put a lot of work into maintaining a Linux driver, actually.

NVIDIA’s main target on Linux is data center cards (Teslas). Desktop is just happen to be supported for the hobbyist market.

This was not like that before their Tesla series took off with such momentum.Currently, X11 and display support is provided at the barely minimum level which doesn’t piss off the people.

I think some parts of their drivers do some black magic, because if that was not the case, there should not be a tug of war about the technical details for providing Wayland support.

Monitor power management and related display parts of the driver break constantly, but not the CUDA parts, because it’s the money making part.

To be, frankly, more fair than they deserve, with CUDA they don't have to worry about anyone else. It's their API, they just have to maintain it themselves. When supporting X or Wayland they have to play nice and integrate with other people and their APIs.

They put a ton of effort into supporting the Linux desktop market, all considering.

Not sure where you're getting that from. NVIDIA has supported professional desktop Linux usage since before anyone was doing AI on their GPUs. All of their GPUs worked well.

I've been running NVIDIA GPUs on Linux workstations in personal and professional settings for almost 20 years. It's been always been an extremely functional and high performance experience.

It's annoying that the drivers are proprietary, and have to be rebuilt during kernel upgrades, but they have worked very well for a long time.

Same. I have been running on and off Nvidia on Linux for more than 20 years and they have committed to the platform for all this time.

It would of course be better if the drivers where OSS and integrated in the kernel, but for more than a decade Nvidia was the only option for high performance graphics on Linux (Intel always had very good stable OSS drivers but not the hardware to match).

The problem is, not everyone can get the latest and greatest card a couple of years for their desktop system for their workstations.

For AI work, their cards are great, yes. Also for accelerated science. We have quite a few of their cards at the bottom floor, churning out number non-stop.

However, desktop experience with their cards are constantly degrading after Tesla got up to speed. VSync can't be enabled without losing 25% performance hit. DPMS support was broken for 1.5 years on DisplayPort. Then, DisplayPort started to lose link when you turn off your monitor for whatever reason.

These things add-up, and when your card is deprecated you can't move to open drivers even if said drivers have lower performance, it breaks the camel's back.

If you're on the happy path (hardware + software wise), NVIDIA is great, and if you don't, you're too poor for NVIDIA and they can't be bothered.

So no, I'll not be buying NVIDIA card for my desktop use.

Official Nvidia drivers for macOS back when those still existed were second class citizens too. They had a rotating cast of odd bugs you’d never see with the Windows drivers.

Non-Windows desktop users definitely don’t seem to be among Nvidia’s chief concerns.

A factor in this case may be the fact that while desktops remain a very sizeable segment in the PC space in the Mac space an actual traditional desktop is available only as a very high priced workstation which starts at $7000 whereas more traditional users are apt to be served by minis or imacs.

There were probably about 1000x more Linux desktop users than Mac Pro users willing to install their own aftermarket GPU even when this was a thing.

There is another group of macOS users who were buying Nvidia cards: hackintoshers (those who hack macOS to run on generic PCs). For several years, by far the most cost effective, powerful, and flexible “mac” available was one that you built yourself from a selection of known-compatible components. Many in this group were buying Nvidia GPUs for use in these machines since Nvidia was furnishing macOS drivers at that point.

It’s hard to tell how numerous this group was, but I saw them come up surprisingly often in photos and discussions online, even appearing in production environments (despite legal dodginess). Wouldn’t be surprised if at times this is where most Nvidia cards purchased for use with macOS were sold.

> Desktop is just happen to be supported for the hobbyist market.

That Linux hobbyist market is barely relevant. Desktop Linux is supported by Nvidia because it is a big thing in the SFX industry.

> NVIDIA’s main target on Linux is data center cards

Linux has been supported before their were data center cards. Before GPU compute was a thing there was workstations which are in fact still a thing.

> Monitor power management and related display parts of the driver break constantly,

In 20 years of usage this appears to be inaccurate. I'm not even 100% sure what your GPU has to do with monitor power management fails which historically consist wholly and only of distros/desktops setting the sleep threshold way to short and whatever half assed hack is being used to keep their machine from turning the monitor off in the middle of their youtube video fails to work properly. The solution as with a lot of over-complicated things is simplicity. Set the threshold far higher and if you actually want the monitor to shut off do so. In any case it again has little to do with your GPU

> X11 and display support is provided at the barely minimum level which doesn’t piss off the people.

Not sure where this is coming from at all. X11 support has pretty much always been great. The most reasonable thing to suppose is that the Linux desktop ecosystem has been historically somewhat fragile especially if you insist on the latest and greatest and that Nvidia due to open source unfriendliness seems to catch a greater than average share of the blame.

Someone will post a random thread on a entirely unrelated matter without even mentioning nvidia and somewhere down thread someone will be blaming Nvidia.

> Well recently my cat got the mange...

>> Are you running NVIDIA? It's known to cause that.

>>> Oh ya I installed NVIDIA recently and my cat is 100% dead!

>>>> My neighbor installed NVIDIA and my cat is now a dog

Look at this singular thread where NVIDIA is assigned the blame for flaky wifi, bluetooth, and display power management.

I got used to it back in the days. I would download the driver from Nvidia, make the installer executable. Then drop into run level 3 and run the installer from there. Reboot, and it worked. Every time there was a kernel upgrade I believe you needed to reinstall the drivers, as the Nvidia software installed kmod's. Needless to say, I use ATI cards now. I wonder if Nvidia supported Wayland natively, maybe the installations will go much smoother?

I had a laptop with an ATI card, 2006 to 2013. Then some 3.x kernel dropped the driver and I had to choose between buying a new laptop and stop upgrading the kernel. I stopped the upgrade but no more ATI cards for me after that experience.

Nowadays their Linux support is probably better than nvidia; when I bought my nvidia card, the amdgpu drivers were just starting to be a thing, and the radeon drivers were so bad I went nvidia, and it's been a pain ever since. I recently got wayland working, but to give you an idea of performance, I get 86FPS on glxgears when maximized on my 1200p screen.

I'm amazed no one's posted is yet, so I guess I'll have to do the honors.

"Nvidia, fuck you" - https://youtu.be/i2lhwb_OckQ

And there’s the thought-terminating cliche, like every nvidia thread

You install the Nvidia drivers through your distro package manager. That's worked for me for the past 10 years. In recent years, the driver or some component of it recompiles via dkms whenever you install a new kernel. The Nouveau drivers have never worked for me.

That’s never worked for me other than to maybe get the native monitor res working. Refresh rates are always off and any remotely advanced configuration has never worked with distro drivers.

Yeah, I see a lot of people bemoaning the difficulty of installing the nVidia driver on Linux, but in my experience it amounts to clicking a box in the configuration and letting DKMS do its magic. Actually easier than the Windows driver that you have to go to their website and download. Downside is the driver version is usually somewhat behind the Windows version, but that's not been a showstopper for me.

This is exactly how I borked my Bluetooth and WiFi.

It's really not hard anymore. I've used it for years, since I got rid of my abomination of a Vega64.

AMD drivers are built into the kernel and work out of the box, but they're still buggy. In my experience, at least 3 times I couldn't boot after a kernel upgrade due to buggy Vega64 drivers.

It's much simpler on Linux. You just do `# apt install nvidia-driver`, and reboot. That's all.

This also won't install all the horrible security nightmares that come with the Windows drivers, as that stuff doesn't exist on Linux.

So overall a much better experience than on Windows.

What exactly is the issue with proprietary drivers? They ship the hardware, they ship the driver(s). That's their problem. They probably want people to be able to use their cards. Why fight this battle?

If Nvidia wants to lose Linux users by not shipping drivers, let them fall, but I don't see the point in badly replicating drivers and making them "open-source". You still bought the GC from BigCorp, and only Nvidia can make those cards anyway: this "open-source" driver can't exist without Nvidia making cards. Who benefits from all that work?

Open source drivers can be shipped in the mainline kernel. Drivers that ship in the mainline kernel, are 1000% less of a pain in the ass.

If that were the case, we’d have almost no HW support on Linux. The Linux kernel doesn’t have a stable API nor ABI which means the only way to get meaningful HW support is to mainline the driver. DKMS helps a bit in “stabilizing” but it has it’s warts.

What is the issue with a proprietary OS ?

1. Privacy: mac/windows requires an online user account sign-in and have built-in telemetry that can't be disabled. 1984 is your reality on these OSs, particularly a problem outside of the free world.

2. Hardware lifespan: apple or microsoft get to decide when you buy a new computer instead of you and the community. Annoying, expensive, and not environmentally friendly.

3. Customizability and control: can't fix or improve the OS, and many powerful features just don't exist.

4. Open knowledge and human progress: by sharing knowledge and allowing others to contribute, we collectively advance. Proprietary operating systems discourage progress, and open source ones facilitate it. Nearly all of the great apps you know and love exist because of the culture of sharing. Even the proprietary OSs only exist because of open source OSs and libraries as the foundation and inspiration.

Linux users benefit from being able to use more hardware. It's the same motivation as any other driver. It's why drivers exist.

> What exactly is the issue with proprietary drivers?

They break. I have a GT730 card which came with my office PC. This card’s support has ended with the 470 driver series, which is one of last (if not the last) release for the previous generation of NVIDIA drivers.

Now, the drivers still ship, and the kernel module is still maintained, but the surrounding GLX drivers are static. As the desktop Linux improves and moves forward, accelerated stuff tends to get migrated to newer technologies, or its GLX use is getting refined. This causes drivers to lose compatibility over time.

This means more and more of your applications fail to start or break in mysterious ways. Also there’s Wayland support issue, which is the elephant in the room.

I had to buy an AMD card which works better, because all the software ecosystem around that card is maintained by volunteers, and the card is architected for working with open drivers well. AMD redesigned its silicon to allow open drivers to work with every unit on the GPU without revealing sensitive information (like HDCP keys) while allowing open drivers to access video encoders and such on the card.

After I got that card, all my problems have just vanished.

So, I’ll never use an NVIDIA card on my computer for the foreseeable future.

Except the exact same thing happens with AMD and their open source drivers. There are tons of AMD cards that are perfectly fine for desktop usage and will absolutely not work under Linux.

It comes down to a religious belief in open source, which is totally fine. But let’s be honest about what’s happening here.

> Except the exact same thing happens with AMD and their open source drivers.

How so?

If the drivers are in-tree, they should keep working indefinitely. What open source drivers are in Linux and stopped working over time?

mach64 and r128, both widely used in mid-2000s servers/ILOM

I have several laptops with Nvidia graphics that can't run proprietary drivers because not only has Nvidia deprecated the drivers, no platforms even package them anymore, while newer drivers exist in distributions' package repositories.

So you can end up in a situation where you've installed proprietary drivers via package manager and then a year later the packages are gone entirely.

You're forced to use PPAs that don't work or packages on the AUR which also don't work, and you're restricted to distributions that support either 3rd party packaging solution if don't want to install things manually, which also doesn't work.

In fairness, the GT 730 will reach 10 years old in only 6 more months and loses performance wise to even older laptop iGPUs by a decent margin. The card alone is years past the age range GPUs “typically fail”, even Windows has long dropped support for it. Expecting even open source volunteers to maintain support for every old GPU while continuously improving the drivers and adding more functionality and fixes is a bit much.

I can run current Linux distros on 15 year old hardware without issue. If the vendor wants to drop support earlier, that's up to them, but it's a reason why people want open drivers.

Also, local stores around me still sell new GT 710s. Probably has something to do with Nvidia not making any low end GPUs since.

> Expecting even open source volunteers to maintain support for every old GPU

The great thing about open source is that anyone can fork the code and maintain support themselves. You don't get that option with proprietary drivers.

Doesn't matter. Its performance was enough for what I needed from my computer until some of the applications started to break.

I have now replaced it with a Radeon RX550, which is 6.5 years old at this point, and works with open drivers like a charm, and amongst other things, I can integrate its power and utilization related data into my system dashboard very easily, because the drivers provide the relevant sensor access. Also, it works way smoother without finicky VSync and other small paper cuts.

Current, modern amdgpu driver supports cards which are 10 years old at this point. radeon kernel module supports cards even older than that, and this module is still updated, tuned up and fixed.

So, while AMD was the underdog, they managed to redesign their chips and restart a community and an independent department to develop and support open source drivers only.

I think NVIDIA can do that, too, if they can be bothered, but alas, they don't care.

RX 550 windows support is being dropped by AMD as well. Linux community support will continue but at some point official support does end for these things.

https://videocardz.com/newz/amd-confirms-polaris-and-vega-ar...

Obviously having an open driver is nice (and nvidia is upstreaming one) but AMD still doesn’t support consumer cards in ROCm in Linux, AMD still doesn’t support hdmi 2.1 in Linux, and there’s probably (different) business concerns for nvidia as well. Not everything can be opened up - again, see hdmi 2.1, which will probably continue to require closed releases due to licensing requirements.

https://gitlab.freedesktop.org/drm/amd/-/issues/1417

RX550 and relevant cards' support was also dropped from AMDGPU-PRO drivers (closed source set of drivers from AMD), AFAIK, but it's not important.

As I said, open drivers supported by AMD are here [0] [1], and even the historic "radeon" driver which supports older cards than "amdgpu" is being supported and fixed up.

It's also important to understand that open source driver team was independent and separate from closed source driver (fglrx + windows) team in the beginning. This might still be the case.

NVIDIA is not upstreaming an open source driver. They are upstreaming a skeleton open source kernel module which bridges the closed source GLX libraries to a closed source blob which moved from the original kernel module to a flash storage + RISC-V core complex on the card itself. This is fundamentally different from what AMD is doing.

ROCm is historically slow to develop and being supported by (m)any cards in general, but considering a couple of high profile supercomputers are using their cards and they openly said that ROCm is a priority now, they started to get way faster in development part. Tons of ROCm libraries have landed to Debian in the last 6 months, and a couple of consumer cards started to be supported under Linux [2]. Depreciation of older cards in closed source drivers will also probably enable this support to be developed faster, because AFAICS, AMD has gone through more ISA changes than NVIDIA in the last decade.

From what I can find in FreeDesktop issue tracker, AMD is actively trying to bring HDMI 2.1 in Linux, in a completely open form, and they are very open about it [3]. Unfortunately free software and large profits are not very compatible in the content industry, but at least AMD is not silent, and trying their best in the open, unlike the other camp, which does sneaky things like artificially limiting the performance of alternative APIs, and flat out refusing the work with some versions of them while advertising support.

[0]: https://gitlab.freedesktop.org/agd5f/linux/-/tree/amd-stagin...

[1]: https://gitlab.freedesktop.org/agd5f/linux/-/tree/amd-stagin...

[2]: https://rocm.docs.amd.com/projects/radeon/en/latest/docs/com...

[3]: https://gitlab.freedesktop.org/drm/amd/-/issues/1417#note_21...

I'm not sure what you're arguing here. There are important features missing in AMD's linux implementation, the ROCm ecosystem remains unsupported (on consumer hardware) under linux, and it relies on the same linux-firmware blobs as NVIDIA and everything else.

AMD is trying to get HDMI 2.1 support through legal, but they've been trying for years and the answer is generally "no". HDMI Forum doesn't want you to release open implementations, it is incompatible by design. This is a microcosm of the problems around licensing in the audiovisual space, the reason NVIDIA can't go open is also because of these intractible licensing problems. They just lean towards "release the functionality, but closed" instead of choosing "don't release the functionality".

In theory: A driver that's actually open source allows it to be ported to future versions of the Linux kernel as well as other kernels such as FreeBSD, giving you some level of guarantee that you'll be able to use the hardware for the full extent of its physical life.

In practice: Even ignoring NVIDIA's insistence on proprietary drivers, other manufacturers have already succeeded in making drivers that are technically "open source" with unreadable source code full of opaque logic and magic constants maintained by a kernel dev who has had to sign an NDA for the privilege of maintaining the driver, so the code isn't any more likely to survive a major kernel redesign (or perhaps a shift to a different operating system) than a proprietary driver would be, unless the manufacturer remains interested in actively supporting the device.

> magic constants maintained by a kernel dev who has had to sign an NDA for the privilege of maintaining the driver

Wait is this true? How did the kernel team agree to this?

Because the alternative would have been not having a driver, I guess.

I'd prefer to have the option to use my current Nvidia card with open source drivers, or to purchase a new one (I care more about good open source drivers now than I did when I bought my current card, in large part because of Wayland). Plus, Nvidia has a virtual monopoly on neural network acceleration because of CUDA, and that seems like it will last at least a few more years, so for some people it's not as simple as "buy AMD".

Second, my understanding of Linux's history is that people creating open source drivers for hardware is responsible for its success. The problem of bootstrapping Linux hardware compatibility was solved in part by people writing open-source drivers when companies didn't support Linux. Community support has been necessary for the creation and upstreaming of many previous drivers, not least among them AMDGpu.

Also, in this case, a large portion of the work for Nouveau is funded by Red Hat. I believe they business reasons for wanting a well-functioning open source Nvidia driver.

Open source driver lasts longer. Because of the great work by the Nouveau guys, I was able to use some hardware for longer than Nvidia would support. Very thankful.

Back in the day, VIA's Unichrome integrated graphics were best supported by the OpenChrome project. Very grateful to those guys too.

Sort of beating a dead horse at this point, the other comments have brought it up, but—they want you buy a card, and use it for at least long enough that you can’t return it anymore.

Driver support will be an afterthought, performed at their whim, and the only harm they suffer from not doing it will be offending the small community Linux users.

I'm all for wanting OSS drivers, but Nvidia does support its hardware across for many many years

Because it leads to straight up better products and companies that don't upstream the drivers get outcompeted by the ones that do.

Greg Kroah-Hartman explains it:

https://youtu.be/fMeH7wqOwXA&t=7m

Except it very clearly doesn’t. At best it’s uncorrelated. AMD and Intel have open source drivers, and Nvidia doesn’t. Nvidia has a much better product. Nvidia has AMDs GPU revenue in the couch cushions near the ping pong table.

I favor Intel and Snapdragon processors because of the Linux support. The nvidia case is unfortunate because its competitors are too far behind to put pressure on it.

"What exactly is the issue with proprietary drivers? They ship the hardware, they ship the driver(s). That's their problem. They probably want people to be able to use their cards. Why fight this battle?"

Linux was built because Linus Thorvalds wanted to use his hardware for something else the manufacturer envisioned. The free software movement got started because Richard Stallman wanted to add a new feature in the printer driver.

It's easy to think they should support their product... they should, but that's not a complete representation.

Their failure to do it well becomes user problems, which history shows, has been the overwhelming case.

Open source gives the user or their community recourse

I wonder, given enough recorded data streams, could a GPT trained on abi-documentation, reconstruct or reverse engineer said abi + undocumented calls.

Don’t wonder, try to do it.

Well, somebody has been there and done it: https://arxiv.org/pdf/1902.09122.pdf I just wanted a expert to comment on it..

Ah yes, Nouveau drivers. The thing that crashes immediately and prevents Linux from booting when you try to set up a fresh install on an Nvidia machine, leading to a short scramble to blacklist it with launch options until the actual drivers can be installed.

I sort of don't really know why they even bother. The only reason to have an Nvidia card is to use their CUDA toolkit, which isn't even supported by Nouveau.

I think plenty of people (myself among them), have used Nouveau without issues.

I admire the Nouveau people, lots of hard work with blocks nvidia is happy to throw in front of them. I have had no issues with Nouveau on the one system I have with an nvidia GPU.

With that said, I wish Linux would do what OpenBSD does, do not support nvidia GPUs until it is opened up. Maybe this will make nvidia smarten up.

Reply on news.ycombinator.com