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

[prenex]

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.

[prenex]

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 ;-)

[prenex]

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 :-(

[duby229]

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

[prenex]

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! ;-)

[prenex]

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.

[prenex]

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

[prenex]

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)

[prenex]

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

http://ballmerpeak.web.elte.hu/devblog/debugging-mesa-and-the-linux-3d-graphics-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.

[bridgman]

That's a great writeup.