Originally posted by bridgman
View Post
Announcement
Collapse
No announcement yet.
Where The Open-Source AMD Driver Is At For Modern GPUs
Collapse
X
-
-
Originally posted by mark_ View PostI 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
Seriously, if the remaining work was that simple it would have been done months ago. Pretty much every feature on the list has already been tried one or more times but proved to be too complicated to get working quickly.
Originally posted by mark_ View Post(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 )Test signature
Comment
-
Originally posted by MisterIO View PostWell, I wasn't blaming anyone about that, it's just that I keep a git repository of mesa on my hd to monitor its progress and I can see that the lines changed(and added) to the r300g have been constantly more(and more frequent) than those for the r600g.
Test signature
Comment
-
Originally posted by bridgman View PostNot sure I agree. The rate of change seems pretty similar to me, at least for the last couple of months.
http://cgit.freedesktop.org/mesa/mes...m/drivers/r600
Comment
-
Originally posted by MisterIO View PostSimilar is kind of vague, what's similar? Let's make an example, from 2011-04-01, removing the commit gallium: add and use generic function for querying patented format support (v2), whichis the same for both, I count: -151/+329 for r300g and -19/+27 for r600g(approximate and not too miningful for various obvious reasons, but it's just to make an example).Test signature
Comment
-
Originally posted by whitecat View Post- 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.
Comment
-
Originally posted by MisterIO View PostThat'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.
Comment
-
Originally posted by agd5f View PostI don't really agree with these statements. r300g uses the same CS ioctls as r600g (same checking and buffer relocation -- all radeons use the same scheme) and it performs close to fglrx (and in some cases faster). As I stated before, the difference lies in the fact that r300g has been worked on and optimized longer.
Comment
Comment