linux-dev/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c, branch linus/master

Merge remote-tracking branch 'drm/drm-next' into drm-misc-next

2022-02-07T16:03:24Z

First backmerge into drm-misc-next. Required for more helpers backmerged, and to pull in 5.17 (rc2). Signed-off-by: Maarten Lankhorst

drm/vmwgfx: remove vmw_wait_dma_fence

2022-02-02T15:15:37Z

Decomposing fence containers don't seem to make any sense here. So just remove the function entirely and call dma_fence_wait() directly. Signed-off-by: Christian König Reviewed-by: Zack Rusin Link: https://patchwork.freedesktop.org/patch/msgid/20220124130328.2376-12-christian.koenig@amd.com

drm/vmwgfx: Fix stale file descriptors on failed usercopy

2022-01-27T15:55:20Z

A failing usercopy of the fence_rep object will lead to a stale entry in the file descriptor table as put_unused_fd() won't release it. This enables userland to refer to a dangling 'file' object through that still valid file descriptor, leading to all kinds of use-after-free exploitation scenarios. Fix this by deferring the call to fd_install() until after the usercopy has succeeded. Fixes: c906965dee22 ("drm/vmwgfx: Add export fence to file descriptor support") Signed-off-by: Mathias Krause Signed-off-by: Zack Rusin Signed-off-by: Dave Airlie Signed-off-by: Linus Torvalds

drm/vmwgfx: add support for updating only offsets of constant buffers

2021-12-09T18:16:30Z

This adds support for the SVGA_3D_CMD_DX_SET_VS/PS/GS/HS/DS/CS_CONSTANT_BUFFER_OFFSET commands (which only update the offset, but don't rebind the buffer), which saves some overhead. Signed-off-by: Roland Scheidegger Reviewed-by: Charmaine Lee Reviewed-by: Martin Krastev Signed-off-by: Zack Rusin Link: https://patchwork.freedesktop.org/patch/msgid/20211206172620.3139754-11-zack@kde.org

drm/vmwgfx: support 64 UAVs

2021-12-09T18:16:28Z

If the host supports SVGA3D_DEVCAP_GL43, we can handle 64 instead of just 8 UAVs. Based on a patch from Roland Scheidegger . Signed-off-by: Roland Scheidegger Signed-off-by: Zack Rusin Reviewed-by: Martin Krastev Link: https://patchwork.freedesktop.org/patch/msgid/20211206172620.3139754-9-zack@kde.org

drm/vmwgfx: support SVGA_3D_CMD_DX_DEFINE_RASTERIZER_STATE_V2 command

2021-12-09T18:16:27Z

This is going to be required for setting the sample count when rendering with no attachments. Also cleans up view handling (should fix depthstencil_v2). Reviewed-by: Charmaine Lee Signed-off-by: Roland Scheidegger Signed-off-by: Zack Rusin Link: https://patchwork.freedesktop.org/patch/msgid/20211206172620.3139754-8-zack@kde.org

drm/vmwgfx: Implement DRIVER_GEM

2021-12-09T18:16:16Z

This is initial change adding support for DRIVER_GEM to vmwgfx. vmwgfx was written before GEM and has always used TTM. Over the years the TTM buffers started inherting from GEM objects but vmwgfx never implemented GEM making it quite awkward. We were directly setting variables in GEM objects to not make DRM crash. This change brings vmwgfx inline with other DRM drivers and allows us to use a lot of DRM helpers which have depended on drivers with GEM support. Due to historical reasons vmwgfx splits the idea of a buffer and surface which makes it a littly tricky since either one can be used in most of our ioctl's which take user space handles. For now our BO's are GEM objects and our surfaces are opaque objects which are backed by GEM objects. In the future I'd like to combine those into a single BO but we don't want to break any of our existing ioctl's so it will take time to do it in a non-destructive way. Signed-off-by: Zack Rusin Reviewed-by: Martin Krastev Link: https://patchwork.freedesktop.org/patch/msgid/20211206172620.3139754-5-zack@kde.org

drm/vmwgfx: Remove the dedicated memory accounting

2021-12-09T18:16:10Z

vmwgfx shared very elaborate memory accounting with ttm. It was moved from ttm to vmwgfx in change f07069da6b4c ("drm/ttm: move memory accounting into vmwgfx v4") but because of complexity it was hard to maintain. Some parts of the code weren't freeing memory correctly and some were missing accounting all together. While those would be fairly easy to fix the fundamental reason for memory accounting in the driver was the ability to invoke shrinker which is part of TTM code as well (with support for unified memory hopefully coming soon). That meant that vmwgfx had a lot of code that was either unused or duplicating code from TTM. Removing this code also prevents excessive calls to global swapout which were common during memory pressure because both vmwgfx and TTM would invoke the shrinker when memory usage reached half of RAM. Fixes: f07069da6b4c ("drm/ttm: move memory accounting into vmwgfx v4") Signed-off-by: Zack Rusin Reviewed-by: Martin Krastev Link: https://patchwork.freedesktop.org/patch/msgid/20211206172620.3139754-2-zack@kde.org

drm/vmwgfx: Copy DRM hash-table code into driver

2021-11-30T08:41:25Z

Besides some legacy code, vmwgfx is the only user of DRM's hash- table implementation. Copy the code into the driver, so that the core code can be retired. No functional changes. However, the real solution for vmwgfx is to use Linux' generic hash-table functions. v2: * add TODO item for updating vmwgfx (Sam) Signed-off-by: Thomas Zimmermann Acked-by: Daniel Vetter Acked-by: Alex Deucher Link: https://patchwork.freedesktop.org/patch/msgid/20211129094841.22499-3-tzimmermann@suse.de

drm/vmwgfx: Update device headers

2021-06-16T18:27:00Z

Historically our device headers have been forked versions of the internal device headers, this has made maintaining them a bit of a burden. To fix the situation, going forward, the device headers will be verbatim copies of the internal headers. To do that the driver code has to be adapted to use pristine device headers. This will make future update to the device headers trivial and automatic. Signed-off-by: Zack Rusin Reviewed-by: Martin Krastev Link: https://patchwork.freedesktop.org/patch/msgid/20210615182336.995192-2-zackr@vmware.com