Notice we have only 1 advert? We are supported almost entirely by Patreon and Donations!
Subscribe to GOL Premium
Valve Games On AMD Foss Drivers
Posted by , 28 February 2014 at 7:01 pm UTC / 16353 views
Hey Linux gamers, got some good news for the AMD users . It’s pretty common knowledge Nvidia users get some good drivers at the trade-off of binary blob drivers (or not, depending on your ethics) and that AMD are often left in the dust, but how can open source drivers change that?

The team behind the open source radeon drivers, the Linux kernel and the various bits that go with it are doing a great job of maintaining drivers and getting them up to spec with OpenGL and AMD's newest hardware and it's fairly obvious that radeon are making more progress than AMD. With this in mind, I ditched the catalyst proprietary driver and went for the full open source menu (information on which can be found in the linked document). For the benchmarks I used mostly Valve games since they tend to be more affected by driver type than most and have some good benchmarking tools while also being a strain on the driver. Xonotic was for scale so you can see how a blood-native game on Linux fares.

The tested games include the likes of the still in beta Portal 2 right down to older benchmark software Unigine Tropics (newer benchmarks from Unigine have an unreasonable requirement of OpenGL 4). The games fared pretty well, achieving 25 to 31.5fps for average scores for each game while running at very high settings at 1080p. Xonotic had an outlier result of 52 fps and so it's clear to see that the drivers are becoming an option for the Linux Gamer.

These aren't to the standards of the catalyst driver by a bit just yet, but from another point of view they are already better. Some non-performance advantages I've found are:
  • For rolling release distros, X updates can be kept running and not held back as with the case of binary drivers.
  • The driver is attended to by many individuals, all of which use Linux in comparison to AMD developers which are multi platform dependant.
  • Stability has been proven to be much better with the radeon driver. The videos show that the games never freeze, and the frame rates for most (Portal being the game that causes issues with its portal rendering) stayed constant.
  • Hell of a lot easier to update by people not having a luxury of PPAs/AUR to keep them going.
  • 2D performance in games is many times better, and this translates into your desktop GUI usage as well.
Of course the biggest proverbial spanner in the code is that OpenGL support is lacking (only OpenGL 3.3 for Radeon 7000s and newer), but that's set to change as more and more features are added and the kernel gets updated. With my AMD Radeon 7950 I hope to be able to make it to 4.3

One last side point to make is the benchmarks used both Portal and Portal 2 for a reason. Its been said by wild people speculating wild speculations that Portal 2 uses a proper OpenGL calling system vs a DirectX => OpenGL pipe system which basically means rendering takes less time and this is reflected in the videos in my opinion, but as Valve have remained quiet about the Portal 2 delay, its still an unconfirmed rumour.

Now for the bit you probably went through that for, the proof of concept videos (bare in mind these are actually using valuable CPU time, so performance will differ to these) :

Team Fortress 2:

Average FPS: 25

Xonotic:

Average FPS: 52

Portal:

Average FPS: 27

Portal 2:

Average FPS:32

Spreadsheet containing my benchmark results and system infomation

I’m not going to say I’ve been trying to convert people to FOSS, because I don’t believe people should just drop to FOSS, so instead hopefully you can see these videos and benefits and make your own decision as to whether you should give it a go.

This article was submitted by a guest, we encourage anyone to submit their own articles.

Comments on this article are now closed.
asdf commented on 28 February 2014 at 7:28 pm UTC

Do you own Natural Selection 2 and get it running with the foss driver?

Do you own Natural Selection 2 and get it running with the foss driver?

Half-Shot commented on 28 February 2014 at 7:58 pm UTC

asdfDo you own Natural Selection 2 and get it running with the foss driver?
Working, yes.
Playable, ish. I got 13fps at the highest settings. Should be ok under a lower setting.

[quote=asdf]Do you own Natural Selection 2 and get it running with the foss driver?[/quote] Working, yes. Playable, ish. I got 13fps at the highest settings. Should be ok under a lower setting.

kwahoo commented on 28 February 2014 at 8:16 pm UTC

Quote(newer benchmarks from Unigine have an unreasonable requirement of OpenGL 4).


No, minimal GL level for Heaven 4.0 and Valley 1.0 is 3.2. All Unigine benchmark works on open source drivers now.

Next, your result are completely horrible. Especially in Valve games. I'm confused, since kernel 3.14 is necessary only for DPM in GCN2.0 cards, and 7950 should work great with 3.13 (afaik). But...

