Page 1 of 3 123 LastLast
Results 1 to 10 of 61

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

Hybrid View

  1. #1
    Join Date
    Jan 2007
    Posts
    15,646

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

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

    Earlier this week Sapphire launched the Radeon HD 5830 Extreme using the well-supported "Cypress LE" graphics processor at a very competitive price relative to the NVIDIA competition and the Radeon HD 5830 graphics cards from other AMD partners. With it being part of the HD 5000 series and not one of the newer HD 6000 series graphics processors, the Linux support is already spot-on for both the official Catalyst Linux driver and within the open-source stack. In this article are the open-source Gallium3D benchmarks for the Radeon HD 5830 along with other recent ATI/AMD GPUs to show where the latest Mesa/Gallium3D code is at today.

    http://www.phoronix.com/vr.php?view=15904

  2. #2

    Unhappy

    While the open-source ATI/AMD Linux driver stack is beginning to catch up with the proprietary Catalyst driver on older generations of Radeon hardware as earlier tests have shown, for modern GPUs it will still be a while before anything close to parity is hit.
    The problem is that it will be like that forever. AMD/NVIDIA deploy over five hundred programmers to create fast/optimized/bug free drivers for their GPUs, while at most there is just a handful of programmers (I'd say 10 tops) working on open source drivers.

  3. #3
    Join Date
    Dec 2009
    Posts
    492

    Default

    Quote Originally Posted by birdie View Post
    The problem is that it will be like that forever. AMD/NVIDIA deploy over five hundred programmers to create fast/optimized/bug free drivers for their GPUs, while at most there is just a handful of programmers (I'd say 10 tops) working on open source drivers.
    Not to mention the five hundred can write the driver the way they see fit, while the rest have to chase moving targets (KMS, DRI, etc).

  4. #4
    Join Date
    Nov 2009
    Posts
    328

    Default

    R300g and intel (sandy bridge) has more or less succeeded in making an optimized driver, without hundred of developers.

    In my opinion there is something weird with r600g, something at mesa or gallium that is really hurting r600-r700-r800 GPUs performance, something that developers don't find. Implementing new features like hiperz, opengl 3-4 will not solve this problem, it seems some type of "architectural" problem.

  5. #5
    Join Date
    Feb 2011
    Location
    France
    Posts
    225

    Default

    Quote Originally Posted by Jimbo View Post
    it seems some type of "architectural" problem.
    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.

  6. #6
    Join Date
    May 2007
    Posts
    233

    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.
    Kernel side is one part of the issue if you want to compete with catalyst. Right now the biggest issue is in r600g itself. Thought given the number of r600g needs i fear that kernel side might also impact it a little bit more than r300g.

  7. #7
    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.

  8. #8
    Join Date
    Dec 2007
    Posts
    2,404

    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.

  9. #9
    Join Date
    Oct 2009
    Posts
    218

    Default

    Quote Originally Posted by bug77 View Post
    Not to mention the five hundred can write the driver the way they see fit, while the rest have to chase moving targets (KMS, DRI, etc).
    That's one point. Underlying specifications constantly change, lot's of efforts become useless.

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

    Default

    Quote Originally Posted by birdie View Post
    The problem is that it will be like that forever. AMD/NVIDIA deploy over five hundred programmers to create fast/optimized/bug free drivers for their GPUs, while at most there is just a handful of programmers (I'd say 10 tops) working on open source drivers.
    300 Spartans can hurt 800 000 very much... http://en.wikipedia.org/wiki/Battle_of_Thermopylae

    why should the 130 radeon devs lose? Linus Torvalds Starts the Kernel alone.

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
  •