# amdgpu_top for AMD GPU Monitoring in Linux

> amdgpu_top is a Rust-based Linux utility for inspecting AMD GPU utilization through DRM performance counters, sensors, fdinfo, gpu_metrics, and the AMDGPU driver. It provides TUI, GUI, SMI-style, diagnostic, and JSON modes for detailed monitoring.

**Umio-Yasuno/amdgpu_top** — Tool to display AMDGPU usage

- Repository: https://github.com/Umio-Yasuno/amdgpu_top
- Stars: 1,733 · Forks: 63
- Language: Rust
- License: MIT
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/umio-yasuno-amdgpu-top

## What amdgpu_top measures on AMD systems

amdgpu_top is designed for observing activity on AMD GPUs rather than providing a general hardware inventory tool. The README identifies GRBM and GRBM2 performance counters, sensors, fdinfo, gpu_metrics, and the AMDGPU driver as its data sources. The program can report GPU information including specifications, VRAM, PCI data, ResizableBAR, VBIOS, and video capabilities. It also exposes per-process GPU information through fdinfo.

The information is more detailed than a single utilization percentage. The TUI can toggle GRBM, GRBM2, VRAM and GTT usage, fdinfo, sensors, and GPU Metrics. The documented fdinfo categories include GFX, Compute or COMP, DMA or SDMA, Decode or DEC, Encode or ENC, JPEG, VPE, and the unified VCN categories used from VCN4 onward. This makes the tool useful for diagnosing graphics, compute, media, or memory activity, provided the underlying driver exposes the relevant fields.

The target user is someone working on Linux with an AMDGPU device and needing more than a desktop notification. The README compares the tool's purpose with umr, radeontop, and intel_gpu_top. That comparison concerns monitoring different parts of the graphics stack, not interchangeable vendor support. amdgpu_top is specifically tied to AMDGPU data sources and its documented dynamic library dependencies.

## Data sources and the amdgpu_top measurement model

The central design is a collection of Linux GPU interfaces rather than a single API. According to the README, performance counter data comes from GRBM and GRBM2, while fdinfo supplies hardware IP usage per process. Sensors and GPU Metrics add separate views of device state. The AMDGPU driver provides device information, and DRM is used for underlying display-device access.

This layered approach has practical consequences. A metric can be unavailable when the driver or hardware does not expose the relevant counter, and the README describes cases where particular fdinfo fields are not shown. The driver documentation states that AMDKFD does not track queues, so the Compute or COMP value should not be interpreted as a complete accounting of every queue. Likewise, the Media field is documented as an average involving video decoding, video encoding, and JPEG decoding, while the VCN Unified category applies from VCN4.

The tool also supports diagnostic output for gpu_metrics and pp_table. The gpu_metrics feature is tied to AMDGPU thermal documentation, and pp_table support is limited by the README to Navi1x, Navi2x, and Navi3x. These boundaries matter when comparing devices. The program can list AMDGPU devices with `--list`, select an instance with `-i`, or select a PCI path with `--pci`. Multiple devices are not treated as an undifferentiated system-wide total, which makes device selection relevant on systems with more than one AMD GPU.

## TUI, GUI, SMI, and JSON workflows

amdgpu_top offers several interfaces because monitoring and scripting have different requirements. Running without a mode flag starts the TUI. `--gui` launches the GUI, while `--smi` starts the Simple TUI mode described by the README as similar to nvidia-smi and rocm-smi. The TUI supports keyboard commands for toggling counters and sorting process information. Pressing `h` changes the update interval between 100ms and 1000ms, and `q` quits.

The sorting commands are tied to fdinfo. `P` sorts by process ID, `M` sorts by VRAM usage, `G` sorts by GFX usage, and another documented `M` command is assigned to MediaEngine usage. The README's table therefore contains duplicate `M` bindings, which is a documentation or interface ambiguity worth checking against `--help` before relying on MediaEngine sorting.

JSON mode is the main automation path. The `-J` and `--json` options output JSON data, and the documentation shows a `jq` pipeline that iterates over `.devices[]`, combines device names with PCI addresses, and formats activity entries. JSON output can also be sent to a named pipe through `--json_fifo`. The `-s` option controls refresh period in milliseconds for JSON mode, while `-n` limits iterations or continues indefinitely when set to `0`. This is more suitable for scripts than reading a continuously changing terminal screen.

For a live but compact view, `--smi` is the better documented entry point than the full TUI. For a graphical display, `--gui` supports either the default backend or explicit `--gl` and `--vk` choices. The Vulkan option is documented as using an APU or integrated GPU for rendering when available.

## Running amdgpu_top and producing JSON data

The README gives the following basic invocation forms. A source checkout can be run with Cargo, and an installed binary can be invoked directly. The first form builds and starts the program through Cargo. The second form assumes that the `amdgpu_top` binary is already available on the command path.

```bash
cargo run -- [options ..]
```

```bash
amdgpu_top [options ..]
```

A first live inspection can be started with no mode flag. This enters the documented TUI, where `g` toggles GRBM, `f` toggles fdinfo, `n` toggles sensors, and `q` quits. The `--list` command is useful when several AMDGPU devices are present because it shows the device list before selection.

```bash
amdgpu_top
```

```bash
amdgpu_top --list
```

For a compact device view, use `--smi`. The README describes this as Simple TUI mode, with output intended to resemble monitoring tools such as nvidia-smi and rocm-smi.

```bash
amdgpu_top --smi
```

To produce machine-readable output continuously, combine `--json` with a pipeline. The documented `jq` expression extracts the device name and PCI address, then formats GFX, MediaEngine, and Memory entries. The example emits one line per device and refreshes them as JSON records arrive.

```bash
amdgpu_top --json | jq -c -r '(.devices[] |
  (.Info | .DeviceName + " (" + .PCI + "): ") +
  ([.gpu_activity | to_entries[] | .key + ": " + (.value.value|tostring) + .value.unit] |
  join(", ")))'
```

The README's installation section is truncated before its package and distribution-specific instructions are included. The repository identifies `libdrm` and `libdrm_amdgpu` as dependent dynamic libraries, but the README does not provide complete package-manager installation commands. The Cargo invocation is therefore a source-build starting point, not proof that all system dependencies have already been installed.

## Diagnostics, process inspection, and feature limits

The diagnostic commands give amdgpu_top value beyond a live utilization display. `-d` or `--dump` outputs AMDGPU information, and it can be combined with `-J` for JSON. `--drm-info` emits DRM information, and `--drm_info` is accepted as an alternate spelling. The `--pp-table` option extracts pp_table data from sysfs and VBIOS, but the README limits support to Navi1x, Navi2x, and Navi3x.

`--gpu_metrics` dumps gpu_metrics for all AMD GPUs. This is distinct from normal live rendering: the command is intended to expose the underlying metric data, and `--decode-gm <path>` decodes a specified gpu_metrics file. Adding `--json` to the decoder produces JSON output. The `--xdna` flag adds XDNA NPU information, although the README does not explain the hardware requirements or output schema.

Process information has its own cost and constraints. `-p` or `--process` dumps all GPU processes and memory usage per process. fdinfo is the documented source for per-process hardware IP usage, and `-u` controls how often the process index for fdinfo is updated in seconds. The default is five seconds. This interval should be considered when interpreting changes in process ownership or memory usage.

The `--no-pc` option prevents reading GRBM and GRBM2 performance counters. The README warns that reading those counters may deactivate a power-saving feature of the APU or GPU. That is a meaningful reason to use `--no-pc` on systems where power-saving behavior matters more than immediate counter visibility. It is also a reminder that collecting detailed telemetry can have system-level side effects.

## Choosing between amdgpu_top and a lighter monitor

radeontop is a relevant alternative for a narrower monitoring goal. The README lists it as a similar AMD GPU monitoring tool, but it does not document the same command set or output interfaces. amdgpu_top combines counter toggles, fdinfo, sensors, GPU Metrics, process inspection, device diagnostics, GUI mode, and JSON output in one application. The README does not provide enough radeontop documentation to compare its complexity or interfaces.

