Re: [PATCH v3 2/5] drm/amdgpu: Throttle visible VRAM moves separately

On Thu, Jul 06, 2017 at 07:51:27PM +0900, Michel Dänzer wrote: > From: John Brooks <j...@fastquake.com> > > The BO move throttling code is designed to allow VRAM to fill quickly if it > is relatively empty. However, this does not take into account situations > where the vi

Re: [PATCH 0/5] amdgpu: Visible VRAM Management Improvements, next take

Details about changes in the individual patches. > > John Brooks (4): > drm/amdgpu: Add vis_vramlimit module parameter > drm/amdgpu: Throttle visible VRAM moves separately > drm/amdgpu: Set/clear CPU_ACCESS flag on page fault and move to VRAM > drm/amdgpu: Don't force BOs into visible VRA

Re: [PATCH v3 3/5] drm/amdgpu: Set/clear CPU_ACCESS flag on page fault and move to VRAM

On Thu, Jul 06, 2017 at 07:51:28PM +0900, Michel Dänzer wrote: > From: John Brooks <j...@fastquake.com> > > When a BO is moved to VRAM, clear AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED. > This allows it to potentially later move to invisible VRAM if the CPU > does not access i

Re: [PATCH 0/5] amdgpu: Visible VRAM Management Improvements, next take

On Tue, Jul 11, 2017 at 05:29:38PM +0900, Michel Dänzer wrote: > On 08/07/17 07:50 AM, John Brooks wrote: > > On Thu, Jul 06, 2017 at 07:51:25PM +0900, Michel Dänzer wrote: > >> From: Michel Dänzer <michel.daen...@amd.com> > >> > >> This is a rearrang

Re: [PATCH 4/5] drm/amdgpu: Set/clear CPU_ACCESS_REQUIRED flag on page fault and CS

On Thu, Jun 29, 2017 at 11:35:53AM +0900, Michel Dänzer wrote: > On 29/06/17 08:26 AM, John Brooks wrote: > > On Wed, Jun 28, 2017 at 03:05:32PM +0200, Christian König wrote: > >> Am 28.06.2017 um 04:33 schrieb John Brooks: > >>> When the AMDGPU_GEM_CREATE_CPU

Re: [PATCH 4/5] drm/amdgpu: Set/clear CPU_ACCESS_REQUIRED flag on page fault and CS

On 2017-06-29 09:56 PM, John Brooks wrote: On Thu, Jun 29, 2017 at 11:35:53AM +0900, Michel Dänzer wrote: On 29/06/17 08:26 AM, John Brooks wrote: On Wed, Jun 28, 2017 at 03:05:32PM +0200, Christian König wrote: Am 28.06.2017 um 04:33 schrieb John Brooks: When

Re: [PATCH 3/5] drm/amdgpu: Track time of last page fault and last CS move in struct amdgpu_bo

On Wed, Jun 28, 2017 at 03:06:47PM +0200, Christian König wrote: > Am 28.06.2017 um 04:33 schrieb John Brooks: > >Signed-off-by: John Brooks <j...@fastquake.com> > >--- > > drivers/gpu/drm/amd/amdgpu/amdgpu.h| 3 +++ > > drivers/gpu/drm/amd/amdgpu/amdgp

Re: [PATCH 4/5] drm/amdgpu: Set/clear CPU_ACCESS_REQUIRED flag on page fault and CS

On Wed, Jun 28, 2017 at 03:05:32PM +0200, Christian König wrote: > Am 28.06.2017 um 04:33 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 > >ac

[PATCH RFC 2/2] drm/amdgpu: Set/clear CPU_ACCESS flag on page fault and move to VRAM

VRAM, because amdgpu_ttm_placement_init() will do it for us. Signed-off-by: John Brooks <j...@fastquake.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 3 +++ drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 8 2 files changed, 11 insertions(+) diff --git a/drivers/gpu/drm/amd/

[PATCH RFC 1/2] drm/amdgpu: Add AMDGPU_BO_FLAG_CPU_ACCESS

constraint. Currently, however, it is treated no differently. Signed-off-by: John Brooks <j...@fastquake.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu.h| 3 +++ drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 9 - include/uapi/drm/amdgpu_drm.h | 1 + 3 files changed, 12 inse

