Re: [PATCH] [RFC] drm/radeon: clear WC flag when moving bo from vram to gtt

On 24 April 2017 at 10:51, Christian König wrote: > Am 24.04.2017 um 11:42 schrieb Julien Isorce: > >> But re-add the flag is the bo is moved back to vram. >> >> This fixes "ring 0/3 stalled" issue which happens when the driver >> evicts bo from vram

[PATCH] [RFC] drm/radeon: clear WC flag when moving bo from vram to gtt

But re-add the flag is the bo is moved back to vram. This fixes "ring 0/3 stalled" issue which happens when the driver evicts bo from vram to gtt, at least on TAHITI and CAPVERDE. I do not know the exact reason among the following: - si_copy_dma from vram to gtt is slow if WC (only for

Re: [PATCH] Revert "drm/radeon: Try evicting from CPU accessible to inaccessible VRAM first"

t;>> >>>> On 28/03/17 08:00 PM, Julien Isorce wrote: >>>> >>>>> On 28 March 2017 at 10:36, Michel Dänzer >>>> <mailto:mic...@daenzer.net>> wrote: >>>>> >>>>> On 28/03/17 05:24 PM, Julien I

Re: [PATCH] Revert "drm/radeon: Try evicting from CPU accessible to inaccessible VRAM first"

On 28 March 2017 at 10:36, Michel Dänzer wrote: > On 28/03/17 05:24 PM, Julien Isorce wrote: > > Hi Michel, > > > > About the hard lockup, I noticed that I cannot have it with the > > following conditions: > > > > 1. soft lockup fix (the 0->i chan

Re: [PATCH] Revert "drm/radeon: Try evicting from CPU accessible to inaccessible VRAM first"

ape Verde 2048M ) I am happy to try any other suggestion. Thx Julien On 24 March 2017 at 19:01, Julien Isorce wrote: > Hi Michel, > > No this change does not help on the other issue (hard lockup). > I have no tried it in combination with the 0 -> i change. > > Thx anyway. >

Re: [PATCH] Revert "drm/radeon: Try evicting from CPU accessible to inaccessible VRAM first"

Hi Michel, No this change does not help on the other issue (hard lockup). I have no tried it in combination with the 0 -> i change. Thx anyway. Julien On 24 March 2017 at 10:03, Michel Dänzer wrote: > On 24/03/17 12:31 AM, Zachary Michaels wrote: > > > > I should also note that we are experie

Re: [PATCH] Revert "drm/radeon: Try evicting from CPU accessible to inaccessible VRAM first"

Hi Michel, I double checked and you are right, the change 0 -> i works. Cheers Julien On 24 March 2017 at 09:59, Michel Dänzer wrote: > On 24/03/17 06:50 PM, Julien Isorce wrote: > > Hi Michel, > > > > (Just for other readers my reply has been delayed on the mailing l

Re: [PATCH] Revert "drm/radeon: Try evicting from CPU accessible to inaccessible VRAM first"

other issue has some similarities (same ioctl call). But in general, isn't "radeon_lockup_timeout" supposed to detect this situation ? Thx Julien On 24 March 2017 at 09:24, Michel Dänzer wrote: > On 23/03/17 06:26 PM, Julien Isorce wrote: > > Hi Michel, > > > &

Re: [PATCH] Revert "drm/radeon: Try evicting from CPU accessible to inaccessible VRAM first"

Hi Michel, When it happens, the main thread of our gl based app is stuck on a ioctl(RADEON_CS). I set RADEON_THREAD=false to ease the debugging but same thing happens if true. Other threads are only si_shader:0,1,2,3 and are doing nothing, just waiting for jobs. I can also do sudo gdb -p $(pidof X

[infinite loop] need some info about TTM's buffer eviction mechanism

Hello, While debugging a softlock that happens on an ioctl(RADEON_CS), I found that it keeps looping indefinitely in the following loop: https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/ttm/ttm_bo.c#L819 That would be great if someone could explain the logic behind this loop iteratio