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 at vodafone.de> 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 >>>> > -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-drm-radeon-fix-page-directory-update-size-estimation.patch Type: text/x-diff Size: 986 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140512/35410e95/attachment.patch>
