27 ms·

1) This is unambiguously Good News 2) This is not upstreamable in its current form (nvidia admit this in their press release) 3) In an ideal world, nouveau (t

by mjg59 4y ago

1) This is unambiguously Good News 2) This is not upstreamable in its current form (nvidia admit this in their press release) 3) In an ideal world, nouveau (the open source driver for nvidia hardware) would be able to target this kernel code. Right now though there's no commitment for any sort of stable userland ABI, and that makes that difficult (moving to a new driver version may break interfaces that nouveau uses) The press release does say that they have plans to figure out a more upstream friendly approach in the long term, which is great - and what has been released will undoubtedly help development of the existing nouveau codebase.

deleted 4y ago
[deleted]
smcl 4y ago
> This is not upstreamable in its current form (nvidia admit this in their press release) True, I remember though that the semi-recent AMD Radeon drop was not immediately merge-able to mainline because they used a bespoke hardware abstraction layer. But (as alluded to by your point #1) it's a huge first step, and in AMD's case I think they eventually reworked it so that it could indeed be merged.
- robocat 4y ago
  This is the key paragraph in the article relevant to your point: This open-source kernel code is currently split into OS-agnostic and kernel interface layer components. This stems from NVIDIA's proprietary driver on Linux largely being shared code across Windows / Linux / FreeBSD / Solaris. For it to be upstreamed in the Linux kernel it would likely need to be more re-factored to cater to Linux, just as AMD's DAL/DC originally had tough time upstreaming due to its numerous abstractions.
boberoni 4y ago
> This is not upstreamable in its current form What does "upstreamable" mean in this context? Is this good or bad? As a follow-up, what would need to be different so that it is upstreamable and would that be good or bad?
- Veliladon 4y ago
  Upstreamable means adding it to the official Linux source being distributed on linux.org. It just means you have to download drivers separately until Nvidia give the kernel guys a pull request for the drivers to be included in the kernel sources by default.
  - eru 4y ago
    I think the more important thing than the separate download is that when someone works on the kernel, they usually make sure that the don't break other things that are in the official kernel. But there's no obligation not to break things outside the official kernel (apart from the interface to userland).
- humanwhosits 4y ago
  You want things to be 'upstreamable' as they can be included in the default upstream kernel. If it gets included in Linus' git tree then keeping it working on future version of the kernel is much less hassle
- Tuna-Fish 4y ago
  > What does "upstreamable" mean in this context? Is this good or bad? "Upstream" is the kernel source tree maintained by Linus (and friends). As Linux is open source, anyone can fork it for any reason, and a lot of people do. However, Linus still maintains the common base that people use to build on top of. "Upstreaming" is the process of getting your code included in these official releases. It's significant because there are no stable interfaces inside the kernel. That is, in any release the Linux developers can change any internal system of the kernel in any way they please, with the only caveat that to get that change included they have to fix up any breakage it causes, but only inside upstream. Or, if you are building your own kernels with your own patch sets, any release of the kernel can completely break your build. Because of this, if you want your code to be actually used by real people, upstreaming it is considered extremely good, to the point of being almost a necessity. However, it can be a significant hurdle to overcome. Partly because there are fairly strict code quality/style requirements (as any kernel dev is supposed to be able to jump into your code to fix issues they caused by modifications elsewhere), but mostly because unlike inside the kernel itself, all interfaces between kernel and userspace are stable. That is, if you start supporting some operation from userspace, you need to be able to support it in perpetuity. Also, the kernel devs are extremely reluctant to add any kind of interface to the kernel where the only thing that uses it is some specific non-free binary blob on the userspace side. Currently the main reason the code is not upstreamable as is is that it needs a very substantial userspace program to function, which currently only exists as nonfree, and nVidia doesn't think that the interface used to connect to it is well-enough decided they want to freeze it. So the main hurdle for upstreaming is developing that interface until they are happy with it, and then develop some free version of the userspace portion of their graphics stack that can plug into that same interface.
mort96 4y ago
Sadly, it's also not the actual GPU driver, just the kernel part; you still need their massive closed blob in userspace. Almost had me excited there for a moment.
- erung88 4y ago
  It takes time for Nvidia to become open-source friendly. Still a good move. Hopefully the GPU driver is next in their open-source roadmap.
- greggsy 4y ago
  Has any rationale been provided around the blob being closed? Is it licensed, or simply too too complicated to pick apart? Graphics is a complicated field, but the techniques could still be patented - surely their market status isn’t dependent on trade secrets?
  - shmerl 4y ago
    My guess - tangled code mess without clear control over ownership and bean counters not approving the work of untangling all that to open things up - it's not an easy process for huge legacy codebase.
  - prash_ant 4y ago
    There have been reports earlier [1] that processing power of some GPUs is suppressed by software rather than the hardware capability itself. It is frequently easier to mass produce similar chips than to have different chips for different priced devices. I had come across comments in other online forums where the users alleged that some software flags restrict the capability. I hope someone else will link those webpages if they come across them [1] https://www.tomshardware.com/news/nvidia-gpu-system-processor-introduction https://www.tomshardware.com/news/nvidia-gpu-system-processo...
    - hyperionplays 4y ago
      this was the case with RTX voice, a simple regedit made it work on non-RTX cards fine.
themusicgod1 4y ago
New code on github is never good news.
- justemre 4y ago
  Why?
  - themusicgod1 4y ago
    Because github is microsoft, the enemy of freedom and the greatest threat the free software movement has ever faced
olliej 4y ago
(1) No, it's unambiguously "meh" news Nvidia have merely moved their giant closed source drivers into "firmware" - they now have a 34Mb firmware image for the GPU, that would be more correctly called the real drivers. They have essentially created an open source GPL forwarding layer so that the non-GPL firmware gets access to GPL-only kernel APIs, that's it.

by mjg59 4y ago

deleted 4y ago

[deleted]

smcl 4y ago

> This is not upstreamable in its current form (nvidia admit this in their press release) True, I remember though that the semi-recent AMD Radeon drop was not immediately merge-able to mainline because they used a bespoke hardware abstraction layer. But (as alluded to by your point #1) it's a huge first step, and in AMD's case I think they eventually reworked it so that it could indeed be merged.

robocat 4y ago
This is the key paragraph in the article relevant to your point: This open-source kernel code is currently split into OS-agnostic and kernel interface layer components. This stems from NVIDIA's proprietary driver on Linux largely being shared code across Windows / Linux / FreeBSD / Solaris. For it to be upstreamed in the Linux kernel it would likely need to be more re-factored to cater to Linux, just as AMD's DAL/DC originally had tough time upstreaming due to its numerous abstractions.

boberoni 4y ago

> This is not upstreamable in its current form What does "upstreamable" mean in this context? Is this good or bad? As a follow-up, what would need to be different so that it is upstreamable and would that be good or bad?

Veliladon 4y ago
Upstreamable means adding it to the official Linux source being distributed on linux.org. It just means you have to download drivers separately until Nvidia give the kernel guys a pull request for the drivers to be included in the kernel sources by default.
- eru 4y ago
  I think the more important thing than the separate download is that when someone works on the kernel, they usually make sure that the don't break other things that are in the official kernel. But there's no obligation not to break things outside the official kernel (apart from the interface to userland).
humanwhosits 4y ago
You want things to be 'upstreamable' as they can be included in the default upstream kernel. If it gets included in Linus' git tree then keeping it working on future version of the kernel is much less hassle
Tuna-Fish 4y ago
> What does "upstreamable" mean in this context? Is this good or bad? "Upstream" is the kernel source tree maintained by Linus (and friends). As Linux is open source, anyone can fork it for any reason, and a lot of people do. However, Linus still maintains the common base that people use to build on top of. "Upstreaming" is the process of getting your code included in these official releases. It's significant because there are no stable interfaces inside the kernel. That is, in any release the Linux developers can change any internal system of the kernel in any way they please, with the only caveat that to get that change included they have to fix up any breakage it causes, but only inside upstream. Or, if you are building your own kernels with your own patch sets, any release of the kernel can completely break your build. Because of this, if you want your code to be actually used by real people, upstreaming it is considered extremely good, to the point of being almost a necessity. However, it can be a significant hurdle to overcome. Partly because there are fairly strict code quality/style requirements (as any kernel dev is supposed to be able to jump into your code to fix issues they caused by modifications elsewhere), but mostly because unlike inside the kernel itself, all interfaces between kernel and userspace are stable. That is, if you start supporting some operation from userspace, you need to be able to support it in perpetuity. Also, the kernel devs are extremely reluctant to add any kind of interface to the kernel where the only thing that uses it is some specific non-free binary blob on the userspace side. Currently the main reason the code is not upstreamable as is is that it needs a very substantial userspace program to function, which currently only exists as nonfree, and nVidia doesn't think that the interface used to connect to it is well-enough decided they want to freeze it. So the main hurdle for upstreaming is developing that interface until they are happy with it, and then develop some free version of the userspace portion of their graphics stack that can plug into that same interface.

mort96 4y ago

Sadly, it's also not the actual GPU driver, just the kernel part; you still need their massive closed blob in userspace. Almost had me excited there for a moment.

erung88 4y ago
It takes time for Nvidia to become open-source friendly. Still a good move. Hopefully the GPU driver is next in their open-source roadmap.
greggsy 4y ago
Has any rationale been provided around the blob being closed? Is it licensed, or simply too too complicated to pick apart? Graphics is a complicated field, but the techniques could still be patented - surely their market status isn’t dependent on trade secrets?
- shmerl 4y ago
  My guess - tangled code mess without clear control over ownership and bean counters not approving the work of untangling all that to open things up - it's not an easy process for huge legacy codebase.
- prash_ant 4y ago
  There have been reports earlier [1] that processing power of some GPUs is suppressed by software rather than the hardware capability itself. It is frequently easier to mass produce similar chips than to have different chips for different priced devices. I had come across comments in other online forums where the users alleged that some software flags restrict the capability. I hope someone else will link those webpages if they come across them [1] https://www.tomshardware.com/news/nvidia-gpu-system-processor-introduction https://www.tomshardware.com/news/nvidia-gpu-system-processo...
  - hyperionplays 4y ago
    this was the case with RTX voice, a simple regedit made it work on non-RTX cards fine.

themusicgod1 4y ago

New code on github is never good news.

justemre 4y ago
Why?
- themusicgod1 4y ago
  Because github is microsoft, the enemy of freedom and the greatest threat the free software movement has ever faced

olliej 4y ago

(1) No, it's unambiguously "meh" news Nvidia have merely moved their giant closed source drivers into "firmware" - they now have a 34Mb firmware image for the GPU, that would be more correctly called the real drivers. They have essentially created an open source GPL forwarding layer so that the non-GPL firmware gets access to GPL-only kernel APIs, that's it.