Graphics: Mike Blumenkrantz Dota2 and on Russell Coker Strange X11 Grabbing (UPDATED)
-
Mike Blumenkrantz: Oom
Memory
I got a report recently that Dota2 was using too much memory on RADV. Host memory, that is, not GPU. So how does one profile Dota2 memory usage?
On Linux, the ideal tool for memory profiling is massif. But does a flawless, unparalleled game like Dota2 run under massif?
Sort of maybe almost but not really.
And it’s not the best way to do it anyway since, for profiling, the ideal scenario is to run a static test. Thus, gfxreconstruct is the best way to test things here. Simply
VK_INSTANCE_LAYERS=VK_LAYER_LUNARG_gfxreconstructin your ultra secret Source Engine debug console and let it run.Then queue up a replay under massif and find something else to do for the next half hour since it’s not exactly a speedy process.
It Bad
-
Russell Coker: Strange X11 Grabbing
A couple of days ago I upgraded my home server from Debian/Bullseye to Debian/Testing (soon to be Bookworm). Since then KDE sessions on that system have had problems of locking the input queue, the mouse can move and mouse-over events work but clicking the mouse or pressing the keyboard does nothing. Various web pages suggested that the xdotool program (in the xdotool package in Debian) can address this. The problem is apparently programs “grabbing” the input and not letting it go.
The command “xdotool key XF86LogGrabInfo” causes the xorg server to dump information on it’s “grabs”. After running that command I looked in /var/log/Xorg.0.log and found that active grabs were only held by /usr/bin/kwin_x11 and /usr/bin/kglobalaccel5. So it seems like a KDE issue. Other systems running X11 with Debian/Testing (such as the laptop I’m using to write this blog post) don’t have the problem, so it could be something related to the KDE configuration of the account used on that system.
The command “xdotool key XF86Ungrab” is supposed to break out of such a grab, but for me didn’t do so.
On the same system running KDE with Wayland works fine in this regard. Does Wayland do things differently and not allow this “grabbing” to block everything? Does KDE have an X11 specific bug? Is there a race condition that just gets triggered by the speed of Xorg on that system but not by the slightly different timings of Wayland? I might never find out.
I previously wrote about problems with Wayland/KDE on laptops [1]. Fortunately this bug happened to occur on a server so inability to reconfigure monitors isn’t necessarily a deal breaker, although being unable to use some of the high-DPI settings for the 4K monitor it has may be an issue. It will be really annoying if some of the laptop configurations I support get this grabbing problem. But since that time I have learned of the kscreen-doctor command which is included in Debian/Testing and can do some of the necessary things, it doesn’t have a man page so you have to run “kscreen-doctor -h” for documentation.
UPDATE
Liam Dawe's update:
-
AMD RADV driver will soon stop eating RAM with some games
Developer Mike Blumenkrantz has continued blogging about Linux graphics driver improvements, with a fix from developer Samuel Pitoiset landing to stop the AMD RADV (Vulkan) driver eating up RAM.