dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Felix Kuehling <Felix.Kuehling@amd.com>
To: amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Cc: Alex Sierra <alex.sierra@amd.com>
Subject: [PATCH 13/34] drm/amdkfd: add xnack enabled flag to kfd_process
Date: Wed, 14 Apr 2021 21:23:16 -0400	[thread overview]
Message-ID: <20210415012337.1755-14-Felix.Kuehling@amd.com> (raw)
In-Reply-To: <20210415012337.1755-1-Felix.Kuehling@amd.com>

From: Alex Sierra <alex.sierra@amd.com>

XNACK mode controls the SQ RETRY_DISABLE setting that determines,
whether recoverable page faults can be supported on GFXv9 hardware.
Only on Aldebaran we can support different processes running with
different XNACK modes. On older chips all processes must use the same
RETRY_DISABLE setting. However, processes not relying on recoverable
page faults can work with RETRY enabled. This means XNACK off is always
available as a fallback so we can use the same mode on all GPUs in a
process.

Signed-off-by: Alex Sierra <alex.sierra@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
---
 .../amd/amdkfd/kfd_device_queue_manager_v9.c  | 13 ++++-
 drivers/gpu/drm/amd/amdkfd/kfd_priv.h         |  4 ++
 drivers/gpu/drm/amd/amdkfd/kfd_process.c      | 53 +++++++++++++++++++
 3 files changed, 68 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_v9.c b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_v9.c
