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.
Originally Posted by whitecat
Which is why that's the one people are talking about when they say it has design problems that are hard to work around.
Originally Posted by MisterIO
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.
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.
Originally Posted by pingufunkybeat
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.
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.
Originally Posted by elanthis
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 ;-)
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.
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.
Originally Posted by mark_
Alex gave a pretty good summary of the work remaining in 600g relative to 300g back in post #26 :
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.
Originally Posted by MisterIO
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 :/ )
Tags for this Thread