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

Yeah, recently we indeed encountered an issue as below: On workstation machine it has 32G system memory and thus the GTT table size takes up about 192M visible VRAM. Maybe if system has bigger memory, GTT table size will exceed 256M, so Limitation for max GTT table size is very necessary.

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

Setting limitation for max GTT table size is necessary. But my only concern is that is it enough for amdgpu_gart_sys_limit 256M. whether it will trigger GTT eviction from GTT to CPU domain easily? Because GTT size always equals to VRAM size before it scales with system memory size. Thanks

[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 Reviewed-by: Michel Dänzer Reviewed-by:

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

Signed-off-by: John Brooks --- 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/amdgpu.h

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

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. Instead of the flag being set in stone at BO creation, set the flag when a page

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

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 visible VRAM is smaller than total VRAM, and total VRAM may not be close to full but the visible VRAM segment is under pressure. In such

[PATCH v2] Visible VRAM Management Improvements

Changes in this version: - Dropped former patch 1 ("Separate placements and busy placements") as it was no longer necessary - Dropped former patch 4 ("Don't force BOs into visible VRAM if they can go to GTT instead") as it was unnecessary and had too many side effects (Thanks Christian) -

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

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. Add GTT as a possible placement so that if visible VRAM is full, page faults move BOs to GTT instead of evicting other BOs from VRAM.

Re: [PATCH 1/3] drm/amdgpu: fix a typo

On 2017年06月28日 04:50, Bas Nieuwenhuizen wrote: On Tue, Jun 27, 2017 at 10:40 PM, Dave Airlie wrote: On 26 June 2017 at 19:10, zhoucm1 wrote: On 2017年06月26日 03:48, Dave Airlie wrote: Do you not use bo list at all in mesa? radv as well? Currently

Re: Question about porting VCE1 to amdgpu

On Tue, Jun 27, 2017 at 1:08 PM, Alexandre Demers wrote: > Just a quick update: things a getting into shape slowly since my paternal > vacancy is over, but I'm still progressing. I'm debugging things as I can. I > managed to work around the missing header with the

RE: [PATCH] drm/amdgpu: Changed CU reservation golden settings

> -Original Message- > From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf > Of ozeng > Sent: Tuesday, June 27, 2017 4:11 PM > To: amd-gfx@lists.freedesktop.org > Cc: Zeng, Oak > Subject: [PATCH] drm/amdgpu: Changed CU reservation golden settings > > With previous

[PATCH] drm/amdgpu: Changed CU reservation golden settings

With previous golden settings, compute task can't use reserved LDS (32K) on CU0 and CU1. On 64K LDS system, if compute work group allocate more than 32K LDS, then it can't be dispatched to CU0 and CU1 because of the reservation. This enables compute task to use reserved LDS on CU0 and CU1.

Re: [PATCH 1/3] drm/amdgpu: fix a typo

On Tue, Jun 27, 2017 at 10:40 PM, Dave Airlie wrote: > On 26 June 2017 at 19:10, zhoucm1 wrote: >> >> >> On 2017年06月26日 03:48, Dave Airlie wrote: Do you not use bo list at all in mesa? radv as well? >>> >>> Currently radv is creating a bo list

Re: [PATCH 1/3] drm/amdgpu: fix a typo

On 26 June 2017 at 19:10, zhoucm1 wrote: > > > On 2017年06月26日 03:48, Dave Airlie wrote: >>> >>> Do you not use bo list at all in mesa? radv as well? >> >> Currently radv is creating a bo list per command submission. radv does >> not use an offload thread to do command

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

On 17-06-27 04:01 AM, Christian König wrote: > Am 27.06.2017 um 04:57 schrieb Michel Dänzer: >> On 27/06/17 08:39 AM, John Brooks wrote: >>> On Mon, Jun 26, 2017 at 03:39:57PM +0200, Christian König wrote: From: Christian König Limit the size of the GART

Re: [PATCH v2] drm/core: Fail atomic IOCTL with no CRTC state but with signaling.

Op 27-06-17 om 09:37 schreef Daniel Vetter: > On Mon, Jun 26, 2017 at 03:44:07PM -0400, Harry Wentland wrote: >> On 2017-06-20 01:57 PM, Andrey Grodzovsky wrote: >>> Problem : While running IGT kms_atomic_transition test suite i encountered >>> a hang in drmHandleEvent immediately following an

RE: [PATCH 2/2] drm/amdgpu: add ACG SMU firmware for other vega10 variants

> -Original Message- > From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf > Of Evan Quan > Sent: Tuesday, June 27, 2017 2:36 AM > To: amd-gfx@lists.freedesktop.org > Cc: Quan, Evan > Subject: [PATCH 2/2] drm/amdgpu: add ACG SMU firmware for other vega10 > variants > >

Re: [PATCH xf86-video-ati 2/2] Improve drmmode_fb_reference debugging code

On Tue, Jun 27, 2017 at 5:38 AM, Michel Dänzer wrote: > From: Michel Dänzer > > If a reference count is <= 0, call FatalError with the call location > (in case it doesn't get resolved in the backtrace printed by > FatalError). > > (Ported from amdgpu

Re: [PATCH xf86-video-amdgpu] Only call drmmode_scanout_free for non-GPU screens in LeaveVT

On Tue, Jun 27, 2017 at 5:18 AM, Michel Dänzer wrote: > From: Michel Dänzer > > Destroying the scanout buffers of GPU screens resulted in a crash when > switching back to the Xorg VT. > > Fixes: b10ecdbd89b0 ("Use drmmode_crtc_scanout_* helpers for

Re: Spread spectrum AMD RX 470

On 2017-06-27 04:17 AM, Christian König wrote: > Hi Peter, > > Am 27.06.2017 um 09:07 schrieb Peter Blum: >> Hello, >> >> does any one know how to disable spread spectrum on the DP outputs >> of a AMD RX 47>> I tried to call the funktion >> amdgpu_atombios_crtc_program_ss(), but >> this seems to

[PATCH xf86-video-ati 2/2] Improve drmmode_fb_reference debugging code

From: Michel Dänzer If a reference count is <= 0, call FatalError with the call location (in case it doesn't get resolved in the backtrace printed by FatalError). (Ported from amdgpu commit 1b6ff5fd9933c00ec1ec90dfc62e0b531927749b) Signed-off-by: Michel Dänzer

[PATCH xf86-video-ati 1/2] Increase reference count of FB assigned to drmmode_crtc->flip_pending

From: Michel Dänzer Otherwise, it could happen that we destroy the FB before the flip completes, resulting in use-after-free and most likely a crash. (Ported from amdgpu commit af7221e1c4d2dbdfd488eb0976a835584ea8441c) Signed-off-by: Michel Dänzer

Re: [PATCH 5/8] drm/amd/sched: allow clients to edit an entity's rq v2

Am 26.06.2017 um 22:36 schrieb Andres Rodriguez: This is useful for changing an entity's priority at runtime. v2: don't modify the order of amd_sched_entity members Signed-off-by: Andres Rodriguez Reviewed-by: Christian König ---

Re: [PATCH v2] drm/amd/sched: print sched job id in amd_sched_job trace

Am 27.06.2017 um 10:49 schrieb Nicolai Hähnle: From: Nicolai Hähnle This makes it easier to correlate amd_sched_job with with other trace points that don't log the job pointer. v2: don't print the sched_job pointer (Andres) Signed-off-by: Nicolai Hähnle

[PATCH xf86-video-amdgpu] Only call drmmode_scanout_free for non-GPU screens in LeaveVT

From: Michel Dänzer Destroying the scanout buffers of GPU screens resulted in a crash when switching back to the Xorg VT. Fixes: b10ecdbd89b0 ("Use drmmode_crtc_scanout_* helpers for RandR 1.4 scanout pixmaps") (Ported from radeon commit

Re: [PATCH 2/8] drm/amdgpu: add framework for HW specific priority settings v9

Am 26.06.2017 um 22:36 schrieb Andres Rodriguez: Add an initial framework for changing the HW priorities of rings. The framework allows requesting priority changes for the lifetime of an amdgpu_job. After the job completes the priority will decay to the next lowest priority for which a request

[PATCH v2] drm/amd/sched: print sched job id in amd_sched_job trace

From: Nicolai Hähnle This makes it easier to correlate amd_sched_job with with other trace points that don't log the job pointer. v2: don't print the sched_job pointer (Andres) Signed-off-by: Nicolai Hähnle Reviewed-by: Andres Rodriguez

Re: Spread spectrum AMD RX 470

Hi Peter, Am 27.06.2017 um 09:07 schrieb Peter Blum: Hello, does any one know how to disable spread spectrum on the DP outputs of a AMD RX 470? I tried to call the funktion amdgpu_atombios_crtc_program_ss(), but this seems to do not work any more. Are there any other solutions? adding the

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

On 27/06/17 07:29 AM, John Brooks wrote: > 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

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

Am 26.06.2017 um 22:12 schrieb Felix Kuehling: I'm wondering what makes this possible. Let me quote the last discussion we had about GART: On 17-04-04 06:26 PM, Felix Kuehling wrote: Even with GART address space being allocated on demand, it still seems to be limiting the maximum available

[PATCH 2/2] drm/amdgpu: add ACG SMU firmware for other vega10 variants

Change-Id: Id15108d2dc192b2d6e80b07369cb9b01098687b2 Signed-off-by: Evan Quan --- drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c | 8 +++- drivers/gpu/drm/amd/amdgpu/soc15.c| 2 -- drivers/gpu/drm/amd/powerplay/smumgr/smumgr.c | 3 ++- 3 files changed, 9

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

Am 27.06.2017 um 04:57 schrieb Michel Dänzer: On 27/06/17 08:39 AM, John Brooks wrote: 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

Re: [PATCH v2] drm/core: Fail atomic IOCTL with no CRTC state but with signaling.

On Mon, Jun 26, 2017 at 03:44:07PM -0400, Harry Wentland wrote: > On 2017-06-20 01:57 PM, Andrey Grodzovsky wrote: > > Problem : While running IGT kms_atomic_transition test suite i encountered > > a hang in drmHandleEvent immediately following an atomic_commit. > > After dumping the atomic state

Re: [Nouveau] [PATCH v2 00/14] improve the fb_setcmap helper

On Tue, Jun 27, 2017 at 05:50:38AM +1000, Dave Airlie wrote: > > > > I'm traveling and cannot make progress this week. The merge window is > > also real close so this series will therefore probably miss it unless > > something unexpected happens... > > Don't worry you missed the merge window for

[PATCH 1/2] drm/amdgpu: drop SMU_DRIVER_IF_VERSION check for some vega10 variants

Change-Id: I68d47d2f9c9021514543ac9386012cc4056b2fe5 Signed-off-by: Evan Quan --- .../gpu/drm/amd/powerplay/smumgr/vega10_smumgr.c | 30 +- 1 file changed, 24 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/vega10_smumgr.c