Your Mesa is too old. If I can suggest something - upgrade mesa to 10.2-devel (git) and benchmark your GPU then.

And radeonsi (>HD 7000) needs the latest packages for good results and comability. Mesa git, LLVM 3.5 etc.

[quote](newer benchmarks from Unigine have an unreasonable requirement of OpenGL 4).[/quote] No, minimal GL level for Heaven 4.0 and Valley 1.0 is 3.2. All Unigine benchmark works on open source drivers now. Next, your result are completely horrible. Especially in Valve games. I'm confused, since kernel 3.14 is necessary only for DPM in GCN2.0 cards, and 7950 should work great with 3.13 (afaik). But... Your [b]Mesa is too old.[/b] If I can suggest something - upgrade mesa to 10.2-devel (git) and benchmark your GPU then. And radeonsi (>HD 7000) needs [b]the latest[/b] packages for good results and comability. Mesa git, LLVM 3.5 etc.

Riotta commented on 28 February 2014 at 8:16 pm UTC

Great article, I think also you should use GALLIUM_HUD=fps %command% in steam app startup options, when testing a game, that will show more readable fps counter for people watching your videos.

Great article, I think also you should use GALLIUM_HUD=fps %command% in steam app startup options, when testing a game, that will show more readable fps counter for people watching your videos.

Half-Shot commented on 28 February 2014 at 8:35 pm UTC

kwahoo
Quote(newer benchmarks from Unigine have an unreasonable requirement of OpenGL 4).

No, minimal GL level for Heaven 4.0 and Valley 1.0 is 3.2. All Unigine benchmark works on open source drivers now.

Not under standard packages offered by Arch Linux. Both Unigine benchmarks REFUSED to run.
kwahoo
Next, your result are completely horrible. Especially in Valve games. I'm confused, since kernel 3.14 is necessary only for DPM in GCN2.0 cards, and 7950 should work great with 3.13 (afaik). But...

Your Mesa is too old. If I can suggest something - upgrade mesa to 10.2-devel (git) and benchmark your GPU then.


And radeonsi (>HD 7000) needs the latest packages for good results and comability. Mesa git, LLVM 3.5 etc.


Results are results, they differ. These are what I achieved with a standard system packages and Gnome 3.10 using the system outlined in the spreadsheet. My mesa is again what the system offers me. They are the stable drivers that most distros do not even support. I'm not going to benchmark using git packages, because then I would get complaints that they couldn't get such high FPS. And anyway, the results were fine considering the games were running maximum settings and were playable.

I do have the ability to use mesa 10.2 and the rest of the updates, but I don't plan to document them on this article.

[quote=kwahoo][quote](newer benchmarks from Unigine have an unreasonable requirement of OpenGL 4). [/quote] No, minimal GL level for Heaven 4.0 and Valley 1.0 is 3.2. All Unigine benchmark works on open source drivers now. [/quote] Not under standard packages offered by Arch Linux. Both Unigine benchmarks REFUSED to run. [quote=kwahoo] Next, your result are completely horrible. Especially in Valve games. I'm confused, since kernel 3.14 is necessary only for DPM in GCN2.0 cards, and 7950 should work great with 3.13 (afaik). But... Your [b]Mesa is too old.[/b] If I can suggest something - upgrade mesa to 10.2-devel (git) and benchmark your GPU then. And radeonsi (>HD 7000) needs [b]the latest[/b] packages for good results and comability. Mesa git, LLVM 3.5 etc. [/quote] Results are results, they differ. These are what I achieved with a standard system packages and Gnome 3.10 using the system outlined in the spreadsheet. My mesa is again what the system offers me. They are the stable drivers that most distros do not even support. I'm not going to benchmark using git packages, because then I would get complaints that they couldn't get such high FPS. And anyway, the results were fine considering the games were running maximum settings and were playable. I do have the ability to use mesa 10.2 and the rest of the updates, but I don't plan to document them on this article.

Half-Shot commented on 28 February 2014 at 8:37 pm UTC

RiottaGreat article, I think also you should use GALLIUM_HUD=fps %command% in steam app startup options, when testing a game, that will show more readable fps counter for people watching your videos.

Noted, I did enable the FPS overlay for source games but it didn't do a great job. Thanks for the feedback though.

[quote=Riotta]Great article, I think also you should use GALLIUM_HUD=fps %command% in steam app startup options, when testing a game, that will show more readable fps counter for people watching your videos.[/quote] Noted, I did enable the FPS overlay for source games but it didn't do a great job. Thanks for the feedback though.

Anonymous commented on 28 February 2014 at 8:53 pm UTC

Half-Shot
kwahoo
No, minimal GL level for Heaven 4.0 and Valley 1.0 is 3.2. All Unigine benchmark works on open source drivers now.
Not under standard packages offered by Arch Linux. Both Unigine benchmarks REFUSED to run.

Unigines on radeonsi work for months (with hack when GL 3.1 had been available, without since GL3.2) http://www.reddit.com/r/linux_gaming/comments/1sbz85/amd_drivers_are_getting_better/cdw8h0e

[quote=Half-Shot][quote=kwahoo] No, minimal GL level for Heaven 4.0 and Valley 1.0 is 3.2. All Unigine benchmark works on open source drivers now. [/quote] Not under standard packages offered by Arch Linux. Both Unigine benchmarks REFUSED to run. [/quote] Unigines on radeonsi work for months (with hack when GL 3.1 had been available, without since GL3.2) http://www.reddit.com/r/linux_gaming/comments/1sbz85/amd_drivers_are_getting_better/cdw8h0e

Anonymous commented on 28 February 2014 at 8:58 pm UTC

Half-Shot
asdfDo you own Natural Selection 2 and get it running with the foss driver?
Working, yes.
Playable, ish. I got 13fps at the highest settings. Should be ok under a lower setting.

Thats nice. I tried to get this game running with different mesa drivers with my AMD Radeon HD 6850 graphic card. Cant figure it out, where the problem is. Other games line Portal 2 are running fine.

I get this error message at startup.

Quote
Installing breakpad exception handler for appid(steam)/version(1393366296_client)
libGL error: MESA-LOADER: could not create udev device for fd 114
unknown chip id 0x6739, can't guess.
libGL error: failed to create dri screen
libGL error: failed to load driver: radeon
CGameStreamThread: Added instance ID 1668 for appid 4920
OnFocusWindowChanged to window type: k_EWindowTypeNonSteamDesktop, 0
GetInstanceCount currently unimplemented
Build 263
Linux
Steam initialized
Num displays: 2
Error: X windows: GLXBadFBConfig
Error: glXCreateContextAttribsARB failed
Error: X windows: GLXBadFBConfig
Error: X windows: GLXBadFBConfig
Error: X windows: GLXBadFBConfig
Error: X windows: GLXBadFBConfig
Error: X windows: GLXBadFBConfig
Error: OpenGL version 3.1 is required
Error: Couldn't initialize the render device.
Game removed: AppID 4920 "Natural Selection 2", ProcID 1637
My glxinfo32 output:

Quote
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
[...]
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD BARTS
OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.1.0-rc2 (git-bef5554)
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
[...]
OpenGL version string: 3.0 Mesa 10.1.0-rc2 (git-bef5554)
OpenGL shading language version string: 1.30

I think the problem is, that the OpenGL version is still version 3.0 :-/ However.. the OpenGL Core profile version is 3.3.

Maybe you or someone else have an idea or a hint, what exactly the problem is.
I am using Arch Linux with the 3.14.0-1-mainline kernel.

[quote=Half-Shot][quote=asdf]Do you own Natural Selection 2 and get it running with the foss driver? [/quote]Working, yes. Playable, ish. I got 13fps at the highest settings. Should be ok under a lower setting.[/quote] Thats nice. I tried to get this game running with different mesa drivers with my AMD Radeon HD 6850 graphic card. Cant figure it out, where the problem is. Other games line Portal 2 are running fine. I get this error message at startup. [quote] Installing breakpad exception handler for appid(steam)/version(1393366296_client) libGL error: MESA-LOADER: could not create udev device for fd 114 unknown chip id 0x6739, can't guess. libGL error: failed to create dri screen libGL error: failed to load driver: radeon CGameStreamThread: Added instance ID 1668 for appid 4920 OnFocusWindowChanged to window type: k_EWindowTypeNonSteamDesktop, 0 GetInstanceCount currently unimplemented Build 263 Linux Steam initialized Num displays: 2 Error: X windows: GLXBadFBConfig Error: glXCreateContextAttribsARB failed Error: X windows: GLXBadFBConfig Error: X windows: GLXBadFBConfig Error: X windows: GLXBadFBConfig Error: X windows: GLXBadFBConfig Error: X windows: GLXBadFBConfig Error: OpenGL version 3.1 is required Error: Couldn't initialize the render device. Game removed: AppID 4920 "Natural Selection 2", ProcID 1637 [/quote] My glxinfo32 output: [quote] client glx vendor string: Mesa Project and SGI client glx version string: 1.4 [...] OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD BARTS OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.1.0-rc2 (git-bef5554) OpenGL core profile shading language version string: 3.30 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile [...] OpenGL version string: 3.0 Mesa 10.1.0-rc2 (git-bef5554) OpenGL shading language version string: 1.30 [/quote] I think the problem is, that the OpenGL version is still version 3.0 :-/ However.. the OpenGL Core profile version is 3.3. Maybe you or someone else have an idea or a hint, what exactly the problem is. I am using Arch Linux with the 3.14.0-1-mainline kernel.