[PATCH RFC 0/2] Re: Deprecation of AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED

> On 30/06/17 03:59 PM, Christian König wrote: >> Am 30.06.2017 um 08:51 schrieb Michel Dänzer: >>> We can deal with that internally in the kernel, while fixing the >>> existing flag for userspace. >> And as I said, NAK to that approach. I'm not going to add a >> CPU_ACCESS_REALLY_REQUIRED flag in

[PATCH RFC v2 1/2] drm/amdgpu: Add AMDGPU_BO_FLAG_CPU_ACCESS

constraint. Currently, however, it is treated no differently. v2: Put the new flag in amdgpu_drm.h, only clear CPU_ACCESS_REQUIRED if bo->tbo.type == ttm_bo_type_device (Christian König) Signed-off-by: John Brooks <j...@fastquake.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_obj

[PATCH 0/2] Fix a couple of amdgpu de-initialization failures

figure out why. But at least it unloads now. -- John Brooks (Frogging101) ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 2/2] drm/amdgpu: Don't call amd_powerplay_destroy() if we don't have powerplay

rm/amd/powerplay: refine powerplay interface.) Signed-off-by: John Brooks <j...@fastquake.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_powerplay.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_powerplay.c b/drivers/gpu/dr

[PATCH 1/2] drm/ttm: Fix use-after-free in ttm_bo_clean_mm

00 00 48 89 e5 e8 9f fe ff [149492.279557] ---[ end trace 2d4e0ffcb66a1016 ]--- Unref the fence *after* waiting for it. Fixes: aff98ba1fdb8 (drm/ttm: wait for eviction in ttm_bo_force_list_clean) Signed-off-by: John Brooks <j...@fastquake.com> --- drivers/gpu/drm/ttm/ttm_bo.c | 3 ++- 1

[PATCH v2 1/2] drm/ttm: Fix use-after-free in ttm_bo_clean_mm

00 00 48 89 e5 e8 9f fe ff [149492.279557] ---[ end trace 2d4e0ffcb66a1016 ]--- Unref the fence *after* waiting for it. v2: Set man->move to NULL after dropping the last ref (Christian König) Fixes: aff98ba1fdb8 (drm/ttm: wait for eviction in ttm_bo_force_list_clean) Signed-off-by: Jo

[PATCH v2 2/2] drm/amdgpu: Don't call amd_powerplay_destroy() if we don't have powerplay

rm/amd/powerplay: refine powerplay interface.) Signed-off-by: John Brooks <j...@fastquake.com> Acked-by: Christian König <christian.koe...@amd.com> Reviewed-by: Alex Deucher <alexander.deuc...@amd.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_powerplay.c | 3 ++- 1 file changed, 2 i

Re: [PATCH 0/5] amdgpu: Visible VRAM Management Improvements, next take

Details about changes in the individual patches. > > John Brooks (4): > drm/amdgpu: Add vis_vramlimit module parameter > drm/amdgpu: Throttle visible VRAM moves separately > drm/amdgpu: Set/clear CPU_ACCESS flag on page fault and move to VRAM > drm/amdgpu: Don't force BOs into visible VRA

[PATCH 5/9] drm/amdgpu: Track time of last page fault and last CS move in struct amdgpu_bo

Signed-off-by: John Brooks <j...@fastquake.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu.h| 3 +++ drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 5 + drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 ++ 3 files changed, 10 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgp

[PATCH 8/9] drm/amdgpu: Asynchronously move BOs to visible VRAM

and severity of visible-VRAM-related stuttering. Signed-off-by: John Brooks <j...@fastquake.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu.h| 5 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 14 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 45 ++ drive

[PATCH 1/9] drm/amdgpu: Separate placements and busy placements

This allows a BO to have busy placements that are not part of its normal placements. Users that want the busy placements to be the same can change the placement.busy_placement pointer and corresponding count to be the same as the regular placements. Signed-off-by: John Brooks <j...@fastquake.

[PATCH 6/9] drm/amdgpu: Set/clear CPU_ACCESS_REQUIRED flag on page fault and CS

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 <j...@fastquake.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 1 + drivers/gpu/drm/amd/

