[PATCH 0/3] drm/vmwgfx: Add support for userspace managed surfaces.

[Maaz Mombasawala]

On 8/13/24 19:33, Zack Rusin wrote:
> On Mon, Aug 12, 2024 at 3:16 PM Maaz Mombasawala
> <maaz.mombasawala at broadcom.com> 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:

There is a patch for mesa, I'll work on getting that upstreamed too.

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

I haven't tested this under memory pressure conditions. That should be a
userspace issue though.

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

For userspace managed surfaces, the driver only accepts ids in the range
1 to 32768 (VMWGFX_NUM_GB_SURFACE) and for an old kernel managed surfaces
it only returns ids in range starting at 53040 (VMWGFX_NUM_MOB).
So if userspace defines a surface with the old ioctls and then tries to
issue the gb_surface_destroy on that surface with that id then the command
buffer submission will fail because it won't pass the res checks.

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

There is no such flag right now, I will add this.

> 
> z


-- 
Maaz Mombasawala <maaz.mombasawala at broadcom.com>