On Wed, Dec 10, 2014 at 8:24 PM, Michel Dänzer <michel@xxxxxxxxxxx> wrote: > On 11.12.2014 05:28, Andy Lutomirski wrote: >> On Wed, Dec 10, 2014 at 1:44 AM, Michel Dänzer <michel@xxxxxxxxxxx> wrote: >>> On 10.12.2014 06:39, Andy Lutomirski wrote: >>>> On Tue, Dec 9, 2014 at 8:06 AM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: >>>>> On Tue, Dec 9, 2014 at 1:18 AM, Michel Dänzer <michel@xxxxxxxxxxx> wrote: >>>>>> On 09.12.2014 09:24, Andy Lutomirski wrote: >>>>>>> >>>>>>> The relevant line from latencytop seems to be: >>>>>>> >>>>>>> 154 20441402 489139 radeon_fence_default_wait [radeon] >>>>>>> fence_wait_timeout ttm_bo_wait [ttm] ttm_bo_move_accel_cleanup [ttm] >>>>>>> radeon_move_blit.isra.12 [radeon] radeon_bo_move [radeon] >>>>>>> ttm_bo_handle_move_mem [ttm] ttm_bo_evict [ttm] ttm_mem_evict_first >>>>>>> [ttm] ttm_bo_mem_space [ttm] ttm_bo_validate [ttm] >>>>>>> radeon_bo_fault_reserve_notify [radeon] >>>>>> >>>>>> Which process is this? >>>>> >>>>> Xorg >>>>> >>>>>> >>>>>> Looks like CPU access to a BO in VRAM, but the BO is located outside of >>>>>> the CPU visible area of VRAM, so it has to be moved into the CPU visible >>>>>> area first. > > [...] > >>>> But I'm still waiting for the day that buggy userspace *can't* cause >>>> kernel graphics stalls. >>> >>> Actually, this looks more like buggy userspace stalling itself. :) >> >> I thought the stall was the kernel evicting things from vram. Why >> does it need to wait for userspace for that? Is it that userspace is >> actively using whatever's being evicted? > > As I explained above, the stall happens because userspace does CPU > access to a BO which resides in the CPU-inaccessible part of VRAM. The > kernel has to move the BO into the CPU accessible part of VRAM before it > can let userspace proceed. Sure, but why does that take nearly 500ms? Even if the object in question is the entire framebuffer, that still seems extraordinarily slow. --Andy > > Current Mesa (10.4 or newer I think) sets a hint for BOs which will > likely be accessed by the CPU, so recent kernels can prioritize putting > those into the CPU accessible part of VRAM in the first place. > > Or, if you're using EXA, the problem could be in the xf86-video-ati EXA > code. > > > -- > Earthling Michel Dänzer | http://www.amd.com > Libre software enthusiast | Mesa and X developer -- Andy Lutomirski AMA Capital Management, LLC _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
