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

  • #71
    Actually the bug is already reported here:

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

    Still in the same time I continue bisecting on my own. Now I have found an interesting commit at 04ea03d99d8 where I already see the considerable slowdown, but counting ioctl calls they are not the high level as the latest version so now I suspect there are at least two commits that have slowed down performance on my machine, but the first/earlier one made the biggest impact so I went in that direction. Commit 04ea03d99d8 is 17.4.x if I am not mistaken.

    Comment


    • #72
      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 ;-)

      Comment


      • #73
        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.

        Comment


        • #74
          Awesome, great work tracking this down! Much props and respect!

          Comment


          • #75
            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! ;-)

            Comment


            • #76
              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.

              Comment


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

                Comment


                • #78
                  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)

                  Comment


                  • #79
                    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.

                    Comment


                    • #80
                      That's a great writeup.

                      Comment

                      Working...
                      X