[PATCH 4/9] drm/amdgpu: Don't force BOs into visible VRAM if they can go to GTT instead

amdgpu_ttm_placement_init() callers that are using both VRAM and GTT as domains usually don't want visible VRAM as a busy placement. Signed-off-by: John Brooks <j...@fastquake.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 10 +- 1 file changed, 9 insertions(+), 1 de

[PATCH 7/9] drm/amdgpu: Throttle visible VRAM moves separately

)) Signed-off-by: John Brooks <j...@fastquake.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu.h| 6 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 76 +++--- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 10 ++-- 3 files changed, 70 insertions(+), 22 deletions(-) diff

[PATCH 2/9] drm/amdgpu: Add vis_vramlimit module parameter

Allow specifying a limit on visible VRAM via a module parameter. This is helpful for testing performance under visible VRAM pressure. Signed-off-by: John Brooks <j...@fastquake.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 4 drive

[PATCH 0/9] Visible VRAM Management Improvements

if visible VRAM is limited to 64MB. It also fixes severely low framerates that occurred in some areas of Dying Light. All my testing was done with an R9 290 with 4GB of visible VRAM with an Intel i7 4790. -- John Brooks (Frogging101) ___ amd-gfx mailing

[PATCH 3/9] drm/amdgpu: Don't force BOs into visible VRAM for page faults

-off-by: John Brooks <j...@fastquake.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 14 ++ 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c index 244a7d3..751bc05

Re: [PATCH 0/9] Visible VRAM Management Improvements

st for this series. Testing takes a long time and I wanted to focus those testing efforts as much as possible, produce something well-tested (I hope), and get feedback on this limited application of the concept before expanding its reach. John > > On 17-06-23 01:39 PM, John Brooks w

Re: [PATCH 0/9] Visible VRAM Management Improvements

On Sat, Jun 24, 2017 at 08:20:22PM +0200, Christian König wrote: > Am 24.06.2017 um 01:16 schrieb John Brooks: > >On Fri, Jun 23, 2017 at 05:02:58PM -0400, Felix Kuehling wrote: > >>Hi John, > >> > >>I haven't read your patches. Just a question based on the

Re: [PATCH 0/9] Visible VRAM Management Improvements

On Sat, Jun 24, 2017 at 08:07:15PM +0200, Christian König wrote: > Am 23.06.2017 um 19:39 schrieb John Brooks: > >This patch series is intended to improve performance when limited CPU-visible > >VRAM is under pressure. > > > >Moving BOs into visible VRAM is essentiall

Re: [PATCH 4/9] drm/amdgpu: Don't force BOs into visible VRAM if they can go to GTT instead

On Sat, Jun 24, 2017 at 08:09:56PM +0200, Christian König wrote: > Am 23.06.2017 um 19:39 schrieb John Brooks: > >amdgpu_ttm_placement_init() callers that are using both VRAM and GTT as > >domains usually don't want visible VRAM as a busy placement. > > > >Si

Re: [PATCH 3/3] drm/amdgpu: add gtt_sys_limit

On Mon, Jun 26, 2017 at 03:39:57PM +0200, Christian König wrote: > From: Christian König > > Limit the size of the GART table for the system domain. > > This saves us a bunch of visible VRAM, but also limitates the maximum BO size > we can swap out. > >

Re: [PATCH 3/9] drm/amdgpu: Don't force BOs into visible VRAM for page faults

On Mon, Jun 26, 2017 at 06:38:29PM +0900, Michel Dänzer wrote: > On 24/06/17 02:39 AM, John Brooks wrote: > > There is no need for page faults to force BOs into visible VRAM if it's > > full, and the time it takes to do so is great enough to cause noticeable > > stuttering.

Re: [PATCH 7/9] drm/amdgpu: Throttle visible VRAM moves separately

On Mon, Jun 26, 2017 at 06:44:30PM +0900, Michel Dänzer wrote: > On 24/06/17 02:39 AM, John Brooks wrote: > > The BO move throttling code is designed to allow VRAM to fill quickly if it > > is relatively empty. However, this does not take into account situations > > w

Re: [PATCH 6/9] drm/amdgpu: Set/clear CPU_ACCESS_REQUIRED flag on page fault and CS

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 > >ac

