dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: John Brooks <john@fastquake.com>
To: "Christian König" <deathsimple@vodafone.de>
Cc: "Michel Dänzer" <michel@daenzer.net>,
	dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 6/9] drm/amdgpu: Set/clear CPU_ACCESS_REQUIRED flag on page fault and CS
Date: Sun, 25 Jun 2017 01:57:19 +0000	[thread overview]
Message-ID: <20170625015719.GA1567@kitsune.fastquake.com> (raw)
In-Reply-To: <55ea5e84-0791-5a70-6278-ade83c343a3b@vodafone.de>

On Sat, Jun 24, 2017 at 08:00:05PM +0200, Christian König wrote:
> Am 23.06.2017 um 19:39 schrieb John Brooks:
> >When the AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED flag is given by userspace,
> >it should only be treated as a hint to initially place a BO somewhere CPU
> >accessible, rather than having a permanent effect on BO placement.
> 
> And that is a clear NAK from my side.
> 
> CPU_ACCESS_REQUIRED is a permanent limitation to where the buffer should be
> placed.
> 
> Ignoring that and changing the IOCTL interface like this is clearly not
> acceptable.
> 
> Christian.
> 

In that case, I will remove this patch. But I will keep in some form the
safeguard against BOs oscillating between VRAM and GTT, as patch 3 allows page
faults to move BOs to GTT (more frequently than before, anyway). If userspace
has *not* marked said BOs with CPU_ACCESS_REQUIRED, amdgpu_cs_bo_validate will
move them to invisible VRAM, where they may promptly generate another page
fault. Cue framerate death. The same problem was seen last month in patch 2 of
the "Tweaks for high pressure on CPU visible VRAM" series.

John

