No clients listed in intel_gpu_top
intel_gpu_top does not show any clients, although clients are definitely rendering (hardware-accelerated video).
The paste at the very end of this entry doesn't just cut off the clients, they are simply not present, regardless of the state of the runtime toggles (sort/display/aggregate).
To reproduce:
sudo intel_gpu_top- start any application which consumes resources tracked by
intel_gpu_top
//exp: some information is rendered below the fancy graph rendition //act: only the graph rendition, no further details in the bottom section
System environment:
- Dell Inspiron 16 Plus (7610) with Nvidia RTX 3060 dGPU
- X11 / Xorg == reverse PRIME configuration, so Intel iGPU renders everything
- external screen on HDMI port attached to Intel output port (and no MUXing involved; the Nvidia dGPU is literally powered down, not involved at all - also validated via
nvidia-smi) - Fedora 36 (5.17.8-300.fc36.x86_64)
intel-gpu-top: Intel Tigerlake (Gen12) @ /dev/dri/card1 - 86/ 349 MHz; 54% RC6
441 irqs/s
ENGINES BUSY MI_SEMA MI_WAIT
Render/3D 19.86% |████████▊ | 0% 0%
Blitter 0.00% | | 0% 0%
Video 2.17% |█ | 0% 0%
VideoEnhance 3.52% |█▋ | 0% 0%
PID NAME Render/3D Blitter Video VideoEnhance
Activity
@tursulin can you check this out?
FWIW, it might be easier to render dummy text saying "Linux kernel 5.19+ is required for a detailed list" - this way, the various hints and notes in the documentation ("h") do not have to be adjusted.
FWIW, Linux kernel 5.18 was just released, so perhaps not mentioning a specific future kernel version might be also be worthwhile?
mentioned in commit 0e5b5c50
Driver version: Intel iHD driver for Intel(R) Gen Graphics - 22.3.1 > lsgpu card1 Intel Tigerlake (Gen12) drm:/dev/dri/card1 └─renderD128 drm:/dev/dri/renderD128 intel-gpu-top: Intel Tigerlake (Gen12) @ /dev/dri/card1 - 5/ 253 MHz; 75% RC6; 93 irqs/s ENGINES BUSY MI_SEMA MI_WAIT Render/3D 0.22% |▉ | 0% 0% Blitter 0.00% | | 0% 0% Video 0.17% |▊ | 0% 0% VideoEnhance 0.39% |█▌ | 0% 0% PID NAME Render/3D Blitter Video VideoEnhanceHope this helps
Nothing in the trace strikes me as odd. Certainly fdinfo files appear to be present and partial content shown looks reasonable.
One odd thing is that lsgpu shows card1 but renderD128. I wonder what is card0 on your machine. Do you see both /sys/class/drm/card0/ and /sys/class/drm/card1/ present and to what they point? Or would you be able to check if lsgpi output is the same with the old kernel?
Maybe also try intel_gpu_top -L and then pass that to -d, in case of auto selection somehow does not fully work.
Or if you are comfortable patching and building it from source see what this line prints:
diff --git a/tools/intel_gpu_top.c b/tools/intel_gpu_top.c index 6de8a164fcff..c4b4726b0fa7 100644 --- a/tools/intel_gpu_top.c +++ b/tools/intel_gpu_top.c @@ -2585,6 +2585,7 @@ int main(int argc, char **argv) ret = EXIT_SUCCESS; if (has_drm_fdinfo(&card)) +printf("xxx '%s'\n", card.pci_slot_name[0]); clients = init_clients(card.pci_slot_name[0] ? card.pci_slot_name : IGPU_PCI); init_engine_classes(engines);Edited by Tvrtko UrsulinNo
/sys/class/drm/card0, interestingly enough.> ls -l /sys/class/drm/ total 0 lrwxrwxrwx. 1 root root 0 Nov 10 10:18 card1 -> ../../devices/pci0000:00/0000:00:02.0/drm/card1 lrwxrwxrwx. 1 root root 0 Nov 10 10:18 card1-DP-1 -> ../../devices/pci0000:00/0000:00:02.0/drm/card1/card1-DP-1 lrwxrwxrwx. 1 root root 0 Nov 10 10:18 card1-DP-2 -> ../../devices/pci0000:00/0000:00:02.0/drm/card1/card1-DP-2 lrwxrwxrwx. 1 root root 0 Nov 10 10:18 card1-DP-3 -> ../../devices/pci0000:00/0000:00:02.0/drm/card1/card1-DP-3 lrwxrwxrwx. 1 root root 0 Nov 10 10:18 card1-DP-4 -> ../../devices/pci0000:00/0000:00:02.0/drm/card1/card1-DP-4 lrwxrwxrwx. 1 root root 0 Nov 10 10:18 card1-DP-5 -> ../../devices/pci0000:00/0000:00:02.0/drm/card1/card1-DP-5 lrwxrwxrwx. 1 root root 0 Nov 10 10:18 card1-DP-6 -> ../../devices/pci0000:00/0000:00:02.0/drm/card1/card1-DP-6 lrwxrwxrwx. 1 root root 0 Nov 10 10:18 card1-DP-7 -> ../../devices/pci0000:00/0000:00:02.0/drm/card1/card1-DP-7 lrwxrwxrwx. 1 root root 0 Nov 10 10:18 card1-eDP-1 -> ../../devices/pci0000:00/0000:00:02.0/drm/card1/card1-eDP-1 lrwxrwxrwx. 1 root root 0 Nov 10 10:18 card1-HDMI-A-1 -> ../../devices/pci0000:00/0000:00:02.0/drm/card1/card1-HDMI-A-1 lrwxrwxrwx. 1 root root 0 Nov 10 10:18 renderD128 -> ../../devices/pci0000:00/0000:00:02.0/drm/renderD128 -r--r--r--. 1 root root 4096 Nov 10 10:18 versionPassing
-d pci:pci:vendor=8086,device=9A60,card=0results in intel_gpu_top to use/dev/dri/card1just the same.I'll clone this repository and add the printf line and see how that goes.
I added the patch but am failing to see where the output should be printed.
> git diff ───────┬────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── │ STDIN ───────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── 1 │ diff --git a/tools/intel_gpu_top.c b/tools/intel_gpu_top.c 2 │ index 6de8a164..78da24a3 100644 3 │ --- a/tools/intel_gpu_top.c 4 │ +++ b/tools/intel_gpu_top.c 5 │ @@ -2585,6 +2585,7 @@ int main(int argc, char **argv) 6 │ ret = EXIT_SUCCESS; 7 │ 8 │ if (has_drm_fdinfo(&card)) 9 │ + printf("xxx '%s'\n", card.pci_slot_name[0]); 10 │ clients = init_clients(card.pci_slot_name[0] ? 11 │ card.pci_slot_name : IGPU_PCI); 12 │ init_engine_classes(engines); ───────┴──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────then
> sudo strace -f -s 65535 -o log ./build/tools/intel_gpu_topand> grep xxx log >I built it using the
meson.shscript.Ah, no worries. Empty message.
> sudo ./build/tools/intel_gpu_top >When build there's a warning about type conversion,
card.pci_slot_name[0]is anintand not achar *. Changing%s%to%dstill returns empty and changingcard.pci_slot_name[0]tocard.pci_slot_namealso returns empty.I also changed
printf("xxx '%s'\n", card.pci_slot_name[0]);toprintf("xxx '%s'\n", &card.pci_slot_name[0]);, but still no luck.Edited by Ingo-
Yes you fixed it correctly (%s and just card.pci_slot_name), my bad. Empty is okay, will make it use IGPU_PCI which matches "drm-pdev:\t0000:00:02.0" from your strace.
I am out of ideas what else could be going wrong.
Maybe try pressing 'H' once and then if still nothing, 'i' once to change the display mode into no PID aggregation and no hiding of clients with no GPU utilization.
-
If there is still nothing with no aggregation and not idle filtering that means it is possibly not able to parse anything at all. Would you able to paste a content of one relevant fdinfo file here? It would go like this, using lsof find something interesting using the GPU:
$ sudo lsof | grep "/dev/dri/"
... xfwm4 944 952 xfwm4:sh1 root 12u CHR 226,0 0t0 397 /dev/dri/card0 ...Copy the PID (2nd field) and cat the fdinfo associated with the file descriptor (6th field, minus the 'u' suffix):
$ cat /proc/944/fdinfo/12
And paste what you get here please. It should look something like this:
pos: 0 flags: 02100002 mnt_id: 21 ino: 397 drm-driver: i915 drm-pdev: 0000:00:02.0 drm-client-id: 6 drm-engine-render: 329700 ns drm-engine-copy: 0 ns drm-engine-video: 0 ns drm-engine-video-enhance: 0 nsEdited by Tvrtko Ursulin > sudo lsof -p 7810 | ag "/dev/dri" ... kitty 7810 100 8u CHR 226,1 0t0 540 /dev/dri/card1 kitty 7810 100 9u CHR 226,1 0t0 540 /dev/dri/card1 kitty 7810 100 10u CHR 226,1 0t0 540 /dev/dri/card1 kitty 7810 100 11u CHR 226,1 0t0 540 /dev/dri/card1 kitty 7810 100 12u CHR 226,1 0t0 540 /dev/dri/card1 > cat /proc/7810/fdinfo/10 pos: 0 flags: 02100002 mnt_id: 24 ino: 540 drm-driver: i915 drm-pdev: 0000:00:02.0 drm-client-id: 24-
Yes, from i915 source code:
/* * Temporarily skip showing client engine information with GuC submission till * fetching engine busyness is implemented in the GuC submission backend */ if (GRAPHICS_VER(i915) < 8 || intel_uc_uses_guc_submission(&i915->gt0.uc)) return;Why are you using GuC on Tigerlake?
I didn't know. I enabled GuC so I can have VP9 hardware encoding. It was the only way I found to enable it.
> vainfo ... VAProfileVP9Profile0 : VAEntrypointVLD VAProfileVP9Profile0 : VAEntrypointEncSliceLP VAProfileVP9Profile1 : VAEntrypointVLD VAProfileVP9Profile1 : VAEntrypointEncSliceLP VAProfileVP9Profile2 : VAEntrypointVLD VAProfileVP9Profile2 : VAEntrypointEncSliceLP VAProfileVP9Profile3 : VAEntrypointVLD VAProfileVP9Profile3 : VAEntrypointEncSliceLP ...Edited by Ingo-
Try enable_guc=2, it should enable it load HuC but refrain from using the GuC for command submission and intel_gpu_top will work.
Oh and if there is some wiki which suggests enable_guc=3 please paste a link or tell them to correct it.
Edited by Tvrtko Ursulin @tursulin , are you saying that
enable_guc=2should always be preferred toenable_guc=3or only to fixintel_gpu_top?A couple of places that seem to recommend
enable_guc=3:are you saying that
enable_guc=2should always be preferred toenable_guc=3Telling GuC FW to load HuC FW (
enable_guc=2) has much less effect on how the kernel GPU driver works, than overriding kernel driver decision of who's in control of GPU scheduling etc, kernel driver or GuC FW (enable_guc=3). Therefore latter decision is better left to kernel developers, unless you're keen to debug those functionalities yourself. :-)While Arch doc documents the meaning of the option values correctly, this one is definitely wrong.
I will try that, thanks.
I read it here, https://gist.github.com/Brainiarc7/aa43570f512906e882ad6cdd835efe57, and after following those steps I was able to see VP9 hardware encoding enabled.
enable_guc=2did the trick, thanks again, @tursulin!
