Announcement

Collapse
No announcement yet.

How to tell if a driver is gallium or just mesa? (Slow renderng with radeon)

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

  • prenex
    replied
    Originally posted by bridgman View Post
    That's a great writeup.
    Thanks! Added similar writeup about fixing the HyperZ issue of mine:

    http://ballmerpeak.web.elte.hu/devbl...el-module.html

    Leave a comment:


  • bridgman
    replied
    That's a great writeup.

    Leave a comment:


  • prenex
    replied
    Added a blog post about the whole issue and its solving process here:

    http://ballmerpeak.web.elte.hu/devbl...ics-stack.html

    I have linked to this forum and every other place and people where communications were do for this issue.
    I just wanted to put things together as it might be valuable for others wanting to do similar things - I was and still is a rookie for these things after all.

    Leave a comment:


  • prenex
    replied
    It seems slowdown is now completely fixed - but who knows when it gets to official mesa builds. Until then the bug report contains the proper fixes anyone can apply if interested.

    See:
    https://bugs.freedesktop.org/show_bug.cgi?id=110781

    Also there is a patch file from someone else who implemented shader caching for r300 too.

    TL;DR: It was a mesa performance regression bug and should be considered solved in my opinion (of course maybe some more testing should help)

    Leave a comment:


  • prenex
    replied
    A more proper quickfix is available that works with current 19.x mesa. See bug report.

    Leave a comment:


  • prenex
    replied
    Now there are a halfway complete proposed solution by Marek here:

    https://bugs.freedesktop.org/show_bug.cgi?id=110781

    It works when I patch the commit I get with the bisecting, but there is an assert failing when applied to latest 19.x in the git. I also provided a simple hack that forces the VRAM domain always that succeeds the assert and gives good performance, but it is only a dirty hack so far and a proper solution is still needed.

    Leave a comment:


  • prenex
    replied
    Sorry... the commit itself is not giant, jut after the bisect finished git moved to the commit where I started bisecting... my bad, my mistake that I diffed against a much later rev haha. Sorry.

    So now I can just check it... It seems small change so there is hope! ;-)

    Leave a comment:


  • duby229
    replied
    Awesome, great work tracking this down! Much props and respect!

    Leave a comment:


  • prenex
    replied
    8b3a257851905ff444d981e52938cbf2b36ba830 is the first bad commit
    commit 8b3a257851905ff444d981e52938cbf2b36ba830
    Author: Marek Olšák <[email protected]>
    Date: Tue Jul 18 16:08:44 2017 -0400

    radeonsi: set a per-buffer flag that disables inter-process sharing (v4)

    For lower overhead in the CS ioctl.
    Winsys allocators are not used with interprocess-sharable resources.

    v2: It shouldn't crash anymore, but the kernel will reject the new flag.
    v3 (christian): Rename the flag, avoid sending those buffers in the BO list.
    v4 (christian): Remove setting the kernel flag for now

    Reviewed-by: Marek Olšák <[email protected]>

    ^^I have tried the revision right before this one and it is still fast, while this is slow. There must be a very minor other slowdown, but this commit seems to make 95% of my slowdown in performance on my Ati Mobility Raderon 200M.

    Will look at the changeset and also try a manual revert on the latest code according to the changeset. Then discuss how to solve this "properly" so I am not slowing down others maybe...

    EDIT: Oh man... that commit is a huge changeset :-(
    Last edited by prenex; 06-03-2019, 06:32 AM.

    Leave a comment:


  • prenex
    replied
    I am getting really close to bisecting the bigger identified problem.

    bad: b672c3833b7
    good: aff1ad0798

    Now at this point:

    Bisecting: 9 revisions left to test after this (roughly 3 steps)
    [3efedf98e8272d1a32a3837b22161582d28c4487] i965: Always flush caches after blitting to a GL buffer object.

    Also now compiation is not even taking an hour like before where bisect was jumping big time periods as code barely changes I guess ;-)

    Leave a comment:

Working...
X