Where The Open-Source AMD Driver Is At For Modern GPUs

[MisterIO]

Yes it is. As Jérôme Glisse said, there is several points :
- the amd gpu conception (contrary to nvidia) need that the kernel take time to analyze the command buffer, for security reason. fglrx do not do that.
- there is some limitation is the API, and it's not easy to fix. Moreover the kernel api is freeze, contrary to nouveau.
- r600g have a design that is not the best to do what it do.

To conclude, in fact, the main "problem" with r600g is in the kernel, not really in gallium side.

That's BS, there's no internal kernel api freeze! Nouveau could be allowed to do more changes after an RC1, if Linus allows it to, but other than that there's no difference, during the development cycle they can change whatever internal api they want(as long as they don't mess it up for someone else). The only api that is freezed(whichisn't actually true either, because it can be extended) is the one presented to user space. The problems of r600g are in r600g. And it will probably keep having them for some time too, considering that it's still being developed at a far slower pace than r300g.

[smitty3268]

The only api that is freezed(whichisn't actually true either, because it can be extended) is the one presented to user space.

Which is why that's the one people are talking about when they say it has design problems that are hard to work around.

They do have versioning, so they could change the API in future versions to fix it, but that would require a fair amount of work to then maintain 2 different code paths. So who knows whether or not it will happen.

I agree that there are currently bigger performance issues elsewhere.

[bug77]

Mac OS and Windows work, so your argument does not make any sense.

Really, I'm the one not making any sense? You should try looking outside your box sometime, maybe you'll notice this thing called "the world". It's a place where people have working video cards and drivers from day 1. And by that, I mean fully working: 2D, 3D, MPEG4 decoding, power saving, even sound over HDMI.

Your argument about having a choice sounds a lot like other people's argument in favor of communism: it doesn't work yet, but let's stay on course, someday we'll get there. I hope you know how that ended.

[deanjo]

Intel has the lion's share of Linux graphics, as they have the lion's share of all graphics.

If you're just talking about high-performance graphics with an eye towards gaming, then NVIDIA has the lion's share on Linux because they also have it on Windows. Steam hardware stats show that well over 60% of all gamers are using NVIDIA hardware. ATI actually has a larger share of the Linux "gamer" desktop than it does of the Windows gamer desktop, if you compare Steam's stats with Phoronix's Linux Graphics Survery results over every year it's been published.

Ya and EVERY year that Phoronix has published it's results, who is top dog? Ya that would be Nvidia users of the blob with good reason. Granted that share is getting smaller (finally). I will also point out that Nvidia blob users have a disproportionally huge share when it comes to linux (even compared to intel IGP's which in "theory" should rule the roost) . Why do you think that is? BTW Steam numbers mean SFA in regards to linux.

[mark_]

is there a maintained and complete list somewhere, regarding the lacking features for r600g? It would be nice to have a complete overview and maybe this opens some opportunity for additional help...
For example, for me it is a huge barrier to help out, because I don't have the time to learn everything about mesa, opengl, the hardware, etc... but I'd like to have a complete driver and if there were a list with missing features with a little bit of information ("this task is easy/medium/hard, write functions foo and bar regarding to spec $URL in file bla/foo.c of mesa", using conventions listed in $URL2) then I guess more people could do some of those tasks. Could this work?
The only thing most users can do now is update the software and moan if something still does not work ;-)

[curaga]

I'm afraid that if there are any simple tasks like that, it will take the devs less time to do that than to google up $URL and $URL2.

[bridgman]

is there a maintained and complete list somewhere, regarding the lacking features for r600g? It would be nice to have a complete overview and maybe this opens some opportunity for additional help...
For example, for me it is a huge barrier to help out, because I don't have the time to learn everything about mesa, opengl, the hardware, etc... but I'd like to have a complete driver and if there were a list with missing features with a little bit of information ("this task is easy/medium/hard, write functions foo and bar regarding to spec $URL in file bla/foo.c of mesa", using conventions listed in $URL2) then I guess more people could do some of those tasks. Could this work?
The only thing most users can do now is update the software and moan if something still does not work ;-)

There isn't really a maintained list but all of the active developers know what work is required. The problem is that the remaining "performance enabling" features tend to be some of the hardest ones so they probably aren't good candidates for new developers. Finding and fixing regressions is probably the best place to start, followed by understanding why application XYZ has problems.

Alex gave a pretty good summary of the work remaining in 600g relative to 300g back in post #26 :

http://phoronix.com/forums/showthrea...026#post198026

[bridgman]

The problems of r600g are in r600g. And it will probably keep having them for some time too, considering that it's still being developed at a far slower pace than r300g.

I don't think r600g work is going at a slower pace than r300g as much as r600g work simply started much more recently. The r300g driver has been actively worked on for a couple of years, while the r600g driver was created quite recently and only became the "primary driver" for developer effort 6-7 months ago. The rate of progress is actually pretty remarkable when you think about how new the driver is and remember that the hardware changed radically between 5xx and 6xx so very little of the r300g work can be re-used in r600g.

[mark_]

I'm afraid that if there are any simple tasks like that, it will take the devs less time to do that than to google up $URL and $URL2.

I don't know, I mostly remember phoronix going wild because some 5 loc patch in mesa brings $gigafeature_we_waited_all_our_lives_for to r600g (resulting in no visible change on my machine of course), where someone added an if-block containing a single line, so my impression is, that this cannot be thaaat difficult
(I didn't hear someone scream about that -7943/+10605 loc branch merge last week yet, maybe the usual scream-guys had a heart attack that day and are still recovering )

[bwat47]

The open source drivers need a LOT of work on the power management side before I consider them remotely usable.

And fglrx is finally pretty decent with the latest releases (finally no tearing!), now they just really need video acceleration. (yeah I know some people have it working, but xvba is totally broken on uvd1 cards :/ )