index eca6331efa94..b5c3d13643f1 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_v9.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_v9.c
@@ -61,10 +61,19 @@ static int update_qpd_v9(struct device_queue_manager *dqm,
 		qpd->sh_mem_config =
 				SH_MEM_ALIGNMENT_MODE_UNALIGNED <<
 					SH_MEM_CONFIG__ALIGNMENT_MODE__SHIFT;
-		if (dqm->dev->noretry &&
-		    !dqm->dev->use_iommu_v2)
+
+		if (dqm->dev->device_info->asic_family == CHIP_ALDEBARAN) {
+			/* Aldebaran can safely support different XNACK modes
+			 * per process
+			 */
+			if (!pdd->process->xnack_enabled)
+				qpd->sh_mem_config |=
+					1 << SH_MEM_CONFIG__RETRY_DISABLE__SHIFT;
+		} else if (dqm->dev->noretry &&
+			   !dqm->dev->use_iommu_v2) {
 			qpd->sh_mem_config |=
 				1 << SH_MEM_CONFIG__RETRY_DISABLE__SHIFT;
+		}
 
 		qpd->sh_mem_ape1_limit = 0;
 		qpd->sh_mem_ape1_base = 0;
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
index 1b829eef9e50..5c0efaaebd8c 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
@@ -824,6 +824,8 @@ struct kfd_process {
 	/* shared virtual memory registered by this process */
 	struct svm_range_list svms;
 	bool svm_disabled;
+
+	bool xnack_enabled;
 };
 
 #define KFD_PROCESS_TABLE_SIZE 5 /* bits: 32 entries */
@@ -883,6 +885,8 @@ struct kfd_process_device *kfd_get_process_device_data(struct kfd_dev *dev,
 struct kfd_process_device *kfd_create_process_device_data(struct kfd_dev *dev,
 							struct kfd_process *p);
 
+bool kfd_process_xnack_mode(struct kfd_process *p, bool supported);
+
 int kfd_reserved_mem_mmap(struct kfd_dev *dev, struct kfd_process *process,
 			  struct vm_area_struct *vma);
 
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
index 3bcde43ccd70..b6ba2b91bdc3 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
@@ -1193,6 +1193,56 @@ void kfd_process_set_trap_handler(struct qcm_process_device *qpd,
 	}
 }
 
+bool kfd_process_xnack_mode(struct kfd_process *p, bool supported)
+{
+	int i;
+
+	/* On most GFXv9 GPUs, the retry mode in the SQ must match the
+	 * boot time retry setting. Mixing processes with different
+	 * XNACK/retry settings can hang the GPU.
+	 *
+	 * Different GPUs can have different noretry settings depending
+	 * on HW bugs or limitations. We need to find at least one
+	 * XNACK mode for this process that's compatible with all GPUs.
+	 * Fortunately GPUs with retry enabled (noretry=0) can run code
+	 * built for XNACK-off. On GFXv9 it may perform slower.
+	 *
+	 * Therefore applications built for XNACK-off can always be
+	 * supported and will be our fallback if any GPU does not
+	 * support retry.
+	 */
+	for (i = 0; i < p->n_pdds; i++) {
+		struct kfd_dev *dev = p->pdds[i]->dev;
+
+		/* Only consider GFXv9 and higher GPUs. Older GPUs don't
+		 * support the SVM APIs and don't need to be considered
+		 * for the XNACK mode selection.
+		 */
+		if (dev->device_info->asic_family < CHIP_VEGA10)
+			continue;
+		/* Aldebaran can always support XNACK because it can support
+		 * per-process XNACK mode selection. But let the dev->noretry
+		 * setting still influence the default XNACK mode.
+		 */
+		if (supported &&
+		    dev->device_info->asic_family == CHIP_ALDEBARAN)
+			continue;
+
+		/* GFXv10 and later GPUs do not support shader preemption
+		 * during page faults. This can lead to poor QoS for queue
+		 * management and memory-manager-related preemptions or
+		 * even deadlocks.
+		 */
+		if (dev->device_info->asic_family >= CHIP_NAVI10)
+			return false;
+
+		if (dev->noretry)
+			return false;
+	}
+
+	return true;
+}
+
 /*
  * On return the kfd_process is fully operational and will be freed when the
  * mm is released
@@ -1232,6 +1282,9 @@ static struct kfd_process *create_process(const struct task_struct *thread)
 	if (err != 0)
 		goto err_init_apertures;
 
+	/* Check XNACK support after PDDs are created in kfd_init_apertures */
+	process->xnack_enabled = kfd_process_xnack_mode(process, false);
+
 	err = svm_range_list_init(process);
 	if (err)
 		goto err_init_svm_range_list;
-- 
2.31.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  parent reply	other threads:[~2021-04-15  1:24 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-15  1:23 [PATCH 00/34] Add HMM-based SVM memory manager to KFD v5 Felix Kuehling
2021-04-15  1:23 ` [PATCH 01/34] drm/amdkfd: helper to convert gpu id and idx Felix Kuehling
2021-04-15  1:23 ` [PATCH 02/34] drm/amdkfd: add svm ioctl API Felix Kuehling
2021-04-15  1:23 ` [PATCH 03/34] drm/amdkfd: register svm range Felix Kuehling
2021-04-15  1:23 ` [PATCH 04/34] drm/amdkfd: add svm ioctl GET_ATTR op Felix Kuehling
2021-04-15  1:23 ` [PATCH 05/34] drm/amdgpu: add common HMM get pages function Felix Kuehling
2021-04-15  1:23 ` [PATCH 06/34] drm/amdkfd: support larger svm range allocation Felix Kuehling
2021-04-15  1:23 ` [PATCH 07/34] drm/amdkfd: validate svm range system memory Felix Kuehling
2021-04-15  1:23 ` [PATCH 08/34] drm/amdkfd: deregister svm range Felix Kuehling
2021-04-15  1:23 ` [PATCH 09/34] drm/amdgpu: export vm update mapping interface Felix Kuehling
2021-04-15  1:23 ` [PATCH 10/34] drm/amdkfd: map svm range to GPUs Felix Kuehling
2021-04-15  1:23 ` [PATCH 11/34] drm/amdkfd: svm range eviction and restore Felix Kuehling
2021-04-15  1:23 ` [PATCH 12/34] drm/amdgpu: Enable retry faults unconditionally on Aldebaran Felix Kuehling
2021-04-15  1:23 ` Felix Kuehling [this message]
2021-04-15  1:23 ` [PATCH 14/34] drm/amdkfd: add ioctl to configure and query xnack retries Felix Kuehling
2021-04-15  1:23 ` [PATCH 15/34] drm/amdkfd: register HMM device private zone Felix Kuehling
2021-04-15  1:23 ` [PATCH 16/34] drm/amdkfd: validate vram svm range from TTM Felix Kuehling
2021-04-15  1:23 ` [PATCH 17/34] drm/amdkfd: support xgmi same hive mapping Felix Kuehling
2021-04-15  1:23 ` [PATCH 18/34] drm/amdkfd: copy memory through gart table Felix Kuehling
2021-04-15  1:23 ` [PATCH 19/34] drm/amdkfd: HMM migrate ram to vram Felix Kuehling
2021-04-15  1:23 ` [PATCH 20/34] drm/amdkfd: HMM migrate vram to ram Felix Kuehling
2021-04-15  1:23 ` [PATCH 21/34] drm/amdkfd: invalidate tables on page retry fault Felix Kuehling
2021-04-15  1:23 ` [PATCH 22/34] drm/amdgpu: enable 48-bit IH timestamp counter Felix Kuehling
2021-04-15  1:23 ` [PATCH 23/34] drm/amdkfd: page table restore through svm API Felix Kuehling
2021-04-15  1:23 ` [PATCH 24/34] drm/amdkfd: SVM API call to restore page tables Felix Kuehling
2021-04-15  1:23 ` [PATCH 25/34] drm/amdkfd: add svm_bo reference for eviction fence Felix Kuehling
2021-04-15  1:23 ` [PATCH 26/34] drm/amdgpu: add param bit flag to create SVM BOs Felix Kuehling
2021-04-15  1:23 ` [PATCH 27/34] drm/amdkfd: add svm_bo eviction mechanism support Felix Kuehling
2021-04-15  1:23 ` [PATCH 28/34] drm/amdgpu: svm bo enable_signal call condition Felix Kuehling
2021-04-15  1:23 ` [PATCH 29/34] drm/amdgpu: add svm_bo eviction to enable_signal cb Felix Kuehling
2021-04-15  1:23 ` [PATCH 30/34] drm/amdkfd: refine migration policy with xnack on Felix Kuehling
2021-04-15  1:23 ` [PATCH 31/34] drm/amdkfd: add svm range validate timestamp Felix Kuehling
2021-04-15  1:23 ` [PATCH 32/34] drm/amdkfd: multiple gpu migrate vram to vram Felix Kuehling
2021-04-15  1:23 ` [PATCH 33/34] drm/amdkfd: Add SVM API support capability bits Felix Kuehling
2021-04-15  1:23 ` [PATCH 34/34] drm/amdkfd: Add CONFIG_HSA_AMD_SVM Felix Kuehling
  -- strict thread matches above, loose matches on Subject: below --
2021-04-06  1:45 [PATCH 00/34] Add HMM-based SVM memory manager to KFD v4 Felix Kuehling
2021-04-06  1:46 ` [PATCH 13/34] drm/amdkfd: add xnack enabled flag to kfd_process Felix Kuehling

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=20210415012337.1755-14-Felix.Kuehling@amd.com \
    --to=felix.kuehling@amd.com \
    --cc=alex.sierra@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=dri-devel@lists.freedesktop.org \
    /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;
as well as URLs for NNTP newsgroup(s).