umr is another reference in the README. The README does not document umr's features or interfaces. amdgpu_top presents collected utilization and device information through interactive and machine-readable interfaces. umr is listed as a related tool rather than a drop-in replacement with the same TUI or JSON model. The README also lists intel_gpu_top as a similar tool without documenting its scope.

The MIT license permits use, modification, and redistribution under its conditions, but the license does not remove platform responsibilities. Users still need compatible Linux graphics stacks and the dependent dynamic libraries named in the README. The Cargo manifest identifies the project as Rust edition 2024 and version 0.11.5. The repository has a workspace organized into `libamdgpu_top`, `amdgpu_top_tui`, `amdgpu_top_gui`, and `amdgpu_top_json`, which explains why the binary can expose several frontends over shared AMDGPU functionality.

## Maintenance, upgrades, and platform boundaries

The repository is not archived, and its last push was on 2026-10-08. That status indicates recent repository activity, but it does not guarantee compatibility with every kernel, driver, or GPU generation. The listed releases include v0.11.5 on 2026-05-18, v0.11.4 on 2026-04-23, and v0.11.3 on 2026-03-30. The version in `Cargo.toml` is 0.11.5, so the manifest and the newest listed release are aligned.

Upgrade cost depends on the installation path. A packaged installation may follow the distribution's package updates, while a Cargo build can involve rebuilding the Rust workspace and resolving the documented `libdrm` and `libdrm_amdgpu` runtime requirements. The manifest exposes features for linked or dynamically loaded libdrm, plus optional TUI, GUI, JSON, and Git version support. Those feature names are documented in `Cargo.toml`, but the README does not provide a complete feature-selection tutorial.

There is also a hardware boundary. The README does not claim support for NVIDIA or Intel GPUs. It documents AMD-specific counters, AMDGPU thermal gpu_metrics, pp_table support for selected Navi generations, and an XDNA NPU dump option. A Linux user with an AMD card should first check whether the relevant driver fields and permissions are available. A user who needs a vendor-neutral dashboard or remote monitoring service is outside the documented use case.

## Conclusion

Adopt amdgpu_top when you need AMD GPU diagnostics or scriptable utilization data from the AMDGPU driver. Do not choose it as a cross-vendor GPU monitor, since its documented scope is AMDGPU systems with libdrm and libdrm_amdgpu. Verify first that your kernel and driver expose the relevant counters, then confirm that the displayed metrics match the workload before using the JSON output for automation.

## FAQ

### What does amdgpu_top display?

It displays AMD GPU utilization and related information gathered from performance counters, sensors, fdinfo, gpu_metrics, and the AMDGPU driver. The README also documents device, VRAM, PCI, VBIOS, process, and DRM information.

### How do I install amdgpu_top?

The README shows `cargo run -- [options ..]` for running from source, but its installation section is truncated before the complete package and distribution-specific instructions. The project depends on the dynamic libraries `libdrm` and `libdrm_amdgpu`.

### Can amdgpu_top output JSON?

Yes. Use the `--json` option for JSON-formatted data, with `-d` when dumping AMDGPU information. JSON output can also be directed to a FIFO with `--json_fifo`, and the README includes a `jq` example for extracting device activity.

### Does reading amdgpu_top performance counters affect power saving?

The README warns that reading the GRBM and GRBM2 performance counters may deactivate a power-saving feature of the APU or GPU. The `--no-pc` option avoids reading those counters.

## Sources

- [Issues](https://github.com/Umio-Yasuno/amdgpu_top/issues)
- [License: MIT](https://github.com/Umio-Yasuno/amdgpu_top/blob/main/LICENSE)
- [README](https://github.com/Umio-Yasuno/amdgpu_top/blob/main/README.md)
- [Releases](https://github.com/Umio-Yasuno/amdgpu_top/releases)
- [Umio-Yasuno/amdgpu_top on GitHub](https://github.com/Umio-Yasuno/amdgpu_top)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/umio-yasuno-amdgpu-top