Re: [PATCH 2/5] drm/amdgpu: Add vm context module param

Am 15.05.2017 um 23:32 schrieb Harish Kasiviswanathan: Add VM update mode module param (amdgpu.vm_update_mode) that can used to control how VM pde/pte are updated for Graphics and Compute. BIT0 controls Graphics and BIT1 Compute. BIT0 [= 0] Graphics updated by SDMA [= 1] by CPU BIT1 [= 0]

RE: [PATCH 0/5] GFX9 KIQ

> -Original Message- > From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf > Of Liu, Shaoyun > Sent: Tuesday, May 23, 2017 7:38 PM > To: Alex Deucher; StDenis, Tom > Cc: amd-gfx list > Subject: RE: [PATCH 0/5] GFX9 KIQ > > I don't have any test for KCQ , but KFD use

[PATCH 3/6] drm/amd/powerplay: update magic number for rv hw backend

Change-Id: If51c5a5e4c534769b95105a1dd5ed76b4ec4bbf3 Signed-off-by: Hawking Zhang --- drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c | 2 +- drivers/gpu/drm/amd/powerplay/inc/hwmgr.h | 3 ++- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git

[PATCH 1/6] drm/amd/powerplay: initialize rv vq table

Change-Id: I64696e3b5418bcdb24a2c359677506d87769afaf Signed-off-by: Hawking Zhang --- drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c | 47 +- drivers/gpu/drm/amd/powerplay/inc/hwmgr.h | 18 +- 2 files changed, 48 insertions(+), 17

[PATCH 5/6] drm/amd/powerplay: bypass pptable process on raven

Change-Id: I550c70144213f9a7490be4df04f7efd286c4d05b Signed-off-by: Hawking Zhang --- drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c

[PATCH 6/6] drm/amd/powerplay: set powerplay support cap on raven

Change-Id: I9aa5e78c1cf19b9069d37215bfd2517980bdf2a6 Signed-off-by: Hawking Zhang --- drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c

RE: [PATCH 4/4] drm/amd/powerplay/smu7: disable mclk switching for high refresh rates

We met similar issue on CI(SWDEV-103046). In high refresh rate, Dal need to notify powerpaly the min_mclk. Best Regards Rex -Original Message- From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Alex Deucher Sent: Wednesday, May 24, 2017 5:27 AM To:

RE: [PATCH 3/4] drm/amd/powerplay/smu7: add vblank check for mclk switching (v2)

+ if (vblank_time_us < switch_limit_us) + return true; + else + return false; How about change the code to return vblank_time_us < switch_limit_us ? true : false; anyway, patch is reviewed-by: Rex Zhu Best Regards Rex

Re: [PATCH xf86-video-amdgpu 1/1] Update URLs

On Tue, May 23, 2017 at 9:18 PM, Michel Dänzer wrote: > From: Michel Dänzer > > * Point to the amd-gfx mailing list > * Specify the component in all bugzilla URLs > * Use https:// for all HTML URLs > > (Ported from radeon commit

[PATCH 2/6] drm/amd/powerplay: using MinFClock/MaxFclock to report Min/Max memory clock limits

Change-Id: I713031dced6e1d5a449cb07a53b644d1014c120c Signed-off-by: Hawking Zhang --- drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c

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

Am 24.05.2017 um 13:03 schrieb Marek Olšák: On Wed, May 24, 2017 at 9:56 AM, Michel Dänzer wrote: On 23/05/17 07:38 PM, Marek Olšák wrote: On Tue, May 23, 2017 at 2:45 AM, Michel Dänzer wrote: On 22/05/17 07:09 PM, Marek Olšák wrote: On Mon, May 22,

[PATCH] drm/amd/display: call amdgpu_dm_fini whewn hw_fini.

to free up drm mode_config info. fix issue: unload amdgpu, can't load amdgpu again. Change-Id: I493bc923b039eae69717cbe8a85c8f3f3ea97465 [drm:drm_debugfs_init [drm]] *ERROR* Cannot create /sys/kernel/debug/dri/0 [drm:drm_minor_register [drm]] *ERROR* DRM: Failed to initialize

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

On Wed, May 24, 2017 at 9:56 AM, Michel Dänzer wrote: > On 23/05/17 07:38 PM, Marek Olšák wrote: >> On Tue, May 23, 2017 at 2:45 AM, Michel Dänzer wrote: >>> On 22/05/17 07:09 PM, Marek Olšák wrote: On Mon, May 22, 2017 at 12:00 PM, Michel Dänzer

Re: [PATCH 1/7] drm/amdgpu: cleanup adjust_mc_addr handling v3

