Re: [PATCH] drm/amdgpu: fix typo in amdgpu_vce_validate_bo

[Andy Furniss]

Christian König wrote:

Otherwise buffer placement is very restrictive and might fail.

Fixes: "drm/amdgpu: fix VCE buffer placement restrictions v2"

Signed-off-by: Christian König 
Reported-by: Deng, Emily 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
index 55a726a322e3..d274ae535530 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
@@ -585,8 +585,8 @@ static int amdgpu_vce_validate_bo(struct amdgpu_cs_parser 
*p, uint32_t ib_idx,
  
  	for (i = 0; i < bo->placement.num_placement; ++i) {

bo->placements[i].fpfn = max(bo->placements[i].fpfn, fpfn);
-   bo->placements[i].lpfn = bo->placements[i].fpfn ?
-   min(bo->placements[i].fpfn, lpfn) : lpfn;
+   bo->placements[i].lpfn = bo->placements[i].lpfn ?
+   min(bo->placements[i].lpfn, lpfn) : lpfn;
}
return ttm_bo_validate(>tbo, >placement, );
  }


This fixes VCE for me, also with this I can again test

https://bugs.freedesktop.org/show_bug.cgi?id=102296

which also seems good now. I'll close that after I am sure I am testing 
correctly.



___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 4/4] drm/amdgpu: fix VCE buffer placement restrictions

[Andy Furniss]

Christian König wrote:

Leo and Andy could you two give that patch set a try?

It should fix occasional VCE fall outs when by coincident a buffers is 
placed on a 4GB boundary.


On drm-next-4.15 vanilla the corruption like in -

https://bugs.freedesktop.org/show_bug.cgi?id=102296

is still present

On both vanilla and patched kernels "lesser" test cases work OK.

With the same test case as the bug (gstreamer encoding 500 frames 2160p 
nv12 in ram) with the patches I get


amdgpu: Not enough memory for command submission.
0:00:01.551998246  1092  0x238bd40 ERRORvaapiencode 
gstvaapiencode.c:214:gst_vaapiencode_default_alloc_buffer: invalid 
GstVaapiCodedBuffer size (0 bytes)
0:00:01.552090124  1092  0x238bd40 ERRORvaapiencode 
gstvaapiencode.c:332:gst_vaapiencode_push_frame: failed to allocate 
encoded buffer in system memory

amdgpu: The CS has been cancelled because the context is lost.
amdgpu: The CS has been cancelled because the context is lost.
amdgpu: The CS has been cancelled because the context is lost.
amdgpu: The CS has been cancelled because the context is lost.
amdgpu: The CS has been cancelled because the context is lost.
amdgpu: The CS has been cancelled because the context is lost.
amdgpu: The CS has been cancelled because the context is lost.
amdgpu: The CS has been cancelled because the context is lost.
amdgpu: The CS has been cancelled because the context is lost.
amdgpu: The CS has been cancelled because the context is lost.
amdgpu: The CS has been cancelled because the context is lost.
amdgpu: The CS has been cancelled because the context is lost.

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: CPU usage/threading on agd5f 4.15-wip

[Andy Furniss]

Andy Furniss wrote:
On 4.15-wip with patches that make powerplay work I have an issue with 
one game = unreal tournament alpha.


This doesn't seem to affect other things like xonotic or unigine demos.

Issue = on fixes 4.14 and other older kernels I've tried, the game is OK 
ish perf wise, 20-40 fps.


On 4.15-wip its 10fps. Using HUD one obvious difference is that the slow 
case is only mostly using one cpu core, on a good kernel all 4 of my old 
phenom 2 x4 are used.


Both kernels seem based on 4.13-rc5 so I guess it's something amdgpu.

Trouble is, I can't bisect 4.15-wip, going back near or > 200 commits I 
lock soon after startx.


So is there any change devs can think of that would cause this?


I filed a bug for this so I could upload some screen shots.

Issue remains with updated 4.15-wip.

https://bugs.freedesktop.org/show_bug.cgi?id=103175

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

CPU usage/threading on agd5f 4.15-wip

[Andy Furniss]

On 4.15-wip with patches that make powerplay work I have an issue with 
one game = unreal tournament alpha.


This doesn't seem to affect other things like xonotic or unigine demos.

Issue = on fixes 4.14 and other older kernels I've tried, the game is OK 
ish perf wise, 20-40 fps.


On 4.15-wip its 10fps. Using HUD one obvious difference is that the slow 
case is only mostly using one cpu core, on a good kernel all 4 of my old 
phenom 2 x4 are used.


Both kernels seem based on 4.13-rc5 so I guess it's something amdgpu.

Trouble is, I can't bisect 4.15-wip, going back near or > 200 commits I 
lock soon after startx.


So is there any change devs can think of that would cause this?
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 2/2] drm/amd/powerplay: fix mclk can't switch on Tonga

[Andy Furniss]

These also fix for me.
Testing with 4.15-wip I also need the partial revert patch.

Tom St Denis wrote:

Hi Rex,

Thanks.  Everything seems to be functional again on my Tonga.

Cheers,
Tom

On 06/10/17 01:18 AM, Rex Zhu wrote:

regresstion issue caused by
commit 47047263c52779f1f3393c32e3e53661b53a372e
("drm/amd/powerplay: delete eventmgr related files.")

Change-Id: Ia2ddf83443a666fd1e97ddf4142acce147be00dc
Signed-off-by: Rex Zhu 
---
  drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c  | 1 -
  drivers/gpu/drm/amd/powerplay/hwmgr/pp_psm.c | 6 +-
  2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c

index 35e80c9..ce59e0e 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
@@ -292,7 +292,6 @@ int hwmgr_hw_fini(struct pp_instance *handle)
  phm_stop_thermal_controller(hwmgr);
  psm_set_boot_states(hwmgr);
-phm_display_configuration_changed(hwmgr);
  psm_adjust_power_state_dynamic(hwmgr, false, NULL);
  phm_disable_dynamic_state_management(hwmgr);
  phm_disable_clock_power_gatings(hwmgr);
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/pp_psm.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/pp_psm.c

