On 30.05.2014 13:46, Grigori Goronzy wrote:
On 30.05.2014 13:30, Marek Olšák wrote:
Grigori,
you can git-checkout the commit before and after the memory management
changes, compile both and test them.
I was trying to revert the changes, but it looks like too much changed
in the meantime. The suitable commits to check out should be 0bc490a8
(before) and 19dff56a (after), right?
Turns out these changes weren't the problem, but instead it's the page
tables rework which seems to also cause a bunch of other issues, commit
6d2f2944. The latest drm-fixes code doesn't change it, either.
According to my (not very scientific) testing with radeontop and the
"time" utility, this appears to be a CPU overhead problem. The "sys"
duration reported by time for a Xonotic benchmark run is over 3x as long
after the regression, and radeontop seems to report about 10% reduced
GPU load on average.
Best regards
Grigori
Best regards
Grigori
Marek
On Fri, May 30, 2014 at 2:30 AM, Grigori Goronzy <greg@xxxxxxxxxxxx>
wrote:
On 13.05.2014 22:27, Marek Olšák wrote:
I applied these two patches Christian sent to dri-devel:
drm/radeon: fix page directory update size estimation
drm/radeon: fix buffer placement under memory pressure v2
on top of torvalds's master branch.
With latest kernel master (a991639c) I still see a regression,
compared to
3.13 or 3.14, which have similar performance. Xonotic is about 7%
slower.
OpenArena and Unigine Tropics are also noticeably slower, but I didn't
record accurate numbers.
Maybe the improved memory management has some overhead, but this is not
acceptable IMHO. I'll try to investigate further.
Best regards
Grigori
Marek
On Tue, May 13, 2014 at 10:19 PM, Grigori Goronzy <greg@xxxxxxxxxxxx>
wrote:
On 13.05.2014 21:50, Marek Olšák wrote:
Hi Christian,
The performance regression I saw with piglit seems to be fixed with
latest kernel git. It's difficult to bisect the kernel, because there
are only merges between 3.14 and 3.15 and the merged committs are
actually based on 3.14-rc1 and 3.14-rc4.
All seems to be fine with your fixes.
Which fixes have you applied? There are quite a few pending patches on
dri-devel, that aren't yet part of drm-fixes-3.15.
Grigori
Marek
On Tue, May 13, 2014 at 5:31 PM, Christian König
<deathsimple@xxxxxxxxxxx> 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@xxxxxxxxxxx> wrote:
Am 13.05.2014 15:22, schrieb Alex Deucher:
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?
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@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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
