The AMD Radeon Performance Is Incredible On Linux 3.12

[Calinou]

Michael, thank you for your continuous tests, but can you include other more tangible games in your analysis?

I guess many people will be really annoyed by my proposal, but I'd really like to see some present and past heavy-weights like:

3DMark 2006 (running in Wine, of course)
StarCraft II (ditto)
Fallout 3 (ditto)
Counter Strike Global Offensive (native)

The games you're currently testing are inconclusive in regard to modern GPU requirements.

Xonotic in Ultra detail is quite relevant. I'd like to see a Wine game maybe, but I'd like to see Red Eclipse, Tesseract and/or Stunt Rally too.

[ChrisXY]

You are using a Southern Islands card on a notebook with switchable graphics. Catalyst is really the only option.

Even just for disabling with vgaswitcheroo. First it didn't work, then it worked for a while, no it doesn't work again.... From my perspective what the open source radeon team really needs is more hardware to have the ability to actually test what they do...

Edit: How do you "start X a little while after boot"? That sounds like a useful workaround to know.

Boot with systemd.unit=rescue.target, then after a few seconds systemctl isolate graphical.target. Or just disable the display manager and start it manually.

[ChrisXY]

is this it? https://bugs.freedesktop.org/show_bug.cgi?id=70391 if so, add yourself to the bug report, please

There is already

https://bugzilla.kernel.org/show_bug.cgi?id=51381

[przemoli]

Even just for disabling with vgaswitcheroo. First it didn't work, then it worked for a while, no it doesn't work again.... From my perspective what the open source radeon team really needs is more hardware to have the ability to actually test what they do...


Boot with systemd.unit=rescue.target, then after a few seconds systemctl isolate graphical.target. Or just disable the display manager and start it manually.

If longer boot up time is acceptable for You, adding sleep to first graphical task should do the trick too.

[asdfblah]

There is already
https://bugzilla.kernel.org/show_bug.cgi?id=51381

I dunno if the "atombios stuck" problem relates to vgaswitcheroo, I'll have to test. Thanks.

EDIT: I got confused and posted a different bug... there are different bugs there, I think: resume from suspend doesn't work: https://bugs.freedesktop.org/show_bug.cgi?id=43829 and "atombios stuck in loop for more than 5secs aborting"

[tarceri]

Somehow this made be just buy the phoronix premium. Having used adblock for years its only fair i think.

Yep, I signed up too. The fact Michael is willing to put the effort into bisecting the performance improvement was the tipping point in making me finally subscribe.

[Ishayu]

Michael, thank you for your continuous tests, but can you include other more tangible games in your analysis?

I guess many people will be really annoyed by my proposal, but I'd really like to see some present and past heavy-weights like:

3DMark 2006 (running in Wine, of course)
StarCraft II (ditto)
Fallout 3 (ditto)
Counter Strike Global Offensive (native)

The games you're currently testing are inconclusive in regard to modern GPU requirements.

Shouldn't use Wine to benchmark. The D3D->OpenGL draw translations are very CPU-intensive, so frankly the results would be flawed at best.

I agree on including games like CS:GO, OilRush and the like, though.

[Luke]

I haven't tried fglrx in nearly a year and a half

let's say the cpu governor is a factor for r600... what about fglrx? how does one compares to the other? what if you run BOTH with the "performance" setting?

I haven't tried fglrx since Spring 2012. I never tried changing CPU governors with it, but can compare performance in Critter (too light to be really valid) and Scorched3d. Scorched3d slows down with the sb backend for r600, needs the default gallium backend for best results, yielding a best framerate on light maps in the mid 80s or so. Best ever with Scorched3d on fglrx with the same processor and HD6750 was 106fps. Critter is odd: About 40% higher framerate with fglrx (and CPU governor by default on "onedemand") with Radeon 6750, but with a Radeon 5570 on a Phenom II x4, Critter hits 730 fps with r600g (instead of 630 on the HD6750), never tested it with fglrx but I suspect it would run no faster as it never got much past 1,000 fps (not all on screen of course!) on the bigger card with fglrx. Critter is written in Opengl but is a 2d early 1980's style game. Oddly it loads my cards hotter than any other game I have to make those high benchmarks, sort of a glxgears ultra in a sense. Also maximum impact from the CPU governor as it is not CPU limited at all and does not hold the CPU on maximum frequency just by running,

None of that is nearly enough difference to run a driver that does not support KMS, adds 100mb to the filesystem , makes images of the filesystem not portable to non-AMD machines, has buggy versions, terrible XV performance requiring the HD6750 for xv video playback in kdenlive once the gnome-shell bugs were fixed, and requires at my security level that encrypted drives not be mounted while it and X are running. That last consideration is just a precaution for closed code that can't be audited. Also it would suck not to take advantage of the incredible work done in Mesa in the last year, not to mention AMD's releasing so much code that used to only be availalbe with fglrx like automatic power management.

I think fglrx is on the way out. RadeonSI is catching up fast, AMD is feeding the Mesa team a lot of good stuff, it appears that support for new cards will be on-time in the future, OpenCL in mesa should be ready by the time many applications can use it-and all that "reverse Optimus" and similar work could ultimately yield not only Crossfire but SLI support as well down the road. At that point, I don't see what AMD would get from a hard-to-mantain driver with individual optimizations for every card never giving more than 20% more performance with the same feature set or even less if it never supports VDPAU. I see AMD dropping fglrx and keeping Catalyst only for Windows and Windows DRM in the future. They don't have CUDA to protect, after all. Hell, when CUDA goes obsolete, even Nvidia might end up following suit.

[Michael]

Bisecting complete plus some additional tests to confirm findings; article being posted within few hours.

[Ericg]

Bisecting complete plus some additional tests to confirm findings; article being posted within few hours.

Looking forward to it, thanks Michael