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

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

    Dear Phoronix members!

    I have changed my linux distro from ubuntu 16.04 to the latest arch32 and installed xf86-video-ati and mesa packages. Direct rendering is enabled, but 3D performance is slower than before. Window manager is the same as before, but I have no display manager now and just do a startx to start dwm so generally the system is sometimes even faster -except for 3D.

    The glxgears reports 50-60 FPS. Extreme Tux Racer lags a bit (especially in the menu) and there is an interesting thing that glxinfo does not report "Gallium 0.4 on ....". Earlier it said Gallium 0.4 on llvmpipe or Gallium 0.4 on Ati ... whatever. Both for software and hardware rendering.

    Do I miss some things on my system or just the strings have changed to not say this??? Please someone who knows it at least tell if this is a change in the strings but everything is the same or if this really indicates there is no gallium for some reason here...

    See these outputs:

    Code:
    [[email protected] examples]$ glxinfo | grep Open
    OpenGL vendor string: X.Org R300 Project
    OpenGL renderer string: ATI RC410
    OpenGL version string: 2.1 Mesa 19.0.3
    OpenGL shading language version string: 1.20
    OpenGL extensions:
    OpenGL ES profile version string: OpenGL ES 2.0 Mesa 19.0.3
    OpenGL ES profile shading language version string: OpenGL ES GLSL ES 1.0.16
    OpenGL ES profile extensions:
    and:

    Code:
    [[email protected] ~]$ export LIBGL_ALWAYS_SOFTWARE=1; glxinfo | grep Open
    OpenGL vendor string: VMware, Inc.
    OpenGL renderer string: llvmpipe (LLVM 8.0, 128 bits)
    OpenGL core profile version string: 3.3 (Core Profile) Mesa 19.0.3
    OpenGL core profile shading language version string: 3.30
    OpenGL core profile context flags: (none)
    OpenGL core profile profile mask: core profile
    OpenGL core profile extensions:
    OpenGL version string: 3.1 Mesa 19.0.3
    OpenGL shading language version string: 1.40
    OpenGL context flags: (none)
    OpenGL extensions:
    OpenGL ES profile version string: OpenGL ES 3.0 Mesa 19.0.3
    OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00
    OpenGL ES profile extensions:
    My GPU is this one (lshw indicates and r300 kind of card):

    Code:
               *-display
                    description: VGA compatible controller
                    product: RC410M [Mobility Radeon Xpress 200M]
                    vendor: Advanced Micro Devices, Inc. [AMD/ATI]
                    physical id: 5
                    bus info: [email protected]:01:05.0
                    version: 00
                    width: 32 bits
                    clock: 66MHz
                    capabilities: vga_controller bus_master cap_list rom
                    configuration: driver=radeon latency=64 mingnt=8
                    resources: irq:17 memory:c0000000-cfffffff ioport:9800(size=256) memory:fe1f0000-fe1fffff memory:c0000-dffff
    I am aware that there used to be an r300 classic and an r300 gallium driver, but it was long ago. Is it possible that this is the classic one??? How can I know which it is?

    Maybe I am completely missing something instead, but I see the perfomance was better earlier...

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

Working...
X