Add auto-detection for Intel GPUs

[guangyey]

Summary

This PR intends to enable --torch-backend=auto to detect Intel GPUs automatically:

• On Linux, detection is performed using the lspci command via Display controller id.
• On Windows, detection is done via a powershell query to Win32_VideoController. Skip support for now—revisit once a better solution is available.

Currently, Intel GPUs (XPU) do not rely on specific driver or toolkit versions to distribute different PyTorch wheels.

Test Plan

On Linux:

On Windows:

[konstin]

Do we need to spawn a std::process::Command to check this or is there e.g. a file we could read that has the same information?

[guangyey]

Do we need to spawn a std::process::Command to check this or is there e.g. a file we could read that has the same information?

OK, I will try it.

[konstin]

If you have links to websites (e.g. from Intel) about how to detect these cards, please share them, it helps with reviewing this code.

[guangyey]

Do we need to spawn a std::process::Command to check this or is there e.g. a file we could read that has the same information?

At the moment, we lack a stable and consistent method to retrieve Intel driver or GPU details from a file. So I intend to use system calls to keep the approach stable across platforms. May I know if it is reasonable and acceptable to you @konstin @charliermarsh

[geofft]

Overall adding this detection seems good, but I agree with avoiding the subprocess.

On the Linux side, you can do this by using sysfs (which is what lspci is going to do anyway), here's some very rough Python for it that I'll let someone else convert to Rust 😄:

import pathlib

PCI_BASE_CLASS_MASK = 0xff0000
PCI_BASE_CLASS_DISPLAY = 0x030000
PCI_VENDOR_ID_INTEL = 0x8086

def has_intel_graphics():
    try:
        for device in pathlib.Path("/sys/bus/pci/devices").iterdir():
            try:
                pci_class = int((device / "class").read_text(), 16)
                vendor = int((device / "vendor").read_text(), 16)
            except IOError:
                continue # maybe log something?
            if (pci_class & PCI_BASE_CLASS_MASK == PCI_BASE_CLASS_DISPLAY) and (vendor == PCI_VENDOR_ID_INTEL):
                return True
    except IOError:
        pass # maybe log something?
    return False

The Windows side looks like it's using WMI and I would expect there's an equivalent API approach for this, too, to save the subprocess.

Maybe the pci-info crate is helpful? It claims to be cross platform and probably looking at PCI is correct on Windows too?

(If we absolutely must go with lspci, let's use lspci -m -n -d 8086::03xx to get machine-parseable output and have lspci do the filtering, instead of using a shell and grep. Among other things, the current code matches the word "Intelligent" which shows up in various non-Intel product names in the PCI DB.)

[geofft]

Also - should we be trying to do something to detect whether we have an Intel GPU actually capable of interesting GPGPU work? I assume a lot of users will have a very boring Intel integrated GPU, and this change as written will switch them to the XPU download instead of the CPU one because we'll see an Intel-brand display device. Will they actually benefit from the XPU download?

I saw that WMI has some info on whether "accelerators" are present, is it worth trying to parse that? Or should we look for whether /dev/dri*/render is present and accessible to the current user? Or should we compare against the list of PCI device IDs at https://dgpu-docs.intel.com/devices/hardware-table.html?

[geofft]

OK, from a bit of very quick poking - I think the only useful info WMI gives us is the (human-readable) device name and a parseable string with PCI vendor/device IDs. So if we want to avoid string-matching Intel, we might as well look at PCI info... can we try using the pci-info crate?

(It appears that pci-info has two backends for Windows, "SetupAPI" and WMI. I don't know what the benefits of each are, but WMI is an optional crate feature and not used by default so I assume it's a heavier-weight dependency. In either case let's keep an eye on performance and binary size.)

By the way, what's a good way to test this? Intel Tiber AI Cloud? (AWS/Google/etc. don't have Intel GPUs, do they?)

[guangyey]

BTW, the windows CI failure is irrelevant to this PR, right?

[guangyey]

BTW, the windows CI failure is irrelevant to this PR, right?

I forgot to update Cargo.lock, which caused the Clippy check to fail on Windows. Rust is smart enough to catch it — I'm really starting to love this language!

[geofft]

OK, this seems fine to me, at least on the Linux side - I'd appreciate if someone else can form an opinion on the Windows side on e.g. whether we can assume it's safe to run powershell, but the logic seems plausible there too.

Thanks for the updates and for contributing this!

[charliermarsh]

Is it important that we support this on Windows for now? I’m hesitant to merge code that relies on a PowerShell invocation.

[guangyey]

@charliermarsh @geofft I completely understand your concerns regarding Windows. You're absolutely right — relying on shellpower doesn’t seem like an elegant or robust solution, and it's reasonable that we shouldn't put that burden on uv. Respecting your perspective, I agree that for now we should limit Intel GPU auto-detection to Linux only, and revisit Windows support once we have a cleaner and more reliable approach. Do you think this is reasonable?

Removed the code for Windows support and highlighted the limitation on the docs.

[charliermarsh]

Is this different than using fs::read_dir, since we're only going one depth?

[charliermarsh]

(Apart from this, the rest of the change looks good and I'm happy to merge once resolved.)

[guangyey]

CI clippy told me fs::read_dir is disallowed in uv, please refer to

uv/clippy.toml

Lines 21 to 29 in 5e2dc5a

	disallowed-methods = [
	"std::fs::canonicalize",
	"std::fs::copy",
	"std::fs::create_dir",
	"std::fs::create_dir_all",
	"std::fs::hard_link",
	"std::fs::metadata",
	"std::fs::read",
	"std::fs::read_dir",

[charliermarsh]

Ohh, it wants you to use fs_err::read_dir.

[guangyey]

@charliermarsh Thanks for the suggestion! I’ve switched to using fs_err::read_dir as recommended. Both the CI and local checks now pass.

[charliermarsh]

Thank you!

[guangyey]

Happy to help. Thanks for your review and feedback.