Announcement

Collapse
No announcement yet.

Radeon vs. Modesetting DDX Performance Comparison

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

  • Radeon vs. Modesetting DDX Performance Comparison

    Phoronix: Radeon vs. Modesetting DDX Performance Comparison

    With xf86-video-modesetting continuing to add support for new features while being a generic hardware driver as long as there's an underlying DRM/KMS driver, how is the 2D and OpenGL performance compare when using this driver on an AMD GPU instead of the specialized xf86-video-ati DDX driver? Here's some benchmarks...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Radeon V Radeon-dri2

    What are the differences between Radeon and Radeon-dri2?

    Comment


    • #3
      Originally posted by You- View Post
      What are the differences between Radeon and Radeon-dri2?
      radeon - https://github.com/iXit/xf86-video-ati (with dri3)
      radeon-dri2 http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/

      Comment


      • #4
        So the generic DDX with code sharing across all KMS drivers is faster than the equivalent GPU-specific one?
        Unless it for some reason e.g. uses more power on APUs, this seems like a prime candidate to get rid of in order to reduce the maintenance burden ...

        Comment


        • #5
          My eyes must be playing tricks on me. The generic xf86-video-modesetting driver is outperforming the radeon driver?

          How about comparing the generic driver to the Nouveau or i915 drivers?

          Comment


          • #6
            SW rendering is usually faster than HW acceleration for those tests IIRC... but not faster for "general use".
            Test signature

            Comment


            • #7
              Originally posted by bridgman View Post
              SW rendering is usually faster than HW acceleration for those tests IIRC... but not faster for "general use".
              Did modesetting not use glamor (hardware accelerated) through mesa dri driver? About what SW rendering you say?

              Code:
              [   288.348] (II) modeset(0): Using exact sizes for initial modes
              [   288.348] (II) modeset(0): Output HDMI-0 using initial mode 1920x1080
              [   288.348] (II) modeset(0): Using default gamma of (1.0, 1.0, 1.0) unless otherwise stated.
              [   288.348] (==) modeset(0): DPI set to (96, 96)
              [   288.387] (==) modeset(0): Backing store enabled
              [   288.387] (==) modeset(0): Silken mouse enabled
              [   288.387] (II) modeset(0): RandR 1.2 enabled, ignore the following RandR disabled message.
              [   288.387] (==) modeset(0): DPMS enabled
              [   288.387] (II) modeset(0): [DRI2] Setup complete
              [   288.387] (II) modeset(0): [DRI2]   DRI driver: radeonsi
              [   288.399] (II) modeset(0): Damage tracking initialized
              [   288.399] (II) modeset(0): Setting screen physical size to 508 x 285
              [   291.238] (II) modeset(0): EDID vendor "HII", prod id 8544
              [   291.238] (II) modeset(0): Using EDID range info for horizontal sync
              [   291.238] (II) modeset(0): Using EDID range info for vertical refresh
              [   291.238] (II) modeset(0): Printing DDC gathered Modelines:

              Comment


              • #8
                Originally posted by CrystalGamma View Post
                So the generic DDX with code sharing across all KMS drivers is faster than the equivalent GPU-specific one?
                Unless it for some reason e.g. uses more power on APUs, this seems like a prime candidate to get rid of in order to reduce the maintenance burden ...
                Already planned as far as I understood

                Comment


                • #9
                  Well someone need clarify the results.

                  The reasons between the differences is ... compositing.

                  For the one named 'radeon' which is the radeon ddx + dri3 enabling patch, the compositor is less efficient because there is no Present support in the ddx. It incurs a copy (the compositor, via mesa, will use dri3 over dri2, and dri3 is used with Present)
                  For the "radeon-dri2" one, compositor uses DRI2. Normal efficiency
                  For the modesetting, the results are slightly better probably because here you have complete DRI3+Present support (which the compositor will use over DRI2) and Present has proper buffer age support which enables more efficient compositing.

                  Comment


                  • #10
                    Works for compiz, but much slower for games

                    I just tested this on AMD FX8120/Radeon HD5760. The MATE/compiz desktop opened fine, the driver is plenty good enough for that. Then I fired up Criticalmass, a 2D game written in Opengl that I use as one of my benchmarks. Framerates dropped from 600+ to about 90, and the dropped frame problem that requires such high framerates in Criticalmass to hide caused substantial stutter. The GPU temperature did not rise at all, indicating that hardware opengl was being used minimally or not at all. I then tried scorched3d, the game did not even open, generating a "failed to set the video mode" error for fullscreen at 1080p, same resolution as Criticalmass/critter.

                    Obviously any passthrough to hardware acceleration does not apply to opengl loads such as games, at least on the version I have (running Ubuntu Vivid with the Oibaf PPA packages from Utopic( still newest version in the PPA).

                    From the modesetting manpage:

                    modesetting is an Xorg driver for KMS devices. This is a non-accelerated driver, the following framebuffer depths are supported: 8, 15, 16, 24. All visual types are supported for depth 8, and TrueColor visual is supported for the other depths. RandR 1.2 is supported.

                    Comment

                    Working...
                    X