Re: [PATCH 3/3] drm/amdgpu: Try evicting from CPU visible to invisible VRAM first

you sure you want to hardcode the placements index? It'll be dependent on the order set up in amdgpu_ttm_placement_init. > + abo->placement.num_busy_placement = 1; > } else { > +gtt: > amdgpu_ttm_placement_from_domain(abo, > AMDGPU_GEM_DOMAIN_GTT

Re: [PATCH 0/3] drm/amdgpu: Tweaks for high pressure on CPU visible VRAM

On Mon, May 22, 2017 at 12:09:21PM +0200, Marek Olšák wrote: > On Mon, May 22, 2017 at 12:00 PM, Michel Dänzer wrote: > > On 20/05/17 06:26 PM, Marek Olšák wrote: > >> On May 20, 2017 3:26 AM, "Michel Dänzer" >> > wrote: > >> >

Re: [PATCH 0/3] drm/amdgpu: Tweaks for high pressure on CPU visible VRAM

On Fri, May 19, 2017 at 05:24:36PM +0200, Marek Olšák wrote: > Where is your "attached" patch? > > Marek It's actually a reply to my message. Sorry if that was unclear. > > On Fri, May 19, 2017 at 5:04 AM, John Brooks <j...@fastquake.com> wrote: > > I'm

Re: [PATCH 3/3] drm/amdgpu: Try evicting from CPU visible to invisible VRAM first

On Fri, May 19, 2017 at 10:20:37AM +0900, Michel Dänzer wrote: > On 19/05/17 12:43 AM, John Brooks wrote: > > On Thu, May 18, 2017 at 06:08:09PM +0900, Michel Dänzer wrote: > >> From: Michel Dänzer <michel.daen...@amd.com> > &g

Re: [PATCH 0/3] drm/amdgpu: Tweaks for high pressure on CPU visible VRAM

/images/screen-dl-gtt_busy_only-20170518-192602.png http://www.fastquake.com/images/screen-dlsysprof-gttpatch-20170518-223200.png -- John Brooks (Frogging101) ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman

[PATCH] drm/amdgpu: Place new CPU-accessbile BOs in GTT if visible VRAM is full

Set GTT as the busy placement for newly created BOs that have the AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED flag, so that they don't cause established BOs to be evicted from visible VRAM. Signed-off-by: John Brooks <j...@fastquake.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_object.

Re: [PATCH] drm/amdgpu: Place new CPU-accessbile BOs in GTT if visible VRAM is full

On Fri, May 19, 2017 at 04:03:28PM +0900, Michel Dänzer wrote: > On 19/05/17 12:04 PM, John Brooks wrote: > > Set GTT as the busy placement for newly created BOs that have the > > AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED flag, so that they don't cause > > established BOs to be

[PATCH 1/5] drm/amdgpu: Add vis_vramlimit module parameter

Allow specifying a limit on visible VRAM via a module parameter. This is helpful for testing performance under visible VRAM pressure. v2: Add cast to 64-bit (Christian König) Signed-off-by: John Brooks <j...@fastquake.com> Reviewed-by: Michel Dänzer <michel.daen...@amd.com&

[PATCH 3/5] drm/amdgpu: Track time of last page fault and last CS move in struct amdgpu_bo

Signed-off-by: John Brooks <j...@fastquake.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu.h| 3 +++ drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 5 + drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 ++ 3 files changed, 10 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgp

[PATCH 4/5] drm/amdgpu: Set/clear CPU_ACCESS_REQUIRED flag on page fault and CS

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 <j...@fastquake.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 ++ drivers/gpu/drm/amd/

[PATCH 2/5] drm/amdgpu: Throttle visible VRAM moves separately

. (Michel Dänzer) Fixes: 95844d20ae02 (drm/amdgpu: throttle buffer migrations at CS using a fixed MBps limit (v2)) Signed-off-by: John Brooks <j...@fastquake.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu.h| 6 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c

[PATCH 5/5] drm/amdgpu: Don't force BOs into visible VRAM for page faults

-off-by: John Brooks <j...@fastquake.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 16 +--- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c index 658d7b1..a215d8c

[PATCH v2] Visible VRAM Management Improvements

side of this tradeoff we want to end up on for now. -- John Brooks (Frogging101) ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx