From: Matthew Auld <matthew.auld@intel.com>
To: intel-xe@lists.freedesktop.org
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Subject: [Intel-xe] [PATCH v2 11/14] drm/xe/migrate: retain CCS aux state for vram -> vram
Date: Tue, 28 Feb 2023 10:41:34 +0000 [thread overview]
Message-ID: <20230228104137.80965-12-matthew.auld@intel.com> (raw)
In-Reply-To: <20230228104137.80965-1-matthew.auld@intel.com>
On small-bar we likely need to be able to deal with vram -> vram
transfers. During eviction, as an optimisation, we don't always
want/need to kick stuff into smem. Plus for some types of CCS surfaces,
where the clear color needs to be accessed from the CPU, we might need
to migrate it.
v2: (Lucas):
- s/lmem/vram/ in the commit message
- Tidy up the code a bit; use one emit_copy_ccs()
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
---
drivers/gpu/drm/xe/xe_migrate.c | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/xe/xe_migrate.c b/drivers/gpu/drm/xe/xe_migrate.c
index bc69ec17d5ad..94c85421e1a5 100644
--- a/drivers/gpu/drm/xe/xe_migrate.c
+++ b/drivers/gpu/drm/xe/xe_migrate.c
@@ -546,11 +546,19 @@ static u32 xe_migrate_ccs_copy(struct xe_migrate *m,
if (xe_device_has_flat_ccs(gt_to_xe(gt)) && !copy_ccs && dst_is_vram) {
/*
- * If the bo doesn't have any CCS metadata attached, we still
- * need to clear it for security reasons.
+ * If the src is already in vram, then it should already
+ * have been cleared by us, or has been populated by the
+ * user. Make sure we copy the CCS aux state as-is.
+ *
+ * Otherwise if the bo doesn't have any CCS metadata attached,
+ * we still need to clear it for security reasons.
*/
- emit_copy_ccs(gt, bb, dst_ofs, true, m->cleared_vram_ofs, false,
- dst_size);
+ u64 ccs_src_ofs = src_is_vram ? src_ofs : m->cleared_vram_ofs;
+
+ emit_copy_ccs(gt, bb,
+ dst_ofs, true,
+ ccs_src_ofs, src_is_vram, dst_size);
+
flush_flags = MI_FLUSH_DW_CCS;
} else if (copy_ccs) {
if (!src_is_vram)
--
2.39.2
next prev parent reply other threads:[~2023-02-28 10:42 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-28 10:41 [Intel-xe] [PATCH v2 00/14] small-bar support Matthew Auld
2023-02-28 10:41 ` [Intel-xe] [PATCH v2 01/14] drm/xe/display: fix IS_ALDERLAKE_P() Matthew Auld
2023-02-28 14:09 ` Maarten Lankhorst
2023-02-28 17:57 ` Matt Roper
2023-02-28 18:54 ` Lucas De Marchi
2023-02-28 10:41 ` [Intel-xe] [PATCH v2 02/14] drm/xe/display: fix bo leak when unloading module Matthew Auld
2023-02-28 10:41 ` [Intel-xe] [PATCH v2 03/14] drm/xe: prefer xe_bo_create_pin_map() Matthew Auld
2023-02-28 10:41 ` [Intel-xe] [PATCH v2 04/14] drm/xe/bo: explicitly reject zero sized BO Matthew Auld
2023-02-28 10:41 ` [Intel-xe] [PATCH v2 05/14] drm/xe/mmio: s/lmem/vram/ Matthew Auld
2023-02-28 10:41 ` [Intel-xe] [PATCH v2 06/14] drm/xe/vram: start tracking the io_size Matthew Auld
2023-02-28 10:41 ` [Intel-xe] [PATCH v2 07/14] drm/xe/buddy: remove the virtualized start Matthew Auld
2023-02-28 10:41 ` [Intel-xe] [PATCH v2 08/14] drm/xe/buddy: add visible tracking Matthew Auld
2023-02-28 14:24 ` Maarten Lankhorst
2023-02-28 15:05 ` Matthew Auld
2023-02-28 20:26 ` Maarten Lankhorst
2023-02-28 10:41 ` [Intel-xe] [PATCH v2 09/14] drm/xe/buddy: add compatible and intersects hooks Matthew Auld
2023-02-28 10:41 ` [Intel-xe] [PATCH v2 10/14] drm/xe/bo: support tiered vram allocation for small-bar Matthew Auld
2023-02-28 10:41 ` Matthew Auld [this message]
2023-02-28 10:41 ` [Intel-xe] [PATCH v2 12/14] drm/xe/display: annotate CC buffers with NEEDS_CPU_ACCESS Matthew Auld
2023-02-28 14:48 ` Maarten Lankhorst
2023-02-28 15:20 ` Matthew Auld
2023-03-02 11:51 ` Maarten Lankhorst
2023-03-03 12:12 ` Matthew Auld
2023-03-03 12:58 ` Maarten Lankhorst
2023-02-28 15:22 ` Matthew Auld
2023-02-28 10:41 ` [Intel-xe] [PATCH v2 13/14] drm/xe/uapi: add the userspace bits for small-bar Matthew Auld
2023-02-28 10:41 ` [Intel-xe] [PATCH v2 14/14] drm/xe: fully turn on small-bar support Matthew Auld
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230228104137.80965-12-matthew.auld@intel.com \
--to=matthew.auld@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=lucas.demarchi@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.