Anonymous commented on 28 February 2014 at 9:10 pm UTC

The open source drivers work well with valve games such as CS:source and l4d2

They cannot seem to handle dota2 well though, radeonsi latest git,kernel,xorg,mesa,atidri and it's clay animation unless turned down to the lowest settings.

however it really handles l4d2 well with the exception of some odd artifacting (coaches head has void where his hair should be) but much smoother than catalyst at roughly 1/10 to 1/4 the frames but feels faster (considering catalyst cranks out 300 fps and stutters, 1/10 to 1/4 is VERY playable as it's ~30-~80 fps. max eye candy @ full HD)

the power management is sorta there, but it still likes to get it up to high profile and bake your card but it seems semi-working.

It really pains me that usually the strong suit of the OSS driver is the weakness of the blob and vice versa.

The open source drivers work well with valve games such as CS:source and l4d2 They cannot seem to handle dota2 well though, radeonsi latest git,kernel,xorg,mesa,atidri and it's clay animation unless turned down to the lowest settings. however it really handles l4d2 well with the exception of some odd artifacting (coaches head has void where his hair should be) but much smoother than catalyst at roughly 1/10 to 1/4 the frames but feels faster (considering catalyst cranks out 300 fps and stutters, 1/10 to 1/4 is VERY playable as it's ~30-~80 fps. max eye candy @ full HD) the power management is sorta there, but it still likes to get it up to high profile and bake your card but it seems semi-working. It really pains me that usually the strong suit of the OSS driver is the weakness of the blob and vice versa.

Half-Shot commented on 28 February 2014 at 9:14 pm UTC

AnonymousThe open source drivers work well with valve games such as CS:source and l4d2

They cannot seem to handle dota2 well though, radeonsi latest git,kernel,xorg,mesa,atidri and it's clay animation unless turned down to the lowest settings.

however it really handles l4d2 well with the exception of some odd artifacting (coaches head has void where his hair should be) but much smoother than catalyst at roughly 1/10 to 1/4 the frames but feels faster (considering catalyst cranks out 300 fps and stutters, 1/10 to 1/4 is VERY playable as it's ~30-~80 fps. max eye candy @ full HD)

the power management is sorta there, but it still likes to get it up to high profile and bake your card but it seems semi-working.

It really pains me that usually the strong suit of the OSS driver is the weakness of the blob and vice versa.

Yeah, it's how it is now but the future looks good. AMD are actually helping out with the FOSS driver much more than Nvidia so hopefully if all goes well you will no longer to choose between them.

[quote=Anonymous]The open source drivers work well with valve games such as CS:source and l4d2 They cannot seem to handle dota2 well though, radeonsi latest git,kernel,xorg,mesa,atidri and it's clay animation unless turned down to the lowest settings. however it really handles l4d2 well with the exception of some odd artifacting (coaches head has void where his hair should be) but much smoother than catalyst at roughly 1/10 to 1/4 the frames but feels faster (considering catalyst cranks out 300 fps and stutters, 1/10 to 1/4 is VERY playable as it's ~30-~80 fps. max eye candy @ full HD) the power management is sorta there, but it still likes to get it up to high profile and bake your card but it seems semi-working. It really pains me that usually the strong suit of the OSS driver is the weakness of the blob and vice versa.[/quote] Yeah, it's how it is now but the future looks good. AMD are actually helping out with the FOSS driver much more than Nvidia so hopefully if all goes well you will no longer to choose between them.

  Go to:
Release Calendar
Popular this week
View by Category
Contact
Twitter
Latest Forum Posts
Facebook
Who's Online
There are 181 in total online.
Users online: Coloneil, crt0mega, oldrocker99, toor,
Misc