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

Hi Maaz,

Updated today: mesa 26.2.1, and the kernel went 7.1.8 -> 7.2.0 in the 
same batch. 3D enabled, renderer is SVGA3D, vmwgfx reports 2.21.0.0.

The surface warning still fires, four times during session startup:

   vmwgfx 0000:00:0f.0: [drm] User surface fd 157 (handle 49) is null.
   !user_srf
   WARNING: drivers/gpu/drm/vmwgfx/vmwgfx_surface.c:958 at
   vmw_surface_handle_reference+0x297/0x320 [vmwgfx], CPU#2: 
kwin_wayland/4631

Not new - we have had it since 12 July - but it survives your fix.

Leak numbers will take a few days. I have no usable baseline on 26.2.0: 
the machine was mostly idle before the update - 27 of the last 42 hours 
were completely flat - and growth here follows render load, not uptime. 
Quoting a rate from that would be a startup curve, not a leak.

An intensive work period starts today, so I will send numbers from that, 
with the caveat that mesa and the kernel changed in the same update.

I have not tried your dri-devel scanout patch yet - we run distribution 
kernels here. Say if you want us to build it.

On the emails: you are right. English is not my first language so I use 
an LLM to write them. I will try to keep them short from now on.


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.
>