No documentation on which GPUs this driver supports #18
Comments
|
It's version 515, so it will support what the equivalent proprietary driver supports. Architecture-wise, that includes : Personally though, I wouldn't mind if the code for Kepler could be released as well. |
|
My personal understanding is that it essentially supports any card that is able to use the GSP firmware. That information seems to be available in the documentation provided with each NVIDIA driver release. https://download.nvidia.com/XFree86/Linux-x86_64/515.43.04/README/gsp.html |
|
Based on the source code here and in the last binary driver set, it looks to "just be the next version" of the same driver, so the same chipsets. |
|
This is limited to only GSP-enabled cards, so 20xx and 30xx cards (Turing and above). From https://www.phoronix.com/scan.php?page=article&item=nvidia-open-kernel&num=1
|
Interesting. I do see some files for Maxwell / Pascal in there though. Was just about to test it on my 1070. |
This is from the NVIDIA documentation.
|
|
Hopefully this helps clarify a response, RobertCochran, from the announcement links: https://developer.nvidia.com/blog/nvidia-releases-open-source-gpu-kernel-modules/ |
|
Seems clear enough. I'd still like if this were mentioned in the README so that the information stays up to date with the driver and removes the guesswork. |
|
Shipping Currently supported-gpus.json is shipped in the .run script, but it would be nice to have it here too. |
|
Both good suggestions, thanks. |
|
Thanks for the discussion. Yes, the open kernel modules support Turing and later GPUs. For datacenter GPUs, that list is currently: https://download.nvidia.com/XFree86/Linux-x86_64/515.43.04/README/gsp.html For GeForce and Workstation, product names can make it difficult to infer what GPU architecture is in a product. Extending supported-gpus/supported-gpus.json with an identifier, and including it in this github repository, is a good idea. Tagging as an enhancement request. |
|
If I was a beginner I would not personally know where to look to see whether my GTX 760 is supported or not (last supported Linux driver was 470) - I recommend a simple markdown file with a list of supported and unsupported GPUs |
|
I agree, I'd like to see an updated list with all officially supported graphics cards. |
It looks like the 16xx are also supported unless @aritger wants to correct me. https://en.wikipedia.org/wiki/GeForce_16_series "The GeForce 16 series is based on the same Turing architecture used in the GeForce 20 series, omitting the Tensor (AI) and RT (ray tracing) cores exclusive to the 20 series" |
|
Yes, the 16xx GeForce series are based on Turing and have a GSP; as such they can use the open source driver. However, GeForce 16xx are not datacenter GPUs and support for them is experimental in this release, so you will have to use NVreg_OpenRmEnableUnsupportedGpus module param for now. I have personally found this wikipedia page to be an excellent mapping between product names and chip/architecture ones: Anything with a codename of |
|
Does anyone think there is a chance of expanding the list to include 10 series or older cards? Whether through a fork or in this repository? |
|
@tajetaje Please see here, cards prior to 16xx and 20xx simply do not have the necessary HW to use this driver. |
Ah, missed that; well hopefully some of the back-ported changes help out then |
They won't backport the driver to older GPU's without the GSP. Nvidia just released this "open source" skeleton full of blob usage to workaround the kernel restriction. So
|
|
This is a useful discussion. Note that I'm working on adding support for some of these questions into inxi at the moment, but still am collecting data. So far there is no online resource that combines nvidia product IDs with microarchitecture names, so I have to combine those lists manually and use some guesswork to match the legacy microarchitecture names to product ids. Some of this is running in pinxi, the development branch of inxi, already, and more will be added as I get more information and data, and figure out how to present this data in the most useful form. I should have something basic working today or in the coming next days, but it won't be perfect due to lack of accurate data online. I've done this type of data assembly many times, any intern could have that page of matching tables up in about 2 days, maybe 3 on the outside (a few hours is there is internal data source for this), but I would only do that if I were paid because it's so boring, I'm looking for more general matches. It sounds like all cards with product ids listed in the 5.15 page will be supported, I'll have to double check their microarchitectures to confirm that, though that's a real pain due to lack of one single reference resource for this information. I also used for this support feature: |
|
This is my raw working code with Product IDs. Needless to say, it would be a lot easier to get this data if per microarchitecture product IDs > microarch tables or whatever were available. These are based on the data in the 515 driver readme. Because I have to use manually generated regex to get each microarch using the data on the nvidia wikipedia pages, I probably missed some product IDs. I honestly scratch my head and wonder why multibillion dollar tech companies can't publish such information in a clear format, it would cost them probably a few hundred dollars max to do it. But nvidia publishes better than most, so there is that. I'm debating adding latest supported driver, but given inxi tends to get stuck in frozen pool distros, the data will get out of date fairly quickly for everything except official legacy releases. And the product ID matches will not include newer card IDs, but it's an ok start, it will cover most users for now. The legacy driver data is generated in a different way for now. This data and code is running live now in pinxi, and creates output like this: Here's the product/pci IDs, so far. I probably missed a few in the regex parsing. [updated 2022-05-15 with parser tool] If I missed a pci/product ID in any microarch let me know the product name string so I can add it to the regex pattern, then update my list of product IDs. |
|
We detect architectures at runtime by reading the PMC_BOOT_0 and comparing the architecture bits with these values (there's also individual implementation constants below). We currently don't have a handy offline reference table to translate device IDs to architectures, but it certainly sounds like a good thing to publish. We do have a list of all published products and their IDs, from which such a list could be constructed: g_nv_name_released.h |
|
That method would be preferred, but this is Perl, so unless it's available in /sys or something like that I couldn't use it, but a real dynamic detection is obviously far superior to a product/pci id detection, which will always miss stuff, and be more difficult to update. I'll poke around in some nvidia user datasets and see if those architecture bits are exposed anywhere that is readable. Given how important knowing your card microarchitecture is beccming, simply adding one more column to your otherwise exceptionally well done product name/id files created with each new driver would really be all it takes, those are relatively easy to parse, that's what I'm using, but it's very difficult combining the wikipedia data directly in with that data because many product names and series are actually different architectures depending on various situations. The wikipedia pages don't have product ids, and are also vastly varying in quality and completeness depending on microarchitecture, they were clearly generated by different people with different ideas of what constitutes consistent data, so not ideal. I'm going to convert my shell filters to perl today to make it easier to build up these lists, until ideally they get published in a more reliable format for 71 > 470 legacy and 515 > product id lists. Note that is quite literally just adding one more table column to the published html tables, which should not take more than an hour or two to do, it only took me as an outsider having to merge data and no access to internal resources a few hours. Note that one very strange thing in the wikipedia data is that a page for say kepler will show the product code for fermi or something, a few mixed in, at which point it's hard to know if they made a mistake, or some codes are not actually referring to the microarch names even though they are clearly meant to like TU, GV, GA, and so on. I haven't found any docs for Tegra anywhere so far unless I'm missing it, I see by the header file that is a different category altogether, but one thing at a time. For now, I'll whip up a perl script to make this more fool proof and repeatable to generate the per arch. id lists, which will make it easy if in the future those arch. are added to the existing html tables, or json data sources, or whatever. I believe these changes will already cover most nvidia users in Linux however, it's just labor intensive to maintain it over time, not ideal. |
|
I've updated the IDs above if they are useful to anyone, those will be going live fairly soon, just need to work out a few last details. Made a Perl tool to do the parsing, that works much better, and is easier to adjust and tweak. This output is designed to copy/paste directly into inxi data structures, but should be easy for anyone to use / modify, at least until something better shows up. I'm adding in Fahrenheit > Ampere microarchitectures, though I believe the Tesla IDs are going be off, maybe also the Curie ones, but those are not well documented and are confusing to figure out. I might use the new tool at least to lock down Fermi/Kepler IDs as well, I'll see. |
|
A subsequent release will include a list of compatible GPUs in the README.md. Self assigning. |
|
Make sure any such list is at some level machine parseable, otheriwise it just moves the problem a bit. Tab separated columns, for instance, not space. That's the only reason your driver release supported products info html pages are usable as data sources. |
|
@smxi, for a machine-parseable format, please see the 'kernelopen' token in supported-gpus/supported-gpus.json of NVIDIA-Linux-x86_64-515.48.07.run and later. I'm going to mark this Issue fixed:
|
|
Thanks for that one, your current HTML tables are actually fine to parse, I'm done with all the backend stuff to make updates fairly trivial in the future. But I'll check that one out, though it requires downloading and extracting the driver package, then grabbing the file, which is actually a lot more work than the method I'm using, but I'll take a look at it, thanks. All the tools are now released as free software, in the inxi-perl branch of inxi, in the tools directory. Note that inxi is out now and is showing nvidia gpu architectures, and next inxi , which ships in a day or two, unless a bug shows up, will even it out, and also show Intel and AMD gpu architecture data. Most of the work involved with this stuff is actually more in the research area than the data sources, your HTML tables have always been useful to me in terms of updating support pci ids. Note that downloading a 344 MiB data file to grab one tiny text file is not very efficient.... and almost 1 TiB extracted, lol... I'm hoping progress is fast for the free driver codebase, will be interesting to watch, you've always been very fast in the past, guess it will depend on factors, some of which are probably not under your control, like licensed code etc. |
|
Just on a technical level, speaking as someone who did gnu/linux nvidia installers for far too long, since around 2008, this data is actually needed before the driver run package is downloaded, not after, since it does no good to know your card is legacy after you've downloaded the full latest driver. My stuff always automated all of this of course so it was transparent to the user. But this json source file should help people who are still interested in making installers since it can be fed into the actual installer that determines which run package to download and install the driver with. I would not have made the json data file this way by the way, it should be similar to your HTML data tables: "legacybranch":"340.xx" {supported 340.xx devices}, that is, it should be multidimensional, not flat, otherwise it's hard to get the data out of it. Your HTML tables did it well in that regard. Yes, you can loop through it, and rebuild it into a better data structure before using it, but why? I guess it makes sense if you're assuming someone is looping through it to find a pci ID, though that's not very efficient, it's far better to extract the PCI ids per legacy type, and simply match the user's pci id against those until you find a match, then you know which driver to use, for installers. inxi does more than that though, so it's more granular, and is broken down into microarchitectures per legacy, or current, levels, plus the legacy driver info too. This would be more useful if it were also added as a downloadable resource somewhere, like the way you can click to see the supported products HTML table page if you know how to find it, that same appendix could have a link to this json file as well. I'm sure there are some people who would benefit from this. I doubt I'd download the latest driver every time myself just to get this file, that's kind of overkill. The kernelopen 'feature' I assume means it's a turing or ampere microarchitecture? I may add a json parser tool to the nvidia logic, but not unless it actually has data the table doesn't have, but this should help some people I think. A 'microarch' field name: value would have been nice since that can be a pain to dig up the data on, but I've done that work mostly so from my side it's largely completed, albeit probably has an error or two in the data, but it's good enough. kernelopen is the one bit of data that the json file contains that the HTML tables don't, unless they've been updated, so it might be worth adding this, I'll see.
Kudos for thinking this one through, though having to download that much binary data to get one single file is not ideal, I wouldn't do it myself as a rule, unless the data added value somehow. The copyright date is out of date, by the way, should be 2022, since that's when this file was released. |
|
Yes, the "kernelopen" feature indicates that the GPU has GSP and therefore can be driven by the open kernel modules. I.e., is >= Turing. Note that supported-gpus.json has been present in the .run file for several years; it is only the "kernelopen" feature that is new in 515.48.07. |
|
Thanks for clarifying. So there's no actual new data in there beyond what I have working already, that's good to know. I don't generally download and look inside the run packages for the drivers, so I would never have found this one, but your HTML tables I think are actually easier to work with as data anyway. These json files could be a lot more data rich, but in general, nvidia does the best job of releasing this type of practical and useful data, so it's more wishing it were more rich than anything else, the research to find the data that most of the devs inside nvidia probably know off the top of their heads, or have ready access to, is really tedious and time consuming, but again, nvidia does a better job of it than intel or amd, so your overall efforts are appreciated anyway. Hoping you can make good progress on the desktop gpu gsp open kernel modules, will be curious to see how long it will take to pull them to beta state at least. But given the gigantic size of the current driver it's probably not going to be something we'll see a full stack free driver for anytime soon, if ever, but still one step at a time. |
There is no bleedingly obvious list of what GPU models this driver does and does not support. It's of course safe to assume that this driver supports all of the latest GPUs and at least a generation back, but beyond that it's difficult to ascertain whether you're in the green here. I know that the proprietary driver fairly regularly drops support for older cards. What options are available for folks that have said older cards?
Please provide a clear list of GPUs are that supported by this driver, thanks.
The text was updated successfully, but these errors were encountered: