191–200 of 415 posts
For those who didn't use Nvidia on linux in the old times: The driver was a proprietary binary. Since a kernel module requires interfacing with the kernel API, it could be considered a derivative work and a breach of the GPL license. So, Nvidia provided a small open source shim which interfaced between the kernel and the proprietary module. You had to compile that shim yourself with the right arcane command line inca…
Would love to hear from folks who worked on this! Was this an ongoing thing? Did it have to be pitched hard? What finally made the difference? I'm assuming here it's not because of LAPSUS as some speculate. This seems like it must have been in the making for quite a while.
I didn't work on this but I have watched it with interest for a very long time. It has been a strategic initiative in order to improve the GPU compute ecosystem. No one loves having a tainted kernel and everyone who uses a GPU with Linux (which is almost all data center GPUs) would prefer to have the kernel modules open source. It took a lot of work and planning to figure out how to do this over many teams for a very…
Earlier quoted context omitted.
The part about them being buggy is definitely true. Up until somewhere around 2016-2017 the ATI/AMD drivers were really bad. I had an "HD 7850" GPU on Linux around that time and it was barely usable. The performance was less than half of what you got on Windows, and the drivers would crash very often, sometimes several times a day if I was trying to play games like Team Fortress 2. It was so bad that I decided to rep…
About them being buggy, I won't discuss. But you didn't have to do anything to even get them installed.
WE REQUEST THAT NVIDIA COMMITS TO COMPLETELY OPEN-SOURCE (AND DISTRIBUTE UNDER A FOSS LICENSE) THEIR GPU DRIVERS”
https://www.theverge.com/2022/3/1/22957212/nvidia-confirms-h...
Earlier quoted context omitted.
The license is abundantly clear about this and answers all your questions. It matters who is doing the rewriting and how they got the code in the first place.
I think one of the matters that confused me about it was the CLISP question. IIRC, CLISP linked to readline, but was released under a non-GPL license. RMS contacted them, and asked them to relicense. They suggested either reimplementing a stub readline-library, or rewriting their line editing code against another lib instead. RMS insisted that they would still be a GPL-derivative, resulting in the current license sit…
https://sourceforge.net/p/clisp/clisp/ci/tip/tree/doc/Why-CLISP-is-under-GPL
Earlier quoted context omitted.
I think one of the matters that confused me about it was the CLISP question. IIRC, CLISP linked to readline, but was released under a non-GPL license. RMS contacted them, and asked them to relicense. They suggested either reimplementing a stub readline-library, or rewriting their line editing code against another lib instead. RMS insisted that they would still be a GPL-derivative, resulting in the current license sit…
RMS may have believed or wanted that, but it is my understanding (IANAL!) that the case law has been settled differently. If you are found in violation of the GPL due to a dependency you weren't aware was released under the GPL, you can fix that violation by rewriting your application to avoid the GPL dependency. CLISP et al cannot be forced to distribute their code under the GPL. It's their code and their choice; co…
To comply with the GPL you only need to publish the one specific snapshot of source code you've combined and redistributed with GPL code, but you don't need to permanently relicense your project if it doesn't contain any code you don't have rights to use. The "tainted" version will be granted as GPLed forever, but other earlier or later versions that don't use any GPL code don't have to.
Or you can go the copyright way, and claim it wasn't a copyright violation (because it was a fair use, or non-copyrightable code) or settle the matter in whatever way the law lets you get away with.
Can this be used with CUDA for GPGPU or is it somehow only relevant for graphics?
But anyway, the user-space stuff is still the same. This only affects the kernel modules.
It will probably end up like how AMD cards work. The closed source driver still exists but there will hopefully be a completely open source stack (Nouveau++?) For nvidia. This blog has more details about red hats plans for this driver. https://blogs.gnome.org/uraeus/2022/05/11/why-is-the-open-so...
I've never properly understood why the closed source AMD driver still exists. Is it substantially different from the open source one? Does it offer anything not included in the open source one?
The latter I wish was just a general purpose feature now that things like resizable bar are seeing general support in the consumer space.
Earlier quoted context omitted.
If the module can use MESA, good. If not, meh. >. Adding enough just emulation for the userspace driver would be a lot easier than maintaining a complete linux emulator. OpenBSD it's the best BSD on support for free (Intel) and semi free drivers such as the ones from AMD, they already adapted all the src from Linux, KMS included.
That's very different. The source code for the userspace portions of the MESA drivers for AMD/Intel are released under a permissive licenses, so OpenBSD (and other BSDs) have been able to modify them to compile under their OS (and get those changes committed to the original tree). With NVIDIA, the userspace portions don't use MESA, so would need some form of translation layer to work on an OS other than Linux. But, s…
Earlier quoted context omitted.
> I used and recommended ATI and INTEL for most of the people I could for a long time because of this. Same here but recently I somehow got a 3700X and there's no integrated GPU so I had to look for a GPU. I like my PC not just quiet but nearly silent, so a GPU with a fan was a big no-no. I couldn't find any single GPU able to drive 3840x1600 without a fan... Except for a NVidia one. Of course the proprietary Linux d…
It’s pretty damn stunning how quite an AIO 2x 140mm cooler can be. And graphics cards with those big triple fans are silent until needed. I’ve been through a couple 12th gens. I like them, but unless you need the machine updated right now, 13th gen is 6 months out.
Almost no AIOs have the fluid-temperature sensors that would allow you to measure this directly, so everyone uses the die sensors. Which, since they're behind the IHS, will be much higher than the fluid itself. The die temperature is also a measurement of interest too - I'm merely explaining why the number you're seeing in the die sensor isn't really the big picture of how good the the radiator is doing at cooling. The die is hot, but the fluid is cool.
The AMD 295x2 is an extremely good example of this observation - this card had a single 120mm radiator, with one fan, and it could dissipate >500W of heat at ~60C die temperature. (not sure if this source says this directly but the non-OC power was ~430W average during gaming, and ~250W is not unreasonable for each 290X chip - actually they could go to 300W or higher if you really poured it on, but they also did generally show some significant power scaling with temperatures, so ~250W per chip/500W total is a reasonable estimate imo).
https://www.techpowerup.com/review/amd-r9-295-x2/28.html
You might say - but that's a dual-GPU card, with bare dies. And yes, that's my point, when the coldplate/IHS is no longer a bottleneck moving heat into the loop, a 120mm radiator is comfortably capable of dissipating 500W of power back out of the loop at extremely reasonable operating temperatures (60C die temperature). 60C is actually barely breaking a sweat, you could probably do 1000W through that 120mm if you didn't mind a die temperature in the 80-90C range. In CPU overclocking - your power limits/temps are almost entirely limited by how fast you can get that heat through the IHS. Reducing fluid temps (by increasing radiator size) is pushing on a string, it takes big gains in fluid temp to produce a small improvement in die temp.
Incidentally, direct-die cooling is the last untapped frontier of gains for ambient (non-chilled) overclocking. Der8auer and IceManCooler.com both make "support brackets" that replace part of the ILM (integrated loading mechanism - the socket and its tensioning mechanism and attachment to the motherboard) that holds the processor. This is necessary since the IHS is actually part of the ILM - the ILM presses down on the sides of the IHS, so removing it would change the pressure, and the ILM needs to keep a specific level of pressure on the chip to make a good contact with the pins but but without damaging anything. But you can delid the processor (there are services that do this for soldered chips, I don't recommend doing it at home) and use one of those brackets with a "normal" waterblock/AIO (or even air-cooler), since the bracket is holding the chip in the pin-bed at the proper tension.
Thermal density is going nowhere but up, Dennard scaling is over, so that is the only way to really improve thermals on power - because of that thermal density, and every time they shrink it's going to get worse. The gains may be more worth it on Intel though - they show better scaling from power/voltage, TSMC nodes seem to pretty much top out at about 4 GHz and past there it gets exponentially worse for very little actual performance gain. 4.3, 4.4, sure, but they don't seem to do 5-5.3 GHz like Intel can on their Intel 7 given good temps and enough voltage.
But yes, to go back to your original point, I really like my 3090 Kingpin as well. It runs extremely cool, I can keep the die at literally 30C with the fans cranked all the way up, and it'll keep the VRAM at under 70C (!). And since it is a 2-slot card it doesn't turn into a compatibility mess with motherboard pcie slots getting blocked and needing airspace/etc. I am 100% behind AIOs on the larger gpus that we are seeing lately, this is a better solution than triple-slot or 3.5 slot coolers, which are (imo) completely ridiculous.