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 >>>

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

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

[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

[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

[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

[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

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

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 >>

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

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

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

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

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,

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

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

[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

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

[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(+)

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

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

[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

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