Page 11 of 11 FirstFirst ... 91011
Results 101 to 109 of 109

Thread: Here's Why Radeon Graphics Are Faster On Linux 3.12

  1. #101
    Join Date
    Sep 2008
    Location
    Vilnius, Lithuania
    Posts
    2,666

    Default

    Quote Originally Posted by Ericg View Post
    On any OTHER distro (not *Buntu based) Yuuuuuuup. But Canonical hasn't gotten their heads out of their asses yet and switched yet. Someone said that it was because of bugs in the driver but im finding it hard to believe that THEY are hitting bugs that no one else has.
    There was a bug in kernel 3.10 where the intel_pstate driver used the turbo frequency as the base performance frequency, and that used to heat things up more than it should have. But that issue was solved in 3.11, but Ubuntu hasn't enabled it back just yet.

  2. #102
    Join Date
    Dec 2008
    Location
    San Bernardino, CA
    Posts
    234

    Default

    Quote Originally Posted by Michael View Post
    Then it should be fixed or the default setting changed within the kernel.
    Agreed! Everyone I know uses the default "ondemand" governor. While I'd like to use the 'performance' governor, the power consumption prevents me from doing so. Almost every user is going to be using 'ondemand'. A good user experience demands that things just work with the default settings. If thats not the case, then someone needs to change the defaults!

  3. #103
    Join Date
    Jan 2010
    Location
    Somewhere in Kansas.
    Posts
    294

    Default

    Quote Originally Posted by GreatEmerald View Post
    And will make your FPS dip to 30 if 60 can't be sustained, instead of just 59... No, you should have VSync on only for games you know will never dip below 60 (or whatever your refresh rate may be).
    Umm. No. It would probably be 58 fps not 30. I know cause I had NS2 and with vsync on the fps ranged from 45 - 60 fps. Vsync just means that it wont display partially rendered frames, it will finish rendering the current frame, display it, and then render the most current frame, display it, etc, etc.

  4. #104
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,939

    Default

    Quote Originally Posted by GreatEmerald View Post
    There was a bug in kernel 3.10 where the intel_pstate driver used the turbo frequency as the base performance frequency, and that used to heat things up more than it should have. But that issue was solved in 3.11, but Ubuntu hasn't enabled it back just yet.
    Interesting that they hit such a bug, I didn't hit that bug on Arch. Wonder if it got pulled in when they were making their 'changes' to the kernel.

  5. #105
    Join Date
    Jan 2009
    Posts
    630

    Default

    Quote Originally Posted by gururise View Post
    Agreed! Everyone I know uses the default "ondemand" governor. While I'd like to use the 'performance' governor, the power consumption prevents me from doing so. Almost every user is going to be using 'ondemand'. A good user experience demands that things just work with the default settings. If thats not the case, then someone needs to change the defaults!
    It's not a default setting in the kernel. It's a setting forced by a startup script in Ubuntu and you can't turn it off (unless you delete the script manually). So this is obviously Canonical's fault. Too bad we didn't get benchmarks with multiple distributions, we'd at least see how bad Canonical is. Generally, "ondemand" is okay for most people, giving you approx. 75-80% performance out of your CPU. You'll never get 100% unless you use up all CPU cores (very unlikely for most people, even gamers). However, there are applications where ondemand is absolutely unacceptable. Those are gaming, benchmarking, and running computationally-intensive applications where the running time matters (compiling too).

  6. #106
    Join Date
    Sep 2008
    Location
    Vilnius, Lithuania
    Posts
    2,666

    Default

    Quote Originally Posted by marek View Post
    It's not a default setting in the kernel. It's a setting forced by a startup script in Ubuntu and you can't turn it off (unless you delete the script manually).
    It isn't? I know acpi_cpufreq is set to ondemand in the kernel in openSUSE. But I'm not sure what it is when you do a make defconfig (don't have kernel sources on this PC). Though the fallback in case ondemand isn't built is performance.

  7. #107
    Join Date
    Sep 2012
    Posts
    369

    Default

    Default governor is performance.
    Code:
    choice
            prompt "Default CPUFreq governor"
            default CPU_FREQ_DEFAULT_GOV_USERSPACE if ARM_SA1100_CPUFREQ || ARM_SA1110_CPUFREQ
            default CPU_FREQ_DEFAULT_GOV_PERFORMANCE
            help
              This option sets which CPUFreq governor shall be loaded at
              startup. If in doubt, select 'performance'.
    Last edited by JS987; 10-16-2013 at 02:56 PM.

  8. #108
    Join Date
    May 2013
    Posts
    639

    Default What my experiments show

    Quote Originally Posted by s_j_newbury View Post
    Luke, while technically a graphically very simple GPU accelerated game might be well be non-CPU limited at the extreme, I'm not sure what you're trying to measure. It could well be you're hitting the GPU fillrate limit, exceeding the internal bandwidth of the card and at such high frame-rates I can't see how it's meaningful.
    Is that the linux3.12 kernel only partially reduced the effect of the governor setting on AMD Bulldozer and fixed the problem (at least in this one case) on Phenom II. I have no other games that do not peg the CPU to continuous full speed, taking the governor out of the picture. If anything about the card were the issue, I would expect the CPU governor to be out of the picture. Strangely, the smaller HD5570 on Phenom II at 3.7 GHZ gets more fps by about 1/7 than the bigger HD6750 on Bulldozer at 4.4GHZ.

    Until rather recently, Critter had issues with running rough on Mesa drivers, dropping frames and visibly stuttering unless the framerate never went under about 300fps. This was because frames would be dropped in strings, and a high framerate kept down the time covered by an entire string of missing or duplicate frames. Both Radeon and Nouveau drivers were affected, I'm pretty sure Intel was too, though it's been awhile since I've tried to ply Critter on the netbook. Nouveau, due to the lack of ability to reclock the GPU, had trouble getting a GTX450 over about 250fps at 1080p, at which point the stuttering was very noticable. A few months ago, another Nouveau test found the roughness in Critter greatly reduced, and the highest framerates in Scorched3d up around 30fps from around 18. About all I use Nvidia stuff for these days is to see how Nouveau is doing from time to time.

    I thought and still think it is NUTS that a game whose progenitors ran on video arcade machines of 30 years ago would have issues running on ANY driver on ANY graphics card produced since whatever version of OpenGL it was written in came out, but it does or at least did due to the dropped frame roughness issue. I would have expected CPU and GPU to sit at stone cold idle playing a Galaxians style game, but due to how it was written this is far from the case. In fact, nothing else I have (game or otherwise) will generate more heat in my graphics cards, as Scorched3d and 0ad are both so CPU limited that the graphics card is of reduced importance it seeems. Due to that, I use both Critter and Scorched3d to benchmark graphics drivers in my machines with games I actualy play. Critter is more repeatable and works the smaller HD5570 as hot as it does an Nivdia GT520 on its blob, Scorched3d is much more graphically demanding but dislikes the sb backend that seems to help a bit in 0ad. 0ad is so CPU bound that even 3 or 4-way SLI on Nvidia's blob would probably show little or no benefit, while finding a way to run the AI in one instance of the game connected to the player game running as a multi-player game would possibly double framerates when a few hundred characters are on the board-and do so even on the ATI HD5570.

    Sorry this is not using a test suite written for games I do not have and cannot easily download due to bandwidth issues, but I just try to add what information I do get to the total body of information that is out there. I'm using some less common hardware, so I figure the results might help somebody,

  9. #109
    Join Date
    Sep 2008
    Location
    Vilnius, Lithuania
    Posts
    2,666

    Default

    Quote Originally Posted by Luke View Post
    Sorry this is not using a test suite written for games I do not have and cannot easily download due to bandwidth issues, but I just try to add what information I do get to the total body of information that is out there. I'm using some less common hardware, so I figure the results might help somebody,
    Well, it's good to have it confirmed that there's also a difference on AMD CPUs.

Posting Permissions

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