Page 1 of 2 12 LastLast
Results 1 to 10 of 16

Thread: Radeon GLAMOR vs. Radeon EXA vs. Catalyst On X.Org Server 1.17

  1. #1
    Join Date
    Jan 2007
    Posts
    16,585

    Default Radeon GLAMOR vs. Radeon EXA vs. Catalyst On X.Org Server 1.17

    Phoronix: Radeon GLAMOR vs. Radeon EXA vs. Catalyst On X.Org Server 1.17

    With Ubuntu 15.04 now shipping X.Org Server 1.17, I've run some 2D performance tests comparing the performance of this newest Ubuntu version when using the open-source Radeon graphics driver -- both with the EXA and GLAMOR acceleration methods -- compared to the new Catalyst Linux driver beta.

    http://www.phoronix.com/vr.php?view=21551

  2. #2
    Join Date
    Jan 2007
    Location
    Germany
    Posts
    2,216

    Default

    Catalyst performance is becoming really good. I have had lots of good improvements with fglrx 15.200.

    Tomorrow, there should be an official Catalyst 15.3 beta drop.

  3. #3

    Default

    I wondering, which one Qt4 graphics system would be faster: raster on EXA, native on GLAMOR on Mesa, or native on GLAMOR on fglrx?

    (Yeah, I know, it doesn't matter since KDE5 is already here.)

  4. #4
    Join Date
    Mar 2013
    Location
    Porto
    Posts
    318

    Default chrome/firefox

    how well firefox/chrome work today with amd drivers?

  5. #5
    Join Date
    Jun 2014
    Location
    EU
    Posts
    293

    Default

    Any chance of a Catalyst vs Catalyst benchmark? I'd really like to see if there's anything changing between versions, apart from the number.

  6. #6
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    2,013

    Default

    Quote Originally Posted by RussianNeuroMancer View Post
    I wondering, which one Qt4 graphics system would be faster: raster on EXA, native on GLAMOR on Mesa, or native on GLAMOR on fglrx?

    (Yeah, I know, it doesn't matter since KDE5 is already here.)
    The last I heard-- this may have changed since then-- raster was always the safer bet to use not only for performance but also for stability.

  7. #7
    Join Date
    Jul 2012
    Posts
    67

    Default

    Anyone else notice that GLAMOR seems to have performance issues with drawing round interface objects?

  8. #8
    Join Date
    Oct 2008
    Posts
    3,409

    Default

    Quote Originally Posted by RussianNeuroMancer View Post
    I wondering, which one Qt4 graphics system would be faster: raster on EXA, native on GLAMOR on Mesa, or native on GLAMOR on fglrx?

    (Yeah, I know, it doesn't matter since KDE5 is already here.)
    Probably raster, at least in benchmarking - it doesn't matter what driver you use in that case, as it doesn't use xrender or the gpu at all.

    The CPU stays busier though, since it's not offloading any of the work.

  9. #9
    Join Date
    Dec 2012
    Posts
    671

    Default

    Quote Originally Posted by rikkinho View Post
    how well firefox/chrome work today with amd drivers?
    I have an r9 290 on Mesa 10.5, Xorg 1.17, kernel 3.18.6 atm (aka Arch) and use both browsers daily. I haven't had any issues with anything except accelerated video (whch I have now almost completely disabled - I disable vdpau everywhere, and I don't use the vaapi vdpau backend) since it pretty much never works at all in my experience - at best, trying to seek the video crashes the player, in general it just freezes, desyncs, has graphical glitches, or gets stuck in a perma-buffer loop forever no matter what program is using it.

    The real problem right now is VLC, since 2.2 it basically is unusable with any acceleration method, so I've been using the KDE Dragon player happily for the last month or so. But hardware accelerated video isn't important at all to me, so having to use software h264 is no problem. But vdpau (or vdpau as a vaapi backend) for radoensi on a 290 is definitely completely broken on Arch.

  10. #10
    Join Date
    Mar 2011
    Posts
    451

    Default

    Quote Originally Posted by zanny View Post
    or vdpau as a vaapi backend
    It's just a shoot into the blue but did you try vaapi directly (without wrapping it to vdpau)? This is supported since (IIRC) Mesa 10.5:
    Code:
    $ vainfo
    libva info: VA-API version 0.35.1
    libva info: va_getDriverName() returns 0
    libva info: Trying to open /usr/lib64/va/drivers/r600_drv_video.so
    libva info: Found init function __vaDriverInit_0_35
    libva info: va_openDriver() returns 0
    vainfo: VA-API version: 0.35 (libva 1.3.1)
    vainfo: Driver version: mesa gallium vaapi
    vainfo: Supported profile and entrypoints
          VAProfileMPEG2Simple            : VAEntrypointVLD
          VAProfileMPEG2Main              : VAEntrypointVLD
          VAProfileMPEG4Simple            : VAEntrypointVLD
          VAProfileMPEG4AdvancedSimple    : VAEntrypointVLD
          VAProfileVC1Advanced            : VAEntrypointVLD
          VAProfileH264Baseline           : VAEntrypointVLD
          VAProfileH264Main               : VAEntrypointVLD
          VAProfileH264High               : VAEntrypointVLD
    In case you're missing the file (that was the case on my gentoo mashine) just symlink it:
    Code:
    $ ls -l /usr/lib64/va/drivers/r600_drv_video.so
    lrwxrwxrwx 1 root root 35 21. Feb 19:00 /usr/lib64/va/drivers/r600_drv_video.so -> /usr/lib64/dri/gallium_drv_video.so*

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •