Announcement

Collapse
No announcement yet.

Open-Source Radeon Driver Reworks Audio Code, Adds DisplayPort Audio

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

  • #31
    Adriannho, consider obtaining/compiling mesa with DRI3 support. I've found that the performance is actually improved with a similar configuration AMD + AMD trinity APU and you don't need to use xrandr to configure it anymore.

    The downside is that vsync won't work but you can workaround it by running a composite manager such as compton with vsync supported, and forcing it in DRI2 mode.

    EDIT: Also requires various other components to be fairly recent. It's all listed here: http://nouveau.freedesktop.org/wiki/Optimus/
    Last edited by AnonymousCoward; 18 January 2015, 01:33 AM.

    Comment


    • #32
      Originally posted by AnonymousCoward View Post
      Adriannho, consider obtaining/compiling mesa with DRI3 support. I've found that the performance is actually improved with a similar configuration AMD + AMD trinity APU and you don't need to use xrandr to configure it anymore.

      The downside is that vsync won't work but you can workaround it by running a composite manager such as compton with vsync supported, and forcing it in DRI2 mode.

      EDIT: Also requires various other components to be fairly recent. It's all listed here: http://nouveau.freedesktop.org/wiki/Optimus/
      Since my last post I switched to arch (via antergos), fetched all updated components (mesa-git, llvm-svn etc) and done a couple of tests.

      With DRI2 no games work. If I do xrandr --setprovideroffloadsink 1 0 and the use DRI_PRIME=1 before game binary, the game will lunch either to a blank screen either will hang at the loading screen (as in the case of unvanquished).

      With DRI3 all games I tried worked, but, frankly, I didn't see any performance improvements. So, if I skip xrandr command and only use DRI_PRIME=1 before binary, the game loads and works. If I use glxgears or glxspheres64 the performance difference is quite noticeable (from 65+ to 250+ in glxspheres64, 60 to 1000+ in glxgears). But in games, kinda nothing (Tested TDM and The Talos Principle). I checked both visually with GALLIUM_HUD and with PTS in unigine tropics and xonotic.

      I don't know if I ran the benchmarks correctly though, as I don't know if running DRI_PRIME=1 phoronix-test-suite run *benchmark is the proper way to test the dGPU with PTS.

      Another strange fact is, if I use xrandr and set the primary card and then check for OpenGL renderer string I get:
      Code:
      OpenGL renderer string: Gallium 0.4 on AMD HAINAN
      but with DRI3 I get
      Code:
      OpenGL renderer string: Gallium 0.4 on AMD ARUBA
      which is the same family as my iGPU.

      So, to sum things up, I don't really know where I'm at right now

      Comment


      • #33
        Originally posted by Adriannho View Post
        With DRI2 no games work. If I do xrandr --setprovideroffloadsink 1 0 and the use DRI_PRIME=1 before game binary, the game will lunch either to a blank screen either will hang at the loading screen (as in the case of unvanquished).
        If you using KDE and Kwin as window manager then it's what cause black screen.
        You can bypass it by setting compositing type to "XRender" in "Desktop Effects -> Advanced".

        Also wouldn't surprise if some other window managers might have same issue with DRI2.

        Comment


        • #34
          Originally posted by SXX⁣ View Post
          If you using KDE and Kwin as window manager then it's what cause black screen.
          You can bypass it by setting compositing type to "XRender" in "Desktop Effects -> Advanced".

          Also wouldn't surprise if some other window managers might have same issue with DRI2.
          No no, I use gnome shell.

          Comment


          • #35
            Originally posted by Adriannho View Post
            No no, I use gnome shell.
            Basically this problem shared between all OpenGL-based compositors (check this wiki page).
            What you can try it's:
            Code:
            xcompmgr --replace
            As far as I remember usage of xcommgr helped me with Kwin at some point.

            Likely you can find solution for that.

            Comment

            Working...
            X