Add Intel Arc GPU support on Linux

[elyerinfox]

Reading the room here, this is probably one of the most absurd PRs that an individual could possibly open on this repository.
As an outsider, I clearly don't know the relationship between NVIDIA and Intel at present, but given that this project has already started integrating other ecosystems such as MacOS I figured it was worth a shot.

Anyways.... The goal is on the tin.

Description

This PR aims to start adding support for Intel ARC graphics cards into this project. The rationale is....ARC cards are cheap memory and they're surprisingly capable, probably not economical given this isn't anything with HMB, but if you have a handful of these cards like me just kicking around then this is probably for you.

Scope

In:

• Intel Arc / Xe detection on Linux (xpu-smi, DRM ioctl, sysfs), dynamic VRAM-used sampling, tests, docs, version bump.

Out:

• Intel utilization without xpu-smi (i915 has no stable busy-percent counter under DRM — a follow-up would need PMU/perf events). AMD dGPU detection.
• Xe driver's newer DRM_IOCTL_XE_DEVICE_QUERY (i915 covers every currently shipping Arc).

Validation

• Was able to add to cluster via TUI
• Tested output generation on an actual machine with 3 ARC cards.
• Live smoke test on a Linux host with three Arc GPUs and no xpu-smi:

cd services/nvpair-node-info
go build ./...              # clean
go vet ./...                # clean
go test -race -count=1 ./... # ok  nvpair-node-info  1.053s (50 tests)

curl -s http://127.0.0.1:14318/v1/node-info | jq '.GPUs'

[
    { "name": "DG2 [Arc A380]", "vram_bytes": 6383730688, "vram_used_bytes": 18210816 },
    { "name": "DG2 [Arc A310]", "vram_bytes": 4244635648, "vram_used_bytes": 18210816 },
    { "name": "DG2 [Arc A750]", "vram_bytes": 8522825728, "vram_used_bytes": 18210816 }
]

Risk

• Unknown, tests cover the JSON parsers (both discovery and dump), BDF normalization, virtual-function filtering, and the number-tolerant column decoding.
• The DRM ioctl requires read access to /dev/dri/renderD* (group render, unprivileged).
• A lot of the detection code was sourced from my personal projects, in combination with LLM generated output. It has been tested by hand and is susceptible to error as any other piece of code would otherwise have. If maintainers would much rather close it for this issue alone despite reading the developer certificate of origin, I understand - however I am attesting to some moderate expertise in the field.

Checklist

• I have read the Contributing Guidelines.
• Every commit is signed off (git commit -s), certifying the Developer Certificate of Origin.
• New or existing tests cover the change.
• Relevant documentation is updated.
• I checked the diff, changed filenames, and commit messages for credentials, private data, internal URLs, internal issue identifiers, and generated artifacts.
• I recorded the validation commands and results above.
• I bumped any affected component in services/versions.json, and described user-visible changes above so they reach the release notes.

[ericcurtin]

@elyerinfox I'd be interested to hear how you things go with that GPU here?

https://github.com/llmmanorg/llmman

[elyerinfox]

@elyerinfox I'd be interested to hear how you things go with that GPU here?

https://github.com/llmmanorg/llmman

Currently on the clock, but I can give it a look at some point in the coming days. Any particular out of the three or just wanting to see how ARC integrates generally?

[ericcurtin]

@elyerinfox I'd be interested to hear how you things go with that GPU here?
https://github.com/llmmanorg/llmman

Currently on the clock, but I can give it a look at some point in the coming days. Any particular out of the three or just wanting to see how ARC integrates generally?

It's supposed to probe and pull the correct version of llama.cpp for your hardware, the order is this:

cuda, rocm, vulkan, cpu

But maybe it should actually be?

cuda, rocm, openvino, vulkan, cpu

But maybe vulkan is more suited and it's ok as is, I don't know?

I don't have the hardware to integrate it and make an informed call.