Depends which chip. It's been shown pretty extensively that the 6000 series, on the open drivers, are about 80-90% as fast as the closed drivers.
Originally Posted by mmstick
Radeonsi? Well, sure, that's another story.
Im curious where you get that 20x from. Maybe radeonsi is slower.
Originally Posted by mmstick
But on a 7560D IGP (A8-5500 APU) radeon drivers are better overall right now (im talking about the latest stuff from git, both kernel and mesa, xfce 4.10, no compositing).
Games - Maybe there are some high resource eater games where fglrx is much faster, but for example Steam/Source games are faster with the oss radeon driver and they run smooth (fglrx has input lag and sometimes stutters). For these kinds of games the oss driver really works.
The older radeon versions that came with kernels up to 3.10 were indeed slow, especially on APUs, but beginning with 3.11 and the dpm code, they are pretty much the same regarding temperatures (didnt measure power consumption) and pretty much the same speed in not that demanding games (Source/TF2 etc) than fglrx.
Desktop - pretty much the same speed
Video Playback - here the OSS driver wins hands down. Why?
1. It has proper synced tear free video whereas fglrx tears everywhere, you have to force the "tear free" option to stop it (higher video memeory consumption+lower playback frame rate, sometimes choppiness, decreased opengl performance sometimes). The only video player that could deliver consistently tearfree movies was xbmc.
2. hardware decoding (native implementation, not the libva plugin that just plain sucks):
-fglrx has hardware decoding in the form of xvba. There is 2 issues with it: only 1 player (xbmc) supports it (works quite well), and only in a specific branch (fernetmenta's) + they plan on dropping support for it since the fglrx team doesnt really seem to care about their bug reports and it breaks frequenty after new drivers are released. They said they focus on the OSS implementation of hw decoding, there everything goes smooth in the development.
Dont even mention the fglrx-libva mess (used by vlc for example), that uses only a fraction of its true power and its buggy as hell (both on fglrx and nvidia).
-radeon OSS implemented recently the hw decoding via VDPAU (yes, that's exactly nvidia's open source solution) - meaning that players such as mplayer can use vdpau with it with no necessary modifications (and they indeed work). As Vlc implements VDPAU too beginning with 2.10, fglrx is left in the dust here.
Even certain sites (youtube for example) can use the radeon VDPAU hw decoding (but other sites will crash if the option is set in mms.cfg, its a half assed implementation by Adobe).
So, for casual gamers, people who watch movies the OSS driver is better (or it will be when all these goodies arrive in the stable packages).
not sure about you but if radeon were say 20 to 30 fps faster in minecraft and pcsx2 and could withstand an uptime of more than 3 days with my HD 6950 then i wouldnt be using fglrx. Just to save me the hassle of having to restart twice each time i update drivers. (although pcsx2 needs ogl4.2 to run decently so i take that back)
And yeah probably it works better in the latest version of radeon, but it's a pita to update the foss drivers if they are already in the repo. blame that on linux and its stupid design fails....
Too bad these drivers didn't come out a week ago, I already ditched the catalyst drivers with radeon. I don't play enough games on linux to really care enough about the performance drop at the moment - considering how much the open source devs have been closing the gap in features and performance every month, I'm sure my decision was fine. Being a KDE user, I'd say overall my experience has improved after ditching catalyst.
If I could get crossfire working under the OSS drivers, that ought to cover the performance I'm lacking in the games I play under linux. Still kind of stupid I have to use 2 GPUs to basically make up for the performance of 1, but, I only got the performance of 1 GPU anyways since nearly nothing under linux used crossfire.
I don't see how linux has design fails from what you just posted.
Originally Posted by ashkbajw
I only had problems like this when playing with non-stable repositories...
Originally Posted by Caledar
Yes yes yes AMD. All is well and fine and and and... But, when will the FLOSS drivers perform at least as well as the closed ones? Actually, getting really good FLOSS drivers is all I care about!
This bug/incompatiblity i had only with 3.8 kernel, sleep/restore works perfectly with 3.2 and 3.5 (did'nt tried with 3.11).
Originally Posted by ngoc1414
Last edited by leonmaxx; 10-01-2013 at 03:21 AM.