Page 5 of 7 FirstFirst ... 34567 LastLast
Results 41 to 50 of 61

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

  1. #41
    Join Date
    Dec 2008
    Posts
    35

    Default

    Quote Originally Posted by whitecat View Post
    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.

  2. #42
    Join Date
    Oct 2008
    Posts
    3,079

    Default

    Quote Originally Posted by MisterIO View Post
    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.

  3. #43
    Join Date
    Dec 2009
    Posts
    492

    Default

    Quote Originally Posted by pingufunkybeat View Post
    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.

  4. #44
    Join Date
    May 2007
    Location
    Third Rock from the Sun
    Posts
    6,583

    Default

    Quote Originally Posted by elanthis View Post
    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.

  5. #45
    Join Date
    Apr 2011
    Posts
    35

    Default

    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 ;-)

  6. #46
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,034

    Default

    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.

  7. #47
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,418

    Default

    Quote Originally Posted by mark_ View Post
    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

  8. #48
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,418

    Default

    Quote Originally Posted by MisterIO View Post
    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.

  9. #49
    Join Date
    Apr 2011
    Posts
    35

    Default

    Quote Originally Posted by curaga View Post
    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 )

  10. #50
    Join Date
    May 2010
    Posts
    684

    Default

    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

Posting Permissions

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