[deveworld]

Summary

Adds support for Intel GPUs on the Xe kernel driver (Lunar Lake, Battlemage, newer Arc / Arc Pro), which the i915 path can't detect.

Closes #1407

What Changed

• Xe collection path in src/linux/btop_collect.cpp, with multi-GPU discovery and per-device i915/xe routing
• src/linux/xe_drm.h with the Xe UAPI definitions needed for the VRAM query
• RC/MC split graphs for Xe
• src/linux/intel_gpu_top/ is unchanged

Metrics (Xe)

Metric	Source
Utilization	fdinfo drm-cycles-*; gtidle sysfs when no client is visible
Clock	tile0/gt*/freq0/cur_freq
VRAM	DRM_XE_DEVICE_QUERY_MEM_REGIONS, dedicated VRAM only
Power	hwmon energy1_input (card) or energy2_input (package), discrete cards only
Temperature	not implemented

Utilization per engine class is Δcycles / (Δtotal × drm-engine-capacity), and the GPU total is the busiest class, like intel_gpu_top. Counters are kept per drm-client-id, so a client exiting doesn't affect the others. No smoothing.

No root needed. Without access to the render node, VRAM is skipped and the rest still works. SR-IOV VFs have no gtidle, so they show VRAM only.

Performance

The fdinfo scan runs at most every 500 ms on the collector thread: ~25–40 ms per scan on Lunar Lake (Core Ultra 5 228V). Logged at --debug as Xe: fdinfo scan <ms>.

Known limitations

• fdinfo only covers processes btop can read, so unprivileged runs miss other users' clients
• Integrated GPUs have no xe hwmon, so there is no power reading
• Devices missing from the bundled name table show as "Intel GPU"

Testing

• make, CMake + ctest, CMake with -DBTOP_GPU=OFF
• Lunar Lake: render (vkcube) and AV1 encode load, compared against raw fdinfo and nvtop
• Power and multi-engine capacity need a discrete card, so they're untested locally

[Copilot]

Pull request overview

This PR adds support for Intel GPUs using the Xe kernel driver, which is required for newer Intel hardware like Lunar Lake and Battlemage that don't use the legacy i915 driver.

Changes:

• Added minimal xe_drm.h header with UAPI definitions for interfacing with the Xe driver
• Implemented Xe namespace with PMU-based GPU monitoring using perf events
• Added dynamic driver detection and PMU device discovery to support both i915 and Xe drivers
• Routes collection to appropriate code path based on detected driver type

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 14 comments.

File	Description
src/linux/xe_drm.h	New header file containing minimal Xe DRM UAPI definitions (structs and ioctls) for device query and engine enumeration
src/linux/btop_collect.cpp	Added Xe namespace with PMU-based monitoring, dynamic driver detection, PMU device discovery, and routing logic to switch between i915 and Xe code paths

Comments suppressed due to low confidence (1)

src/linux/btop_collect.cpp:2103

• Missing free() call for gpu_path on error path. If get_intel_device_id() returns null, the function returns false without freeing gpu_path that was allocated by find_intel_gpu_dir().

			char *gpu_device_id = get_intel_device_id(gpu_path);
			if (!gpu_device_id) {
				Logger::debug("Failed to find Intel GPU device ID, Intel GPUs will not be detected");
				return false;

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[TheSovietPancakes]

Please do not reformat code if you can

[deveworld]

Please do not reformat code if you can

Thanks for the feedback!
I've restored fmt::format usage and the clang diagnostic pragma.
It should now match the original code style

[TheSovietPancakes]

I was referring to the code style. Please continue using fmt, since this is preferred. But I was referring to things like changing the indentation of completely unrelated code. This makes for a larger diff and can sometimes get your PR rejected outright in some repositories.
(@deckstose Ngl this would be a really great usecase for .clang-format, it's starting to warm up on me 😆)
If you can make one big change to fix Intel, without touching other code, that would be awesome 😄

[MrChuw]

I tested on my B580 sparkle, it works as expected, but I have a suggestion, how about using nvtop if available, the nvtop -i (or -i) option provides an output in json format with memory and power usage and also temperature and more.

Here a example of nvtop output.

[
  {
   "device_name": "Battlemage G21 (Arc B580)",
   "gpu_clock": "1200MHz",
   "mem_clock": null,
   "temp": "54C",
   "fan_speed": "0RPM",
   "power_draw": "43W",
   "gpu_util": "11%",
   "encode_decode": "0%",
   "mem_util": "54%",
   "mem_total": "12809404416",
   "mem_used": "6956257280",
   "mem_free": "5853147136",
   "processes" : [
     {
       "pid": "1",
       "cmdline": "/usr/lib/systemd/systemd --switched-root --system --deserialize=56",
       "kind": "graphic",
       "user": "root",
       "gpu_usage": "0%",
       "gpu_mem_bytes_alloc": null,
       "gpu_mem_usage": null,
       "encode_decode": "0%"
     },
     {
       "pid": "894",
       "cmdline": "/usr/lib/systemd/systemd-logind",
       "kind": "graphic",
       "user": "root",
       "gpu_usage": "0%",
       "gpu_mem_bytes_alloc": null,
       "gpu_mem_usage": null,
       "encode_decode": "0%"
     }
   ]
  }
]

[PrakarshPanwar]

Works well on my both laptops, Tiger Lake-H and Raptor Lake-P iGPUs. No need for sudo access to read GPU stats. When it will be merged?

[deveworld]

Rebased this on current upstream/main, cleaned up the Xe path, and updated the PR description so it matches the code again.

The branch now prefers fdinfo for utilization, keeps gtidle/PMU as fallback, handles drm-engine-capacity-* when available, and only reports actual dedicated VRAM. I also fixed the remaining local Xe build warnings.

I reran make -j4 and cmake -S . -B build-test && cmake --build build-test -j4 && ctest --test-dir build-test --output-on-failure.

The main limitation still left is that unprivileged fdinfo collection can undercount protected clients.

[MrChuw]

latest commit, making the percentage wrong.

[deveworld]

Thanks, @MrChuw

The last Xe fdinfo change was skewing the percentage. I had added drm-engine-capacity-* into the calculation, and that made the reported value too low for cases like the one in your screenshot.

That part is removed, so the latest head should be back to the expected raw fdinfo-style value.

If you get a chance, please try the latest commit again and let me know how it looks.

[MrChuw]

The last commit where the GPU utilization on my B580 was right was 45aa98f

the latest commit still with skewed utilization 922a37e

[aristocratos]

Whats the performance impact of this? (How long does the collection cycle for GPU take when running btop with --debug when using the fdinfo method?)

[deveworld]

about 24-48 ms per scan on Lunar Lake, throttled to once per 500 ms on the collector thread
Added a --debug line (Xe: fdinfo scan ) to measure it on any device

[deveworld]

Rebased and pushed.

@aristocratos, collect_fdinfo_cycles: 110–150 ms -> ~90 ms/sample after 229e6f6 (/proc/*/fd prefilter). FDINFO_SAMPLE_MIN_NS = 500 ms caps calls. Lunar Lake 228V, ~5000 open fds / ~90 drm fds.

@MrChuw, B580 % restored via 8ad127e (per-class max() on drm-total-cycles instead of sum). Other commits fix late-fdinfo RC/MC activation (f1ecf86), gtidle false-100% on short ticks (d244373), plus dead-code / whitespace / style cleanup.

Deferred to a follow-up PR: multi-engine class capacity normalization (Battlemage VCS=2 / DG2 CCS=4 partial-use underreport).

[deveworld]

Force-pushed, rebased onto current main (resolves the merge conflict), squashed to one commit, and integrated with the new AMD Asysfs backend.

New since last review:

• No root / render group needed. The DRM fd is now optional; if it can't be opened, VRAM is skipped but gtidle/fdinfo utilization and clock still work, so the GPU is shown instead of dropped.
• Power for discrete Arc via hwmon. Integrated GPUs expose no GPU power sensor (no hwmon, no PMU energy event), so iGPU power isn't available.
• fdinfo perf: about 24-48 ms/scan on Lunar Lake, throttled to 500 ms; the /proc scan no longer throws on unreadable processes; per-scan time logged at --debug.

Deferred: CCS / multi-engine capacity normalization; i915 still needs PMU permissions.

[temidaradev]

looks accurate so far

[jlfranklin]

Looks good on a Debian/forky system:

CPU: 16-core Intel Core Ultra 7 356H (-MCP-)
speed/min/max: 400/400/4700:3700:3300 MHz Kernel: 7.1.8+deb14.1-amd64 x86_64
Up: 3d 17h 18m Mem: 9.15/15.03 GiB (60.9%) Storage: 476.94 GiB (16.7% used)
Procs: 703 Shell: Bash inxi: 3.3.41

[stolk]

Works.

The usage seems to have a low pass filter on it, though? I hammer it going from 0 to 100 in a fraction of a second, but:

[Boladi888]

I've got a little different problem on my asrock B70 pro 32gb

On my system, btop can see the GPU and utilization, but wattage shows as 0.00W. The sensor itself is not dead though. It looks like power is available, just not in the form the current Xe path is expecting.

System:
0000:03:00.0 VGA compatible controller [0300]: Intel Corporation Battlemage G31 [Intel Graphics] [8086:e223]
kernel: 7.0.0-31-generic
btop: 1.4.6, GPU_SUPPORT=true

The relevant hwmon node looks like this:
/sys/class/hwmon/hwmon7/name: xe
/sys/class/hwmon/hwmon7/energy1_label: card
/sys/class/hwmon/hwmon7/energy1_input:
/sys/class/hwmon/hwmon7/energy2_label: pkg
/sys/class/hwmon/hwmon7/power1_label: card
/sys/class/hwmon/hwmon7/power1_cap: 275000000
/sys/class/hwmon/hwmon7/power1_input: missing
/sys/class/hwmon/hwmon7/power1_average: missing

Sampling energy1_input manually gives a real nonzero value. In one sample I got:
Battlemage card energy delta: 414 J over 2.01 s => 206.33 W

So the practical issue is not that Battlemage has no power data. It is that this card exposes cumulative energy for card, and the current path appears to look only for instantaneous power1_average or power1_input.

Would it make sense for the Xe backend to fall back to deriving watts from energy*_input where energy*_label == card when power1_average and power1_input are absent? Basically sample energy twice, divide by elapsed time, and treat that as the same source of truth. Power is not missing here. It is just wearing the wrong sysfs hat.

For images: include one cropped screenshot of btop showing GPU ... 0.00W, but don’t use the full screenshot unless you’re fine with the visible process list and local IP. I’d also include a terminal screenshot or pasted text showing the hwmon7 files and the manual 206 W energy-delta calculation. That second one is the stronger evidence.

[BBaoVanC]

I just now tested it on Arch Linux with my Intel Core Ultra 325 iGPU, and I don't see VRAM or power usage. On my desktop with an Arc B580, I see VRAM usage fine but it still doesn't show power. nvtop is able to see VRAM on both devices, and power on the B580 (still not on the Panther Lake iGPU, but that might not be btop's fault)

[deveworld]

Rebased onto main.

• Utilization per engine class, normalized by drm-engine-capacity-* and tracked per drm-client-id. No smoothing.
• Power from hwmon energy1_input / energy2_input, which should fix the 0.00W on B70/B580.
• Removed the PMU fallback, which could never run.
• Fixed the panel height index.

A B580/B70 power report would help.