If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
Announcement
Collapse
No announcement yet.
Benchmarking The New RadeonSI/Gallium3D Threaded Support
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?
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.
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?
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.
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)
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
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.
Ok, I found the commit that causes the regression:
On branch "17.1":
35ec26bb00536639b9571f31d8e3f2bcbcfc32fb 30.31fps
ad3b5b7f5f7590fd4359ea3483e2309e4cebc472 18.12fps
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.
Comment