On Mon, May 12, 2014 at 7:38 PM, Grigori Goronzy <greg@xxxxxxxxxxxx> wrote: > I can confirm this fixes it for me, too. > > 3.15 with these fixes and the large PTE patches actually ends up being > noticeably slower than earlier kernels with Xonotic, though. I wonder what's > going on. Allocation overhead? > > Grigori > > > On 12.05.2014 14:50, Christian König wrote: >> >> I could reproduce the problem with xonotic and I think I've found the >> issue. >> >> Please test the attached patch. >> >> Thanks, >> Christian. >> >> Am 11.05.2014 11:06, schrieb Christian König: >>>> >>>> I have tested it and it doesn't fix the hangs. >>> >>> Yeah, thought so. Well it was just a guess. >>> >>>> (Also, I don't like the patch, because it reverts the behavior I added >>>> for userspace buffers.) >>> >>> Actually it shouldn't affect that. The alternative domain always >>> contains GART even when userspace only specified VRAM as placement (as >>> long as it is technical possible to do so). >>> >>> So what should happen is that TTM sees the current placement, matches >>> that with the desired placement and should find that it doesn't need >>> to move the buffer (we should just test if this behavior really works >>> as expected). >>> >>> Christian. >>> >>> Am 10.05.2014 23:38, schrieb Marek Olšák: >>>> >>>> Hi Christian, >>>> >>>> I have tested it and it doesn't fix the hangs. >>>> >>>> (Also, I don't like the patch, because it reverts the behavior I added >>>> for userspace buffers.) >>>> >>>> Marek >>>> >>>> >>>> >>>> On Sat, May 10, 2014 at 6:34 PM, Christian König >>>> <deathsimple@xxxxxxxxxxx> wrote: >>>>> >>>>> Couldn't reproduce the issue so far. So the attached patch is just a >>>>> complete shoot into the dark found by rereading the code, but it might >>>>> actually be the problem. >>>>> >>>>> Please give it a try. >>>>> >>>>> Going to keep testing in the meantime, >>>>> Christian. >>>>> >>>>> Am 10.05.2014 10:23, schrieb Christian König: >>>>> >>>>>>> I see hangs with kernel 3.15 and SI under memory pressure, e.g. if >>>>>>> I boot >>>>>>> with radeon.vramlimit=256 and then run Xonotic timedemo with high >>>>>>> settings. >>>>>>> I haven't had a chance to bisect it yet, but it might be a similar >>>>>>> problem. >>>>>> >>>>>> Sounds like the same issue to me. Thx for the good test case. >>>>>> >>>>>>> Any idea what is wrong with it? >>>>>> >>>>>> Actually I already wondered that it went so smooth without any >>>>>> regression >>>>>> so far, didn't noticed the bug in bugzilla.kernel.org yet. >>>>>> >>>>>>> Some of the tests allocate a lot of MSAA textures and the tests also >>>>>>> run in parallel, which creates a lot of memory pressure and probably >>>>>>> causes buffer evictions. >>>>>> >>>>>> Sounds like the underlying problem to me. We probably evict some >>>>>> part of a >>>>>> page table without updating the page directory. Going to dig into >>>>>> it today, >>>>>> it's probably just a one liner missing somewhere in the VM code. >>>>>> >>>>>> Christian. >>>>>> >>>>>> Am 09.05.2014 23:39, schrieb Grigori Goronzy: >>>>>>> >>>>>>> On 09.05.2014 20:03, Marek Olšák wrote: >>>>>>>> >>>>>>>> >>>>>>>> This commit which first appeared in 3.15-rc1 causes hangs on >>>>>>>> Bonaire: >>>>>>>> [...] >>>>>>>> >>>>>>>> The simplest way to reproduce the hangs is to run piglit with these >>>>>>>> parameters: >>>>>>>> -t texelFetch.fs >>>>>>>> >>>>>>>> Some of the tests allocate a lot of MSAA textures and the tests also >>>>>>>> run in parallel, which creates a lot of memory pressure and probably >>>>>>>> causes buffer evictions. >>>>>>>> >>>>>>> I see hangs with kernel 3.15 and SI under memory pressure, e.g. if >>>>>>> I boot >>>>>>> with radeon.vramlimit=256 and then run Xonotic timedemo with high >>>>>>> settings. >>>>>>> I haven't had a chance to bisect it yet, but it might be a similar >>>>>>> problem. >>>>>>> >>>>>>> Grigori >>>>>> >>>>>> >>> >> > > _______________________________________________ > dri-devel mailing list > dri-devel@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/dri-devel _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