index 167cdc3..ffa44bb 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/pp_psm.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/pp_psm.c
@@ -224,6 +224,8 @@ int psm_adjust_power_state_dynamic(struct pp_hwmgr 
*hwmgr, bool skip,

  if (skip)
  return 0;
+phm_display_configuration_changed(hwmgr);
+
  if (new_ps != NULL)
  requested = new_ps;
  else
@@ -232,7 +234,6 @@ int psm_adjust_power_state_dynamic(struct pp_hwmgr 
*hwmgr, bool skip,

  pcurrent = hwmgr->current_ps;
  phm_apply_state_adjust_rules(hwmgr, requested, pcurrent);
-
  if (pcurrent == NULL || (0 != phm_check_states_equal(hwmgr,
  >hardware, >hardware, )))
  equal = false;
@@ -241,6 +242,9 @@ int psm_adjust_power_state_dynamic(struct pp_hwmgr 
*hwmgr, bool skip,
  phm_set_power_state(hwmgr, >hardware, 
>hardware);

  memcpy(hwmgr->current_ps, hwmgr->request_ps, hwmgr->ps_size);
  }
+
+phm_notify_smc_display_config_after_ps_adjustment(hwmgr);
+
  return 0;
  }



___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amd/powerplay: Partially revert changes and fix smu7_notify_smc_display()

[Andy Furniss]

For me testing on 4.15-wip with tonga it does "fix", but memclk is 
stuck, which would have avoided the lines had I forced it without this.


Maybe you see different on a different kernel - is memclk stuck for you 
with this?


Tom St Denis wrote:

This partially reverts 0b6b4cbf77c995a34a4ec3d705a636434dadc51a and fixes
the noise issues on Tonga.

Signed-off-by: Tom St Denis 
---
  drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 7 ++-
  1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
index 8dbe9148aad3..4826b2991b7e 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
@@ -3825,14 +3825,11 @@ static int 
smu7_notify_link_speed_change_after_state_change(
  static int smu7_notify_smc_display(struct pp_hwmgr *hwmgr)
  {
struct smu7_hwmgr *data = (struct smu7_hwmgr *)(hwmgr->backend);
-   int ret = 0;
  
-	if (hwmgr->feature_mask & PP_VBI_TIME_SUPPORT_MASK) {

+   if (hwmgr->feature_mask & PP_VBI_TIME_SUPPORT_MASK)
smum_send_msg_to_smc_with_parameter(hwmgr,
(PPSMC_Msg)PPSMC_MSG_SetVBITimeout, 
data->frame_time_x2);
-   ret = (smum_send_msg_to_smc(hwmgr, (PPSMC_Msg)PPSMC_HasDisplay) 
== 0) ?  0 : -EINVAL;
-   }
-   return ret;
+   return (smum_send_msg_to_smc(hwmgr, (PPSMC_Msg)PPSMC_HasDisplay) == 0) 
?  0 : -EINVAL;
  }
  
  static int smu7_set_power_state_tasks(struct pp_hwmgr *hwmgr, const void *input)




___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: Regressions in amd-staging-drm-next

[Andy Furniss]

Martin Babutzka wrote:

2. Flicker issue: As wrote in my last mail the amd-staging-drm-next 
causes heavy flickering horizontal lines. Had to do a large bisect

to find the bad commit. No idea what is precisely broken there but I
hope this helps to resolve it.


I bisected to the same commit for the flicker issue on tonga. I am not
sure it's that commit though, as forcing memclk fixes it and before that
commit memclk was stuck for me so may have been hiding the issue.

https://bugs.freedesktop.org/show_bug.cgi?id=102926

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amdgpu: use 256 bit buffers for all wb allocations

[Andy Furniss]

Alex Deucher wrote:

On Fri, Jul 28, 2017 at 6:08 PM, Andy Furniss <adf.li...@gmail.com> wrote:

Alex Deucher wrote:


May waste a bit of memory, but simplifies the interface
significantly.



Can't boot tonga with this (testing 4.14-wip)


Should be fixed with this patch.


Yes, OK with that, thanks.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amdgpu: use 256 bit buffers for all wb allocations

[Andy Furniss]

Alex Deucher wrote:

May waste a bit of memory, but simplifies the interface
significantly.


Can't boot tonga with this (testing 4.14-wip)

Jul 28 23:00:29 ph4 kernel: [drm] amdgpu kernel modesetting enabled.
Jul 28 23:00:29 ph4 kernel: [drm] initializing kernel modesetting (TONGA 
0x1002:0x6939 0x1458:0x229D 0x00).

Jul 28 23:00:29 ph4 kernel: [drm] register mmio base: 0xFEA0
Jul 28 23:00:29 ph4 kernel: [drm] register mmio size: 262144
Jul 28 23:00:29 ph4 kernel: [drm] probing gen 2 caps for device 
1002:5a16 = 31cd02/0

Jul 28 23:00:29 ph4 kernel: [drm] probing mlw for device 1002:5a16 = 31cd02
Jul 28 23:00:29 ph4 kernel: [drm] VCE enabled in physical mode
Jul 28 23:00:29 ph4 kernel: amdgpu :01:00.0: Invalid PCI ROM header 
signature: expecting 0xaa55, got 0x8b00

Jul 28 23:00:29 ph4 kernel: ATOM BIOS: 113-xxx-Xxx
Jul 28 23:00:29 ph4 kernel: [drm] GPU post is not needed
Jul 28 23:00:29 ph4 kernel: [drm] Changing default dispclk from 600Mhz 
to 625Mhz

Jul 28 23:00:29 ph4 kernel: [drm] vm size is 64 GB, block size is 13-bit
Jul 28 23:00:29 ph4 kernel: amdgpu :01:00.0: VRAM: 2048M 
0x00F4 - 0x00F47FFF (2048M used)
Jul 28 23:00:29 ph4 kernel: amdgpu :01:00.0: GTT: 256M 
0x - 0x0FFF

Jul 28 23:00:29 ph4 kernel: [drm] Detected VRAM RAM=2048M, BAR=256M
Jul 28 23:00:29 ph4 kernel: [drm] RAM width 256bits GDDR5
Jul 28 23:00:29 ph4 kernel: [TTM] Zone  kernel: Available graphics 
memory: 4069418 kiB
Jul 28 23:00:29 ph4 kernel: [TTM] Zone   dma32: Available graphics 
memory: 2097152 kiB

Jul 28 23:00:29 ph4 kernel: [TTM] Initializing pool allocator
Jul 28 23:00:29 ph4 kernel: [TTM] Initializing DMA pool allocator
Jul 28 23:00:29 ph4 kernel: [drm] amdgpu: 2048M of VRAM memory ready
Jul 28 23:00:29 ph4 kernel: [drm] amdgpu: 3072M of GTT memory ready.
Jul 28 23:00:29 ph4 kernel: [drm] GART: num cpu pages 65536, num gpu 
pages 65536
Jul 28 23:00:29 ph4 kernel: [drm] PCIE GART of 256M enabled (table at 
0x00F40004).
Jul 28 23:00:29 ph4 kernel: [drm] Supports vblank timestamp caching Rev 
2 (21.10.2013).
Jul 28 23:00:29 ph4 kernel: [drm] Driver supports precise vblank 
timestamp query.

Jul 28 23:00:29 ph4 kernel: amdgpu :01:00.0: amdgpu: using MSI.
Jul 28 23:00:29 ph4 kernel: [drm] amdgpu: irq initialized.
Jul 28 23:00:29 ph4 kernel: amdgpu: [powerplay] amdgpu: powerplay sw 
initialized

Jul 28 23:00:29 ph4 kernel: [drm] AMDGPU Display Connectors
Jul 28 23:00:29 ph4 kernel: [drm] Connector 0:
Jul 28 23:00:29 ph4 kernel: [drm]   DP-1
Jul 28 23:00:29 ph4 kernel: [drm]   HPD4
Jul 28 23:00:29 ph4 kernel: [drm]   DDC: 0x4868 0x4868 0x4869 0x4869 
0x486a 0x486a 0x486b 0x486b

Jul 28 23:00:29 ph4 kernel: [drm]   Encoders:
Jul 28 23:00:29 ph4 kernel: [drm] DFP1: INTERNAL_UNIPHY1
Jul 28 23:00:29 ph4 kernel: [drm] Connector 1:
Jul 28 23:00:29 ph4 kernel: [drm]   HDMI-A-1
Jul 28 23:00:29 ph4 kernel: [drm]   HPD5
Jul 28 23:00:29 ph4 kernel: [drm]   DDC: 0x4870 0x4870 0x4871 0x4871 
0x4872 0x4872 0x4873 0x4873

Jul 28 23:00:29 ph4 kernel: [drm]   Encoders:
Jul 28 23:00:29 ph4 kernel: [drm] DFP2: INTERNAL_UNIPHY1
Jul 28 23:00:29 ph4 kernel: [drm] Connector 2:
Jul 28 23:00:29 ph4 kernel: [drm]   DVI-D-1
Jul 28 23:00:29 ph4 kernel: [drm]   HPD1
Jul 28 23:00:29 ph4 kernel: [drm]   DDC: 0x4878 0x4878 0x4879 0x4879 
0x487a 0x487a 0x487b 0x487b

Jul 28 23:00:29 ph4 kernel: [drm]   Encoders:
Jul 28 23:00:29 ph4 kernel: [drm] DFP3: INTERNAL_UNIPHY
Jul 28 23:00:29 ph4 kernel: [drm] Connector 3:
Jul 28 23:00:29 ph4 kernel: [drm]   DVI-I-1
Jul 28 23:00:29 ph4 kernel: [drm]   HPD6
Jul 28 23:00:29 ph4 kernel: [drm]   DDC: 0x487c 0x487c 0x487d 0x487d 
0x487e 0x487e 0x487f 0x487f

Jul 28 23:00:29 ph4 kernel: [drm]   Encoders:
Jul 28 23:00:29 ph4 kernel: [drm] DFP4: INTERNAL_UNIPHY2
Jul 28 23:00:29 ph4 kernel: [drm] CRT1: INTERNAL_KLDSCP_DAC1
Jul 28 23:00:29 ph4 kernel: amdgpu :01:00.0: fence driver on ring 0 
use gpu addr 0x00400200, cpu addr 0x88022e059200
Jul 28 23:00:29 ph4 kernel: amdgpu :01:00.0: fence driver on ring 1 
use gpu addr 0x00400600, cpu addr 0x88022e059600
Jul 28 23:00:29 ph4 kernel: amdgpu :01:00.0: fence driver on ring 2 
use gpu addr 0x00400a00, cpu addr 0x88022e059a00
Jul 28 23:00:29 ph4 kernel: amdgpu :01:00.0: fence driver on ring 3 
use gpu addr 0x00400e00, cpu addr 0x88022e059e00
Jul 28 23:00:29 ph4 kernel: amdgpu :01:00.0: (-22) ring rptr_offs wb 
alloc failed
Jul 28 23:00:29 ph4 kernel: [drm:amdgpu_device_init [amdgpu]] *ERROR* 
sw_init of IP block  failed -22

Jul 28 23:00:29 ph4 kernel: amdgpu :01:00.0: amdgpu_init failed
Jul 28 23:00:29 ph4 kernel: [TTM] Finalizing pool allocator
Jul 28 23:00:29 ph4 kernel: [TTM] Finalizing DMA pool allocator
Jul 28 23:00:29 ph4 kernel: [TTM] Zone  kernel: Used memory at exit: 73 kiB
Jul 28 23:00:29 ph4 kernel: [TTM] Zone   dma32: Used memory at exit: 25 kiB
Jul 28 23:00:29 ph4 kernel: [drm] amdgpu: ttm finalized
Jul 

Re: [PATCH 6/6] drm/amdgpu: change gartsize default to 256MB

[Andy Furniss]

Andy Furniss wrote:
Bit late, but this causes a startup fail for me with r9 285 , nothing 
logged, just a blank screen when the driver loads.


Heads of both amd-staging-4.11 and drm-next-4.14-wip both failing.


Both branches are OK now after the latest updates.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 6/6] drm/amdgpu: change gartsize default to 256MB

[Andy Furniss]

Bit late, but this causes a startup fail for me with r9 285 , nothing 
logged, just a blank screen when the driver loads.


Heads of both amd-staging-4.11 and drm-next-4.14-wip both failing.

Deucher, Alexander wrote:

-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
Of Christian König
Sent: Friday, July 07, 2017 7:53 AM
To: amd-gfx@lists.freedesktop.org
Subject: [PATCH 6/6] drm/amdgpu: change gartsize default to 256MB

From: Christian König 

Limit the default GART size and save a lot of VRAM.

Signed-off-by: Christian König 


Patch 1-4, 6:
Reviewed-by: Alex Deucher 


---
  drivers/gpu/drm/amd/amdgpu/amdgpu.h|  2 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 12 +---
  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|  6 +++---
  drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c   |  9 +
  4 files changed, 10 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 94bbf71..2421b6a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -76,7 +76,7 @@
   */
  extern int amdgpu_modeset;
  extern int amdgpu_vram_limit;
-extern int amdgpu_gart_size;
+extern unsigned amdgpu_gart_size;
  extern int amdgpu_gtt_size;
  extern int amdgpu_moverate;
  extern int amdgpu_benchmarking;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 8ef7e5e..7a90dec 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -1128,13 +1128,11 @@ static void amdgpu_check_arguments(struct
amdgpu_device *adev)
amdgpu_sched_jobs =
roundup_pow_of_two(amdgpu_sched_jobs);
}

