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

On Sat, May 20, 2017 at 10:27:14AM +0900, Michel Dänzer wrote: > On 20/05/17 04:23 AM, John Brooks wrote: > > On Fri, May 19, 2017 at 04:03:28PM +0900, Michel Dänzer wrote: > >> On 19/05/17 12:04 PM, John Brooks wrote: > >>> Set GTT as the busy placement for newly created BOs that have the > >>> AM

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

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

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

On 20/05/17 01:14 AM, Marek Olšák wrote: > Hi Michel, > > I've applied your series Thanks for testing it. > and it doesn't help with low Dirt Rally performance on Fiji. I see TTM > buffer moves at 800MB/s and many VRAM page faults. Did you see this: >> Note that there's only little if any impr

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

On 20/05/17 12:52 AM, Marek Olšák wrote: > On Fri, May 19, 2017 at 9:03 AM, Michel Dänzer wrote: >> On 19/05/17 12:04 PM, John Brooks wrote: >>> Set GTT as the busy placement for newly created BOs that have the >>> AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED flag, so that they don't cause >>> establishe

[PATCH v2 3/3] drm/radeon: Cleanup pageflipping IRQ handling for evergreen, si

Same as the previous patch, but for pageflipping now. This also lets us clear up the copy paste for vblank/vline IRQs. Changes since v1: - Preserve the order all registers are written back Signed-off-by: Lyude --- drivers/gpu/drm/radeon/evergreen.c | 105 --- dri

[PATCH v2 2/3] drm/radeon: Cleanup HDMI audio interrupt handling for evergreen

Same as the previous patch, but now for handling HDMI audio interrupts. Changes since v1: - Preserve the order we write back all registers Signed-off-by: Lyude --- drivers/gpu/drm/radeon/evergreen.c | 153 +++-- drivers/gpu/drm/radeon/radeon.h| 7 +- 2 file

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

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 debug something I realized basically all of the code was copy pasted everywhere, and quite difficult to actually read through. Will come up wit

[PATCH v2 1/3] drm/radeon: Cleanup display interrupt handling for evergreen, si

The current code here is really, really bad. A huge amount of it looks to be copy pasted, it has some weird hatred of arrays and code sharing, switch cases everywhere for things that really don't need them, and it makes the file seem immensely more complex then it actually is. This is a pain for ma

Re: [PATCH] drm/amd/display: Limit DCN to x86 arch

On 2017-05-19 04:18 PM, Dave Airlie wrote: On 20 May 2017 at 05:36, Harry Wentland wrote: On 2017-05-19 11:02 AM, Christian König wrote: Am 19.05.2017 um 16:01 schrieb Harry Wentland: DCN bw calcs currently rely on the following gcc options: -mhard-float -msse -mpreferred-stack-bounda

Re: [PATCH] drm/amd/display: Limit DCN to x86 arch

On 20 May 2017 at 05:36, Harry Wentland wrote: > On 2017-05-19 11:02 AM, Christian König wrote: >> >> Am 19.05.2017 um 16:01 schrieb Harry Wentland: >>> >>> DCN bw calcs currently rely on the following gcc options: >>>-mhard-float -msse -mpreferred-stack-boundary=4 >> >> >> Mhm, price question

Re: [PATCH] drm/amd/display: Limit DCN to x86 arch

On 2017-05-19 11:02 AM, Christian König wrote: Am 19.05.2017 um 16:01 schrieb Harry Wentland: DCN bw calcs currently rely on the following gcc options: -mhard-float -msse -mpreferred-stack-boundary=4 Mhm, price question: Why does DCN rely on the gcc options? Tony and Dmytro can probably

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

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

Re: [PATCH] drm: Harmonize CIK ASIC support in radeon and amdgpu (v2)

On 17-05-18 09:17 PM, Michel Dänzer wrote: > Obviously, out-of-tree module builds will have to continue doing what > they've been doing so far with kernels without your patch. I'm thinking > about making it easier for them with kernels which do have your patch. > At some point in the future, maybe

RE: [PATCH] drm/amd/display: Limit DCN to x86 arch

Acked-by: Jordan Lazare -Original Message- From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Harry Wentland Sent: Friday, May 19, 2017 10:01 AM To: amd-gfx@lists.freedesktop.org Cc: Wentland, Harry ; Daenzer, Michel ; Laktyushkin, Dmytro ; Deucher, Alexander ; C

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

Hi Michel, I've applied your series and it doesn't help with low Dirt Rally performance on Fiji. I see TTM buffer moves at 800MB/s and many VRAM page faults. Marek On Thu, May 18, 2017 at 11:08 AM, Michel Dänzer wrote: > From: Michel Dänzer > > This series was developed and tested under the fo

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

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

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

