Originally posted by bash
View Post
Announcement
Collapse
No announcement yet.
R500 Mesa Is Still No Match To An Old Catalyst Driver
Collapse
X
-
-
Originally posted by Pickup View PostWe were told it was almost impossible to write good drivers with no specifications. Then, 3 years ago, AMD released the specs. Thank you, AMD.
Three years passed. More specs were released. Developers worked very hard on them. Thank you all, developers.
But the open driver still does not break the 30fps wall.
"with Gallium everything will boost to the stars!" we are told. Maybe. But Gallium has been around for a while, and... (i'm keeping my ears shut...)
Eventually the driver will be within 60-70% of fglrx' peak- but it's still a while out.
Comment
-
Originally posted by bridgman View PostFair question, but the thing to remember is that developer efforts have been divided between improving "user visible" support (using the hardware specs) and re-architecting the lower levels of the driver stack (KMS, GEM/TTM, DRI2, Gallium3D etc...), with more than half of the effort over the last 2 years going into re-architecture work.
What you had 2 years ago was basic drivers on a relatively old architecture which was limiting both performance and functionality (eg GL support was capped at 1.x). What you have today is equally basic drivers running on a significantly improved architecture. The drivers aren't much faster than they were 2 years ago (heck, they're slower in some cases), and you could argue that the code is even less mature in some ways, but the work that *has* been done over the last couple of years was a pre-requisite to the kind of functionality and performance that users want to see.
From an end-user perspective it looks like "gee, after 2-1/2 years they're finally at GL 2 and even that is still buggy", but what really happened was more like 2 years of rearchitecture work that didn't give you *any* visible benefits plus a big spurt of progress in the last 6 months built on the previous 2 years of behind-the-scenes work.
We're putting in our pain, suffering, and time right now...it'll pay off later
Comment
-
Actually
It's 2010.
Here in lies the same arguments/excuses:
1. Volunteer developers.
2. Not enough time outside day job.
3. It's only a matter of time.
I think we should quit buying into the hysterical belief that OSS versions of the drivers will ever be as good as the Paid Development Versions.
There are patented algorithms. I remember wasting a lot of time waiting for the Intel crew to get their act together. 2006-2010. For three years I waited for a marginal increase in 3D performance on my I945GM.
N/M
Comment
-
It's not "paid development" that makes the difference - there are paid developers working on the open source drivers as well.
The difference is "proprietary code sharing across 100% of the PC market where the number of paid developers is a function of the size of the entire PC market" vs "Linux-specific development where the number of paid resources is roughly tied to Linux market share".
Bottom line is that the 3D stack is larger and more complicated than the 2D/video stack, so even though the same developers have manged to give a 2D/video experience that is often *better* than what you get from the proprietary drivers that won't be so easy on the 3D side. Right now open source 3D performance averages maybe 30% of what the proprietary drivers give - it seems likely that can get to maybe 60-70% on average which you'll probably find to be fast enough.
Note that the Intel open source devs went through all the same rearchitecture efforts, and were leading the way on some of them, so they were dealing with all the same constraints I described above.
There is no proprietary Linux driver to use as a reference on the Intel side, but my understanding was that the Intel open source devs were coming pretty close to Windows performance already on the same hardware (minus any slowdowns that happened during the move to KMS, which I think are being addressed or have been already).
I guess the key point is that none of the open source devs have been doing much performance work in the last few years since any work they did would have been thrown away after moving to the new stack. Now the transition is more or less finished I think you'll see performance work happening this year.Test signature
Comment
-
Originally posted by homerhomer View PostRecently I upgrade to the latest 10.04 beta and I've noticed that the OSS radeon driver is slower than it was with 9.10 /w xorg-edgers updates. I'm just happy the suspend is working correctly. I know that glxgear is not a bench, but I went from 5500 to 2500.
BTW, suspend is broken for me in 10.04 (RV515/M26) unless I upgrade to a 2.6.34 kernel.
Comment
-
Originally posted by squirrl View PostIt's 2010.
Here in lies the same arguments/excuses:
1. Volunteer developers.
2. Not enough time outside day job.
3. It's only a matter of time.
I think we should quit buying into the hysterical belief that OSS versions of the drivers will ever be as good as the Paid Development Versions.
There are patented algorithms. I remember wasting a lot of time waiting for the Intel crew to get their act together. 2006-2010. For three years I waited for a marginal increase in 3D performance on my I945GM.
N/M
Already better IMO.
Comment
-
Originally posted by yesterday View Post2D and video is FAR superior in open drivers. They are also ALOT more stable. And they are free (libre).
Already better IMO.
Add to this the still being worked out but not ready yet power management features and the 3D performance differences, and one finds it difficult to qualify Radeon as already better than Fgrlx. In the not-so-distant future? I hope so.
Comment
-
Originally posted by tormod View PostNote that 10.04 uses KMS by default whereas 9.10 didn't, which probably accounts for the difference. Try booting 10.04 with "nomodeset" to run the old non-KMS path.
BTW, suspend is broken for me in 10.04 (RV515/M26) unless I upgrade to a 2.6.34 kernel.
Comment
-
Originally posted by yotambien View PostThe same goes for video playback, I had no problems with Fglrx or Radeon, and the same benchmarks suggest a difference in CPU usage of ~2%. "Far superior" to Fgrlx is not how I would define the state of the open driver in these areas.
Comment
Comment