Announcement

Collapse
No announcement yet.

Benchmarking The New RadeonSI/Gallium3D Threaded Support

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • grigi
    replied
    Thank you

    Leave a comment:


  • marek
    replied
    Originally posted by grigi View Post

    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/me...e2309e4cebc472
    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.

    Leave a comment:


  • grigi
    replied
    Originally posted by marek View Post

    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/me...e2309e4cebc472
    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.

    Leave a comment:


  • grigi
    replied
    Originally posted by marek View Post

    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)

    Leave a comment:


  • marek
    replied
    Originally posted by grigi View Post
    @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.

    Leave a comment:


  • grigi
    replied
    @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?

    Leave a comment:


  • grigi
    replied
    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.

    Leave a comment:


  • grigi
    replied
    Originally posted by marek View Post
    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?

    Leave a comment:


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

    Leave a comment:


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

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

    Leave a comment:

Working...
X