Mem meter: show RAM used by the GPU in a different color

[gerion0]

On an AMD Ryzen 7 PRO 6850U the GPU seems to be able to additionally use the normal RAM, via the GTT (when I searched correctly, it is possible to find out that value with radeontop by looking at the GTT line). Based on my experience this RAM is shown as "used" in htop but has no reference in the process list, which is confusing. I have a very high standard memory usage (as displayed by htop) but it seems that half of it is "eaten" by the GPU (at least the processes does not sum up at all to the used memory and radeontop shows around 7GB of VTT memory).

As far as I know not only AMD GPUs/APUs are capable of using the main RAM, so I think it would be a nice feature of htop to display that RAM in a special color so a user is capable of classifying it.

Seems kind of related to #406, #1100, #631.

[BenBE]

Is the GTT memory information available in any file htop is currently reading already?

Also: If this change is made it should be done consistently across all platforms. Please provide some information for platforms like *BSD and Darwin, on where to get the information on those systems.

[gerion0]

In readeontop the information is retrieved by calling a specific function of libdrm (amdgpu_query_info()).
strace filtered by open results in these files:

openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib64/libdrm_amdgpu.so.1", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib64/libpciaccess.so.0", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib64/libdrm.so.2", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libm.so.6", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libncursesw.so.6", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libtinfow.so.6", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libz.so.1", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/dev/dri", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3
openat(AT_FDCWD, "/sys/devices/pci0000:00/0000:00:08.1/0000:04:00.0/uevent", O_RDONLY) = 4
openat(AT_FDCWD, "/sys/devices/pci0000:00/0000:00:08.1/0000:04:00.0/uevent", O_RDONLY) = 4
openat(AT_FDCWD, "/dev/dri", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3
openat(AT_FDCWD, "/sys/devices/pci0000:00/0000:00:08.1/0000:04:00.0/uevent", O_RDONLY) = 4
openat(AT_FDCWD, "/sys/devices/pci0000:00/0000:00:08.1/0000:04:00.0/vendor", O_RDONLY) = 4
openat(AT_FDCWD, "/sys/devices/pci0000:00/0000:00:08.1/0000:04:00.0/device", O_RDONLY) = 4
openat(AT_FDCWD, "/sys/devices/pci0000:00/0000:00:08.1/0000:04:00.0/subsystem_vendor", O_RDONLY) = 4
openat(AT_FDCWD, "/sys/devices/pci0000:00/0000:00:08.1/0000:04:00.0/subsystem_device", O_RDONLY) = 4
openat(AT_FDCWD, "/sys/devices/pci0000:00/0000:00:08.1/0000:04:00.0/uevent", O_RDONLY) = 4
openat(AT_FDCWD, "/sys/devices/pci0000:00/0000:00:08.1/0000:04:00.0/vendor", O_RDONLY) = 4
openat(AT_FDCWD, "/sys/devices/pci0000:00/0000:00:08.1/0000:04:00.0/device", O_RDONLY) = 4
openat(AT_FDCWD, "/sys/devices/pci0000:00/0000:00:08.1/0000:04:00.0/subsystem_vendor", O_RDONLY) = 4
openat(AT_FDCWD, "/sys/devices/pci0000:00/0000:00:08.1/0000:04:00.0/subsystem_device", O_RDONLY) = 4
openat(AT_FDCWD, "/dev/dri/renderD128", O_RDWR) = 3
openat(AT_FDCWD, "/usr/share/libdrm/amdgpu.ids", O_RDONLY) = 5
openat(AT_FDCWD, "/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 5
openat(AT_FDCWD, "/usr/share/locale/de/LC_MESSAGES/radeontop.mo", O_RDONLY) = 5
openat(AT_FDCWD, "/usr/lib64/gconv/gconv-modules.cache", O_RDONLY) = 5

Sorry, I cannot say something about other platforms and have no direct access. If you have a patch, I can however boot a BSD live system on my machine to test it (if that exists and if they have support for newer AMD GPUs).

[BenBE]

To reduce the number of dependencies we'd best like to avoid introducing unnecessary dependencies, especially as this would only cover AMD GPUs and only some of them and only on Linux. But given this requests things from the DRM there might be a chance this can be read directly from the kernel or better yet, some file in procfs or sysfs.

[gerion0]

I digged around a little bit in the sysfs. This file looks really promising:

cat /sys/class/graphics/fb0/device/mem_info_gtt_used
15523934208
cat /sys/class/graphics/fb0/device/mem_info_gtt_total 
16167870464

radeontop at the same time reports 14805M / 15335M GTT. My used RAM according to htop is 23GB + 3GB swap without having anything RAM intensive program open (my browser has RES = 1331M as the top RAM user), so I think the values fit quite nicely.

[fasterit]

# system with AMD GPU
$ cat /sys/class/graphics/fb0/name 
amdgpudrmfb
$ ls /sys/class/graphics/fb0/device/mem*
/sys/class/graphics/fb0/device/mem_info_gtt_total       /sys/class/graphics/fb0/device/mem_info_vis_vram_used
/sys/class/graphics/fb0/device/mem_info_gtt_used        /sys/class/graphics/fb0/device/mem_info_vram_total
/sys/class/graphics/fb0/device/mem_info_preempt_used    /sys/class/graphics/fb0/device/mem_info_vram_used
/sys/class/graphics/fb0/device/mem_info_vis_vram_total  /sys/class/graphics/fb0/device/mem_info_vram_vendor

# system with Intel GPU
$ cat /sys/class/graphics/fb0/name 
i915drmfb
# -> no /sys/class/graphics/fb0/device/mem_* files

Anybody can check an NVidia system?
(do they use host memory, and if so how much?)

[BenBE]

For NVIDIA both nv and nouveau should be checked. Unfortunately no such system at hand.

[gerion0]

Grepping in the Linux source results in:

$ rg mem_info_gtt_used
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
56: * DOC: mem_info_gtt_used
60: * The file mem_info_gtt_used is used for this, and returns the current used
63:static ssize_t amdgpu_mem_info_gtt_used_show(struct device *dev,
76:static DEVICE_ATTR(mem_info_gtt_used, S_IRUGO,
77:	          amdgpu_mem_info_gtt_used_show, NULL);
81:	&dev_attr_mem_info_gtt_used.attr,

Documentation/gpu/amdgpu/driver-misc.rst
87:mem_info_gtt_used
91:   :doc: mem_info_gtt_used

So this sysfs file seems to be amdgpu specific. However, according to Wikipedia, the concept exists for Intel GPUs, too.

[gerion0]

The Intel driver (i915) has a lot of GTT specific code in the kernel. Maybe some usable numbers can be found in this file:
/sys/kernel/debug/dri/*/i915_gem_objects
(Source: Stackexchange).

[BenBE]

The Intel driver (i915) has a lot of GTT specific code in the kernel. Maybe some usable numbers can be found in this file:
/sys/kernel/debug/dri/*/i915_gem_objects

# ls -lad / /sys/ /sys/kernel/ /sys/kernel/debug/ /sys/kernel/debug/dri/ /sys/kernel/debug/dri/0/ /sys/kernel/debug/dri/0/i915_gem_objects
drwxr-xr-x 22 root root 4096 Mär 31  2022 /
dr-xr-xr-x 13 root root    0 Jul  1 21:18 /sys/
drwxr-xr-x 17 root root    0 Jul  1 21:18 /sys/kernel/
drwx------ 53 root root    0 Jul  1 21:18 /sys/kernel/debug/
drwxr-xr-x  4 root root    0 Jul  1 21:18 /sys/kernel/debug/dri/
drwxr-xr-x  9 root root    0 Jul  1 21:18 /sys/kernel/debug/dri/0/
-r--r--r--  1 root root    0 Jul  1 21:18 /sys/kernel/debug/dri/0/i915_gem_objects
# cat /sys/kernel/debug/dri/0/i915_gem_objects 
6049 shrinkable [0 free] objects, 1290665984 bytes
system: total:0x00000007c0573000 bytes
stolen-system: total:0x0000000010000000 bytes

Thus, access only with root permissions …

[russelltg]

On GPUs that support per-process memory reporting it may be nice to add that as as column as well. I believe Nvidia and AMD do this? I don't think it exists yet for intel, however.

[BenBE]

On GPUs that support per-process memory reporting it may be nice to add that as as column as well. I believe Nvidia and AMD do this? I don't think it exists yet for intel, however.

Given the right PRs I see a real chance for this. ;-)