From: Zack Rusin <zackr@vmware.com>
To: <dri-devel@lists.freedesktop.org>
Cc: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
"Christian König" <christian.koenig@amd.com>
Subject: [PATCH v4] drm/ttm: Clarify that the TTM_PL_SYSTEM is under TTMs control
Date: Wed, 10 Nov 2021 09:50:34 -0500 [thread overview]
Message-ID: <20211110145034.487512-1-zackr@vmware.com> (raw)
In-Reply-To: <3687c5f0-edb9-3cdb-2bb7-e45549a1cfb8@amd.com>
TTM takes full control over TTM_PL_SYSTEM placed buffers. This makes
driver internal usage of TTM_PL_SYSTEM prone to errors because it
requires the drivers to manually handle all interactions between TTM
which can swap out those buffers whenever it thinks it's the right
thing to do and driver.
CPU buffers which need to be fenced and shared with accelerators should
be placed in driver specific placements that can explicitly handle
CPU/accelerator buffer fencing.
Currently, apart, from things silently failing nothing is enforcing
that requirement which means that it's easy for drivers and new
developers to get this wrong. To avoid the confusion we can document
this requirement and clarify the solution.
This came up during a discussion on dri-devel:
https://lore.kernel.org/dri-devel/232f45e9-8748-1243-09bf-56763e6668b3@amd.com
Signed-off-by: Zack Rusin <zackr@vmware.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
---
include/drm/ttm/ttm_placement.h | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/include/drm/ttm/ttm_placement.h b/include/drm/ttm/ttm_placement.h
index 76d1b9119a2b..8074d0f6cae5 100644
--- a/include/drm/ttm/ttm_placement.h
+++ b/include/drm/ttm/ttm_placement.h
@@ -35,6 +35,17 @@
/*
* Memory regions for data placement.
+ *
+ * Buffers placed in TTM_PL_SYSTEM are considered under TTMs control and can
+ * be swapped out whenever TTMs thinks it is a good idea.
+ * In cases where drivers would like to use TTM_PL_SYSTEM as a valid
+ * placement they need to be able to handle the issues that arise due to the
+ * above manually.
+ *
+ * For BO's which reside in system memory but for which the accelerator
+ * requires direct access (i.e. their usage needs to be synchronized
+ * between the CPU and accelerator via fences) a new, driver private
+ * placement that can handle such scenarios is a good idea.
*/
#define TTM_PL_SYSTEM 0
--
2.32.0
next prev parent reply other threads:[~2021-11-10 14:50 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-05 19:38 [PATCH v2 0/6] Support module unload and hotunplug Zack Rusin
2021-11-05 19:38 ` [PATCH v2 1/6] drm/vmwgfx: Remove the deprecated lower mem limit Zack Rusin
2021-11-05 19:38 ` [PATCH v2 2/6] drm/vmwgfx: Release ttm memory if probe fails Zack Rusin
2021-11-05 19:38 ` [PATCH v2 3/6] drm/vmwgfx: Fail to initialize on broken configs Zack Rusin
2021-11-05 19:38 ` [PATCH v2 4/6] drm/vmwgfx: Introduce a new placement for MOB page tables Zack Rusin
2021-11-05 19:38 ` [PATCH v2 5/6] drm/vmwgfx: Switch the internal BO's to ttm_bo_type_kernel Zack Rusin
2021-11-05 19:38 ` [PATCH v2 6/6] drm/ttm: Clarify that the TTM_PL_SYSTEM buffers need to stay idle Zack Rusin
2021-11-08 11:07 ` Christian König
2021-11-08 15:42 ` [PATCH v3] " Zack Rusin
2021-11-10 14:50 ` Zack Rusin [this message]
2021-11-11 16:44 ` [PATCH v4] drm/ttm: Clarify that the TTM_PL_SYSTEM is under TTMs control Zack Rusin
2021-11-13 11:26 ` Thomas Hellström
2021-11-16 7:19 ` Christian König
2021-11-16 7:43 ` Thomas Hellström
2021-11-16 8:20 ` Christian König
2021-11-16 8:33 ` Thomas Hellström
2021-11-16 8:54 ` Christian König
2021-11-16 9:00 ` Thomas Hellström
2021-11-16 9:09 ` Christian König
2021-11-16 15:49 ` Daniel Vetter
2021-11-16 15:53 ` Zack Rusin
2021-11-22 14:15 ` Christian König
2021-11-22 15:05 ` Zack Rusin
2021-11-24 8:22 ` Christian König
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=20211110145034.487512-1-zackr@vmware.com \
--to=zackr@vmware.com \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=thomas.hellstrom@linux.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox