Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
Yay for open source drivers
Posted Jul 24, 2012 3:06 UTC (Tue) by scientes (guest, #83068)
Posted Jul 24, 2012 8:00 UTC (Tue) by drag (subscriber, #31333)
fglrx needs to burn at the stake.
Posted Jul 24, 2012 9:29 UTC (Tue) by moltonel (guest, #45207)
It would be great if changing between the two drivers didn't involve as much config file changes and a reboot (module unload doesn't seem to be enough). That way I'd use the free drivers most of the time, and only switch to catalyst when the need to swing a beautifully-rendered magical axe arises.
Posted Jul 24, 2012 9:43 UTC (Tue) by gidoca (subscriber, #62438)
Posted Jul 24, 2012 9:53 UTC (Tue) by drag (subscriber, #31333)
Posted Jul 25, 2012 15:52 UTC (Wed) by Cato (subscriber, #7643)
http://www.anandtech.com/show/4199/lucids-virtu-enables-s... - one example, I think MacOS X does something similar.
Posted Jul 24, 2012 9:55 UTC (Tue) by drag (subscriber, #31333)
If I need to run fglrx to run games then I am not running those games.
Destroying my Linux desktop for the sake of a video game is a no-go. I need my system for more serious things.
Posted Jul 24, 2012 14:59 UTC (Tue) by nye (guest, #51576)
If you don't need a powerful GPU, it makes much more sense to stick with some properly-supported Intel GPU than to pay extra for a load of silicon which you then proceed not to use - especially since buying it sends a (financial) signal that the status quo is just fine.
(I'm guessing that in many cases the answer is dual-booting)
Posted Jul 24, 2012 15:28 UTC (Tue) by drag (subscriber, #31333)
The answer is to use open source drivers. I have found that depending on what I am doing I can actually get better or on par performance with anything from catalyst drivers.
Posted Jul 24, 2012 16:06 UTC (Tue) by nye (guest, #51576)
Ah, so you're saying that the cited speed reduction is actually only applicable to certain operations which you happen not to need, and in other cases you're able to use the device to its potential?
(I don't have any first-hand experience of these drivers; I'm just working on the basis that I keep reading complaints about the speed of the OSS drivers)
Posted Jul 24, 2012 16:58 UTC (Tue) by drag (subscriber, #31333)
Fglrx have optimized code paths for specific usage patterns from specific gaming engines. If you are looking at benchmarks were you are dealing with older popular proprietary gaming engines then the catalyst drivers will have very significant performance advantages over the open source drivers. It would not be unusual to see performance advantages as more then 3:1.
On engines that fglrx was not optimized for then you won't see anything like that. They will generally still be faster, but there are times when OSS driver will beat the newer one.
In general day-to-day usage the open source drivers are superior on all counts. Gnome-shell works fine. Crashes are rear. Compatibility with games and applications are superior.
> (I don't have any first-hand experience of these drivers; I'm just working on the basis that I keep reading complaints about the speed of the OSS drivers)
I really don't understand it, but I guess unless people are running something that looks good in benchmarks then they not as much of a man or something like that. Then there is a intense sense of unjustified self entitlement.
There is a very loud contingent of users that have the belief that they bitch hard enough and loud enough about AMD and abuse AMD employees every time they say something on the internet then AMD will break down and be forced to make perfect drivers for them. They see that Nvidia has fast drivers that are fairly stable and don't understand why AMD can't be the same way.
Posted Jul 24, 2012 17:30 UTC (Tue) by Cyberax (✭ supporter ✭, #52523)
Phoronix regularly compares fglrx against the open source drivers. Fglrx almost always wins on rather generic benchmarks.
Posted Jul 24, 2012 17:52 UTC (Tue) by drag (subscriber, #31333)
Not only did fglrx crash more often, was a pain in the ass to install, it broke my desktop, and performance of starcraft in wine was miserable. Graphic glitches and poor performance. OSS worked much better.
IMHO; if you are planning on running proprietary drivers to get good performance you are a moron if you buy AMD.
I run AMD because I want open source drivers and something that is faster then Intel.
Posted Jul 24, 2012 19:53 UTC (Tue) by Cyberax (✭ supporter ✭, #52523)
Yet they persist because OpenSource drivers are not yet up to speed with the proprietary ones. It's not uncommon to have 2-10 times speed difference between them.
Posted Jul 24, 2012 20:08 UTC (Tue) by drag (subscriber, #31333)
If it was up to me AMD would drop catalyst altogether and pool their effort into the OSS drivers.
But I understand that isn't going to happen because they need to maintain competitive performance with Nvidia for the people that use it on professional graphical workstations. It simply will take too long for OSS drivers to catch up.
Posted Jul 27, 2012 13:41 UTC (Fri) by Wol (guest, #4433)
I would have thought there would be a decent number of developers - either true open source guys, or games company guys like here, who would be prepared to sign the NDA and then (because the AMD code wouldn't be covered by the NDA) leak code or design into the Open Source drivers.
And just in case anyone misunderstands me, what I'm suggesting is perfectly legit - developers can get hold of the driver source under NDA (to protect AMD's suppliers) but can't release THAT source on. They're free to release on any AMD code, or read the drivers to find out what they actually do (and then re-implement it as free code).
Posted Jul 24, 2012 18:41 UTC (Tue) by rahvin (subscriber, #16953)
You are also dealing with the situation that because of contractual relationships AMD and Intel have failed to divulge information about the hardware (the Digital rights management code paths, etc).
It going to take time for Linux drivers to catch up and optimize for code paths that have dominated on other platforms. I personally don't understand why everyone expects Linux to catch up to Windows 15 year head start in a year or two (I totally agree that blaming AMD is just wrong). Even if driver development is going twice as fast its going to take half a decade to catch up (and that's if Windows is standing still, which it's not).
Until there is a real drive by manufacturers and game developers to target Linux this is race that Linux will have a hard time winning. That's why what Valve is doing is so interesting. If they successfully bring a Steam console to market running Linux the community will have its first major commercial effort (where hardware and software companies are interested in full optimizations) to improve gaming on Linux. Not only that but such a console could drive Linux adoption.
Posted Jul 24, 2012 21:13 UTC (Tue) by raven667 (subscriber, #5198)
Posted Jul 24, 2012 22:41 UTC (Tue) by Cyberax (✭ supporter ✭, #52523)
With open source drivers it's even worse. For example, DRM2 and KMS were introduced after Windows Vista came out with its new driver model and DirectX10. Mesa has achieved OpenGL3 compliance only earlier this year.
Posted Jul 24, 2012 22:26 UTC (Tue) by dlang (✭ supporter ✭, #313)
because you can't buy a not-powerful discrete graphics hardware options?
The only on-board option that has full open support is a subset of what Intel offers, and unless you are going to buy an Intel motherboard and CPU, you can't use it.
Posted Jul 25, 2012 7:54 UTC (Wed) by jezuch (subscriber, #52988)
I'm not sure that's true. I have a Radeon card (HD 5450, I think) which I bought specifically because it has passive cooling - and was cheap. I wouldn't call anything with passive cooling "powerful", although it's definitely much more powerful than the crappy IGP I have on my (several years old) motherboard. I still have to objectively determine its performance though, and that's why I'm not sure :)
Posted Jul 25, 2012 18:52 UTC (Wed) by dlang (✭ supporter ✭, #313)
(end of sarcasam)
Posted Jul 26, 2012 13:20 UTC (Thu) by nye (guest, #51576)
Posted Jul 27, 2012 7:59 UTC (Fri) by jezuch (subscriber, #52988)
Well, some people forget that the graphics card manufacturers have an entire lineup of cards, from the very-low-end to extreme-enthusiast-high-end. This particular chip is (I think?) marketed as an HTPC thing that is good for decoding video but not much else. It works well enough for its stated purpose on my Debian system with free drivers, and I'm never going back to fglrx.
Posted Jul 27, 2012 8:02 UTC (Fri) by dlang (✭ supporter ✭, #313)
In some people's view (and I believe in the view of the poster a few levels up who asked the question), anyone buying a separate card for their machine is by definition buying a 'performance' option
Posted Jul 27, 2012 12:27 UTC (Fri) by jezuch (subscriber, #52988)
Actually I didn't as it was very explicit ;)
Posted Jul 25, 2012 10:01 UTC (Wed) by etienne (subscriber, #25256)
I also do not use any graphic animations/mathematically described screen, so totally agree.
What I really need, instead of a graphic card where its processors could be used for other non graphic tasks, is some kind of (free and open) programmable logic with a well designed interface to memory, I/O, PCIe, memory caches...
Programmable logic is these days quite a few order of magnitude quicker than processors, and a kind of well though standard would enable "state machines" sub-systems with their own DMAs to talk to video, main memory bypassing cache, SATA disks, PCIe, USB, so that the processor is not slowed down by boring tasks like waiting for hardware to be ready, or transferring/comparing massive amount of data in between subsystems.
For instance, I would use such a system to implement RAID on top of IDE (no even need of AHCI) so that the disk data is not sent twice by the processor to two different devices, and the disk data is compared by the state machine (after both reads have finished) to indicate a RAID corruption without wasting CPU time.
Also, small modifications of interfaces (thinking now of USB/ethernet) would be handled by changing the USB/ethernet state machine, but kernel interfaces would be so simple the software would not need to change.
Posted Jul 24, 2012 12:42 UTC (Tue) by ballombe (subscriber, #9523)
Posted Jul 24, 2012 15:57 UTC (Tue) by moltonel (guest, #45207)
So if fglrx drops support for my card tomorrow, I won't be able to play that game (and many others) anymore (or rather, I'll boot into an old kernel/distro, which is still better than booting into Windows). Cool that I got to play for a while, I guess ? What I'm actually hoping is that the free drivers will have caught up by then, but in the meantime I dont fancy restricting myself to low-spec games only.
Posted Jul 24, 2012 12:33 UTC (Tue) by bjacob (subscriber, #58566)
That being, said, to stop the FGLRX-bashing below: the most recent versions of the FGLRX drivers (since a few months) on very recent Linux kernels work very well (pass almost all WebGL conformance tests, no crashes anymore).
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds