I think that's right? I have gen3 being 910/915G, GMA 900, and gen3.5 being 945/946G, GMA 950

Also, I've added a slight future proofing fallback, for the latest gpu types that there are no pci ids for, pinxi wil use the same pattern I use in ids.pl to generate the ids, but only in the case of the very latest where pci id resources don't have any name + id sets for those yet.

That's intel gen 12.5, 12.7, the new standalone gpus, also for datacenters, and nvidia hopper/lovelace, which nvidia has not published any pci id/name sets for yet.

Once I get ids, I'll remove the pattern checks, which ideally should mean I only really have to update this roughly as often as I update the cpu microarch stuff, now and then when I remember, or to fix failed matches. CPU arch is easier though because I get family/model/stepping to match against, then it's only the very very newest that don't have this on cpu-world.com yet that I can't match.

Note that Zen 3+ and maybe zen 4 are now matching, or may be, though cpu-world.com wasn't sure about the zen 3+ ids, and the zen 4 only had the first major part, like 7x, but that's enough to ID them.

I can access the kernel config but have no power as no longer a member of forum to change config
but if interested, I did a private update to libcpuid built in 2016 to v 0.5.1

and running provide 2 text file and full output of report.txt below

from post 21 cpuinfo...we have
cpu family : 23
model : 24
model name : AMD Ryzen 3 3200G with Radeon Vega Graphics

from this post report.txt.. we have
ext_family : 23 (17h)
ext_model : 24 (18h)
brand_str : `AMD Ryzen 3 3200G with Radeon Vega Graphics

IMHO ...for AMD users, you could include EITHER cat /proc/cpuinfo or dependency of libcpuid, have pinxi run cpuid_tool and grep report.txt?

hi h2-1,

Here is the output from the 852/855 laptop.

It's a wonderful tool. Thanks.

1 members found this post helpful.

aus9, can't use c libraries in pinxi, but I actually prefer how they do the hex numbers, I have inxi when it shows hex as 0x, but they have XXh, which looks nicer.

cpuid_tool isn't a standard installed tool, I try to avoid adding stuff for things that aren't standard, with some exceptions. Not probably worth taking the time there.

Why don't you package the stuff for tinycore? If you have the inclination or whatever.

I've refactored the core logic a bit to get rid of some redundant or repetitive code, seems to all be working now again.

Seems 'ok'.

Regnad Kcin, glad you like it, always nice to hear inxi/pinxi is useful to people.

This is 600+ lines of data, ouch. These graphics features really eat up lines of code, the EDID stuff was about the same in the end too.

Well I can't resist testing this newer version out. This is from my desktop, it is not specifically what you are looking for (Intel, AMD) but the details are awesome. I do indeed have a legacy card with EOL this year. Pretty cool. I have an Intel laptop and will post that later (laptop is not with me right now). What is different from previous post of the computer is I am using nouveau vice the NVIDIA drivers

Oh, that's a good one. I couldn't think of any terse way to express it, but _some_ of those mobile gpus were 40 nm, the rest, and desktops, are 28nm, if I remember right. Or was it the other way around? Anyway, I think that's the only one that uses that xx/yynm syntax.

For nvidia I do agree with an earlier post, for at least these later series, the code: item is not that useful. Some types don't have codes that I could discover, so 'code:' is probably the least useful feature in --gpu, the rest is actually kind of nice to know at a glance. I checked some of the nvidia data files and it appears that only appears in that similar format on later series as a rule, unless it's something that lspci adds, which is possible, I don't know.

graphics is getting really long, sigh... but that's why I stuck some of it in --gpu, that means you want to see it, otherwise nothing except -v8 will trigger --edid and --gpu.

I hope I did the tools and docs right so that this feature is maintainable over time, these manual lookup tables are a pain over time to keep up to date, so I tried to make it as smooth as possible with the backend stuff.

Hi "h2-1",

I have done a little reading, and it appears to me Intel had these video controllers:
Intel GMA 4500
Intel GMA X4500
Intel GMA X4500HD
Intel GMA 4500MHD
Intel GMA X4700MHD
As far as I can tell, the "X" in the model name just meant the controller ran faster. What do you think?

I gather the G45 chipset in my computer actually has the "X4500HD" variety (not what I wrote earlier).

According to my new understanding, these Intel 4500/4700 video controllers (physically located in the chipset) were the last of the so-called "Gen4" --- and "Gen5" began with the "Intel HD Graphics" (physically located in the processor-package (adjacent to the core-chip)) (2010/Jan, in Clarkdale and Arrandale processors).

I see the pinxi output says "Gen5"; do you think it should say "Gen4"?
Why does the pinxi output say "Intel 4 Series Integrated Graphics", instead of something like "Intel GMA X4500HD"?

baumei, good questions.

https://www.techpowerup.com/gpu-specs/gma-x4500.c3116

As you can see there, clearly gen 5.

Generation
GMA Graphics-M
(GMA 4700M IGP)

Gen5 is: GMA X?4[57]00

https://www.techpowerup.com/gpu-spec...ort=generation

Gen 4 is:
https://www.techpowerup.com/gpu-spec...ort=generation
GMA [X]?3[01]00

PowerVR SGX545 is:
GMA 3600/D2xxx/N2xxx/Cedarview

I will need to add some notes, X means fast, E means Embedded gpu, N and D mean an Atom device, and P may also mean an Atom device but I only have one example of this. Atom also uses the Z.

I'm also adding these more specific things to tools/ids.pl since it's impossible to remember these things.

I reran the intel ids generation and no changes occurred with the tightened rules.

The HD Graphics series started at 5.75. Yes, Intel numbering is clinically insane.

https://www.techpowerup.com/gpu-spec...ort=generation

Obviously, one can ask, why wasn't this gen 6? why the absurd gen 5.75?

I was pleased to find this 2006 article about the insanity of how Intel does their versioning, this one was about CPUs, but they have the same issues with their GPU generations. I follow something I learned long ago from a programming teacher, sloppy output formatting often reflects sloppy internal coding, and to me, these failures to create simple coherent generation/family/model planning and data reflect larger issues at Intel, which finally manifested in public with their "hyper threading" security disasters and their failures to adapt and deliver next gen CPU process nodes. What struck me about this, as an aside, is that even when Intel had the chance to finally stop using CPU family 6 with Alder Lake, they kept using it, even though they are going to run out of hex IDs for family 6 at some point.

https://www.pagetable.com/?p=18

Re NVIDIA FOSS kernel driver
As an aside, I've read some critics of Nvidia's open sourcing of the Turing/Ampere kernel module, as if Nvidia can deliver a 100% production ready desktop foss kernel driver instantly, without any problems of kernel module code that can't be instantly published open source, something that took AMD almost 10 years to do, but I've watched nvidia's ability to adapt for over 10 years via my sgfxi tool, and I have very little doubt that they will take MUCH less time to deliver their beta level kernel driver, and I would not be surprised at all if they manage to ship a final stable foss turing/ampere kernel driver within 12 months based on the speed I've seen them show over years when adapting to kernel changes.

I would not personally even pay any attention to this in terms of being impatient until at least 12 months have passed, that's when we'll be able to see roughly how nvidia is handling this process for real. Keep in mind also, this wasn't done because of consumer linux (can't be more than 1% max of their consumer market), and even less so because of consumer bsd, which is essentially zero percent now of their consumer market. No, this was done because both Intel and AMD are shipping data center gpu processors now, AMD with their CDNA series, and Intel with their new standalone cards, and both those are shipping with free Linux drivers out of the box.

This is all about taking care of their roughly 30+% percent total gross sales to mainly Linux datacenter gpu centers, like Tesla's, which currently has several billion dollars worth of latest generation nvidia machine learning gpus, I think the Ampere A100 series. and the new Hopper H100 series, both of which already are supported by the free kernel driver fully, no beta, they work. This was done in conjunction with Redhat, due to demand from their customers for free kernel drivers that can be shipped by Redhat and other vendors together with the Kernel.

I view this as a great moment, sure, Nvidia did it to service their real datacenter gpu linux market, not desktop users, but now it's just a matter of moving more code into the kernel gpu driver, or into the non free userland driver, and changing long standing internal work flows that were always aimed at supporting specific kernels, to something that can one day ideally be merged with the linux kernel, or at least, be built via dkms to new kernels without failing, so this will be interesting to watch, obviously will not happen overnight, and only time will tell if they make the move to full kernel integration, which requires corresponding free userland drivers.

Call me cynical, but I expect Linus and company to do what the big users want, so if they want the kernel only free driver as a native Linux kernel module driver, that's what we'll get in not too long I believe. Whether Nvidia can even open their userspace driver pieces is unknown to us since we don't know the license states of that codebase, maybe they have to rewrite or rearchitect big chunks to make it foss compatible. Right now they are following their old workflow, which is delivering drivers tested for specific frozen pool distro kernels, like redhat RHEL, but that's not viable long term, but it's a good way to start.

A lot of critics I read, particularly in places like lwn.net where you expect the users to know better, seemed to believe Nvidia is doing this mainly for desktop users, and the fact they don't work perfectly out of the box somehow indicates something at all beyond it's a second priority which will be addressed over the coming years.

If I were to make a very educated guess, I'd guess that the next nvidia legacy driver will slice off Maxwell, Pascal, and Volta microarchitectures (since that hardware does not support what the foss driver needs, and only if they can backport the fossed parts would pascal, or even maybe kepler, be supported), and that legacy driver, which will be 5.15 or newer, will be the last to not support quite decent foss nvidia kernel driver code. Given how fast good programmers can work, and in particular, how likely it is the linux kernel guys are going to bend over backwards to get nvidia into mainline kernel in terms of helping in the process, I would not be at all surprised if the current ampere/turing/hopper/lovelace driver will be quite close to working in quality at least beta mode.

Keep in mind, if memory serves me, AMD basically just tossed their code to the foss developers after releasing their hardware specs, which slowed stuff way down, and amd never had very good programmers from what I saw over the years. I'd guess however that AMD has pulled this back in house now that they entered the server gpu market since there is now actually money involved. I've seen how fast projects can work when they are motivated, it only took under a month for the OpenBSD guys to ship their first libressl after the openssl debacle, for example.

1 members found this post helpful.

Hi "h2-1",

After a little more reading on my part, I think TechPowerUp is correct about "GMA X?4[57]00" being Gen5 (and what I was previously reading is wrong).

I have a guess. Perhaps the video chip (marketed as "Intel HD Graphics") which Intel put in the Clarkdale processor is a slightly modified version of the X4500HD chip Intel put in the G45 chipset?

Yes, that's a good guess I'd say. After using way too many resources, and reading way too many pages of specs, my conclusion is, each place, cpu-world.com, wikichip, wikipedia, and techpowerup, are good at certain things, but only techpowerup is good at gpu stuff, one thing that really threw me off was following the roadmap of wikichip for the generations.

But techpowerup has a real bug in their database design, where you have to click on many many products to randomly find listed in the results boxes a block of generation data for that type, but that data is not even consistent, for example, I had looked at probably 20-40 results pages and never seen the PowerVR SGX535/PowerVR SGX545 generations even listed. In other words, rather than using a correctly designed database, it looks to me like each product is entered using static data about various bits of information, and sometimes they don't even show things like the generations box, sometimes a subset of the generations, it was only later in the process that I realized I had been using a subset of the generations, which is what led to my confusion initially.

But techpowerup I would trust for AMD/Intel data more than anyone else, they seem obsessed by the stuff, which is a good thing when it comes to arcane questions like this. Their weakness is also due to their initial database design errors, the very early generation amd/intel gpus have very poor linking to later added data, so early generation stuff is weak at best, and sometimes almost totally missing, but not completely, they for example have data on the i740 generation, which appears to be the actual first generation, except it has a product number > than gen1, sigh...

Nvidia is best in class when it comes to actually publishing usable data, the only thing they do not publish on is the actual microarchitectures each gpu product id is, but that's pretty easy to look up on techpowerup.

I had my doubts whether the intel stuff could be locked down, but it appears that with some nearly perfect samples here, which invariably seemed to be from the most problematic ID cases, most of the issues are worked out now for Intel.

Intel and Nvidia now also have very latest generation matches running so currently unsupported gpus will ideally get matched, until I can get the pci ids. Data center pci ids unless nvidia are hard to find because you don't see them on the big pci id lists in general, but objectively, how many people are running datacenter gpus and inxi? lol... but still it's nice to be complete.

I've been working on the long term maintainability of this feature, I'm fairly happy with how it's turning out, much better, more debuggable, and much better output for really checking the detections in real time.

I still find it difficult to understand that multibillion dollar tech companies can't take the few hours it would take them to publish simple tables that collate all this data into one place, it's literally something an intern could do in a day or two max, then maintain at each new product release, it's totally trivial to make those tables if you have access to the internal data. I've nudged nvidia about this but their 'solution' was kind of pathetic and anemic, it's like they just don't get the concept that it's ok to publish actual information about your generations and stuff in ways that are usable for people who need them. With Intel, I think the issue may be too big corporation, too many vps needed to approve doing something trivial like this, so it never happens, and with nvidia, I think it's just because nobody thinks it's an interesting problem, and at amd, I think nobody cares.

I can say this, wikichip and wikipedia are significantly out of date, the pci id lists are out of date, even nvidia doesn't have product ids for their hopper or lovelace cards shipping I think now, or about to ship.

hi h2-1,

I'll see if I have the hardware upgrade books in storage still. There was a chip before the I740
based off Chips and Tech, I believe. that was never mass produced/released.

I still have an I-740 8mb AGP card ... will have to see if my old p-2 can boot
modern linux for a printout of it on your program. What flags are best for the
output to post on these?

I was just going by what you posted as flags. Would a full "-zv8" help
with any of the other chip ID?

If it runs, pinxi --gpu -CMz. Actually for my real curiosity, though it will take a while to execute, pinxi -zv8 to see what inxi gets off that system. -v8 triggers --edid and --gpu. Did someone last time get a P2 running? if so, I think I remember it took like a minute or more for pinxi to execute, but it did work, but P2 might be pushing it. Certainly interested to see what pinxi can get, to me, really old hardware is the real test for inxi/pinxi.

Remember that has to have Perl version 5.008/aka 5.8 or newer.

machine -M just for my own curiosity.

This is making my deciding some years back to prune my old agp card collection way down seem like not the best idea, but objectively, I don't think I have an agp motherboard running anymore, maybe i have one, not sure, but I've been getting rid of that generation, no room.

i740 is an odd one, I think techpowerup might have gotten that one slightly wrong, but it's really hard to say, they have that generation listed as right after gen1, but gen 1 is i750 and newer, but nobody else even lists i740 as its own generation besides techpowerup, but they were right on the gpu stuff more than anyone else.

i740 generation had only 1 iteration, 1998, gen 1 was around several years, 1998 into the 2000s. It's also possible because the i740 product id i have is > the gen 1 product IDs that intel just did an odd concurrent type release, like maybe releasing i740 just after i750, but who knows?

I'm going to guess that nobody really knew video cards would be a 'thing', so it was only after i740 that intel realized these things would have generations, and actually continue to exist.