https://bugs.kde.org/show_bug.cgi?id=523812
--- Comment #8 from AccessWebBE <[email protected]> --- Correction to my previous comment: enabling 3D acceleration did not fix this, and I would rather say so here than leave that standing as the outcome of this report. That comment was based on two svga sessions of 15.6 and 18.2 hours. Over full boots the leak is present in both configurations. Growth per boot, system_ttm and mob_ttm added together: 3D off, llvmpipe +442 to +1367 MB/h (5 boots) 3D on, svga +5 to +161 MB/h (3 boots) The "5-22 MB/h" I quoted was real but came from sessions that had not run long enough. The same boot that gave +22 MB/h over its first 18.2 hours works out at +161 MB/h over its full 115.5 hours. Enabling 3D reduces it substantially - very roughly a factor 3 to 30 depending on the session - but it does not remove it. The resolution as UPSTREAM still looks right to me. The logout test in comment 2 stands: the GEM objects went from 8139 to 19 when the compositor exited and the memory did not come back. Zack Rusin (Broadcom) confirmed the mechanism on dri-devel: vmwgfx never had explicit prime export deref/destroy ioctls, so gem_close on resources created from fd handles did nothing and they all leaked. That thread is ongoing. I am correcting the record here mainly because of the advice I gave at the end of that comment - that turning 3D on is worth trying before anything else. It helps, but it is not a fix, and I would rather not leave that standing for the next person who finds this report. -- You are receiving this mail because: You are watching all bug changes.
