aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/vmwgfx/vmwgfx_so.c
diff options
context:
space:
mode:
authorThomas Hellstrom <thellstrom@vmware.com>2019-02-20 08:21:26 +0100
committerDeepak Rawat <drawat@vmware.com>2019-04-08 10:29:04 -0700
commita9f58c456e9dde6f272e7be4d6bed607fd7008aa (patch)
treea09c48c8624cd0630f88d4656aa9d4699ea1afae /drivers/gpu/drm/vmwgfx/vmwgfx_so.c
parentMerge tag 'drm-misc-next-2019-04-04' of git://anongit.freedesktop.org/drm/drm-misc into drm-next (diff)
downloadlinux-dev-a9f58c456e9dde6f272e7be4d6bed607fd7008aa.tar.xz
linux-dev-a9f58c456e9dde6f272e7be4d6bed607fd7008aa.zip
drm/vmwgfx: Be more restrictive when dirtying resources
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>
Diffstat (limited to 'drivers/gpu/drm/vmwgfx/vmwgfx_so.c')
-rw-r--r--drivers/gpu/drm/vmwgfx/vmwgfx_so.c24
1 files changed, 24 insertions, 0 deletions
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_so.c b/drivers/gpu/drm/vmwgfx/vmwgfx_so.c
index bc8bb690f1ea..4ef8460eaf2c 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_so.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_so.c
@@ -497,6 +497,30 @@ struct vmw_resource *vmw_view_lookup(struct vmw_cmdbuf_res_manager *man,
vmw_view_key(user_key, view_type));
}
+/**
+ * vmw_view_dirtying - Return whether a view type is dirtying its resource
+ * @res: Pointer to the view
+ *
+ * Each time a resource is put on the validation list as the result of a
+ * view pointing to it, we need to determine whether that resource will
+ * be dirtied (written to by the GPU) as a result of the corresponding
+ * GPU operation. Currently only rendertarget- and depth-stencil views are
+ * capable of dirtying its resource.
+ *
+ * Return: Whether the view type of @res dirties the resource it points to.
+ */
+u32 vmw_view_dirtying(struct vmw_resource *res)
+{
+ static u32 view_is_dirtying[vmw_view_max] = {
+ [vmw_view_rt] = VMW_RES_DIRTY_SET,
+ [vmw_view_ds] = VMW_RES_DIRTY_SET,
+ };
+
+ /* Update this function as we add more view types */
+ BUILD_BUG_ON(vmw_view_max != 3);
+ return view_is_dirtying[vmw_view(res)->view_type];
+}
+
const u32 vmw_view_destroy_cmds[] = {
[vmw_view_sr] = SVGA_3D_CMD_DX_DESTROY_SHADERRESOURCE_VIEW,
[vmw_view_rt] = SVGA_3D_CMD_DX_DESTROY_RENDERTARGET_VIEW,