Am 23.05.2017 um 21:03 schrieb Felix Kuehling: On 17-05-23 12:52 PM, Christian König wrote: --- a/drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c @@ -395,7 +395,13 @@ static uint64_t gmc_v6_0_get_vm_pte_flags(struct amdgpu_device *adev, return

Re: [PATCH 0/5] GFX9 KIQ

On 23/05/17 05:32 PM, Alex Deucher wrote: On Tue, May 23, 2017 at 5:31 PM, Alex Deucher wrote: On Fri, May 12, 2017 at 7:11 AM, Tom St Denis wrote: On 11/05/17 07:33 PM, Tom St Denis wrote: On 11/05/17 02:35 PM, Alex Deucher wrote: These are

Re: [PATCH 0/5] GFX9 KIQ

On 24/05/17 09:19 AM, Deucher, Alexander wrote: -Original Message- From: StDenis, Tom Sent: Wednesday, May 24, 2017 9:10 AM To: Deucher, Alexander; Alex Deucher Cc: amd-gfx list Subject: Re: [PATCH 0/5] GFX9 KIQ On 24/05/17 09:10 AM, Deucher, Alexander wrote: >> -Original

RE: [PATCH] drm/amd/display: call amdgpu_dm_fini whewn hw_fini.

> -Original Message- > From: Deucher, Alexander > Sent: Wednesday, May 24, 2017 9:10 AM > To: Zhu, Rex; amd-gfx@lists.freedesktop.org; Wentland, Harry; Grodzovsky, > Andrey > Cc: Zhu, Rex > Subject: RE: [PATCH] drm/amd/display: call amdgpu_dm_fini whewn > hw_fini. > > > -Original

Re: [PATCH] drm/amd/display: call amdgpu_dm_fini whewn hw_fini.

Please fix the typo (whewn -> when) in the title. With that this patch is Reviewed-by: Harry Wentland Harry On 2017-05-24 07:20 AM, Rex Zhu wrote: to free up drm mode_config info. fix issue: unload amdgpu, can't load amdgpu again. Change-Id:

RE: [PATCH 0/5] GFX9 KIQ

> -Original Message- > From: StDenis, Tom > Sent: Wednesday, May 24, 2017 9:10 AM > To: Deucher, Alexander; Alex Deucher > Cc: amd-gfx list > Subject: Re: [PATCH 0/5] GFX9 KIQ > > On 24/05/17 09:10 AM, Deucher, Alexander wrote: > >> -Original Message- > >> From: amd-gfx

RE: [PATCH 6/6] drm/amd/powerplay: set powerplay support cap on raven

> -Original Message- > From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf > Of Hawking Zhang > Sent: Wednesday, May 24, 2017 7:14 AM > To: amd-gfx@lists.freedesktop.org > Cc: Zhang, Hawking > Subject: [PATCH 6/6] drm/amd/powerplay: set powerplay support cap on > raven >

RE: [PATCH] drm/amd/display: call amdgpu_dm_fini whewn hw_fini.

> -Original Message- > From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf > Of Rex Zhu > Sent: Wednesday, May 24, 2017 7:20 AM > To: amd-gfx@lists.freedesktop.org > Cc: Zhu, Rex > Subject: [PATCH] drm/amd/display: call amdgpu_dm_fini whewn hw_fini. > > to free up drm

RE: [PATCH 1/1] amdgpu: move asic id table to a separate file

>There's no need for a separate repo upstream. It's purely to aid internal >packaging. As a first step, we can put a snapshot in libdrm for now. External packaging will face the same issue though ... the packagers need to put the ids in various versions of various distros. We also likely need

RE: [PATCH 0/5] GFX9 KIQ

> -Original Message- > From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf > Of Tom St Denis > Sent: Wednesday, May 24, 2017 7:50 AM > To: Alex Deucher > Cc: amd-gfx list > Subject: Re: [PATCH 0/5] GFX9 KIQ > > On 23/05/17 05:32 PM, Alex Deucher wrote: > > On Tue, May

Re: [PATCH 0/5] GFX9 KIQ

On 24/05/17 09:10 AM, Deucher, Alexander wrote: -Original Message- From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Tom St Denis Sent: Wednesday, May 24, 2017 7:50 AM To: Alex Deucher Cc: amd-gfx list Subject: Re: [PATCH 0/5] GFX9 KIQ On 23/05/17 05:32 PM, Alex

Re: [PATCH 2/5] drm/syncobj: add sync obj wait interface. (v3)

On Wed, May 24, 2017 at 10:25 AM, Jason Ekstrand wrote: > On Wed, May 24, 2017 at 12:06 AM, Dave Airlie wrote: > >> From: Dave Airlie >> >> This interface will allow sync object to be used to back >> Vulkan fences. This API is pretty

Re: [PATCH 2/5] drm/syncobj: add sync obj wait interface. (v3)

On Wed, May 24, 2017 at 12:06 AM, Dave Airlie wrote: > From: Dave Airlie > > This interface will allow sync object to be used to back > Vulkan fences. This API is pretty much the vulkan fence waiting > API, and I've ported the code from amdgpu. > > v2:

Re: [PATCH 1/5] drm: introduce sync objects (v3)

I can't really review for all of the kernel details (though the seem ok to me) so this mostly applies to the API: Reviewed-by: Jason Ekstrand On Wed, May 24, 2017 at 12:06 AM, Dave Airlie wrote: > From: Dave Airlie > > Sync objects

Re: [PATCH 3/5] drm/syncobj: add sync_file interaction.

Yes, I believe this is the proper way for sync_file and syncobj to interact. Again, I can't really review for all of the kernel details (though the seem ok to me) so this mostly applies to the API: Reviewed-by: Jason Ekstrand On Wed, May 24, 2017 at 12:06 AM, Dave Airlie

RE: [PATCH 0/5] GFX9 KIQ

HI , Alex It turn out to be a wrong card I used for test . With a correct Vega10 card , KIQ and other compute rings ring test and IB test passed. I also verified KFD can use the KIQ to submit the invalidate_tlbs successfully . Regards Shaoyun.liu -Original Message- From:

RE: [PATCH 2/5] drm/amdgpu: Add vm context module param

-Original Message- From: Christian König [mailto:deathsim...@vodafone.de] Sent: Wednesday, May 24, 2017 5:41 AM To: Kasiviswanathan, Harish ; amd-gfx@lists.freedesktop.org Subject: Re: [PATCH 2/5] drm/amdgpu: Add vm context module param Am 15.05.2017 um

Re: [PATCH] drm/radeon: Unbreak HPD handling for r600+

On Fri, May 12, 2017 at 2:56 AM, Christian König wrote: > Am 12.05.2017 um 01:31 schrieb Lyude: >> >> We end up reading the interrupt register for HPD5, and then writing it >> to HPD6 which on systems without anything using HPD5 results in >> permanently disabling

Re: [PATCH v2 0/3] Cleanup evergreen/si IRQ handling code

On Sat, May 20, 2017 at 7:39 AM, Christian König wrote: > Am 20.05.2017 um 01:48 schrieb Lyude: >> >> This is the first part of me going through and cleaning up the IRQ >> handling >> code for radeon, since after taking a look at it the other day while >> trying to >>

Re: Topics for beginners

Hi Christian, I have built a stack from git sources. Is drm-next a good branch for basing development on? As you suspected, piglit reported a few crashes and failures with gpu and cl profiles. So I will start looking at those. Thanks for the pointers! Interest wise, I am the most interested in

Re: [PATCH 1/7] drm/amdgpu: cleanup adjust_mc_addr handling v2

On 05/24/2017 05:18 PM, Christian König wrote: Am 18.05.2017 um 07:33 schrieb Zhang, Jerry (Junwei): On 05/17/2017 05:22 PM, Christian König wrote: [SNIP] +static uint64_t gmc_v6_0_get_vm_pde(struct amdgpu_device *adev, uint64_t addr) +{ +BUG_ON(addr & 0xF000FFFULL); +return

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

On 24/05/17 08:27 PM, Christian König wrote: > Am 24.05.2017 um 13:03 schrieb Marek Olšák: >>> >> I think the final solution (done in fault_reserve_notify) should be: >> if (bo->num_cpu_page_faults++ > 20) >> bo->preferred_domain = GTT_WC; I agree something like that will probably be part of

[PATCH 3/3] drm/amdgpu: add a mechanism to acquire gpu exclusivity

A DRM_MASTER may wish to restrict gpu job submission to only a limited set of clients. To enable this use case we provide the following new IOCTL APIs: * A mechanism to change a process's ctx priorities * A mechanism to limit the minimum priority required for the gpu scheduler to queue a

[RFC] Exclusive gpu access for SteamVR usecases

When multiple environments are running simultaneously on a system, e.g. an X desktop + a SteamVR game session, it may be useful to sacrifice performance in one environment in order to boost it on the other. This series provides a mechanism for a DRM_MASTER to provide exclusive gpu access to a

[PATCH 1/3] drm/amdgpu: add a new scheduler priority AMD_SCHED_PRIORITY_HIGH_SW

Add a new priority level to the gpu scheduler *_HIGH_SW. This level intends to provide elevated entity priority at the sw scheduler level without the negative side effects of an elevated HW priority. Some of the negative effects of HW priorities can include stealing resources from other queues.

[PATCH 2/3] drm/amdgpu: make amdgpu_to_sched_priority detect invalid parameters

Returning invalid priorities as _NORMAL is a backwards compatibility quirk of amdgpu_ctx_ioctl(). Move this detail one layer up where it belongs. Signed-off-by: Andres Rodriguez --- drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 8 +---

Re: [PATCH 1/1] amdgpu: move asic id table to a separate file

On 25/05/17 12:10 AM, Li, Samuel wrote: >> There's no need for a separate repo upstream. It's purely to aid >> internal packaging. > As a first step, we can put a snapshot in libdrm for now. External > packaging will face the same issue though ... the packagers need to > put the ids in various

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

On 23/05/17 07:38 PM, Marek Olšák wrote: > On Tue, May 23, 2017 at 2:45 AM, Michel Dänzer wrote: >> On 22/05/17 07:09 PM, 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

Re: [PATCH 1/4] drm/amdgpu/ci: disable mclk switching for high refresh rates (v2)

Am 23.05.2017 um 23:26 schrieb Alex Deucher: Even if the vblank period would allow it, it still seems to be problematic on some cards. v2: fix logic inversion (Nils) bug: https://bugs.freedesktop.org/show_bug.cgi?id=96868 Signed-off-by: Alex Deucher Acked-by:

[PATCH 1/5] drm: introduce sync objects (v3)

From: Dave Airlie Sync objects are new toplevel drm object, that contain a pointer to a fence. This fence can be updated via command submission ioctls via drivers. There is also a generic wait obj API modelled on the vulkan wait API (with code modelled on some amdgpu code).

drm syncobj - final posting I hope

I've fixed up a few things in here from Daniel's comments, Daniel I didn't change things exactly as suggested but I removed fd_flags from API completely. Christian, I think I got the post deps hook in the right place now in the amdgpu patch. Would be nice if someone can validate the timeout

[PATCH 3/5] drm/syncobj: add sync_file interaction.

From: Dave Airlie This interface allows importing the fence from a sync_file into an existing drm sync object, or exporting the fence attached to an existing drm sync object into a new sync file object. This should only be used to interact with sync files where necessary.

[PATCH 5/5] amdgpu: use drm sync objects for shared semaphores (v5)

From: Dave Airlie This creates a new command submission chunk for amdgpu to add in and out sync objects around the submission. Sync objects are managed via the drm syncobj ioctls. The command submission interface is enhanced with two new chunks, one for syncobj pre

[PATCH 4/5] amdgpu/cs: split out fence dependency checking

From: Dave Airlie This just splits out the fence depenency checking into it's own function to make it easier to add semaphore dependencies. Reviewed-by: Christian König Signed-off-by: Dave Airlie ---

Re: [PATCH 5/5] amdgpu: use drm sync objects for shared semaphores (v5)

On 2017年05月24日 15:06, Dave Airlie wrote: From: Dave Airlie This creates a new command submission chunk for amdgpu to add in and out sync objects around the submission. Sync objects are managed via the drm syncobj ioctls. The command submission interface is enhanced with

Re: [PATCH 5/5] amdgpu: use drm sync objects for shared semaphores (v5)

Am 24.05.2017 um 09:25 schrieb zhoucm1: On 2017年05月24日 15:06, Dave Airlie wrote: From: Dave Airlie This creates a new command submission chunk for amdgpu to add in and out sync objects around the submission. Sync objects are managed via the drm syncobj ioctls. The

Re: [PATCH 7/7] drm/amdgpu: enable huge page handling in the VM

Am 18.05.2017 um 07:30 schrieb zhoucm1: On 2017年05月17日 17:22, Christian König wrote: [SNIP] +/* In the case of a mixed PT the PDE must point to it*/ +if (p->adev->asic_type < CHIP_VEGA10 || +nptes != AMDGPU_VM_PTE_COUNT(p->adev) || +p->func != amdgpu_vm_do_set_ptes ||

Re: [PATCH 1/7] drm/amdgpu: cleanup adjust_mc_addr handling v2

Am 18.05.2017 um 07:33 schrieb Zhang, Jerry (Junwei): On 05/17/2017 05:22 PM, Christian König wrote: [SNIP] +static uint64_t gmc_v6_0_get_vm_pde(struct amdgpu_device *adev, uint64_t addr) +{ +BUG_ON(addr & 0xF000FFFULL); +return addr; +} Just wonder why we didn't return the