Page 6 of 7 FirstFirst ... 4567 LastLast
Results 51 to 60 of 61

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

  1. #51
    Join Date
    Jun 2009
    Posts
    2,908

    Default

    Quote Originally Posted by bug77 View Post
    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.
    Yes, that's exactly what I said.

    And nobody is stopping you from using them.

    What's happening is that you are trying to prevent people from having an open alternative, free to study, modify, use and distribute.

    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.
    You shouldn't post drunk.

    I know how GCC, Firefox and Linux ended. If one day Mesa and Gallium3d end up the same way, it will be great.

    In the meantime, just continue using windows, with 1st day support. nobody is stopping you. Why do you have open source so much?

  2. #52
    Join Date
    Dec 2008
    Posts
    35

    Default

    Quote Originally Posted by bridgman View Post
    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.
    Well, 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.

  3. #53
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,281

    Default

    Quote Originally Posted by mark_ View Post
    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
    In most cases when you see a 5 line patch add an important feature that usually means there were a couple of dozen earlier patches that represented the real work and the last patch either turned it on or fixed the last serious problem with the implementation. There were a couple of features which really *did* only take a few lines to enable but I don't think it makes sense to consider them "typical" of the work required.

    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.

    Quote 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 )
    I think that work was related to a GL3 feature which is important to get to the next level of GL support but probably doesn't greatly impact end users today (since most of the apps out there are still using only GL 2.x level support). It is changes like that which represent a lot of the groundwork required in order to let a 5 line patch make a big difference a few months down the road.

  4. #54
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,281

    Default

    Quote Originally Posted by MisterIO View Post
    Well, 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.
    Not 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/r300

    http://cgit.freedesktop.org/mesa/mes...m/drivers/r600

  5. #55
    Join Date
    Dec 2008
    Posts
    35

    Default

    Quote Originally Posted by bridgman View Post
    Not 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/r300

    http://cgit.freedesktop.org/mesa/mes...m/drivers/r600
    Similar 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).

  6. #56
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,281

    Default

    Quote Originally Posted by MisterIO View Post
    Similar 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).
    That's a pretty short sample period. If you look at the last 6 weeks (1 page) or 10 weeks (2 pages) the change volume is a lot closer.

  7. #57
    Join Date
    Dec 2007
    Posts
    2,276

    Default

    Quote 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.
    I 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.

  8. #58
    Join Date
    May 2007
    Posts
    228

    Default

    Quote Originally Posted by MisterIO View Post
    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.
    You missing the point, nouveau in theory can change it's userspace API and say screw you old userspace. Radeon doesn't have this right.

  9. #59
    Join Date
    Aug 2007
    Posts
    6,598

    Default

    But cant you still add extra (optional) features to it?

  10. #60
    Join Date
    Nov 2008
    Location
    Germany
    Posts
    5,411

    Default

    Quote Originally Posted by deanjo View Post
    And in the end they lost and were wiped out (even with the help of 5000-7000 supporting forces).
    but they hurt them very much ;-)

    and the spartans lose this battle but later they won the war...

    in OSS speak they maybe lose the battle but be sure later they won the war!

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •