All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nirmoy Das <nirmoy.das@intel.com>
To: intel-xe@lists.freedesktop.org
Cc: Nirmoy Das <nirmoy.das@intel.com>,
	Michal Mrozek <michal.mrozek@intel.com>
Subject: [PATCH v6 5/5] drm/xe: Refactor default device atomic settings
Date: Tue, 30 Apr 2024 18:25:29 +0200	[thread overview]
Message-ID: <20240430162529.21588-6-nirmoy.das@intel.com> (raw)
In-Reply-To: <20240430162529.21588-1-nirmoy.das@intel.com>

The default behavior of device atomics depends on the
VM type and buffer allocation types. Device atomics are
expected to function with all types of allocations for
traditional applications/APIs. Additionally, in compute/SVM
API scenarios with fault mode or LR mode VMs, device atomics
must work with single-region allocations. In all other cases
device atomics should be disabled by default also on platforms
where we know device atomics doesn't on work on particular
allocations types.

v3: fault mode requires LR mode so only check for LR mode
    to determine compute API(Jose).
    Handle SMEM+LMEM BO's migration to LMEM where device
    atomics is expected to work. (Brian).
v2: Fix platform checks to correct atomics behaviour on PVC.

Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>
Acked-by: Michal Mrozek <michal.mrozek@intel.com>
---
 drivers/gpu/drm/xe/xe_pt.c | 37 ++++++++++++++++++++++++++++++++++---
 drivers/gpu/drm/xe/xe_vm.c |  2 +-
 2 files changed, 35 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/xe/xe_pt.c b/drivers/gpu/drm/xe/xe_pt.c
index 8d3765d3351e..87975e45622a 100644
--- a/drivers/gpu/drm/xe/xe_pt.c
+++ b/drivers/gpu/drm/xe/xe_pt.c
@@ -619,9 +619,40 @@ xe_pt_stage_bind(struct xe_tile *tile, struct xe_vma *vma,
 	struct xe_pt *pt = xe_vma_vm(vma)->pt_root[tile->id];
 	int ret;
 
-	if ((vma->gpuva.flags & XE_VMA_ATOMIC_PTE_BIT) &&
-	    (is_devmem || !IS_DGFX(xe)))
-		xe_walk.default_pte |= XE_USM_PPGTT_PTE_AE;
+	/**
+	 * Default atomic expectations for different allocation scenarios are as follows:
+	 *
+	 * 1. Traditional API: When the VM is not in LR mode:
+	 *    - Device atomics are expected to function with all allocations.
+	 *
+	 * 2. Compute/SVM API: When the VM is in LR mode:
+	 *    - Device atomics are the default behavior when the bo is placed in a single region.
+	 *    - In all other cases device atomics will be disabled with AE=0 until an application
+	 *      request differently using a ioctl like madvise.
+	 */
+	if (vma->gpuva.flags & XE_VMA_ATOMIC_PTE_BIT) {
+		if (xe_vm_in_lr_mode(xe_vma_vm(vma))) {
+			if (bo && xe_bo_has_single_placement(bo))
+				xe_walk.default_pte |= XE_USM_PPGTT_PTE_AE;
+			/**
+			 * If a SMEM+LMEM allocation is backed by SMEM, a device
+			 * atomics will cause a gpu page fault and which then
+			 * gets migrated to LMEM, bind such allocations with
+			 * device atomics enabled.
+			 */
+			else if (is_devmem && !xe_bo_has_single_placement(bo))
+				xe_walk.default_pte |= XE_USM_PPGTT_PTE_AE;
+		} else {
+			xe_walk.default_pte |= XE_USM_PPGTT_PTE_AE;
+		}
+
+		/**
+		 * Unset AE if the platform(PVC) doesn't support it on an
+		 * allocation
+		 */
+		if (!xe->info.has_device_atomics_on_smem && !is_devmem)
+			xe_walk.default_pte &= ~XE_USM_PPGTT_PTE_AE;
+	}
 
 	if (is_devmem) {
 		xe_walk.default_pte |= XE_PPGTT_PTE_DM;
diff --git a/drivers/gpu/drm/xe/xe_vm.c b/drivers/gpu/drm/xe/xe_vm.c
index f1357e2a3b10..d17192c8b7de 100644
--- a/drivers/gpu/drm/xe/xe_vm.c
+++ b/drivers/gpu/drm/xe/xe_vm.c
@@ -888,7 +888,7 @@ static struct xe_vma *xe_vma_create(struct xe_vm *vm,
 	for_each_tile(tile, vm->xe, id)
 		vma->tile_mask |= 0x1 << id;
 
-	if (GRAPHICS_VER(vm->xe) >= 20 || vm->xe->info.platform == XE_PVC)
+	if (vm->xe->info.has_atomic_enable_pte_bit)
 		vma->gpuva.flags |= XE_VMA_ATOMIC_PTE_BIT;
 
 	vma->pat_index = pat_index;
-- 
2.42.0


  parent reply	other threads:[~2024-04-30 16:40 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-30 16:25 [PATCH v6 0/5] Refactor default device atomic settings Nirmoy Das
2024-04-30 16:25 ` [PATCH v6 1/5] drm/xe: Introduce has_atomic_enable_pte_bit device info Nirmoy Das
2024-04-30 16:25 ` [PATCH v6 2/5] drm/xe: Move vm bind bo validation to a helper function Nirmoy Das
2024-04-30 16:25 ` [PATCH v6 3/5] drm/xe: Introduce has_device_atomics_on_smem device info Nirmoy Das
2024-04-30 16:25 ` [PATCH v6 4/5] drm/xe: Add function to check if BO has single placement Nirmoy Das
2024-04-30 16:25 ` Nirmoy Das [this message]
2024-05-03 15:39   ` [PATCH v6 5/5] drm/xe: Refactor default device atomic settings Zeng, Oak
2024-05-03 16:00     ` Nirmoy Das
2024-05-03 16:11       ` Zeng, Oak
2024-05-03 16:30         ` Nirmoy Das
2024-04-30 18:47 ` ✓ CI.Patch_applied: success for Refactor default device atomic settings (rev6) Patchwork
2024-04-30 18:48 ` ✓ CI.checkpatch: " Patchwork
2024-04-30 18:49 ` ✓ CI.KUnit: " Patchwork
2024-04-30 19:00 ` ✓ CI.Build: " Patchwork
2024-04-30 19:03 ` ✓ CI.Hooks: " Patchwork
2024-04-30 19:04 ` ✓ CI.checksparse: " Patchwork
2024-04-30 19:28 ` ✓ CI.BAT: " Patchwork
2024-04-30 22:20 ` ✓ CI.FULL: " Patchwork
2024-05-03  9:47 ` [PATCH v6 0/5] Refactor default device atomic settings Lionel Landwerlin
2024-05-03  9:54   ` Nirmoy Das
2024-05-06  7:13     ` Lionel Landwerlin
2024-05-06  9:25       ` Lionel Landwerlin
2024-05-06 16:21 ` Nirmoy Das

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=20240430162529.21588-6-nirmoy.das@intel.com \
    --to=nirmoy.das@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=michal.mrozek@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.