[PATCH i-g-t v4] tools/mk_detect_intel_gpu: add a tool to detect Intel GPUs from their PCI IDs

[Kamil Konieczny]

Hi Jani,
On 2024-05-23 at 12:10:05 +0300, Jani Nikula wrote:
> On Thu, 23 May 2024, Mauro Carvalho Chehab <mauro.chehab at linux.intel.com> wrote:
> > On Thu, 23 May 2024 10:30:37 +0300
> > Jani Nikula <jani.nikula at intel.com> wrote:
> >
> >> On Wed, 22 May 2024, Kamil Konieczny <kamil.konieczny at linux.intel.com> wrote:
> >> > Looks like a good idea but this is also dependancy, btw  
> >> 
> >> [snip]
> >> 
> >> > But this one is creating one more dependancy, one should have
> >> > modules compiled in current running kernel.  
> >> 
> >> Reading the comments about dependencies, I think this needs a different
> >> perspective.
> >> 
> >> What is the target audience of the tool? What are they expected to have
> >> around? What is the easiest for them to install?
> >
> > The target audience for the submitted changeset is to provide a way for
> > IGT developers to generate a script to detect the presence and the GPU
> > model for Device Under Test (DUT) machines.
> >
> > It was written to be generic enough to use different directories for Xe
> > and for i915 (or the same one). So, it should work properly when different
> > versions of the drivers would be used, during driver's development.
> >
> > On other words, the way it is, this is not focused on the end user. 
> >
> > The way it works is that a C file read the i915 and Xe macros, creating
> > a PCI ID database, stored as hash(dict):
> >
> > 	my %intel_pci_id = (
> > 		"8086:46d0" => "ADLN",
> > 		"8086:46d1" => "ADLN",
> > 		"8086:46d2" => "ADLN",
> > 		...
> > 	)
> > 	...
> > 	my %intel_pci_id_alt_name = (
> > 		# AML_CFL_GT2 alternative names
> > 		"8086:87ca" => "CFL",
> >
> > 		# AML_KBL_GT2 alternative names
> > 		"8086:591c" => "KBL",
> > 		"8086:87c0" => "KBL",
> > 		...
> > 	)
> >
> > 	Typically, most GPUs have two entries:
> >
> > 	$ grep 8086:9b41 ./intel_detect_gpu.pl
> > 		"8086:9b41" => "CFL",
> > 		"8086:9b41" => "CML_U_GT2",
> >
> > 	The first one is the generic name, the second one contains
> > 	an alternate name, with has additional GPU version details
> > 	(in this case, CML-U GT2). All of that obtained from the
> > 	driver's source code.
> >
> > The generated script itself doesn't require anything other than lspci to
> > run, as what the script does, on its 35 lines of code (not including the
> > PCI ID database), is:
> >
> > 	1. run lspci -nm
> >
> > 	2. If the PCI ID device is at the database, it prints:
> >
> > 		print "Detected GPU PCI device: $id$subtype, PCI ID: $pci_id\n";
> >
> > 	   For the above example, the output is:
> >
> > 		Detected GPU PCI device: CFL (CML_U_GT2), PCI ID: 8086:9b41
> >
> > 	3. If multiple Intel GPUs are found, it prints a warning, as DUT
> > 	   tests may require an extra parameter to use the right GPU:
> >
> > 		Warning: More than one Intel GPUs detected
> >
> > 	4. if no Intel GPU is found, it will print:
> >
> > 		Warning: No Intel GPUs detected
> 
> The way I see it, intel_device_info.c and igt_device_scan.c have all the
> building blocks necessary to accomplish this. As long as
> intel_device_match[] is kept up-to-date, which naturally will be, it
> needs no further maintenance. It could be added to lsgpu as an option.
> 

Yes it would be helpfull.

> >> lspci and modinfo are trivial to install, and most people have them
> >> installed already. modinfo does not require the modules to be probed,
> >> you can also point it at the .ko under /usr/lib/modules. For a user,
> >> this gives information about the modules they actually have on their
> >> system, which may be different from kernel or igt sources.
> >
> > Once generated, intel_detect_gpu.pl would be trivial to install and
> > to be used, as the only requirements are to have perl and pci-tools
> > (due to lspci dependency) installed.
> >
> >> OTOH most people won't have kernel or igt sources available. (Let alone
> >> specific versions of the source, which match the expectations of the
> >> patch at hand.) Indeed, you can install igt via the distro package
> >> manager, with no need to check out the sources.
> >
> > If IGT maintainers think it is worth targeting end users in the future,
> > the best is for them to periodically generate the script (for example,
> > when releasing a new IGT version), adding it to scripts/ and adding a
> > target at Meson to install it under ${installprefix}/bin directory.
> 
> The best is what I described above, not adding Rube Goldberg machines
> that require constant attention.
> 
> BR,
> Jani.

Maybe this should/may be added to scripts?
I do find it usefull to have a little script checks,
without much dependancy on other libs/tools. I would
also want to have a way to semi-automatically update
it later on, where new devices will be added.

Regards,
Kamil

> 
> 
> >
> > Regards,
> > Mauro
> 
> -- 
> Jani Nikula, Intel