I think it's caused by something else. I'll continue testing and bisecting.
Marek
On Tue, May 13, 2014 at 5:31 PM, Christian König deathsimple@vodafone.de wrote:
Is the performance regression regression caused by the page table changes or something else?
I did made some tests with xonotic while developing it and it didn't showed anything obvious, but I didn't made tests on different systems.
Christian.
Am 13.05.2014 17:19, schrieb Marek Olšák:
Your latest patches fix the regression.
The performance regression can also be reproduced with piglit "-t texelFetch.fs".
Kernel 3.14: real 0m17.724s user 0m41.905s sys 0m11.299s
The problematic commit checked out + your fixes (without the PTE patch I think): real 0m23.474s user 1m1.008s sys 0m13.812s
Marek
On Tue, May 13, 2014 at 3:57 PM, Christian König deathsimple@vodafone.de wrote:
Am 13.05.2014 15:22, schrieb Alex Deucher:
On Mon, May 12, 2014 at 7:38 PM, Grigori Goronzy greg@chown.ath.cx 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?
Unlikely, Xonotic just allocates a single page table at start, which then gets extended to a certain rate until they no longer need more address space and are done with it.
Grigori, can you bisect and/or try to figure out what's wrong here?
Christian.
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@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 >>>> >>>>
dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel