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

[Jani Nikula <jani.nikula@intel.com>]

On Thu, 23 May 2024, Mauro Carvalho Chehab <mauro.chehab@linux.intel.com> wrote:
> On Thu, 23 May 2024 10:30:37 +0300
> Jani Nikula <jani.nikula@intel.com> wrote:
>
>> On Wed, 22 May 2024, Kamil Konieczny <kamil.konieczny@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.

>> 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.


>
> Regards,
> Mauro

-- 
Jani Nikula, Intel