On Fri, May 19, 2017 at 5:47 PM, Marek Olšák wrote: > On Fri, May 19, 2017 at 5:27 PM, John Brooks wrote: >> On Fri, May 19, 2017 at 05:24:36PM +0200, Marek Olšák wrote: >>> Where is your "attached" patch? >>> >>> Marek >> >> It's actually a reply to my message. Sorry if that was unclear. > > Tha

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

On Fri, May 19, 2017 at 5:27 PM, John Brooks wrote: > On Fri, May 19, 2017 at 05:24:36PM +0200, Marek Olšák wrote: >> Where is your "attached" patch? >> >> Marek > > It's actually a reply to my message. Sorry if that was unclear. That's OK, but I don't see any patch from you here. Marek

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

On Fri, May 19, 2017 at 05:24:36PM +0200, Marek Olšák wrote: > Where is your "attached" patch? > > Marek It's actually a reply to my message. Sorry if that was unclear. > > On Fri, May 19, 2017 at 5:04 AM, John Brooks wrote: > > I'm glad this is being worked on. However, somewhat to my surpris

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

Where is your "attached" patch? Marek On Fri, May 19, 2017 at 5:04 AM, John Brooks wrote: > I'm glad this is being worked on. However, somewhat to my surprise, this patch > series didn't help Dying Light's BO eviction problem. For those who don't > know, > that game performs very badly in certa

Re: [PATCH] drm/amd/display: Limit DCN to x86 arch

Am 19.05.2017 um 16:01 schrieb Harry Wentland: DCN bw calcs currently rely on the following gcc options: -mhard-float -msse -mpreferred-stack-boundary=4 Mhm, price question: Why does DCN rely on the gcc options? That is something very unusual for drivers. We occasionally have something lik

[PATCH] drm/amd/display: Limit DCN to x86 arch

DCN bw calcs currently rely on the following gcc options: -mhard-float -msse -mpreferred-stack-boundary=4 We probably shouldn't allow building this on architectures other than x86. CC: Alex Deucher CC: Christian König CC: Michel Dänzer CC: Tony Cheng CC: Dmytro Laktyushkin Signed-off-by: H

Re: [PATCH] iommu/amd: flush IOTLB for specific domains only (v2)

On Fri, 2017-05-19 at 15:32 +0530, arindam.n...@amd.com wrote: > From: Arindam Nath > > Change History > -- > > v2: changes suggested by Joerg > - add flush flag to improve efficiency of flush operation > > v1: > - The idea behind flush queues is to defer the IOTLB flushing > for

[PATCH] drm/amd/display: default spd packet to invalid

Signed-off-by: Jeff Smith --- All of the encoder_info_frame's info packets are initialized to invalid in resource_build_info_frame except for spd. This appears to be simply an oversight. drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 1 + 1 file changed, 1 insertion(+) diff --git a/driver

Re: [PATCH 1/5] drm/radeon: Add module param to control CIK support

Am 18.05.2017 um 23:44 schrieb Felix Kuehling: If AMDGPU supports CIK, add a module parameter to control CIK support in radeon. It's off by default in radeon, while it will be on by default in AMDGPU. Signed-off-by: Felix Kuehling I'm not 100% sure if amdgpu should be the default for CIK eith

Re: [PATCH] drm/amdgpu: fix ocl test performance drop

I'm pretty sure that bug is fixed in GFX9. So we don't need the check there any more. Regards, Christian. Am 19.05.2017 um 07:16 schrieb zhoucm1: I also realized this problem when I did fix for sched fence, I thought if no issue, just left it as current code, it's more safe. As Flora point it

Re: [PATCH] drm/amdgpu: fix ocl test performance drop

Am 19.05.2017 um 04:25 schrieb Flora Cui: On Thu, May 18, 2017 at 01:38:15PM +0200, Christian König wrote: Am 18.05.2017 um 09:45 schrieb Flora Cui: partial revert commit <6971d3d> - drm/amdgpu: cleanup logic in amdgpu_vm_flush Change-Id: Iadce9d613dfe9a739643a74050cea55854832adb Signed-off-by

[PATCH] iommu/amd: flush IOTLB for specific domains only (v2)

From: Arindam Nath Change History -- v2: changes suggested by Joerg - add flush flag to improve efficiency of flush operation v1: - The idea behind flush queues is to defer the IOTLB flushing for domains for which the mappings are no longer valid. We add such domains in queue_ad

Re: Plan: BO move throttling for visible VRAM evictions

On 18/05/17 07:22 PM, Marek Olšák wrote: > On May 18, 2017 10:17 AM, "Michel Dänzer" > wrote: > > On 17/05/17 09:35 PM, Marek Olšák wrote: > > On May 16, 2017 3:57 AM, "Michel Dänzer" > >

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

On 19/05/17 12:04 PM, John Brooks wrote: > Set GTT as the busy placement for newly created BOs that have the > AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED flag, so that they don't cause > established BOs to be evicted from visible VRAM. This is an interesting idea, but there are some issues with this pa