Benchmarking The New RadeonSI/Gallium3D Threaded Support

[grigi]

Thank you

[marek]

Ok, I found the commit that causes the regression:
On branch "17.1":
35ec26bb00536639b9571f31d8e3f2bcbcfc32fb 30.31fps
ad3b5b7f5f7590fd4359ea3483e2309e4cebc472 18.12fps

So the commit that causes the big slowdown:

https://cgit.freedesktop.org/mesa/mesa/commit/?h=17.1&id=ad3b5b7f5f7590fd4359ea3483e2309e4cebc472

seems to be specific to SI.
Note that I have a Mobile Cape Verde (M4000: 512 shaders, 675Mhz, 1G DDR5 RAM) which is si.

The commit sounds like it should fix a tesselation related bug, but in Shadow of Mordor I notice no visual difference, just a massive performance deficit.

You can keep the commit reverted. Fixing the performance regression is under discussion.

[grigi]

At this point I think bisecting the regression is the only option. I don't think sisched and forcedma are necessary.

Ok, I found the commit that causes the regression:
On branch "17.1":
35ec26bb00536639b9571f31d8e3f2bcbcfc32fb 30.31fps
ad3b5b7f5f7590fd4359ea3483e2309e4cebc472 18.12fps

So the commit that causes the big slowdown:

https://cgit.freedesktop.org/mesa/mesa/commit/?h=17.1&id=ad3b5b7f5f7590fd4359ea3483e2309e4cebc472

seems to be specific to SI.
Note that I have a Mobile Cape Verde (M4000: 512 shaders, 675Mhz, 1G DDR5 RAM) which is si.

The commit sounds like it should fix a tesselation related bug, but in Shadow of Mordor I notice no visual difference, just a massive performance deficit.

[grigi]

At this point I think bisecting the regression is the only option. I don't think sisched and forcedma are necessary.

I didn't get round to bisecting it yet, but I noticed that the regression also happens between 17.1.0 and 17.1.1 Which is a lot less changes to test.
Hopefully I'll be able to confirm that this is the case and then at least I have bounds to narrow the search (because the validation is manual, and I need to use this system for work)

[marek]

@marek

Right, so there is definitely a big regression with the current GIT.
After downgrading to mesa-17.1.0, I now get 30.4fps average on the benchmark.
(glad my memory wasn't lying to me)

All benchmarking was also done with this env vars:
vblank_mode=0 R600_DEBUG=sisched,forcedma

I'm still open to testing specific versions of the git repo, Is there a git version you want me to try?

At this point I think bisecting the regression is the only option. I don't think sisched and forcedma are necessary.

[grigi]

@marek

Right, so there is definitely a big regression with the current GIT.
After downgrading to mesa-17.1.0, I now get 30.4fps average on the benchmark.
(glad my memory wasn't lying to me)

All benchmarking was also done with this env vars:
vblank_mode=0 R600_DEBUG=sisched,forcedma

I'm still open to testing specific versions of the git repo, Is there a git version you want me to try?

[grigi]

Ok, I upgraded to 4.11.1 and the only change I noticed is that the VRAM usage was a bit lower, and num-bytes-moved was also definitely lower (almost always zero now).
But benchmark results are more-or-less the same at 17.8fps.

I'm going to downgrade to mesa-17.1, and see.

[grigi]

I recomment trying: GALLIUM_THREAD=0
Also add this to your HUD: GALLIUM_HUD=num-bytes-moved

Thanks for the response Marek.

I added GALLIUM_THREAD=0 to the environment, but it made no change at all. bench average stayed at 17.7fps.
This doesn't seem right?

num-bytes-moved graph was mostly spiking during loading, during the benchmark run it was most often at 0, sometimes jump up to a few hundred KB, and had one big spike of about 5MB.
That seems ok?

I'm going to try upgrading to 4.11.1 kernel to see if that makes a difference?

[marek]

I recomment trying: GALLIUM_THREAD=0
Also add this to your HUD: GALLIUM_HUD=num-bytes-moved

[grigi]

I upgraded to LLVM 4.0, and noticed no change. Now on Git (b5437fc05c7d8fb3899b073b451c7c658c4dc441)

Sigh, this is going to take a while to find.