Re: drm/vmwgfx: graphics memory not returned,after all GEM objects are released

[Jellis Onsea | AccessWeb <jellis@accessweb.be>]

Hi Maaz,

Short version: mesa 26.2.1 is running here with 3D on, and the leak is 
still there.

Setup: one boot, 119 h, a single kwin_wayland (6.7.4), mesa 3:26.2.1-1, 
kernel 7.2.0, renderer SVGA3D.

   TTM sys+mob    0.36 -> 16.73 GB
   objects        1948 -> 10365
   kwin_wayland   holds 8484 MB in 4894 objects
   free RAM       4.9 of 31 GB - we have to reboot today

It tracks rendering, not uptime. Idle nights (02:00-07:00) in this same 
boot:

   22 Aug  -0.03 GB       25 Aug  +0.00 GB
   23 Aug  +0.02 GB       26 Aug  +0.04 GB
   24 Aug  +1.88 GB   <- the one night an automated GUI test run was active

The surface warning still fires: 1168 WARNING blocks at 
vmw_surface_handle_reference in the last 27 hours. That is a window, not 
a total - journald has already rotated away the earlier part of this boot.

Correction to my previous mail: "four times during session startup" was 
wrong. It fires in bursts throughout the session.

We have not tried "drm/vmwgfx: Return gem fd handle for scanout buffers" 
we run distribution kernels here. Say the word and we will build it.

Best regards,
Jellis

Op 21-08-2026 om 04:09 schreef Maaz Mombasawala:
> For the 3D-enabled case, could you try with mesa 26.1.8 or 26.2.1, both of which contain my fix.
> Also if you could try the patch I just submitted on dri-devel - drm/vmwgfx: Return gem fd handle for scanout buffers.
> If you still see issues with these patches, let me know.
> 
> As for the 3D disabled case, I can see issues on my local machine and am working on a fix.
> 
> PS - Your emails are overly verbose and narrative, could you include only the actual problems you are facing.
> If you're using an llm to write these, please make them more terse and human readable. Thanks.
>