7 ms·

I am totally out of the loop here, but wasn't the main problem with Nouveau the lack of documentation from Nvidia? They had to reverse engineer things to get it

• porphyra 3y ago
  My understanding is that nowadays most of the heavy lifting is done by magic going on in the firmware, so the actual driver is relatively simple and is open source: https://github.com/NVIDIA/open-gpu-kernel-modules https://github.com/NVIDIA/open-gpu-kernel-modules
  • roenxi 3y ago
    Any efforts by Nvidia are welcome, but that raises the question of why Red Hat are writing a new driver. Presumably there is some aspect of the OSS component that is dissatisfying Red Hat. It is weird for a 3rd party to be maintaining a 2nd driver when the first party has a reasonable OSS driver.
    • doctorpangloss 3y ago
      There are a few things someone would pay Red Hat dearly to do. In my opinion the most likely are: - No telemetry. - Enabling software blocked features. - Emulation. There are few possibilities about making a performant OSS driver: - This is impracticable, because the software you want to run on the GPU is so complex, and the hardware is so complex, that you will never get enough insights to make something that compares with the people who can see it all. - This is eminently practicable because: (1) the software is much simpler, and the GPU hardware much simpler. Perhaps there is a lot of obfuscation of the simplicity. Or (2) the application that best utilizes the hardware only needs a limited feature set that is within scope. I'm leaning on "application limited scope" and "telemetry." It aligns best with what is actually happening, which is NVIDIA is scooping up a lot of valuable intelligence on LLM workloads; and that there isn't enough competition for LLM "ASICs" to make them cheap enough to be worthwhile.
      • greggsy 3y ago
        The telemetry aspect is easily resolved by any enterprise that cares enough about it. The conclusion that this is more to do with the overall architecture and deployment of the existing driver is much more plausible.
        • doctorpangloss 3y ago
          > The telemetry aspect is easily resolved by any enterprise that cares enough about it. Yeah, this is how, by writing your own driver. NVIDIA sells you turnkey DGX machines. It doesn't give you firmware. You have to be Internet-connected to refresh your various licenses, at some point, which is the moment the telemetry is shared. Google "NVIDIA telemetry." If you are using NVIDIA on the cloud, well all bets are off. You are using their drivers. Amazon can't force you, in your VM, to install a different driver for the GPU you are using - there's no alternative to the proprietary one. Hence, my theory for why Red Hat could be paid to do this. Telemetry is something that NVIDIA doesn't budge on for enterprises. You're welcome to see for yourself and start a sales call. I hear they're pretty busy.
      • gigatexal 3y ago
        I never understood all the hate we in the OSS world have with telemetry. Why? I mean if nvidia and red hat paid for this to be developed wouldn’t it help them continue to develop it by knowing how and where and how often it was used?
        • speed_spread 3y ago
          Because it's never just for engineering purposes anymore. Marketing departments are CRAZY about consumer data of any kind and you can be assured the value of such collected data will be maximized on the information exchange market. Advertisers pay good money for trustable data streams, which can be essentially de-anonymized with enough cross correlation between sources. A GPU happens to be a good place to capture user activity, since from the screen buffer you can tell what website they visit, what videos they watch and what games they play. This stuff is rather hush hush not to scare people but it's also well documented and certainly not an unfounded conspiracy. Its also why Europeans have adopted far reaching privacy laws (GDPR), their industries don't rely on consumer surveillance the way Americans have developed for the last decades.
    • zekica 3y ago
      > but that raises the question of why Red Hat are writing a new driver Nvidia's driver cannot be included in the upstream linux as it doesn't follow kernel coding style and code organization, but more importantly it is tightly coupled to a single version of their GSP firmware - they have to be updated at the same time.
    • cozzyd 3y ago
      Perhaps it has something to do with getting Nvidia drivers to compile properly with RH's Frankenstein kernels?
  • denzil 3y ago
    I'm not sure if it's different for Nvidia, but the Gamer Nexus video about Intel drivers suggest a lot of the work getting good performance is done on the driver side for all GPU vendors: https://www.youtube.com/watch?v=Qp3BGu3vixk https://www.youtube.com/watch?v=Qp3BGu3vixk
  • Tuna-Fish 3y ago
    Shader compilation happens on CPU, and is neither simple nor (for the nvidia compiler) open source. GPU drivers are significantly more complicated than any other drivers because they do things that are not considered part of a driver for any other device, the proprietary nV driver contains roughly as much code as the linux kernel.
• wezm 3y ago
  NVIDIA started publishing more of their driver as open-source in 2022, which while not hardware documentation probably helps a lot. You may be wondering why Red Hat is bothering with this effort then? I assume it’s so that the code can be added to Linux directly as opposed to being out of tree. https://developer.nvidia.com/blog/nvidia-releases-open-source-gpu-kernel-modules/ https://developer.nvidia.com/blog/nvidia-releases-open-sourc...