> >
> >Instead of the flag being set in stone at BO creation, set the flag when a
> >page fault occurs so that it goes somewhere CPU-visible, and clear it when
> >the BO is requested by the GPU.
> >
> >However, clearing the CPU_ACCESS_REQUIRED flag may move a BO to invisible
> >VRAM, which is likely to cause a page fault that moves it right back to
> >GTT. When this happens too much, it is highly detrimental to performance.
> >Only clear the flag on CS if:
> >
> >- The BO wasn't page faulted for a certain amount of time (currently 10
> >   seconds, measured with jiffies), and
> >- its last page fault didn't occur too soon (currently 500ms) after its
> >   last CS request, or vice versa.
> >
> >Setting the flag in amdgpu_fault_reserve_notify() also means that we can
> >remove the loop to restrict lpfn to the end of visible VRAM, because
> >amdgpu_ttm_placement_init() will do it for us.
> >
> >Signed-off-by: John Brooks <john@fastquake.com>
> >---
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c     |  1 +
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 46 ++++++++++++++++++++++--------
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_object.h |  1 +
> >  3 files changed, 36 insertions(+), 12 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> >index 2fad8bd..73d6882 100644
> >--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> >+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> >@@ -320,6 +320,7 @@ static int amdgpu_cs_bo_validate(struct amdgpu_cs_parser *p,
> >  	else
> >  		domain = bo->allowed_domains;
> >+	amdgpu_bo_clear_cpu_access_required(bo);
> >  retry:
> >  	amdgpu_ttm_placement_from_domain(bo, domain);
> >  	initial_bytes_moved = atomic64_read(&adev->num_bytes_moved);
> >diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> >index 31d1f21..a7d48a7 100644
> >--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> >+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> >@@ -967,8 +967,8 @@ int amdgpu_bo_fault_reserve_notify(struct ttm_buffer_object *bo)
> >  {
> >  	struct amdgpu_device *adev = amdgpu_ttm_adev(bo->bdev);
> >  	struct amdgpu_bo *abo;
> >-	unsigned long offset, size, lpfn;
> >-	int i, r;
> >+	unsigned long offset, size;
> >+	int r;
> >  	if (!amdgpu_ttm_bo_is_amdgpu_bo(bo))
> >  		return 0;
> >@@ -991,18 +991,9 @@ int amdgpu_bo_fault_reserve_notify(struct ttm_buffer_object *bo)
> >  	/* hurrah the memory is not visible ! */
> >  	atomic64_inc(&adev->num_vram_cpu_page_faults);
> >+	abo->flags |= AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED;
> >  	amdgpu_ttm_placement_from_domain(abo, AMDGPU_GEM_DOMAIN_VRAM |
> >  					 AMDGPU_GEM_DOMAIN_GTT);
> >-	lpfn =	adev->mc.visible_vram_size >> PAGE_SHIFT;
> >-	for (i = 0; i < abo->placement.num_placement; i++) {
> >-		/* Try to move the BO into visible VRAM */
> >-		if ((abo->placements[i].flags & TTM_PL_FLAG_VRAM) &&
> >-		    (!abo->placements[i].lpfn ||
> >-		     abo->placements[i].lpfn > lpfn))
> >-			abo->placements[i].lpfn = lpfn;
> >-	}
> >-	abo->placement.busy_placement = abo->placement.placement;
> >-	abo->placement.num_busy_placement = abo->placement.num_placement;
> >  	r = ttm_bo_validate(bo, &abo->placement, false, false);
> >  	if (unlikely(r != 0))
> >  		return r;
> >@@ -1057,3 +1048,34 @@ u64 amdgpu_bo_gpu_offset(struct amdgpu_bo *bo)
> >  	return bo->tbo.offset;
> >  }
> >+
> >+/**
> >+ * amdgpu_bo_clear_cpu_access_required
> >+ * @bo: BO to update
> >+ *
> >+ * Clears CPU_ACCESS_REQUIRED flag if the BO hasn't had a page fault in a while
> >+ * and it didn't have a page fault too soon after the last time it was moved to
> >+ * VRAM.
> >+ *
> >+ * Caller should have bo reserved.
> >+ *
> >+ */
> >+void amdgpu_bo_clear_cpu_access_required(struct amdgpu_bo *bo)
> >+{
> >+	const unsigned int page_fault_timeout_ms = 10000;
> >+	const unsigned int min_period_ms = 500;
> >+	unsigned int ms_since_pf, period_ms;
> >+
> >+	ms_since_pf = jiffies_to_msecs(jiffies - bo->last_page_fault_jiffies);
> >+	period_ms = jiffies_to_msecs(abs(bo->last_page_fault_jiffies -
> >+					 bo->last_cs_move_jiffies));
> >+
> >+	/*
> >+	 * Try to avoid a revolving door between GTT and VRAM. Clearing the
> >+	 * flag may move this BO back to VRAM, so don't clear it if it's likely
> >+	 * to page fault and go right back to GTT.
> >+	 */
> >+	if ((!bo->last_page_fault_jiffies || !bo->last_cs_move_jiffies) ||
> >+	    (ms_since_pf > page_fault_timeout_ms && period_ms > min_period_ms))
> >+		bo->flags &= ~AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED;
> >+}
> >diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
> >index 3824851..b0cb137 100644
> >--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
> >+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
> >@@ -182,6 +182,7 @@ int amdgpu_bo_restore_from_shadow(struct amdgpu_device *adev,
> >  				  struct reservation_object *resv,
> >  				  struct dma_fence **fence,
> >  				  bool direct);
> >+void amdgpu_bo_clear_cpu_access_required(struct amdgpu_bo *bo);
> >  /*
> 
> 
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2017-06-25  1:57 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-23 17:39 [PATCH 0/9] Visible VRAM Management Improvements John Brooks
2017-06-23 17:39 ` [PATCH 3/9] drm/amdgpu: Don't force BOs into visible VRAM for page faults John Brooks
     [not found]   ` <1498239580-17360-4-git-send-email-john-xq/Ko7C6e2Bl57MIdRCFDg@public.gmane.org>
2017-06-26  9:38     ` Michel Dänzer
     [not found]       ` <f399c192-d90d-9f43-9b8a-820fa51a7715-otUistvHUpPR7s880joybQ@public.gmane.org>
2017-06-27  3:25         ` John Brooks
2017-06-23 17:39 ` [PATCH 5/9] drm/amdgpu: Track time of last page fault and last CS move in struct amdgpu_bo John Brooks
2017-06-23 17:39 ` [PATCH 9/9] drm/amdgpu: Reduce lock contention when evicting from visible VRAM John Brooks
     [not found] ` <1498239580-17360-1-git-send-email-john-xq/Ko7C6e2Bl57MIdRCFDg@public.gmane.org>
2017-06-23 17:39   ` [PATCH 1/9] drm/amdgpu: Separate placements and busy placements John Brooks
2017-06-23 17:39   ` [PATCH 2/9] drm/amdgpu: Add vis_vramlimit module parameter John Brooks
2017-06-26  9:48     ` Michel Dänzer
2017-06-26  9:57     ` Christian König
2017-06-23 17:39   ` [PATCH 4/9] drm/amdgpu: Don't force BOs into visible VRAM if they can go to GTT instead John Brooks
     [not found]     ` <1498239580-17360-5-git-send-email-john-xq/Ko7C6e2Bl57MIdRCFDg@public.gmane.org>
2017-06-24 18:09       ` Christian König
     [not found]         ` <0c5064f9-5b84-8833-b410-055b5e2064bf-ANTagKRnAhcb1SvskN2V4Q@public.gmane.org>
2017-06-24 18:37           ` John Brooks
2017-06-23 17:39   ` [PATCH 6/9] drm/amdgpu: Set/clear CPU_ACCESS_REQUIRED flag on page fault and CS John Brooks
     [not found]     ` <1498239580-17360-7-git-send-email-john-xq/Ko7C6e2Bl57MIdRCFDg@public.gmane.org>
2017-06-24 18:00       ` Christian König
2017-06-25  1:57         ` John Brooks [this message]
     [not found]         ` <55ea5e84-0791-5a70-6278-ade83c343a3b-ANTagKRnAhcb1SvskN2V4Q@public.gmane.org>
2017-06-26  9:27           ` Michel Dänzer
     [not found]             ` <6c6fca21-df95-a413-d5eb-c05f1913787b-otUistvHUpPR7s880joybQ@public.gmane.org>
2017-06-26 23:25               ` Marek Olšák
2017-06-23 17:39   ` [PATCH 7/9] drm/amdgpu: Throttle visible VRAM moves separately John Brooks
     [not found]     ` <1498239580-17360-8-git-send-email-john-xq/Ko7C6e2Bl57MIdRCFDg@public.gmane.org>
2017-06-26  9:44       ` Michel Dänzer
     [not found]         ` <c132d211-bb7c-1e7d-617a-6f128343a581-otUistvHUpPR7s880joybQ@public.gmane.org>
2017-06-26 22:29           ` John Brooks
2017-06-27  8:25             ` Michel Dänzer
2017-06-23 17:39   ` [PATCH 8/9] drm/amdgpu: Asynchronously move BOs to visible VRAM John Brooks
2017-06-23 21:02   ` [PATCH 0/9] Visible VRAM Management Improvements Felix Kuehling
     [not found]     ` <82339d2d-481c-ab3f-1590-ab22f0eac371-5C7GfCeVMHo@public.gmane.org>
2017-06-23 23:16       ` John Brooks
2017-06-24 18:20         ` Christian König
     [not found]           ` <644cf9b4-e22b-eab1-a505-b0e1f9850f82-ANTagKRnAhcb1SvskN2V4Q@public.gmane.org>
2017-06-24 21:50             ` John Brooks
2017-06-25 11:54               ` Christian König
2017-06-24 18:07   ` Christian König
     [not found]     ` <3cd916a7-6734-5eff-b645-66f3ee83f13a-ANTagKRnAhcb1SvskN2V4Q@public.gmane.org>
2017-06-24 18:36       ` John Brooks
2017-06-25 11:31         ` 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=20170625015719.GA1567@kitsune.fastquake.com \
    --to=john@fastquake.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=deathsimple@vodafone.de \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=michel@daenzer.net \
    /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).