Am 24.05.2017 um 13:03 schrieb Marek Olšák:
On Wed, May 24, 2017 at 9:56 AM, Michel Dänzer <mic...@daenzer.net> wrote:
On 23/05/17 07:38 PM, Marek Olšák wrote:
On Tue, May 23, 2017 at 2:45 AM, Michel Dänzer <mic...@daenzer.net> wrote:
On 22/05/17 07:09 PM, Marek Olšák wrote:
On Mon, May 22, 2017 at 12:00 PM, Michel Dänzer <mic...@daenzer.net> wrote:
On 20/05/17 06:26 PM, Marek Olšák wrote:
On May 20, 2017 3:26 AM, "Michel Dänzer" <mic...@daenzer.net
<mailto:mic...@daenzer.net>> wrote:
On 20/05/17 01:14 AM, Marek Olšák wrote:
> Hi Michel,
>
> I've applied your series
Thanks for testing it.
> and it doesn't help with low Dirt Rally performance on Fiji. I see TTM
> buffer moves at 800MB/s and many VRAM page faults.
Did you see this:
>> Note that there's only little if any improvement of the average
framerate
>> reported, but the minimum framerate as seen on the HUD goes from
~10 fps
>> to ~17.
I.e. it mostly affects the minimum framerate and smoothness for me
as well.
Without the series, I get 70 average fps. With the series, I get 30
average fps. That might just be random bad luck. I don't know.
Hmm, yeah, maybe that was just one of the random slowdowns you've been
talking about in other threads and on IRC?
I can't reproduce any slowdown with these patches, even leaving visible
VRAM size at 256 MB.
The random slowdowns with Dirt Rally are only caused by the pressure
on visible VRAM. This whole thread is about those random slowdowns.
No, this thread is about the scenario described in the cover letter of
this patch series.
If you're saying "maybe it was just one of the random slowdowns", you're
saying "maybe it was just the visible VRAM pressure". It's only
random with Dirt Rally, which makes it difficult to believe statements
such as "I can't reproduce any slowdown".
I could say the same thing about you seeing random slowdowns... I've
never seen that, I had to artificially limit the size of visible VRAM to
64 MB to make it significantly affect the benchmark result.
How many times do you need to run the benchmark on average to hit a
random slowdown? Which desktop environment and other X clients are
running during the benchmark? Which tab is active in the Steam window
while the benchmark runs?
In my case, it's only xfwm4, xterm and steam on the Dirt Rally page in
the library.
Ubuntu Unity, Steam small mode (there are no tabs), Ultra settings in
Dirt Rally.
Every single time I run the game with this series, I get 700-1000MB/s
of TTM BO moves. There doesn't seem to be any randomness.
It was better without this series. (meaning it was sometimes OK, sometimes bad)
Thanks for the additional details. I presume that in the bad case there
are some BOs lying around in visible VRAM (e.g. from Unity), which
causes some of Dirt Rally's BOs to go back and forth between GTT on CPU
page faults and VRAM on GPU usage.
This means at least patch 2 goes out the window. I'll see if I can
salvage something out of patch 3.
I think the final solution (done in fault_reserve_notify) should be:
if (bo->num_cpu_page_faults++ > 20)
bo->preferred_domain = GTT_WC;
I more or less agree on that, but setting preferred_domain permanently
to GTT_WC is what worries me a bit.
E.g. imagine you alt+tab from a game to your browser and back and the
game runs way slower now because BOs are never moved back to VRAM.
What we need is a global limit of number of bytes transfered per second
for swap operations or something like that.
Or maybe a timeout which says when a BO was moved (either by swapping it
out or by a CPU page fault) only move it back after +n jiffies or
something like that.
Christian.
Otherwise I think we'll be just going in circles and not get anywhere.
Marek
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
