summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/vmwgfx/vmwgfx_validation.h
AgeCommit message (Collapse)AuthorFilesLines
2021-12-09drm/vmwgfx: Remove the dedicated memory accountingZack Rusin1-46/+0
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 <zackr@vmware.com> Reviewed-by: Martin Krastev <krastevm@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211206172620.3139754-2-zack@kde.org
2021-11-30drm/vmwgfx: Copy DRM hash-table code into driverThomas Zimmermann1-3/+4
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 <tzimmermann@suse.de> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211129094841.22499-3-tzimmermann@suse.de
2019-11-06drm/vmwgfx: Implement an infrastructure for write-coherent resourcesThomas Hellstrom1-14/+2
This infrastructure will, for coherent resources, make sure that from the user-space point of view, data written by the CPU is immediately automatically available to the GPU at resource validation time. Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Matthew Wilcox <willy@infradead.org> Cc: Will Deacon <will.deacon@arm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Rik van Riel <riel@surriel.com> Cc: Minchan Kim <minchan@kernel.org> Cc: Michal Hocko <mhocko@suse.com> Cc: Huang Ying <ying.huang@intel.com> Cc: Jérôme Glisse <jglisse@redhat.com> Cc: Kirill A. Shutemov <kirill@shutemov.name> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Deepak Rawat <drawat@vmware.com>
2019-10-25drm/ttm: always keep BOs on the LRUChristian König1-1/+1
This allows blocking for BOs to become available in the memory management. Amdgpu is doing this for quite a while now during CS. Now apply the new behavior to all drivers using TTM. Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Thomas Hellstrom <thellstrom@vmware.com> Link: https://patchwork.freedesktop.org/patch/332878/
2019-08-15drm/vmwgfx: drop use of drmP.h in header filesSam Ravnborg1-1/+2
To facilitate removal of drmP.h in the .c files remove the use from header files first. Fix fallout in the other files. Sorted include files in blocks and sorted files within each block in alphabetical order. This revealed a dependency from an uapi header to a header located below drivers/gpu/drm/vmwgfx/. Added FIXME to remind someone to fix this. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Cc: VMware Graphics <linux-graphics-maintainer@vmware.com> Cc: Thomas Hellstrom <thellstrom@vmware.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Reviewed-by: Deepak Rawat <drawat@vmware.com> Signed-off-by: Deepak Rawat <drawat@vmware.com> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
2019-07-15Revert "Merge branch 'vmwgfx-next' of ↵Dave Airlie1-2/+14
git://people.freedesktop.org/~thomash/linux into drm-next" This reverts commit 031e610a6a21448a63dff7a0416e5e206724caac, reversing changes made to 52d2d44eee8091e740d0d275df1311fb8373c9a9. The mm changes in there we premature and not fully ack or reviewed by core mm folks, I dropped the ball by merging them via this tree, so lets take em all back out. Signed-off-by: Dave Airlie <airlied@redhat.com>
2019-06-18drm/vmwgfx: Implement an infrastructure for write-coherent resourcesThomas Hellstrom1-14/+2
This infrastructure will, for coherent resources, make sure that from the user-space point of view, data written by the CPU is immediately automatically available to the GPU at resource validation time. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Deepak Rawat <drawat@vmware.com>
2019-05-31drm/ttm: Make LRU removal optional v2Christian König1-1/+1
We are already doing this for DMA-buf imports and also for amdgpu VM BOs for quite a while now. If this doesn't run into any problems we are probably going to stop removing BOs from the LRU altogether. v2: drop BUG_ON from ttm_bo_add_to_lru Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Chunming Zhou <david1.zhou@amd.com> Tested-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-04-08drm/vmwgfx: Be more restrictive when dirtying resourcesThomas Hellstrom1-0/+7
Currently we flag resources as dirty (GPU contents not yet read back to the backing MOB) whenever they have been part of a command stream. Obviously many resources can't be dirty and others can only be dirty when written to by the GPU. That is when they are either bound to the context as render-targets, depth-stencil, copy / clear destinations and stream-output targets, or similarly when there are corresponding views into them. So mark resources dirty only in these special cases. Context- and cotable resources are always marked dirty when referenced. This is important for upcoming emulated coherent memory, since we can avoid issuing automatic readbacks to non-dirty resources when the CPU tries to access part of the backing MOB. Testing: Unigine Heaven with max GPU memory set to 256MB resulting in heavy resource thrashing. --- v2: Addressed review comments by Deepak Rawat. v3: Added some documentation Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Deepak Rawat <drawat@vmware.com>
2018-12-13drm/vmwgfx: Protect from excessive execbuf kernel memory allocations v3Thomas Hellstrom1-0/+37
With the new validation code, a malicious user-space app could potentially submit command streams with enough buffer-object and resource references in them to have the resulting allocated validion nodes and relocations make the kernel run out of GFP_KERNEL memory. Protect from this by having the validation code reserve TTM graphics memory when allocating. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Deepak Rawat <drawat@vmware.com> --- v2: Removed leftover debug printouts
2018-09-28drm/vmwgfx: Adapt validation code for reference-free lookupsThomas Hellstrom1-2/+17
Adapt the validation code so that vmw_validation_add[res|bo] can be called under an rcu read lock (non-sleeping) and with rcu-only protected resource- or buffer object pointers. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com>
2018-09-27drm/vmwgfx: Use a validation context allocator for relocations and validationsThomas Hellstrom1-1/+11
A common trait of these objects are that they are allocated during the command validation phase and freed after command submission. Furthermore they are accessed by a single thread only. So provide a simple unprotected stack-like allocator from which these objects can be allocated. Their memory is freed with the validation context when the command submission is done. Note that the mm subsystem maintains a per-cpu cache of single pages to make single page allocation and freeing efficient. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com>
2018-09-27drm/vmwgfx: Add a validation module v2Thomas Hellstrom1-0/+202
Isolate the functionality needed for reservation, validation and fencing of vmwgfx buffer objects and resources and publish an API for this. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com> Reviewed-by: Deepak Rawat <drawat@vmware.com> #v1