-   if (amdgpu_gart_size != -1) {
-   /* gtt size must be greater or equal to 32M */
-   if (amdgpu_gart_size < 32) {
-   dev_warn(adev->dev, "gart size (%d) too small\n",
-amdgpu_gart_size);
-   amdgpu_gart_size = -1;
-   }
+   if (amdgpu_gart_size < 32) {
+   /* gart size must be greater or equal to 32M */
+   dev_warn(adev->dev, "gart size (%d) too small\n",
+amdgpu_gart_size);
+   amdgpu_gart_size = 32;
}

if (amdgpu_gtt_size != -1 && amdgpu_gtt_size < 32) {
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index b7c6cee..559e092 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -74,7 +74,7 @@
  #define KMS_DRIVER_PATCHLEVEL 0

  int amdgpu_vram_limit = 0;
-int amdgpu_gart_size = -1; /* auto */
+unsigned amdgpu_gart_size = 256;
  int amdgpu_gtt_size = -1; /* auto */
  int amdgpu_moverate = -1; /* auto */
  int amdgpu_benchmarking = 0;
@@ -122,8 +122,8 @@ int amdgpu_lbpw = -1;
  MODULE_PARM_DESC(vramlimit, "Restrict VRAM for testing, in
megabytes");
  module_param_named(vramlimit, amdgpu_vram_limit, int, 0600);

-MODULE_PARM_DESC(gartsize, "Size of PCIE/IGP gart to setup in
megabytes (32, 64, etc., -1 = auto)");
-module_param_named(gartsize, amdgpu_gart_size, int, 0600);
+MODULE_PARM_DESC(gartsize, "Size of PCIE/IGP gart to setup in
megabytes (32, 64, etc.)");
+module_param_named(gartsize, amdgpu_gart_size, uint, 0600);

  MODULE_PARM_DESC(gttsize, "Size of the GTT domain in megabytes (-1 =
auto)");
  module_param_named(gttsize, amdgpu_gtt_size, int, 0600);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
index cb0814a..124b237 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
@@ -62,14 +62,7 @@
   */
  void amdgpu_gart_set_defaults(struct amdgpu_device *adev)
  {
-   /* unless the user had overridden it, set the gart
-* size equal to the 1024 or vram, whichever is larger.
-*/
-   if (amdgpu_gart_size == -1)
-   adev->mc.gart_size =
max((AMDGPU_DEFAULT_GTT_SIZE_MB << 20),
-   adev->mc.mc_vram_size);
-   else
-   adev->mc.gart_size = (uint64_t)amdgpu_gart_size << 20;
+   adev->mc.gart_size = (uint64_t)amdgpu_gart_size << 20;
  }

  /**
--
2.7.4

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx



___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [ANNOUNCE] xf86-video-amdgpu 1.3.0

[Andy Furniss]

Michel Dänzer wrote:


I'm pleased to announce the 1.3.0 release of xf86-video-amdgpu,



Highlights:

* Allow TearFree to be toggled at runtime via an RandR output property
  "TearFree". The xorg.conf option "TearFree" now controls the default
  value of the output properties.


Nice feature. Minor man page glitch = the line starting with 'on' in the
patch snippet below doesn't show up when viewed with man amdgpu.

+Set the default value of the per-output 'TearFree' property, which controls
+tearing prevention using the hardware page flipping mechanism. TearFree is
+on for any CRTC associated with one or more outputs with TearFree on. Two
+separate scanout buffers need to be allocated for each CRTC with TearFree
+on. While TearFree is on for any CRTC, it currently prevents clients 
from using
+DRI page flipping. If this option is set, the default value of the 
property is
+'on' or 'off' accordingly. If this option isn't set, the default value 
of the

+property is
+.B auto,
+which means that TearFree is on for outputs with rotation or other RandR
+transforms, and for RandR 1.4 slave outputs, otherwise off.






___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 4/4] drm/amdgpu: extend profiling mode.

[Andy Furniss]

Zhu, Rex wrote:

Sorry for the late response.

Yes, I set the fan speed to max in this patch when user set high performance.

Considering that: 1. set fan speed to max is helpful to let GPU run under 
highest clock as long as possible.
   2. avoid GPU rapid temperature rise in some case.


OK, I guess you know if it's needed or not.

It is somewhat annoying noise wise, maybe one day there will be a way 
for users to set fan back on auto?


Accepting I don't know how the h/w works your point 2 would imply that
with perf on auto doing something like running a benchmark that pegs
all the clocks high should also instantly force fan high?

I don't think that would be popular WRT noise.




Best Regards
Rex



-Original Message-
From: Andy Furniss [mailto:adf.li...@gmail.com]
Sent: Wednesday, February 01, 2017 11:37 PM
To: Alex Deucher
Cc: Zhu, Rex; amd-gfx list
Subject: Re: [PATCH 4/4] drm/amdgpu: extend profiling mode.

Alex Deucher wrote:

On Tue, Jan 31, 2017 at 6:19 PM, Andy Furniss <adf.li...@gmail.com> wrote:

Andy Furniss wrote:


Rex Zhu wrote:


in profiling mode, powerplay will fix power state as stable as
possible.and disable gfx cg and LBPW feature.

profile_standard: as a prerequisite, ensure power and thermal
sustainable, set clocks ratio as close to the highest clock ratio
as possible.
profile_min_sclk: fix mclk as profile_normal, set lowest sclk
profile_min_mclk: fix sclk as profile_normal, set lowest mclk
profile_peak: set highest sclk and mclk, power and thermal not
sustainable
profile_exit: exit profile mode. enable gfx cg/lbpw feature.



Testing R9 285 Tonga on drm-next-4.11-wip

This commit has the effect that doing

echo high >
/sys/class/drm/card0/device/power_dpm_force_performance_level

instantly forces fan to (I guess) max, where normally it doesn't
need anything like as fast with the clocks high when doing nothing else.



Ping - just in case this got missed, still the same on current
drm-next-4.11-wip


Just a heads up, Rex was looking at this, but it's Chinese New Year this week.


OK, thanks & Happy new year.




___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 4/4] drm/amdgpu: extend profiling mode.

[Andy Furniss]

Alex Deucher wrote:

On Tue, Jan 31, 2017 at 6:19 PM, Andy Furniss <adf.li...@gmail.com> wrote:

Andy Furniss wrote:


Rex Zhu wrote:


in profiling mode, powerplay will fix power state
as stable as possible.and disable gfx cg and LBPW feature.

profile_standard: as a prerequisite, ensure power and thermal
sustainable, set clocks ratio as close to the highest clock
ratio as possible.
profile_min_sclk: fix mclk as profile_normal, set lowest sclk
profile_min_mclk: fix sclk as profile_normal, set lowest mclk
profile_peak: set highest sclk and mclk, power and thermal not
sustainable
profile_exit: exit profile mode. enable gfx cg/lbpw feature.



Testing R9 285 Tonga on drm-next-4.11-wip

This commit has the effect that doing

echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level

instantly forces fan to (I guess) max, where normally it doesn't
need anything like as fast with the clocks high when doing nothing else.



Ping - just in case this got missed, still the same on current
drm-next-4.11-wip


Just a heads up, Rex was looking at this, but it's Chinese New Year this week.


OK, thanks & Happy new year.


___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 4/4] drm/amdgpu: extend profiling mode.

[Andy Furniss]

Andy Furniss wrote:

Rex Zhu wrote:

in profiling mode, powerplay will fix power state
as stable as possible.and disable gfx cg and LBPW feature.

profile_standard: as a prerequisite, ensure power and thermal
sustainable, set clocks ratio as close to the highest clock
ratio as possible.
profile_min_sclk: fix mclk as profile_normal, set lowest sclk
profile_min_mclk: fix sclk as profile_normal, set lowest mclk
profile_peak: set highest sclk and mclk, power and thermal not
sustainable
profile_exit: exit profile mode. enable gfx cg/lbpw feature.


Testing R9 285 Tonga on drm-next-4.11-wip

This commit has the effect that doing

echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level

instantly forces fan to (I guess) max, where normally it doesn't
need anything like as fast with the clocks high when doing nothing else.


Ping - just in case this got missed, still the same on current 
drm-next-4.11-wip



___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 4/4] drm/amdgpu: extend profiling mode.

[Andy Furniss]

Rex Zhu wrote:

in profiling mode, powerplay will fix power state
as stable as possible.and disable gfx cg and LBPW feature.

profile_standard: as a prerequisite, ensure power and thermal
sustainable, set clocks ratio as close to the highest clock
ratio as possible.
profile_min_sclk: fix mclk as profile_normal, set lowest sclk
profile_min_mclk: fix sclk as profile_normal, set lowest mclk
profile_peak: set highest sclk and mclk, power and thermal not
sustainable
profile_exit: exit profile mode. enable gfx cg/lbpw feature.


Testing R9 285 Tonga on drm-next-4.11-wip

This commit has the effect that doing

echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level

instantly forces fan to (I guess) max, where normally it doesn't
need anything like as fast with the clocks high when doing nothing else.

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 4/4] drm/amd/powerplay: add profiling mode in dpm level

[Andy Furniss]

Zhu, Rex wrote:

Thanks for quick response.


The patch doesn't apply directly to drm-next-4.10-wip, here's what I tested -


Sorry, it is because code base has been changed in my local.

Please review the attached patch.


The patch applies OK and produces an identical diff to the one I tested.



Best Regards
Rex


-Original Message-
From: Andy Furniss [mailto:adf.li...@gmail.com]
Sent: Monday, January 09, 2017 6:29 PM
To: Zhu, Rex; Alex Deucher
Cc: amd-gfx list
Subject: Re: [PATCH 4/4] drm/amd/powerplay: add profiling mode in dpm level

Hi, that change does fix it for me.

The patch doesn't apply directly to drm-next-4.10-wip, here's what I tested -

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
index 0345fbb..ac2e5f4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
@@ -162,7 +162,7 @@ static ssize_t
amdgpu_set_dpm_forced_performance_level(struct device *dev,
  }

  if (current_level == level)
-   return 0;
+   return count;

  if (level == AMD_DPM_FORCED_LEVEL_PROFILING)
  amdgpu_set_clockgating_state(adev, AMD_IP_BLOCK_TYPE_GFX,



Zhu, Rex wrote:

Thanks Andy,

The attached patch can fix this bug.
Please review.

Best Regards
Rex

-Original Message-
From: Andy Furniss [mailto:adf.li...@gmail.com]
Sent: Monday, January 09, 2017 4:18 AM
To: Alex Deucher; Zhu, Rex
Cc: amd-gfx list
Subject: Re: [PATCH 4/4] drm/amd/powerplay: add profiling mode in dpm
level

Alex Deucher wrote:

On Fri, Dec 23, 2016 at 3:45 AM, Rex Zhu <rex@amd.com> wrote:

Change-Id: I4a46440882cd94fe5e77e3f351aaccc218a2ece5


Patches 1-3:
Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>

patch 4:
Please add a better patch description and explain what profiling mode
is good for, etc.


This on drm-next-4.10-wip regresses setting profile a bit on R9285.

It works eg. if in auto then doing

echo high >
/sys/class/drm/card0/device/power_dpm_force_performance_level

is OK and echo auto  > ... is also OK.

The issue if I am in auto and echo auto >  then I don't get my prompt back.

echo high from elsewhere will make it return - but it doesn't set high.





___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 4/4] drm/amd/powerplay: add profiling mode in dpm level

[Andy Furniss]

Hi, that change does fix it for me.

The patch doesn't apply directly to drm-next-4.10-wip, here's what I 
tested -


diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c

index 0345fbb..ac2e5f4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
@@ -162,7 +162,7 @@ static ssize_t 
amdgpu_set_dpm_forced_performance_level(struct device *dev,

}

if (current_level == level)
-   return 0;
+   return count;

if (level == AMD_DPM_FORCED_LEVEL_PROFILING)
amdgpu_set_clockgating_state(adev, AMD_IP_BLOCK_TYPE_GFX,



Zhu, Rex wrote:

Thanks Andy,

The attached patch can fix this bug.
Please review.

Best Regards
Rex

-Original Message-
From: Andy Furniss [mailto:adf.li...@gmail.com]
Sent: Monday, January 09, 2017 4:18 AM
To: Alex Deucher; Zhu, Rex
Cc: amd-gfx list
Subject: Re: [PATCH 4/4] drm/amd/powerplay: add profiling mode in dpm level

Alex Deucher wrote:

On Fri, Dec 23, 2016 at 3:45 AM, Rex Zhu <rex@amd.com> wrote:

Change-Id: I4a46440882cd94fe5e77e3f351aaccc218a2ece5


Patches 1-3:
Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>

patch 4:
Please add a better patch description and explain what profiling mode
is good for, etc.


This on drm-next-4.10-wip regresses setting profile a bit on R9285.

It works eg. if in auto then doing

echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level

is OK and echo auto  > ... is also OK.

The issue if I am in auto and echo auto >  then I don't get my prompt back.

echo high from elsewhere will make it return - but it doesn't set high.



___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 4/4] drm/amd/powerplay: add profiling mode in dpm level

[Andy Furniss]

Alex Deucher wrote:

On Fri, Dec 23, 2016 at 3:45 AM, Rex Zhu  wrote:

Change-Id: I4a46440882cd94fe5e77e3f351aaccc218a2ece5


Patches 1-3:
Reviewed-by: Alex Deucher 

patch 4:
Please add a better patch description and explain what profiling mode
is good for, etc.


This on drm-next-4.10-wip regresses setting profile a bit on R9285.

It works eg. if in auto then doing

echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level

is OK and echo auto  > ... is also OK.

The issue if I am in auto and echo auto >  then I don't get my
prompt back.

echo high from elsewhere will make it return - but it doesn't set high.

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amdgpu: set bypass mode when uvd is idle.

[Andy Furniss]

Deucher, Alexander wrote:

-Original Message- From: amd-gfx
[mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Andy
Furniss Sent: Sunday, November 06, 2016 3:31 PM To: Zhu, Rex;
Deucher, Alexander; amd-gfx@lists.freedesktop.org Subject: Re:
[PATCH] drm/amdgpu: set bypass mode when uvd is idle.

Zhu, Rex wrote:

Is there any harm in just always putting it into bypass
mode or does it interact badly with PG?  Presumably it does
(otherwise we wouldn't need this patch), it would be good
to note why.


Rex: when UVD PG enabled, DCLK/VCLK will be turn off when uvd is
idle(DCLK=OFF). If we set bypass mode=1, dclk/vclk will be
bypassed to an external ‘Bypass’ clock(DCLK = 100MHz)

So it is unnecessary to set bypass mode when PG enabled.

+uvd_v5_0_set_bypass_mode(adev, !enable); This change is because
tom's commit 72cb64c1f6a3a8129af341e90418a687c4971a40 Fix the
sequence of UVD powergate function in smu7_clockgating.c.


I was about to file a bug till I tried this which fixes UVD perf on
my R9285 + agd5f drm-next-4.10-wip.

Additional unrelated question = I notice that UVD does not seem to
set other clocks quite high enough when used.

For playback the vo may bump things up a bit, but even then it can
be a bit borderline for playing high bitrate UHD with powerplay on
auto.

Pure decode benchmarks like

ffmpeg -hwaccel vdpau -i high-bitrate-2160p60-vid -pix_fmt nv12 -f
null -

go from 63 -> 81 fps, powerplay auto -> high.


The UVD and gfx clocks are separate.  The gfx load for video decode
operations is not generally great enough (CSC and maybe scaling) to
generate enough gfx load to boost the gfx clocks to their highest
level.  We plan to add an API to allow userspace applications to
request a minimum floor for specific contexts, but it hasn't been
implemented yet.  This is useful if you are trying to hit maximum
decode rates, but may not always be the best choice for power usage.
You really only want to set the clocks high enough to hit the target
frame rate.

Alex


OK, thanks for the info.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amdgpu: set bypass mode when uvd is idle.

[Andy Furniss]

Zhu, Rex wrote:

Is there any harm in just always putting it into bypass mode or
does it interact badly with PG?  Presumably it does (otherwise
we wouldn't need this patch), it would be good to note why.


Rex: when UVD PG enabled, DCLK/VCLK will be turn off when uvd is
idle(DCLK=OFF). If we set bypass mode=1, dclk/vclk will be bypassed
to an external ‘Bypass’ clock(DCLK = 100MHz)

So it is unnecessary to set bypass mode when PG enabled.

+uvd_v5_0_set_bypass_mode(adev, !enable); This change is because
tom's commit 72cb64c1f6a3a8129af341e90418a687c4971a40 Fix the
sequence of UVD powergate function in smu7_clockgating.c.


I was about to file a bug till I tried this which fixes UVD perf
on my R9285 + agd5f drm-next-4.10-wip.

Additional unrelated question = I notice that UVD does not seem
to set other clocks quite high enough when used.

For playback the vo may bump things up a bit, but even then it can be a bit
borderline for playing high bitrate UHD with powerplay on auto.

Pure decode benchmarks like

ffmpeg -hwaccel vdpau -i high-bitrate-2160p60-vid -pix_fmt nv12 -f null -

go from 63 -> 81 fps, powerplay auto -> high.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 4/4] drm/amdgpu: used cached gca values for vi_read_register

[Andy Furniss]

Alex Deucher wrote:

On Tue, Oct 11, 2016 at 7:48 PM, Andy Furniss <adf.li...@gmail.com> wrote:

The boot vce/uvd issue is fixed in 4.9-wip now, so I can boot latest but -

The segfault on startx is still there.


Fixed in v2.


Yea, all OK now.

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 2/2] drm/amdgpu: add VCE VM session tracking

[Andy Furniss]

Christian König wrote:

Andy & Leo could you give that a brief testing?


Seems to be OK for me.



I currently don't have a setup for encoding/transcoding clips.

Regards,
Christian.

Am 10.10.2016 um 18:45 schrieb Alex Deucher:

On Mon, Oct 10, 2016 at 9:40 AM, Christian König
 wrote:

From: Christian König 

Only compile tested, but should fix the problems with killing
VCE sessions in VM mode.

Signed-off-by: Christian König 

Series is:
Reviewed-by: Alex Deucher 


---
  drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c | 90
+
  drivers/gpu/drm/amd/amdgpu/amdgpu_vce.h |  1 +
  drivers/gpu/drm/amd/amdgpu/vce_v3_0.c   |  1 +
  3 files changed, 92 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
index 05a1ea9..3d6f86c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
@@ -792,6 +792,96 @@ out:
  }

  /**
+ * amdgpu_vce_cs_parse_vm - parse the command stream in VM mode
+ *
+ * @p: parser context
+ *
+ */
+int amdgpu_vce_ring_parse_cs_vm(struct amdgpu_cs_parser *p, uint32_t
ib_idx)
+{
+   struct amdgpu_ib *ib = >job->ibs[ib_idx];
+   int session_idx = -1;
+   uint32_t destroyed = 0;
+   uint32_t created = 0;
+   uint32_t allocated = 0;
+   uint32_t tmp, handle = 0;
+   int i, r = 0, idx = 0;
+
+   while (idx < ib->length_dw) {
+   uint32_t len = amdgpu_get_ib_value(p, ib_idx, idx);
+   uint32_t cmd = amdgpu_get_ib_value(p, ib_idx, idx + 1);
+
+   if ((len < 8) || (len & 3)) {
+   DRM_ERROR("invalid VCE command length
(%d)!\n", len);
+   r = -EINVAL;
+   goto out;
+   }
+
+   switch (cmd) {
+   case 0x0001: /* session */
+   handle = amdgpu_get_ib_value(p, ib_idx, idx +
2);
+   session_idx = amdgpu_vce_validate_handle(p,
handle,
+
);
+   if (session_idx < 0) {
+   r = session_idx;
+   goto out;
+   }
+   break;
+
+   case 0x0101: /* create */
+   created |= 1 << session_idx;
+   if (destroyed & (1 << session_idx)) {
+   destroyed &= ~(1 << session_idx);
+   allocated |= 1 << session_idx;
+
+   } else if (!(allocated & (1 << session_idx))) {
+   DRM_ERROR("Handle already in use!\n");
+   r = -EINVAL;
+   goto out;
+   }
+
+   break;
+
+   case 0x0201: /* destroy */
+   destroyed |= 1 << session_idx;
+   break;
+
+   default:
+   break;
+   }
+
+   if (session_idx == -1) {
+   DRM_ERROR("no session command at start of
IB\n");
+   r = -EINVAL;
+   goto out;
+   }
+
+   idx += len / 4;
+   }
+
+   if (allocated & ~created) {
+   DRM_ERROR("New session without create command!\n");
+   r = -ENOENT;
+   }
+
+out:
+   if (!r) {
+   /* No error, free all destroyed handle slots */
+   tmp = destroyed;
+   amdgpu_ib_free(p->adev, ib, NULL);
+   } else {
+   /* Error during parsing, free all allocated handle
slots */
+   tmp = allocated;
+   }
+
+   for (i = 0; i < AMDGPU_MAX_VCE_HANDLES; ++i)
+   if (tmp & (1 << i))
+   atomic_set(>adev->vce.handles[i], 0);
+
+   return r;
+}
+
+/**
   * amdgpu_vce_ring_emit_ib - execute indirect buffer
   *
   * @ring: engine to use
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.h
index 12729d2..44d49b5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.h
@@ -34,6 +34,7 @@ int amdgpu_vce_get_destroy_msg(struct amdgpu_ring
*ring, uint32_t handle,
bool direct, struct fence **fence);
  void amdgpu_vce_free_handles(struct amdgpu_device *adev, struct
drm_file *filp);
  int amdgpu_vce_ring_parse_cs(struct amdgpu_cs_parser *p, uint32_t
ib_idx);
+int amdgpu_vce_ring_parse_cs_vm(struct amdgpu_cs_parser *p, uint32_t
ib_idx);
  void amdgpu_vce_ring_emit_ib(struct amdgpu_ring *ring, struct
amdgpu_ib *ib,
  unsigned vm_id, bool ctx_switch);
  void amdgpu_vce_ring_emit_fence(struct amdgpu_ring *ring, u64 addr,
u64 seq,
diff --git a/drivers/gpu/drm/amd/amdgpu/vce_v3_0.c
b/drivers/gpu/drm/amd/amdgpu/vce_v3_0.c

Re: [PATCH 4/4] drm/amdgpu: used cached gca values for vi_read_register

[Andy Furniss]

Grazvydas Ignotas wrote:

On Wed, Oct 12, 2016 at 2:48 AM, Andy Furniss <adf.li...@gmail.com> wrote:


I still can't shutdown/reboot
as in https://bugs.freedesktop.org/show_bug.cgi?id=98200
which is fixed for radeon, but apparently not (for me at least) with amdgpu.


You probably need a951ed85abd46 that went to 4.8-fixes and is not part
of 4.9-wip.


Thanks, it's OK with that.


___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 4/4] drm/amdgpu: used cached gca values for vi_read_register

[Andy Furniss]

The boot vce/uvd issue is fixed in 4.9-wip now, so I can boot latest but -

The segfault on startx is still there.

I still can't shutdown/reboot
as in https://bugs.freedesktop.org/show_bug.cgi?id=98200
which is fixed for radeon, but apparently not (for me at least) with amdgpu.
Reverting amdgpu always apply pci shutdown callbacks has fixed this
for recent kernels, though it's not that simple, as I do have a kernel
from last month that has the commit but works OK.


StDenis, Tom wrote:

Yup confirmed...


[root@fx6 linux]# git bisect good
da00756f75422b04befae381e7e48d0cacf299f3 is the first bad commit
commit da00756f75422b04befae381e7e48d0cacf299f3
Author: Christian König <christian.koe...@amd.com>
Date:   Wed Oct 5 16:09:32 2016 +0200

 drm/amdgpu: move align_mask and nop into ring funcs as well

 They are constant as well.

 Signed-off-by: Christian König <christian.koe...@amd.com>
 Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>

:04 04 a8f2ca9290985991b3cc37cbeb902f060573fdbb 
2309b176a1d4ff9e59eaf25688b5db6eb9759dd0 M  drivers





From: amd-gfx <amd-gfx-boun...@lists.freedesktop.org> on behalf of StDenis, Tom 
<tom.stde...@amd.com>
Sent: Tuesday, October 11, 2016 09:20
To: Andy Furniss; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: Re: [PATCH 4/4] drm/amdgpu: used cached gca values for vi_read_register


Hi Andy,


Ha, I'm 1 step away (that was my last bad commit) from determining that.  I'll 
finish up for formality sake but I suspect that is the bad one.


Cheers,

Tom


________
From: Andy Furniss <adf.li...@gmail.com>
Sent: Tuesday, October 11, 2016 09:10
To: StDenis, Tom; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: Re: [PATCH 4/4] drm/amdgpu: used cached gca values for vi_read_register

StDenis, Tom wrote:

Actually NAK that, I don't have the cache patch internally.  So my Tonga crash 
is something else.


Yes, seems the boot fail starts with the tip commit =

drm/amdgpu: move align_mask and nop into ring funcs as well
They are constant as well.

Will also reply to that patch.




Tom



From: amd-gfx <amd-gfx-boun...@lists.freedesktop.org> on behalf of StDenis, Tom 
<tom.stde...@amd.com>
Sent: Tuesday, October 11, 2016 08:11
To: Andy Furniss; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: Re: [PATCH 4/4] drm/amdgpu: used cached gca values for vi_read_register


Yup, my Tonga system dies on modprobe with the tip of stg-4.7 this morning.


Tom



From: amd-gfx <amd-gfx-boun...@lists.freedesktop.org> on behalf of Andy Furniss 
<adf.li...@gmail.com>
Sent: Tuesday, October 11, 2016 08:07
To: Alex Deucher; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: Re: [PATCH 4/4] drm/amdgpu: used cached gca values for vi_read_register

Alex Deucher wrote:

Using the cached values has less latency for bare metal and SR-IOV,
and prevents reading back bogus values if the engine is powergated.


I can't startx since this on r9285.

Seems there are further issues later in current 4.9-wip = I die on
driver load, will see if that's related or one of Christians patches later.

Also anyone on list have shutdown/reboot issues - I can't for the past
few 4.9-wips (I did tag on to someone elses bug, but that's gone quiet).

One thing at a time this commit for me, boots into fbcon OK but then
segfaults -

[19.694] (II) AIGLX: Loaded and initialized radeonsi
[19.694] (II) GLX: Initialized DRI2 GL provider for screen 0
[19.694] (EE)
[19.694] (EE) Backtrace:
[19.717] (EE) 0: /usr/libexec/Xorg (OsSigHandler+0x29) [0x5853b9]
[19.726] (EE) 1: /lib/libc.so.6 (killpg+0x40) [0x7f97e86cb68f]
[19.756] (EE) 2: /usr/lib/dri/radeonsi_dri.so
(amdgpu_surface_init+0x486) [0x7f97e1a40746]
[19.757] (EE) 3: /usr/lib/dri/radeonsi_dri.so
(r600_texture_create_object+0xd7) [0x7f97e1a5dfe7]
[19.759] (EE) 4: /usr/lib/dri/radeonsi_dri.so
(r600_texture_create+0x75) [0x7f97e1a5ea15]
[19.771] (EE) 5: /usr/lib/dri/radeonsi_dri.so
(st_texture_create+0x5b) [0x7f97e178af1b]
[19.773] (EE) 6: /usr/lib/dri/radeonsi_dri.so
(guess_and_alloc_texture+0x1ac) [0x7f97e173ae9c]
[19.774] (EE) 7: /usr/lib/dri/radeonsi_dri.so
(st_AllocTextureImageBuffer+0x3a4) [0x7f97e173b3d4]
[19.775] (EE) 8: /usr/lib/dri/radeonsi_dri.so (st_TexImage+0x6c)
[0x7f97e173f9ac]
[19.786] (EE) 9: /usr/lib/dri/radeonsi_dri.so
(_mesa_get_fallback_texture+0x193) [0x7f97e16cb763]
[19.786] (EE) 10: /usr/lib/dri/radeonsi_dri.so
(_mesa_update_texture+0x1a7) [0x7f97e16d1c37]
[19.787] (EE) 11: /usr/lib/dri/radeonsi_dri.so
(_mesa_update_state_locked+0x683) [0x7f97e16b00e3]
[19.787] (EE) 12: /usr/lib/dri/radeonsi_dri.so
(_mesa_update_state+0x11) [0x7f97e16b0441]
[19.787] (EE) 13: /usr/lib/dri/radeonsi_dri.so
(_mesa_EGLImageTargetTexture2DOES+0x168) 

Re: [PATCH] drm/amdgpu: fix broken VCE startup in phys mode

[Andy Furniss]

I can boot OK with this.

Christian König wrote:

From: Christian König 

Add type, align_mask and nop to the physical mode VCE funcs as well.

Signed-off-by: Christian König 
---
  drivers/gpu/drm/amd/amdgpu/vce_v3_0.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/vce_v3_0.c 
b/drivers/gpu/drm/amd/amdgpu/vce_v3_0.c
index f7dbd0d..c7ddbef 100644
--- a/drivers/gpu/drm/amd/amdgpu/vce_v3_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/vce_v3_0.c
@@ -829,6 +829,9 @@ const struct amd_ip_funcs vce_v3_0_ip_funcs = {
  };

  static const struct amdgpu_ring_funcs vce_v3_0_ring_phys_funcs = {
+   .type = AMDGPU_RING_TYPE_VCE,
+   .align_mask = 0xf,
+   .nop = VCE_CMD_NO_OP,
.get_rptr = vce_v3_0_ring_get_rptr,
.get_wptr = vce_v3_0_ring_get_wptr,
.set_wptr = vce_v3_0_ring_set_wptr,



___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 4/4] drm/amdgpu: used cached gca values for vi_read_register

[Andy Furniss]

StDenis, Tom wrote:

Actually NAK that, I don't have the cache patch internally.  So my Tonga crash 
is something else.


Yes, seems the boot fail starts with the tip commit =

drm/amdgpu: move align_mask and nop into ring funcs as well
They are constant as well.

Will also reply to that patch.




Tom



From: amd-gfx <amd-gfx-boun...@lists.freedesktop.org> on behalf of StDenis, Tom 
<tom.stde...@amd.com>
Sent: Tuesday, October 11, 2016 08:11
To: Andy Furniss; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: Re: [PATCH 4/4] drm/amdgpu: used cached gca values for vi_read_register


Yup, my Tonga system dies on modprobe with the tip of stg-4.7 this morning.


Tom



From: amd-gfx <amd-gfx-boun...@lists.freedesktop.org> on behalf of Andy Furniss 
<adf.li...@gmail.com>
Sent: Tuesday, October 11, 2016 08:07
To: Alex Deucher; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: Re: [PATCH 4/4] drm/amdgpu: used cached gca values for vi_read_register

Alex Deucher wrote:

Using the cached values has less latency for bare metal and SR-IOV,
and prevents reading back bogus values if the engine is powergated.


I can't startx since this on r9285.

Seems there are further issues later in current 4.9-wip = I die on
driver load, will see if that's related or one of Christians patches later.

Also anyone on list have shutdown/reboot issues - I can't for the past
few 4.9-wips (I did tag on to someone elses bug, but that's gone quiet).

One thing at a time this commit for me, boots into fbcon OK but then
segfaults -

[19.694] (II) AIGLX: Loaded and initialized radeonsi
[19.694] (II) GLX: Initialized DRI2 GL provider for screen 0
[19.694] (EE)
[19.694] (EE) Backtrace:
[19.717] (EE) 0: /usr/libexec/Xorg (OsSigHandler+0x29) [0x5853b9]
[19.726] (EE) 1: /lib/libc.so.6 (killpg+0x40) [0x7f97e86cb68f]
[19.756] (EE) 2: /usr/lib/dri/radeonsi_dri.so
(amdgpu_surface_init+0x486) [0x7f97e1a40746]
[19.757] (EE) 3: /usr/lib/dri/radeonsi_dri.so
(r600_texture_create_object+0xd7) [0x7f97e1a5dfe7]
[19.759] (EE) 4: /usr/lib/dri/radeonsi_dri.so
(r600_texture_create+0x75) [0x7f97e1a5ea15]
[19.771] (EE) 5: /usr/lib/dri/radeonsi_dri.so
(st_texture_create+0x5b) [0x7f97e178af1b]
[19.773] (EE) 6: /usr/lib/dri/radeonsi_dri.so
(guess_and_alloc_texture+0x1ac) [0x7f97e173ae9c]
[19.774] (EE) 7: /usr/lib/dri/radeonsi_dri.so
(st_AllocTextureImageBuffer+0x3a4) [0x7f97e173b3d4]
[19.775] (EE) 8: /usr/lib/dri/radeonsi_dri.so (st_TexImage+0x6c)
[0x7f97e173f9ac]
[19.786] (EE) 9: /usr/lib/dri/radeonsi_dri.so
(_mesa_get_fallback_texture+0x193) [0x7f97e16cb763]
[19.786] (EE) 10: /usr/lib/dri/radeonsi_dri.so
(_mesa_update_texture+0x1a7) [0x7f97e16d1c37]
[19.787] (EE) 11: /usr/lib/dri/radeonsi_dri.so
(_mesa_update_state_locked+0x683) [0x7f97e16b00e3]
[19.787] (EE) 12: /usr/lib/dri/radeonsi_dri.so
(_mesa_update_state+0x11) [0x7f97e16b0441]
[19.787] (EE) 13: /usr/lib/dri/radeonsi_dri.so
(_mesa_EGLImageTargetTexture2DOES+0x168) [0x7f97e16c5c88]
[19.802] (EE) 14: /usr/lib/xorg/modules/libglamoregl.so
(glamor_create_texture_from_image+0xaa) [0x7f97d93bf89a]
[19.803] (EE) 15: /usr/lib/xorg/modules/libglamoregl.so
(glamor_egl_create_textured_pixmap+0x12d) [0x7f97d93bfafd]
[19.803] (EE) 16: /usr/lib/xorg/modules/libglamoregl.so
(glamor_egl_create_textured_screen+0x33) [0x7f97d93bfc23]
[19.811] (EE) 17: /usr/lib/xorg/modules/drivers/amdgpu_drv.so
(amdgpu_glamor_create_screen_resources+0x67) [0x7f97e2ea7cf7]
[19.812] (EE) 18: /usr/lib/xorg/modules/drivers/amdgpu_drv.so
(AMDGPUCreateScreenResources_KMS+0x27e) [0x7f97e2e9fe3e]
[19.813] (EE) 19: /usr/libexec/Xorg
(xf86CrtcCreateScreenResources+0x2e) [0x4a3b7e]
[19.814] (EE) 20: /usr/libexec/Xorg (dix_main+0x26e) [0x438ebe]
[19.815] (EE) 21: /lib/libc.so.6 (__libc_start_main+0xf0)
[0x7f97e86b85e0]
[19.816] (EE) 22: /usr/libexec/Xorg (_start+0x29) [0x424659]
[19.816] (EE)
[19.816] (EE) Segmentation fault at address 0x4023321cc
[19.816] (EE)
Fatal server error:
[19.816] (EE) Caught signal 11 (Segmentation fault). Server aborting
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
amd-gfx Info Page - 
lists.freedesktop.org<https://lists.freedesktop.org/mailman/listinfo/amd-gfx>
lists.freedesktop.org
To see the collection of prior postings to the list, visit the amd-gfx 
Archives. Using amd-gfx: To post a message to all the list members, send email 
...






___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 2/2] drm/amdgpu: bind GTT on demand

[Andy Furniss]

With current drm-next-4.9-wip plus  drm/amdgpu: fix addr handling in 
amdgpu_vm_bo_update_mapping


testdma is now working OK for my R9285 - just did 35k tests while 
simultaneously running valley/heaven, plus messing with 
powerplay/cpufreq and all is

good, no lock, no vm faults.


Andy Furniss wrote:

Christian König wrote:

Am 22.09.2016 um 23:54 schrieb Andy Furniss:

Marek Olšák wrote:

This breaks Tonga such that it hangs. Reproducible quickly with:

R600_DEBUG=testdma glxgears

It's a randomized test that runs forever. It should hang within 2
seconds.


So what is the status of this now?


The status is that I'm hammering my head on the desk for two weeks now
what the heck is going wrong here.


Oh, OK, I was just checking no one thought it was fixed really.



What I've found so far is that a VM update command doesn't have the
result it should have, but I absolutely don't understand what happens
here.

The good news is that it's 100% reproducible and I already found and
fixed two bugs.

If you have any idea or more testing results what is going wrong here
please let me know.


I guess, you already did it anyway or it doesn't help, but

R600_DEBUG=testdma,check_vm glxgears

Does catch a vmfault and output to ddebug_dumps.
It initially saves me from locking, though I will lock on repeated runs.



If we can't fix this before the 4.9 release we are just going to revert
the patch causing this.

Regards,
Christian.



R600_DEBUG=testdma glxgears isn't a test I've run on my r9285 tonga
until I, by luck, saw this.

On agddf 4.9-wip at post time it did hang/reboot after 2 seconds.

On every update since it's still hung though now it takes longer.

Todays update tested both on head and reset on to the drm-next tag
still hang.

Going back over older 4.9-wips it's one built on 26th August that is
the first not to hang.



___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx








___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 3/3] drm/amdgpu: add vce bypass mode for tonga.

[Andy Furniss]

Andy Furniss wrote:

This regresses vce perf badly on tonga

https://bugs.freedesktop.org/show_bug.cgi?id=97494

Maybe I need a better test case or faster cpu or something,
but vce powerplay encode issues disappeared for me with the latest
firmware.


I did eventually find an issue - but I don't know if it's what the
comment below referred to.

vaapi cbr since the mesa commit that enabled dual instance
can sometimes produce different md5sums, though the vid is visually
OK. Maybe gstreamer timing based as it can be reduced by changing
cpufreq from on_demand to perf or adding ! queue !. Higher bitrates
seem to not have the issue, cqp doesn't seem affected.



root wrote:

From: Rex Zhu <rex@amd.com>

fix issue that encode test failed on the second time when
vce dpm enabled on tonga.

Signed-off-by: Rex Zhu <rex@amd.com>

Change-Id: I9c77b631b977ab5cc14dc553b6e6beb502e4bd0e
Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>
---
  drivers/gpu/drm/amd/amdgpu/vce_v3_0.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/vce_v3_0.c
b/drivers/gpu/drm/amd/amdgpu/vce_v3_0.c
index df66abe..168b0db 100644
--- a/drivers/gpu/drm/amd/amdgpu/vce_v3_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/vce_v3_0.c
@@ -704,7 +704,8 @@ static int vce_v3_0_set_clockgating_state(void
*handle,
  bool enable = (state == AMD_CG_STATE_GATE) ? true : false;
  int i;

-if (adev->asic_type == CHIP_POLARIS10)
+if ((adev->asic_type == CHIP_POLARIS10) ||
+(adev->asic_type == CHIP_TONGA))
  vce_v3_0_set_bypass_mode(adev, enable);

  if (!(adev->cg_flags & AMD_CG_SUPPORT_VCE_MGCG))





___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 2/2] drm/amdgpu: bind GTT on demand

[Andy Furniss]

Christian König wrote:

Am 22.09.2016 um 23:54 schrieb Andy Furniss:

Marek Olšák wrote:

This breaks Tonga such that it hangs. Reproducible quickly with:

R600_DEBUG=testdma glxgears

It's a randomized test that runs forever. It should hang within 2
seconds.


So what is the status of this now?


The status is that I'm hammering my head on the desk for two weeks now
what the heck is going wrong here.


Oh, OK, I was just checking no one thought it was fixed really.



What I've found so far is that a VM update command doesn't have the
result it should have, but I absolutely don't understand what happens here.

The good news is that it's 100% reproducible and I already found and
fixed two bugs.

If you have any idea or more testing results what is going wrong here
please let me know.


I guess, you already did it anyway or it doesn't help, but

R600_DEBUG=testdma,check_vm glxgears

Does catch a vmfault and output to ddebug_dumps.
It initially saves me from locking, though I will lock on repeated runs.



If we can't fix this before the 4.9 release we are just going to revert
the patch causing this.

Regards,
Christian.



R600_DEBUG=testdma glxgears isn't a test I've run on my r9285 tonga
until I, by luck, saw this.

On agddf 4.9-wip at post time it did hang/reboot after 2 seconds.

On every update since it's still hung though now it takes longer.

Todays update tested both on head and reset on to the drm-next tag
still hang.

Going back over older 4.9-wips it's one built on 26th August that is
the first not to hang.



___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx






___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 2/2] drm/amdgpu: bind GTT on demand

[Andy Furniss]

Marek Olšák wrote:

This breaks Tonga such that it hangs. Reproducible quickly with:

R600_DEBUG=testdma glxgears

It's a randomized test that runs forever. It should hang within 2 seconds.


So what is the status of this now?

R600_DEBUG=testdma glxgears isn't a test I've run on my r9285 tonga
until I, by luck, saw this.

On agddf 4.9-wip at post time it did hang/reboot after 2 seconds.

On every update since it's still hung though now it takes longer.

Todays update tested both on head and reset on to the drm-next tag
still hang.

Going back over older 4.9-wips it's one built on 26th August that is
the first not to hang.



___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 3/5] drm/amdgpu:fix RB cost calculator

[Andy Furniss]

This has just gone into drm-next-4.9-wip and caused lots of logging noise.

Seems to work OK though.

Sep 14 23:18:38 ph4 kernel: [drm:gfx_v8_0_ring_emit_fence_gfx [amdgpu]] 
*ERROR* amdgpu: writing more dwords to the ring than expected!

Sep 14 23:18:38 ph4 last message repeated 11 times
Sep 14 23:18:38 ph4 kernel: [drm:gfx_v8_ring_emit_sb [amdgpu]] *ERROR* 
amdgpu: writing more dwords to the ring than expected!
Sep 14 23:18:38 ph4 kernel: [drm:gfx_v8_ring_emit_sb [amdgpu]] *ERROR* 
amdgpu: writing more dwords to the ring than expected!
Sep 14 23:18:38 ph4 kernel: [drm:amdgpu_ring_insert_nop [amdgpu]] 
*ERROR* amdgpu: writing more dwords to the ring than expected!

Sep 14 23:18:38 ph4 last message repeated 10 times
Sep 14 23:18:38 ph4 kernel: [drm:gfx_v8_0_ring_emit_ib_gfx [amdgpu]] 
*ERROR* amdgpu: writing more dwords to the ring than expected!
Sep 14 23:18:38 ph4 kernel: [drm:gfx_v8_0_ring_emit_ib_gfx [amdgpu]] 
*ERROR* amdgpu: writing more dwords to the ring than expected!
Sep 14 23:18:38 ph4 kernel: [drm:gfx_v8_0_ring_emit_hdp_invalidate 
[amdgpu]] *ERROR* amdgpu: writing more dwords to the ring than expected!

Sep 14 23:18:38 ph4 last message repeated 4 times
Sep 14 23:18:38 ph4 kernel: [drm:gfx_v8_0_ring_emit_fence_gfx [amdgpu]] 
*ERROR* amdgpu: writing more dwords to the ring than expected!

Sep 14 23:18:38 ph4 last message repeated 11 times
Sep 14 23:18:38 ph4 kernel: [drm:gfx_v8_ring_emit_sb [amdgpu]] *ERROR* 
amdgpu: writing more dwords to the ring than expected!
Sep 14 23:18:38 ph4 kernel: [drm:gfx_v8_ring_emit_sb [amdgpu]] *ERROR* 
amdgpu: writing more dwords to the ring than expected!
Sep 14 23:18:38 ph4 kernel: [drm:amdgpu_ring_insert_nop [amdgpu]] 
*ERROR* amdgpu: writing more dwords to the ring than expected!

Sep 14 23:18:38 ph4 last message repeated 10 times

Monk Liu wrote:

Change-Id: Ie3e4587ed49c487c562f45a99f236a76727ace1e
Signed-off-by: Monk Liu 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
index 029ee79..6ad45fa 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
@@ -151,7 +151,7 @@ int amdgpu_ib_schedule(struct amdgpu_ring *ring, unsigned 
num_ibs,
return -EINVAL;
}

-   r = amdgpu_ring_alloc(ring, 256 * num_ibs);
+   r = amdgpu_ring_alloc(ring, 256 + (num_ibs << 4));
if (r) {
dev_err(adev->dev, "scheduling IB failed (%d).\n", r);
return r;



___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx