https://bugs.kde.org/show_bug.cgi?id=523812
--- Comment #7 from AccessWebBE <[email protected]> --- (In reply to Zamundaaa from comment #6) > Well, it sounds to me more like the driver is leaking stuff, and those > buffers happen to be attributed to KWin. Until that part is fixed, I > wouldn't want to spend any time investigating any possible issues in KWin > that don't happen with other drivers. Closing the loop on this one, since your answer turned out to be exactly right. It was the driver. Zack Rusin (vmwgfx maintainer) explained on dri-devel that vmwgfx never got the explicit prime export deref/destroy ioctls in the kernel DRM uapi, so gem_close on resources created from fd handles did nothing there and every one of them leaked. Thread and his reply: https://lore.kernel.org/dri-devel/ (subject "drm/vmwgfx: graphics memory not returned after all GEM objects are released", 5 August 2026). Mesa fix: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/43386 What actually made it go away on my side was enabling 3D acceleration in the VMware host settings. Same machine, same kernel 7.1.6, same distribution mesa 26.1.6, no patch involved: 3D disabled, 4 sessions of 8 to 35 hours 667 to 1367 MB/hour 3D enabled (svga), 2 sessions of 16-18h 5 and 22 MB/hour Two things changed measurably at the same time. The TTM MOB pool had been constant at 0.023 GB across 409 samples over four days and only started moving once svga was in use, and the dominant buffer went from 8355840 bytes (1920x1088x4, height padded to a multiple of 64, i.e. a dumb buffer) to 8294400 (1920x1080x4, exactly the screen). So the configuration I originally reported was not going through gallium svga at all. For anyone finding this later: if you run KWin in a VMware guest with 3D acceleration turned off, this is what you hit. Turning it on is worth trying before anything else. Sorry for the noise on the KWin side, and thanks for the quick and correct call. -- You are receiving this mail because: You are watching all bug changes.
