[Bug 110781] Radeon: heavy r300 performance drop regression between 11.x and 19.x

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Tue May 28 11:51:35 UTC 2019


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

            Bug ID: 110781
           Summary: Radeon: heavy r300 performance drop regression between
                    11.x and 19.x
           Product: Mesa
           Version: git
          Hardware: x86 (IA32)
                OS: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Drivers/Gallium/r300
          Assignee: dri-devel at lists.freedesktop.org
          Reporter: u9vata at gmail.com
        QA Contact: dri-devel at lists.freedesktop.org

Dear mesa/freedesktop team!

I am a happy user of the open source radeon r300 driver for my Mobility radeon
200M card in my (pretty old, but good-enough) laptop.

I have updated my system + changed distro and got a complete slowdown. I have
checked if it is the kernel or the distro and found that I can get back my
performance if I revert to mesa 11.x and corresponding xorg while still using
the latest linux kernel. This seems to be some kind of performance regression.

The performance drop is heavy: 50%..100% slowdown and very high CPU usage. For
example now extreme tux racer reports 100% CPU usage and before it reports
25-50% at maximum (including any spikes) and mostly around 30% actually when
averaging.

I have used the perf tool to locate what causes the heavy CPU usage and I find
that there is a lot of memory movements in a create_bo call.

  See this log:
  Samples: 171K of event 'cycles', Event count (approx.): 67632101793           
    Children      Self  Command      Shared Object              Symbol          
  -   61,12%     0,09%  etr          [kernel.vmlinux]           [k]
entry_SYSENTER_32                                                             ◆
   - 61,07% entry_SYSENTER_32                                                   
    - 60,94% do_fast_syscall_32                                                 
     - 57,92% sys_ioctl                                                         
      - 57,84% do_vfs_ioctl                                                     
       - 57,43% radeon_drm_ioctl                                                
        - 57,04% drm_ioctl                                                      
         - 56,81% drm_ioctl_kernel                                              
          - 55,86% radeon_gem_create_ioctl                                      
           - 55,46% radeon_gem_object_create                                    
            - 55,36% radeon_bo_create                                           
             - 55,20% ttm_bo_init                                               
              - 55,14% ttm_bo_init_reserved                                     
               - 54,75% ttm_bo_validate                                         
                - 54,42% ttm_bo_handle_move_mem                                 
                 - 54,07% ttm_tt_bind                                           
                  - 53,36% radeon_ttm_tt_populate                               
                   + 53,33% ttm_populate_and_map_pages                          
                     0,62% radeon_ttm_backend_bind

I see these are code paths in the kernel, but the same happens regardless I use
an old kernel (and modules) or the newest one, while this gets a near complete
disappear when I revert to old mesa and X.

I do not see anything related to bo (buffer object??) creation in mesa sources
below the gallium/r300 directory, but I have found things that make ioctl in:

gallium/winsys/radeon/drm/radeon_drm_bo.c

^^Is this also used for r300 cards? The "source tree" documentation page seems
to tell me this is a "shared code for r600 and radeonsi", but where is r300
doing calls to the ioctls then?

Something happened in the last 1-3 years that changed stuff to move memory
around crazily for some reason and use more CPU for that. Surely it was not
having this heavy slowdown before. Now it is nearly as slow as llvmpipe for
practical cases (but not slower!).

Can anyone help me with this? I am a developer myself, but I am not well versed
in the source code of mesa and in how to analyse its performance bottlenecks.

PS.: On phoronix I was already analysing the problem for long: 

https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/open-source-amd-linux/1099745-how-to-tell-if-a-driver-is-gallium-or-just-mesa-slow-renderng-with-radeon

^^There the whole process of what I was trying is written with every step, but
maybe only perf outputs are of interest from there...

Feel free to ask me anything about the issue. If I would be able to help
solving this myself I will be happy too, but I have never really did any
patches to these kind of core system libraries and I am quite rookie for gpu
drivers...

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20190528/6ce6ba38/attachment-0001.html>


More information about the dri-devel mailing list