Nvidia releases open-source GPU kernel modules
201–210 of 415 posts
Re: Nvidia releases open-source GPU kernel modules
#2021) 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)…
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?
Re: Nvidia releases open-source GPU kernel modules
#203Earlier 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…
If you want to stick with AMD and don't want to swap out the motherboard, then you'd probably just need to get an AMD CPU with on board graphics. The actual name of the CPU should help you find one that would work in that regard, for example, see this link which explains the naming suffixes: https://www.androidauthority.com/amd-cpu-guide-1222438/ In particular: X - Higher clocked desktop processor (what you got) G -…
in almost all situations, the "lower tier" CPUs can be replicated simply by taking the higher-tier CPU and setting a lower power limit. A 1800X with a 65W power limit is the same thing as a 1700, a 3400G with a 45W (?) power limit is the same thing as a 3400GE, etc. Since the "GE" chips and other niche SKUs (there is a 3700 non-X iirc, for example) are often OEM-only, and thus they only have a very limited availability, they will often command higher prices on ebay/etc than the "real" chip. In this case, there is no reason to seek out the "E" chip, with the possible exception of if it gets you the "pro" feature set and you happen to need one of the features (particularly for APUs since ECC is disabled on non-pro APUs). So if you see a 3400G for $200 and a 3400GE for $250 (made-up numbers) then don't buy the GE, buy the G and set the power limit yourself.
Lower-end chips do not have better binning - actually the opposite, higher-end chips have better binning and will run at lower voltages for a given frequency than the lower-end chips will. The "higher leakage clocks better" thing is not really a factor that matters on ambient cooling, that is for XOC doing LN2 or LHe runs, but it has entered the public consciousness that "low-TDP chips are binned for efficiency". Not in the consumer market they're not - the exceptions being things like Fury Nano that explicitly are binned better, and for which you pay a premium price for that efficiency. But most low-end consumer processors are just... low-end. They're priced according to performance, not binning.
You can see this in the SiliconLottery historically binning statistics: 1800X will categorically clock higher at any voltage than a 1700, a 3800X is categorically better at any voltage than a 3700X, etc - and that also means they will run a lower voltage at any target frequency. AMD bins straight-down in terms of chip quality: Epyc and TR get the best, then the high-end enthusiast chips, then the value enthusiast chips, then the efficiency parts at the bottom of the bins.
The "E" parts are efficient because they have a low power limit set - not because they're binned better. Lots of chips can run fine at lower voltages, they just don't do the peak frequencies as well as the binned chips. A 1800X will still get you a bit lower voltage - but since the voltage/power curve is quadratic, the difference in power is compressed at lower frequencies/voltages. Also, at a low-enough frequency you will bump into the minimum voltage required, so that tends to compress things as well. So at 3 GHz, the impact on binning between a 1800X and a 1700 would be a lot smaller than, say, at 4 GHz. The 1800X can usually do that fairly easily in a later sample, but 4 GHz is pretty much always pushing the limits of safe voltage for a 1700, for example, so the 1700 gets crappier silicon because it clocks lower.
https://siliconlottery.com/pages/statistics
https://www.reddit.com/r/Amd/comments/cll1r9/hardware_numb3r...
(the "one weird exception" is lower core-count chips. If you think of each core as a dice roll, this means that an 8-core chip has to roll perfectly 8 times, where a 6-core chip only has to roll perfectly 6 times. Since all-core OC is limited by the performance of the worst core, this means that for equal yields, there may be more lower-core-count chips with high all-core OCs. Many midrange parts do not actually have defective cores, they're locked out for market segmentation to avoid undercutting margins on the higher-end parts (which is why Phenoms and 7950s used to be unlockable, etc) and - while I'm not sure AMD has explicitly ever said it - it would also be sensible that when they are disabling cores on an 8-core to turn it into a 6-core they pick the best 6 cores, which would push silicon quality upwards too. A 1600X actually has silicon quality comparable to a 1800X according to SiliconLottery, for example, despite being a much higher-volume part. This "weird exception" also gets complicated with Zen2/Zen3 because AMD deliberately uses a low-quality die for the second CCD (3900X/3950X) since it will mostly be used under those lower-clocking all-core loads, and the impact of binning is compressed in those lower-clocking situations...)
Re: Nvidia releases open-source GPU kernel modules
#204Re: Nvidia releases open-source GPU kernel modules
#2051) 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)…
> 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?
Re: Nvidia releases open-source GPU kernel modules
#2061) 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)…
> 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?
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.
Re: Nvidia releases open-source GPU kernel modules
#207Earlier quoted context omitted.
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…
Why is the firmware closed source?
Re: Nvidia releases open-source GPU kernel modules
#208Earlier 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 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.
Re: Nvidia releases open-source GPU kernel modules
#209Earlier 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.
APUs are eating the market of novideo, see e.g. the performance of the M1 iGPU
Re: Nvidia releases open-source GPU kernel modules
#210Phoronix link about what this actually means: https://www.phoronix.com/scan.php?page=article&item=nvidia-o... Main takeaways: - support for gaming workstation GPUs is alpha - the user space stuff (OpenGL/Vulkan) is still closed source. (A LOT of heavy lifting is done here.)
Much like AMD - surely they benefit a lot from having a relatively stable non-kernel ABI they can target, though. The problem right now is that everything changes every time the kernel is updated, but if you turn it into a "here's how you dispatch PTX to the card" layer and a "here's how you turn OGL/Vulkan into PTX" blob then the dispatch layer probably isn't changing as much.
(graphics doesn't really use PTX but you get what I mean... dispatching compiled assembly and graphics API calls to the card.)
It doesn't help further the copyleft cause as much as if NVIDIA had open-sourced everything, of course, but from an end-user perspective of "I don't want my kernel updates to be tied to my driver release-cycle" it should solve almost all of the problem?