Page 5 of 16 FirstFirst ... 3456715 ... LastLast
Results 41 to 50 of 155

Thread: ATI R600 Gallium3D Driver Continues Advancing

  1. #41
    Join Date
    Oct 2009
    Posts
    1,987

    Default

    I think that there are two things to think about regarding bugs;

    1) at a constant rate of errors per lines of code, doubling the code means doubling the bugs.
    2) as the complexity increases, the rate of bugs tends to rise as well since it becomes exponentially more difficult to analyse the code in the "big picture".... especially when bad development methodologies are used, as is likely more common in closed source code.

  2. #42
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,283

    Default

    It's a pretty safe bet that proprietary driver development is using more advanced processes than open source these days. I think you'll find that the defect density ((latent + known defects) / LOC) is actually lower for closed source drivers than for open source drivers. I can't go into a lot of details but you might be surprised how far proprietary driver development has come in the last decade.

    I agree with the exponential rise in complexity as the driver grows though... that is a problem for open and closed drivers. The open source stack for ATI radeon GPUs has gone from ~50 KSLOC to over 250 KSLOC in the last couple of years (not counting close to 1,000 KSLOC of common Mesa code) and there is probably still some growing to do. By way of comparison, the proprietary drivers are well over 10,000 KSLOC.

    That said, the main challenges with closed source Linux drivers are more related to "big expectations vs. small market share/resources" and "large code size due to code sharing across multiple OSes" than to development process.

    Open source has one big advantage over closed source development, however, which is that users can bisect regression failures. We really need to get something similar implemented in the closed source world (the problem is sanitizing out future product info, not tools/process).

    I think this post added 5 or 6 to my post count... maybe 7 now.

  3. #43
    Join Date
    Jul 2007
    Posts
    428

    Default Actually, OSS has another advantage

    Quote Originally Posted by bridgman View Post
    Open source has one big advantage over closed source development, however, which is that users can bisect regression failures.
    With OSS, you don't get exchanges like this:
    User: Hi, The fglrx driver is having trouble running on my laptop.
    AMD: Did you buy a discrete graphics card from us?
    User: No, it's a laptop with an integrated AMD graphics chip.
    AMD: Then go talk to your laptop vendor instead. Goodbye.

  4. #44
    Join Date
    Nov 2009
    Location
    Italy
    Posts
    872

    Default

    Quote Originally Posted by bridgman View Post
    Open source has one big advantage over closed source development, however, which is that users can bisect regression failures. We really need to get something similar implemented in the closed source world
    This implies answering to your users. As soon as amd released the specs I bought an ati card and I started to use it with fglrx discovering some issues with libdrm v.<something>. I contacted the debian maintainer and he told me he was unable to do anything, so I contacted ati's technical support (linking the bugs reports) and I received no answer. I don't think they wanted some kind of user interaction and in fact I reported fglrx issues no more.

  5. #45
    Join Date
    Aug 2010
    Location
    Austro-Bavaria
    Posts
    30

    Default

    Quote Originally Posted by bridgman View Post
    Open source has one big advantage over closed source development, however, which is that users can bisect regression failures. We really need to get something similar implemented in the closed source world (the problem is sanitizing out future product info, not tools/process).
    Something like walking a customer through a bisect session with a script on a web server?

    You'd probably need a server with a huge repository of binary patches corresponding to commits, and with every bisect step merge the necessary patches to a single one for download, so the customer can easily apply and test.

    I guess that would be a real win for your customers.

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

    Default

    Quote Originally Posted by bridgman View Post
    Open source has one big advantage over closed source development, however, which is that users can bisect regression failures. We really need to get something similar implemented in the closed source world (the problem is sanitizing out future product info, not tools/process).
    i do Git Bisect for wine sometimes and this needs a lot of time with a lot of hand testing the bug very single step and you need an fast multicore pc

    but yes its an powerfull tool for the customers to find the source of the 'bug'

    the power of Bisect for the cloused source world ?

    if the hell is frozen then the cloused source world will get an opensource tool like Bisect LOL

    DEV's save a lot of time if the users found the bug by bisect and companys like AMD save a lot of money if the users find the bug by Bisect ;-)

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

    Default

    Quote Originally Posted by darkbasic View Post
    This implies answering to your users. As soon as amd released the specs I bought an ati card and I started to use it with fglrx discovering some issues with libdrm v.<something>. I contacted the debian maintainer and he told me he was unable to do anything, so I contacted ati's technical support (linking the bugs reports) and I received no answer. I don't think they wanted some kind of user interaction and in fact I reported fglrx issues no more.
    thats it ;-)

    they wana interact with the cloused beta programm users....

    sign a NDA and they start to speak with you ;-)

  8. #48
    Join Date
    Apr 2009
    Posts
    31

    Default

    last piglit test with r600g (22 september) : 824/930

    http://people.freedesktop.org/~airlied/piglit/r600g/

    19 august r600c : 642/711
    http://people.freedesktop.org/~airlied/piglit/r600c/


    R600G WIN !

  9. #49
    Join Date
    Oct 2008
    Posts
    68

    Default

    What does that mean in general usage? Is it faster/more feature complete/more bugfree...?

  10. #50
    Join Date
    Nov 2009
    Location
    Italy
    Posts
    872

    Default

    Quote Originally Posted by Schmaker View Post
    Is it faster/more feature complete/more bugfree...?
    No.

    [stupid 10 characters limit]

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
  •