Re: Latest drm-next-4.9-wip is causing gfx kernel thread to be pegged 100% running piglit
On Sunday, September 18, 2016 8:06:51 PM EDT Shawn Starr wrote: > Looks like something broke in drm-next-4.9-wip, unsure which change did. > > When running: piglit tests/gpu summary/amdgpu > It's spinning in: 82.37%82.37% [kernel] [k] amdgpu_sync_peek_fence This is on a CIK (Bonaire) chip. Thanks, Shawn > > Also triggers: > [ 1848.505498] [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* ttm_eu_reserve_buffers > failed. > > Will test 4.8-rc6 vanilla to see if something broke there. > > Thanks, > Shawn > ___ > 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
Latest drm-next-4.9-wip is causing gfx kernel thread to be pegged 100% running piglit
Looks like something broke in drm-next-4.9-wip, unsure which change did. When running: piglit tests/gpu summary/amdgpu Also triggers: [ 1848.505498] [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* ttm_eu_reserve_buffers failed. Will test 4.8-rc6 vanilla to see if something broke there. Thanks, Shawn ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 4/6] drm/radeon: Provide page_flip_target hook
Hi Michel, all your patches, both the already merged kernel bits in radeon/amdgpu and also all the userspace bits in libdrm/ati-ddx/amdgpu-ddx are all Reviewed-and-tested-by: Mario KleinerI successfully tested with old/current userspace and the new userspace patches from your own libdrm/ati-ddx/amdgpu-ddx repos, under radeon-kms with HD-5770 and amdgpu-kms with R9 380, under DRI2 and DRI3/Present with the new userspace and at least DRI3/Present with the old/current userspace (can't quite remember if i also tested with DRI2 on old/current userspace, but probably). Hardware measured timing tests all work fine. So all is good, except for pre-DCE4 without pflip irqs, but for that see the patchset i just sent out, which should make those old asics work well as well. -mario On 08/16/2016 03:49 AM, Michel Dänzer wrote: On 16/08/16 09:35 AM, Mario Kleiner wrote: Hi Michel, sorry for the super-late reply, i was just catching up with all the mails and discussions, starting in June, leading to this patch set. Looks all pretty good. I'll look at this radeon patch and 2/6 for amdgpu later this week when i have a fresh brain and enough "obsessive compulsive time", to make sure all the magic wrt. "virtually extended vblank" and the fudging logic is fine. Excellent! I'll then also run it through my timing tests. I assume the ati/amdgpu-ddx patches and libdrm patches in your freedesktop home are all i need for testing? Yes, although it would also be nice to test with unmodified userspace and make sure there are no regressions with that. ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [pull] radeon and amdgpu drm-next-4.9
On Fri, Sep 16, 2016 at 06:07:36PM -0400, Alex Deucher wrote: > On Fri, Sep 16, 2016 at 5:38 PM, Lukas Wunnerwrote: > > On Fri, Sep 16, 2016 at 04:42:43PM -0400, Alex Deucher wrote: > >> drm/amdgpu: skip suspend/resume on DRM_SWITCH_POWER_DYNAMIC_OFF > >> drm/radeon: skip suspend/resume on DRM_SWITCH_POWER_DYNAMIC_OFF > > > > Those two are unnecessary, it can't happen that the ->suspend hook > > is executed with the device runtime suspended. > > > > Since commit d14d2a8453d6 ("drm: Remove dev_pm_ops from drm_class"), > > DRM devices are afforded direct_complete, i.e. if the GPU is runtime > > suspended upon system sleep, it is left in this state. The only > > callbacks that are executed are the ->prepare and the ->complete hook. > > All the callbacks in-between, like ->suspend, are skipped. > > > > Even if direct_complete is not afforded for some reason, the PM core > > will automatically runtime resume the device before executing ->suspend. > > > > That ->suspend is skipped in the DRM_SWITCH_POWER_OFF case was done > > because the device is suspended behind the PM core's back if runpm=0 > > is set. (And it doesn't work properly because the PCI core will > > invalidate the saved_state during ->resume_noirq. That could be > > solved by returning 1 from the ->prepare hook in the DRM_SWITCH_POWER_OFF > > case, but that's a different story.) > > > > (Sorry for not raising this earlier, I'm not subscribed to amd-gfx.) > > Thanks for the heads up. They shouldn't hurt anything and it matches > what other drivers do. If you feel strongly about it, I can revert > them later. Well, superfluous code shouldn't be included just because it doesn't hurt or because others didn't know better either, or removed because of someone else's feelings. ;-) You can find the runtime resume before execution of the driver ->suspend callback in drivers/pci/pci-driver.c:pci_pm_suspend(): const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL; ... pm_runtime_resume(dev); ... if (pm->suspend) { ... error = pm->suspend(dev); The device is prevented from auto-suspending because of a runtime PM ref acquired beforehand in drivers/base/power/main.c:device_prepare(). Best regards, Lukas ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 3/3] drm/amdgpu: set gfx clock gating for tonga/polaris.
Change-Id: I65d9858b8ca0789c5d82db2f8893b7c10fc6f471 Signed-off-by: Rex Zhu--- drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 77 +++ 1 file changed, 77 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c index 1902442..9970893 100644 --- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c @@ -5818,6 +5818,76 @@ static int gfx_v8_0_update_gfx_clock_gating(struct amdgpu_device *adev, return 0; } +static int gfx_v8_0_tonga_update_gfx_clock_gating(struct amdgpu_device *adev, + enum amd_clockgating_state state) +{ + uint32_t msg_id, pp_state; + void *pp_handle = adev->powerplay.pp_handle; + + if (state == AMD_CG_STATE_UNGATE) + pp_state = 0; + else + pp_state = PP_STATE_CG | PP_STATE_LS; + + msg_id = PP_CG_MSG_ID(PP_GROUP_GFX, + PP_BLOCK_GFX_CG, + PP_STATE_SUPPORT_CG | PP_STATE_SUPPORT_LS, + pp_state); + amd_set_clockgating_by_smu(pp_handle, msg_id); + + msg_id = PP_CG_MSG_ID(PP_GROUP_GFX, + PP_BLOCK_GFX_MG, + PP_STATE_SUPPORT_CG | PP_STATE_SUPPORT_LS, + pp_state); + amd_set_clockgating_by_smu(pp_handle, msg_id); + + return 0; +} + +static int gfx_v8_0_polaris_update_gfx_clock_gating(struct amdgpu_device *adev, + enum amd_clockgating_state state) +{ + uint32_t msg_id, pp_state; + void *pp_handle = adev->powerplay.pp_handle; + + if (state == AMD_CG_STATE_UNGATE) + pp_state = 0; + else + pp_state = PP_STATE_CG | PP_STATE_LS; + + msg_id = PP_CG_MSG_ID(PP_GROUP_GFX, + PP_BLOCK_GFX_CG, + PP_STATE_SUPPORT_CG | PP_STATE_SUPPORT_LS, + pp_state); + amd_set_clockgating_by_smu(pp_handle, msg_id); + + msg_id = PP_CG_MSG_ID(PP_GROUP_GFX, + PP_BLOCK_GFX_3D, + PP_STATE_SUPPORT_CG | PP_STATE_SUPPORT_LS, + pp_state); + amd_set_clockgating_by_smu(pp_handle, msg_id); + + msg_id = PP_CG_MSG_ID(PP_GROUP_GFX, + PP_BLOCK_GFX_MG, + PP_STATE_SUPPORT_CG | PP_STATE_SUPPORT_LS, + pp_state); + amd_set_clockgating_by_smu(pp_handle, msg_id); + + msg_id = PP_CG_MSG_ID(PP_GROUP_GFX, + PP_BLOCK_GFX_RLC, + PP_STATE_SUPPORT_CG | PP_STATE_SUPPORT_LS, + pp_state); + amd_set_clockgating_by_smu(pp_handle, msg_id); + + msg_id = PP_CG_MSG_ID(PP_GROUP_GFX, + PP_BLOCK_GFX_CP, + PP_STATE_SUPPORT_CG | PP_STATE_SUPPORT_LS, + pp_state); + amd_set_clockgating_by_smu(pp_handle, msg_id); + + return 0; +} + static int gfx_v8_0_set_clockgating_state(void *handle, enum amd_clockgating_state state) { @@ -5830,6 +5900,13 @@ static int gfx_v8_0_set_clockgating_state(void *handle, gfx_v8_0_update_gfx_clock_gating(adev, state == AMD_CG_STATE_GATE ? true : false); break; + case CHIP_TONGA: + gfx_v8_0_tonga_update_gfx_clock_gating(adev, state); + break; + case CHIP_POLARIS10: + case CHIP_POLARIS11: + gfx_v8_0_polaris_update_gfx_clock_gating(adev, state); + break; default: break; } -- 1.9.1 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 2/3] drm/amdgpu: set system clock gating for tonga/polaris.
Change-Id: Ie66afaea8b30c4b7b6d491c7aa63775e4a5cd6e1 Signed-off-by: Rex Zhu--- drivers/gpu/drm/amd/amdgpu/vi.c | 61 + 1 file changed, 61 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c b/drivers/gpu/drm/amd/amdgpu/vi.c index 370bf2f..6561c54 100644 --- a/drivers/gpu/drm/amd/amdgpu/vi.c +++ b/drivers/gpu/drm/amd/amdgpu/vi.c @@ -2131,6 +2131,63 @@ static void vi_update_rom_medium_grain_clock_gating(struct amdgpu_device *adev, WREG32_SMC(ixCGTT_ROM_CLK_CTRL0, data); } +static int vi_common_set_clockgating_state_by_smu(void *handle, + enum amd_clockgating_state state) +{ + uint32_t msg_id, pp_state; + struct amdgpu_device *adev = (struct amdgpu_device *)handle; + void *pp_handle = adev->powerplay.pp_handle; + + if (state == AMD_CG_STATE_UNGATE) + pp_state = 0; + else + pp_state = PP_STATE_CG | PP_STATE_LS; + + msg_id = PP_CG_MSG_ID(PP_GROUP_SYS, + PP_BLOCK_SYS_MC, + PP_STATE_SUPPORT_CG | PP_STATE_SUPPORT_LS, + pp_state); + amd_set_clockgating_by_smu(pp_handle, msg_id); + + msg_id = PP_CG_MSG_ID(PP_GROUP_SYS, + PP_BLOCK_SYS_SDMA, + PP_STATE_SUPPORT_CG | PP_STATE_SUPPORT_LS, + pp_state); + amd_set_clockgating_by_smu(pp_handle, msg_id); + + msg_id = PP_CG_MSG_ID(PP_GROUP_SYS, + PP_BLOCK_SYS_HDP, + PP_STATE_SUPPORT_CG | PP_STATE_SUPPORT_LS, + pp_state); + amd_set_clockgating_by_smu(pp_handle, msg_id); + + msg_id = PP_CG_MSG_ID(PP_GROUP_SYS, + PP_BLOCK_SYS_BIF, + PP_STATE_SUPPORT_LS, + pp_state); + amd_set_clockgating_by_smu(pp_handle, msg_id); + + msg_id = PP_CG_MSG_ID(PP_GROUP_SYS, + PP_BLOCK_SYS_BIF, + PP_STATE_SUPPORT_CG, + pp_state); + amd_set_clockgating_by_smu(pp_handle, msg_id); + + msg_id = PP_CG_MSG_ID(PP_GROUP_SYS, + PP_BLOCK_SYS_DRM, + PP_STATE_SUPPORT_LS, + pp_state); + amd_set_clockgating_by_smu(pp_handle, msg_id); + + msg_id = PP_CG_MSG_ID(PP_GROUP_SYS, + PP_BLOCK_SYS_ROM, + PP_STATE_SUPPORT_CG, + pp_state); + amd_set_clockgating_by_smu(pp_handle, msg_id); + + return 0; +} + static int vi_common_set_clockgating_state(void *handle, enum amd_clockgating_state state) { @@ -2156,6 +2213,10 @@ static int vi_common_set_clockgating_state(void *handle, vi_update_hdp_light_sleep(adev, state == AMD_CG_STATE_GATE ? true : false); break; + case CHIP_TONGA: + case CHIP_POLARIS10: + case CHIP_POLARIS11: + vi_common_set_clockgating_state_by_smu(adev, state); default: break; } -- 1.9.1 ___ 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
Alex fixed this up in a rather complete series for all engines/rings. Christian. Am 18.09.2016 um 05:47 schrieb Liu, Monk: Is that applied to all ring ? Cuz seems only GFX ring each lot of dw per submit ... BR Monk -Original Message- From: Christian König [mailto:deathsim...@vodafone.de] Sent: Thursday, September 15, 2016 3:24 PM To: Andy Furniss; Liu, Monk ; amd-gfx@lists.freedesktop.org Subject: Re: [PATCH 3/5] drm/amdgpu:fix RB cost calculator 256dw for the header are probably not enough. Since we now uses NOPs for the CE/DE sync we only need 256dw for that alone. I suggest to raise that to 512. Christian. Am 15.09.2016 um 00:24 schrieb 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 ___ 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