woah.... that only took like forever. anyhow - good job
Nvidia releases open-source GPU kernel modules
311–320 of 415 posts
Re: Nvidia releases open-source GPU kernel modules
#312Earlier quoted context omitted.
> 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?
'Upstreamable' means that they send Linus a pull request, and Linus merges it into the kernel. It would then become part of Linux. It's a negative that it's not upstreamable. I wouldn't go so far as to say it's bad, but it's less than good. That means you'll continue to maintain a separate kernel module that's rebuilt for each kernel. It would need to be modified to match the kernel's coding standards and whatnot. Pa…
What would the practical effect be for me as a user, say I render in Blender, or I play a few intensive 3d games?
Re: Nvidia releases open-source GPU kernel modules
#313[deleted]
Re: Nvidia releases open-source GPU kernel modules
#314Earlier quoted context omitted.
This small tirade of yours is arguing against a strawman. GP is likely referring to the userspace component of nvidia's driver, not the actual blob that gets loaded onto the gpu. If it is indeed true that you need to run proprietary userland code, then this open-source release is nothing but a way to circumvent the GPL issues that lead to nvidia's driver partially breaking in Linux 5.??. While not ideal, I like many…
Interesting, so they can do whatever they want, provided it runs as firmware.
I think this firmwareblob vs. kernelblob vs. userspace blob needs to be decided on a case by case basis, and no strict line that shall not be crossed can be drawn anywhere. The important factor is, does their contribution help the community or not, will it allow the community to fix bugs and port stuff to a new innovative kernel, without it needing to re-implement everything from Linux?
Personally I would try to decide on blob size and scope. With nvidias driver I suspect that require massive firmware and userspace blobs, and the kernel driver is probably just a pass-through API. I would argue that this doesn't really move the community forward.
However if the blobs are small and simple, and have specific scope and a reason, like legislation or security, maybe even calibration data blobs, are useful independent of the OS itself, then I would give them a pass, since it allows the community to build upon.
Re: Nvidia releases open-source GPU kernel modules
#315Earlier quoted context omitted.
This small tirade of yours is arguing against a strawman. GP is likely referring to the userspace component of nvidia's driver, not the actual blob that gets loaded onto the gpu. If it is indeed true that you need to run proprietary userland code, then this open-source release is nothing but a way to circumvent the GPL issues that lead to nvidia's driver partially breaking in Linux 5.??. While not ideal, I like many…
Interesting, so they can do whatever they want, provided it runs as firmware.
Where do you draw the border? Even if they open source the firmware, they can also do whatever they want provided it runs as hardware.
If trust is the issue, you would have to open source the hardware/the silicon as well.
If trust isn't the issue, but being able to do your own things with the hardware you own, this is sth. different.
Re: Nvidia releases open-source GPU kernel modules
#316Earlier quoted context omitted.
I wonder if this is related: https://www.eetimes.com/wp-content/uploads/Nvidia-hack-secur...
I wonder if this release will meet the hacker's definition of open source in this case. People like that have a habit of changing the goal lines.
[deleted]
Re: Nvidia releases open-source GPU kernel modules
#317Earlier quoted context omitted.
Uh why would you change from a good, official source to a worse rehash of the same stuff with less detail from Phoronix? I don't even dislike Phoronix, but what was wrong with the first-party source?
User suggestions about better articles tend to be pretty reliable, so we tend to trust them. Sometimes they turn out not to be better (at least not by consensus)—in which case we can change the link back. I've done so in this case. If you want to understand this process, you should understand that none of it involves actually reading the articles!
I would argue the Phonorix is the vastly superior link.
That blog is the most dedicated to the confluence of 3D, Linux, and open source.
The Nvidia copy is typical engineering marketing copy. The Phonorix post dives into everything with great detail and goes further by discussing the future of open source Nvidia support with the upcoming technologies, and existing technologies (Noveau, Mesa, etc)
Nvidia fanboys care little for Phonorix because that site consistently points out how unfriendly and uncooperative Nvidia has been with the whole of the Linux community. (Web search for yourself Nvidia EGLStreams GBM.)
Re: Nvidia releases open-source GPU kernel modules
#3181) 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)…
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.
While this is not as good as an open-source GPU driver, it is nonetheless a significant progress, which cannot be dismissed as useless.
It is far more important to have open sources for all programs that are executed in privileged mode than to have the source for the programs that are executed in user mode.
The kernel can control what a user-mode program does and limit its access to any hardware resources or CPU time, but it cannot do anything against kernel modules that are executed in privileged mode.
So having the source for all the kernel modules is the main priority. With this new open-source kernel module from NVIDIA, the only closed-source kernel module used by a large number of Linux users is no longer so.
Now the main problems remain the BIOS/UEFI of the computers, which is free to override what the operating system does, due to the exceedingly stupid System Management Mode invented by Intel, and the firmware for the auxiliary CPUs that may be used for unauthorized remote management in most Intel- and AMD-based computers.
Re: Nvidia releases open-source GPU kernel modules
#319Earlier quoted context omitted.
> I like back-foot, underdog NVIDIA. Ascendent AMD hasn't drawn my ire yet, let's hope power corrupts slowly. That "back-foot" "underdog" nVidia has the edge in the video market still... and 3x the market cap of AMD.
It's fair to extrapolate because their strategic decisions will be based on extrapolations. NVIDIA had to overclock and hustle the current generation of cards and it's looking even worse for the next generation. Software was a moat when AMD was heavily resource constrained, but now they can afford the headcount to give chase. Between the chip shortage and crypto, there was plenty of noise on top of fundamentals, but…
NVIDIA is well, well ahead of AMD.
NVIDIA's cards were faster than AMD's with the huge gap in transistor density that was the Samsung fab.
Don't get excited for the AMD graphics division up in Canada.
Re: Nvidia releases open-source GPU kernel modules
#320Earlier quoted context omitted.
>Amd changed their windows drivers to not output video if it detects its running in a VM. What? Why?
Because the drivers for the consumer GPUs are not licensed for datacebter use and obviously VM == datacenter
This is a problem for QUbes OS which has a legitimate need for vgpu on a desktop operating system.
It's because of this arbitrary restriction that Qubes is not able to provide GPU acceleration, which is a huge barrier to its adoption.