linux-dev/drivers/gpu/drm/vmwgfx/Makefile, branch master

drm/vmwgfx: Remove explicit transparent hugepages support

2021-12-17T15:34:27Z

Old versions of the svga device used to export virtual vram, handling of which was optimized on top of transparent hugepages support. Only very old devices (OpenGL 2.1 support and earlier) used this code and at this point performance differences are negligible. Because the code requires very old hardware versions to run it has been largely untested and unused for a long time. Furthermore removal of the ttm hugepages support in: commit 0d979509539e ("drm/ttm: remove ttm_bo_vm_insert_huge()") broke the coherency mode in vmwgfx when running with hugepages. Fixes: 0d979509539e ("drm/ttm: remove ttm_bo_vm_insert_huge()") Signed-off-by: Zack Rusin Cc: Jason Gunthorpe Cc: Thomas Hellström Cc: Christian König Cc: Daniel Vetter Reviewed-by: Martin Krastev Reviewed-by: Maaz Mombasawala Link: https://patchwork.freedesktop.org/patch/msgid/20211215184147.3688785-2-zack@kde.org (cherry picked from commit 49d535d64d52945e2c874f380705675e20a02b6a) Signed-off-by: Thomas Zimmermann

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: Introduce a new placement for MOB page tables

2021-12-01T16:58:35Z

For larger (bigger than a page) and noncontiguous mobs we have to create page tables that allow the host to find the memory. Those page tables just used regular system memory. Unfortunately in TTM those BO's are not allowed to be busy thus can't be fenced and we have to fence those bo's because we don't want to destroy the page tables while the host is still executing the command buffers which might be accessing them. To solve it we introduce a new placement VMW_PL_SYSTEM which is very similar to TTM_PL_SYSTEM except that it allows fencing. This fixes kernel oops'es during unloading of the driver (and pci hot remove/add) which were caused by busy BO's in TTM_PL_SYSTEM being present in the delayed deletion list in TTM (TTM_PL_SYSTEM manager is destroyed before the delayed deletions are executed) Signed-off-by: Zack Rusin Reviewed-by: Martin Krastev Cc: Christian König Cc: Thomas Hellström Link: https://patchwork.freedesktop.org/patch/msgid/20211105193845.258816-5-zackr@vmware.com

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: Simplify devcaps code

2021-06-12T04:00:48Z

Make devcaps code self-contained so that it's easier to cache and operate on them. As the number of devcaps got bigger the code dealing with them got more and more tricky. Lets create a central place to deal with all the complexity. This lets us remove the lock we used to require to deal with register write races because we only read the devcaps at initialization. Signed-off-by: Zack Rusin Reviewed-by: Roland Scheidegger Reviewed-by: Martin Krastev Link: https://patchwork.freedesktop.org/patch/msgid/20210609172307.131929-2-zackr@vmware.com

drm/vmwgfx: Remove the reservation semaphore

2021-05-11T17:37:15Z

Now since Christian reworked TTM to always keep objects on the LRU list unless they are pinned we shouldn't need the reservation semaphore. It makes the driver code a lot cleaner, especially because it was a little hard to reason when and where the reservation semaphore needed to be held. Signed-off-by: Zack Rusin Reviewed-by: Roland Scheidegger Link: https://patchwork.freedesktop.org/patch/msgid/20210505035740.286923-5-zackr@vmware.com

drm/vmwgfx: Make console emulation depend on DRM_FBDEV_EMULATION

2021-04-26T08:45:30Z

Respect DRM's kconfig setting for fbdev console emulation. If enabled, it will select all required config options. So remove them from vmwgfx's Kconfig file. Signed-off-by: Thomas Zimmermann Reviewed-by: Zack Rusin Link: https://patchwork.freedesktop.org/patch/msgid/20210415110040.23525-2-tzimmermann@suse.de

drm/ttm: move memory accounting into vmwgfx v4

2021-02-09T16:27:33Z

This is just another feature which is only used by VMWGFX, so move it into the driver instead. I've tried to add the accounting sysfs file to the kobject of the drm minor, but I'm not 100% sure if this works as expected. v2: fix typo in KFD and avoid 64bit divide v3: fix init order in VMWGFX v4: use pdev sysfs reference instead of drm Signed-off-by: Christian König Reviewed-by: Zack Rusin (v3) Tested-by: Nirmoy Das Link: https://patchwork.freedesktop.org/patch/msgid/20210208133226.36955-2-christian.koenig@amd.com

drm/vmwgfx: Cleanup the cmd/fifo split

2021-01-14T17:15:49Z

Lets try to cleanup the usage of the term FIFO which we used for both our MMIO based cmd queue processing and for general command processing which could have been using command buffers interface. We're going to rename the functions which are processing commands (and work either via MMIO or command buffers) as _cmd_ and functions which operate on the MMIO based commands as FIFO to match the SVGA device naming. Signed-off-by: Zack Rusin Reviewed-by: Martin Krastev Link: https://patchwork.freedesktop.org/patch/414044/?series=85516&rev=2