• wmf 3y ago
  They're still reverse engineering. The hardware is so good that people would rather use an Nvidia GPU with reverse engineered drivers than AMD with open documentation and official open source drivers. Same with Apple and Asahi.
• weikju 3y ago
  Cynically, I’m thinking the main “problem” being solve here is the current drivers are not written in Rust
  • throwaway48476 3y ago
    Unless the problem is memory safety, probably not.
    • worthless-trash 3y ago
      There is another perspective you msy not be thinking of, developer availability In 20 years when the current crop of greybeards are dead, how many experienced c programmers with kernel experience will exist. Rust lowers the bar for contributing and also increases the pool of programmers who can.
      • sham1 3y ago
        I do somewhat doubt that. `no_std` Rust is still quite different from normal, userspace Rust. You don't get all the fancy libraries or whatever (of course Linus would probably just veto them anyway) and the Linux kernel development model is probably quite different (IIRC no cargo and whatnot). So… what should we reckon? Would there a difference in getting new developers into `no_std` Rust in the kernel, and how different would that be versus having people learn freestanding C, with all the kernel add-ons and nicknacks?
        • worthless-trash 3y ago
          Systems programming is always a full step sideways from traditional applications and I do see where you are coming from. I would still reckon that having familiarity with the standard rust (even with std) will still have more programmers willing to make the leap than learn C for this one project. I know of less than a handful of C projects starting in 2024, I know there is a bunch in rust , even with no_std.
        • charlotte-fyi 3y ago
• lyu07282 3y ago
  I was hoping they officially partnered with NVIDIA in that effort, perhaps eventually even replacing the proprietary one on Linux. But then I awoke from that dream, it's less exciting. Still cool though. Unfortunately Linux Desktop still seems to be too irrelevant for NVIDIA. All current drivers have issues with suspend, multiple displays and Wayland among other things.
  • xorcist 3y ago
    Which is a bit surprising because they make their money from the AI/LLM hype now, which presumably is all Linux. So Linux should be a priority for them, just not on the desktop. But the step should be small.
    • lyu07282 3y ago
      It probably makes it even worse, its the enterprise/data center cards for ML that are making huge profits and where the growth is, and those don't even have a video out.
• uluyol 3y ago
  The problem with Nouveau was that Nvidia hardware could not be reclocked (the cores were basically always in low power mode) without a signed firmware blob. That blob couldn't be legally distributed except by Nvidia, so the open source folks more or less gave up on a high performance driver. Now, for newer hardware, Nvidia has changed some aspects of the firmware and allows redistribution. So it's feasible to make a good open source driver. AMD and Intel also use different drivers for different hardware generations, since eventually things change so much that it's better to start clean. With regards to reverse engineering, Mesa has a number of reverse engineered drivers. That isn't anything new.
  • wengo314 3y ago
    the problem was the nouveau would do this before when firmware was easy to intercept from the driver (and could be extracted easily). the newer driver uses different methods of firmware upload and it's a real chore to do so now. so nouveau gave up on it. they also expected nvidia to drop some firmware. now that newer cards have GSP.bin firmware, which can be interfaced with easily - things are different. i would wager a guess that it's similar to atombios from amd. you just call a function in GSP and it knows what registers to poke with the right values to achieve what you need.
• inamberclad 3y ago
  A coworker of mine formerly worked on Nvidia's proprietary drivers. They remarked at just how wrong the Nouveau driver was about certain things, including the functionality and reasons for certain registers.
  • kelnos 3y ago
    Around a decade ago, I was introduced to a couple people who it turned out worked at nvidia. After a bunch of conversation, nouveau came up; they were intensely negative about it, mocking it and its developers, criticizing its existence, even, and declaring it would never amount to anything. (Meanwhile, I was running it on a computer at home and it was significantly more stable than the nvidia proprietary driver at the time, and performed well enough for my use.) I wish I'd had more conversational courage at the time to "stand up" for nouveau with them; it was super rude to shit on someone else's hard work, especially when the reason why they had to do that hard work was because nvidia was a bunch of jerks with a shitty FOSS policy.
    • matheusmoreira 3y ago
      That's completely fucked up and has soured my opinion of nvidia and the people involved with it more than anything they've ever officially done as a company.
    • throwaway48476 3y ago
      Yeah look at those idiots getting 80% of the way there with no support. Clearly incompetent.
    • westhanover 3y ago
      [dead]
  • bogantech 3y ago
    Given that there's no official documentation and they can only learn through reverse engineering this is not at all surprising. Presumably RedHat are in the same boat.