On Mon, Aug 12, 2024 at 3:16 PM Maaz Mombasawala <maaz.mombasawala@xxxxxxxxxxxx> wrote: > > This series introduces basic support for userspace managed surfaces. The > lifetime and id's of these surfaces is managed by userspace submitted > commands instead of relying on the kernel to manage them. > > Maaz Mombasawala (3): > drm/vmwgfx: Introduce userspace managed surfaces > drm/vmwgfx: Support hw_destroy for userspace managed surfaces > drm/vmwgfx: Add support for older define commands for userspace > surfaces > > drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 24 +- > drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 331 ++++++++++++++++++++++-- > drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 196 +++++++++++++- > 3 files changed, 518 insertions(+), 33 deletions(-) > In general that looks great. Do you happen to have the userspace patch somewhere where we could see it? In particular there are three things I'm wondering about: 1) In the first patch you mark the gb surface as may_evict = false; correctly, because if user space is the thing that attaches mob's then kernel can not switch them underneath but then I'd like to see how are the memory pressure situations handled on the user-side, 2) Since now we allow surface destroy commands from userspace could one trigger some kernel oops when running old surface defines with mob_create flag set and issuing the gb surface destroy or will the res->id be reset properly? 3) how is userspace able to select whether it should self-manage the mob's or let the kernel do it? i.e. what flag signifies that the userspace is running on a kernel that is capable of handling this? z
