Page 4 of 20 FirstFirst ... 2345614 ... LastLast
Results 31 to 40 of 200

Thread: ATI R600g Gains Mip-Map, Face Culling Support

  1. #31
    Join Date
    Aug 2009
    Posts
    2,264

    Default

    @Agdr,
    you are two things:
    1. license to playback bluray means entire device must be drm'ed
    2. competition is clearly at the driver level and not so much on the hardware, although the theoretical computation power needs to be closely leveled. That said: if AMD releases portions of the driver then they literaly give away their optimisations that can show nVidia their way to victory.

  2. #32
    Join Date
    Jul 2010
    Posts
    46

    Default

    Quote Originally Posted by rohcQaH View Post
    you're making the assumption that fglrx is neatly modularized with clean inter-module APIs. I wouldn't count on that.
    Not necessarily: they could just rip the offending parts out even if intermingled with the rest, and keep both a "public" and a "private" development branch. With tools like git, this is quite manageable.
    Private code could be marked with a special comment and tools can then prevent accidental release of private code.

    Then there's the legal review. If you follow the news, you'll know how much work legal review is for the OS drivers that are mostly written from a known amount of documentation. Try to imagine sifting through a few hundred thousand lines of fglrx code to determine if it contains any licensed code that mustn't be shared, uses any patents that aren't covered outside of fglrx or tells internals about the hardware which AMD wants to keep secret.

    When AMD/ATI's linux strategy was formed, opening up parts of fglrx was discussed. But it was deemed easier to start from the scratch.
    The result may not be as fast as fglrx, but it's cleaner, better structured code. To me, that's more important.
    I think it should take much less time to review code than to rewrite it from scratch, obviously, especially for very non-trivial parts like how to maximize utilization of the r600+ VLIW ALUs.

    Not to mention that the result is guaranteed to work well and be as good as the original one (if only non-essential parts are withheld), while starting from scratch gives no guarantee of matching fglrx performance at all.

    But the really important thing is that the open source Linux driver would be at least partially a subset of the "real" driver that AMD really cares about, and thus would be guaranteed to be top notch and support new hardware immediately.

    As long as the open driver is separate from the primary driver, hardware will always be supported months late (e.g. no HD 5xxx 3D support almost a year after release!), and the driver won't be competitive for 3D gaming, which is definitely not a desirable outcome for users, and arguably not desirable for AMD either (unless other concerns are more important).

    Obviously, the ATI situation is still much better than the nVidia one, but it still falls way short of the ideal outcome (a top-notch open driver with full AMD software engineering support).

  3. #33
    Join Date
    Dec 2008
    Posts
    988

    Default

    ATI is never going to open source fglrx, you can forget about that. Despite the few devs they've allocated to the open source drivers, they're still very much a closed source company.

  4. #34
    Join Date
    Jun 2009
    Posts
    2,929

    Default

    I can live with full docs and a decent open source driver which can use all the card's features. It doesn't have to be a speed demon either, as long as it's reasonable (i.e. not 20% of the fglrx performance, but more like 75-80%)

    I'd like UVD support, but I can live with shader decoding.

  5. #35
    Join Date
    Jul 2010
    Posts
    46

    Default

    Quote Originally Posted by V!NCENT View Post
    @Agdr,
    you are two things:
    1. license to playback bluray means entire device must be drm'ed
    If they are allowed to release 3D documentation, almost surely they can also release an open driver that only uses that functionality, so I don't think this should be an issue, except for video-related parts that they can just not open at first.

    Obviously there may be DRM-related hooks in the 3D code, but they can be just ripped out and kept in a branch.

    Quote Originally Posted by V!NCENT View Post
    @Agdr,
    2. competition is clearly at the driver level and not so much on the hardware, although the theoretical computation power needs to be closely leveled.
    Actually, according for instance to Anandtech's "The RV770 Story: Documenting ATI's Road to Success", hardware seems the deciding factor, particularly the ability to effectively adapt to evolving silicon manufacturing processes (which makes sense, since that's where erformance ultimately comes from).

    Quote Originally Posted by V!NCENT View Post
    That said: if AMD releases portions of the driver then they literaly give away their optimisations that can show nVidia their way to victory.
    Yes, this is may be a good argument against opening parts of the driver.
    However, it is likely not the case at least for parts of the driver since they could either be too specific for ATI hardware, already publicly known, already implemented by nVidia or just easy to reverse engineer.

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

    Default

    Quote Originally Posted by monraaf View Post
    I wish it was. An untrusted user space driver confined to its own little sandbox, unable to lock up my system or stealing all my precious ram.

    Unfortunately it's not.
    20 years ago people talk to RMS like this: "you will never get an free unix because you don't have the manpower to beat the cloused ones"

    same for linus 15 years ago for the kernel.

    and now the people talk about the radeon driver in the same way ....''


    trust me in the future the fglrx will lose!

    Qaridarium wrote this lines with the: ***Radeon-opensource-driver***

  7. #37
    Join Date
    Nov 2008
    Posts
    768

    Default

    Agdr, people at AMD have considered this option and decided against it. Trust their judgment. They know more about GPUs than you do. They also know more about their markets and the things they must do to stay in business.

    Your GIT idea doesn't work, either. GIT can do quite a few nice things, but it doesn't magically provide a stable API where there's none. If the branches differ too much, you'll end up with patches that don't apply to both branches, leading to even bigger differences etc.. it can be made to work, but that puts additional requirements on anyone working on that code.
    Remember, their windows drivers are mission-critical. Their linux drivers are not. Allowing the latter to impede work on the former doesn't sound smart to me.

  8. #38
    Join Date
    Jun 2009
    Posts
    2,929

    Default

    Actually, the x86 machine code has remained rather stable over the last 20 years. GPUs have a much shorter lifespan and there is more change.

    On the other hand, Gallium3d should be able to help, at least with keeping the generic knowledge in one place. Also, it seems like the major 3d hardware is becoming more similar and doesn't make such radical changes in design as often nowadays.

  9. #39
    Join Date
    Jul 2010
    Posts
    46

    Default

    Quote Originally Posted by rohcQaH View Post
    Remember, their windows drivers are mission-critical. Their linux drivers are not. Allowing the latter to impede work on the former doesn't sound smart to me.
    That doesn't need to be the case.

    They could do development on their proprietary branch as usual and from time to time cherry-pick the commits that can be made public (editing them if necessary) to the public branch (this would be done by the open/linux team). This has no impact at all on windows/proprietary driver development.

    In the worst case, the open driver may lag a bit behind if significant adaptation work has to be done, but that would likely still be much better than the current situation.

  10. #40
    Join Date
    Aug 2009
    Posts
    2,264

    Default

    @Agdr,
    Do you have any idea about just how much these driver _stacks_ differ?

    There is no need for code sharing because the know-how is already there and the 'two' drivers differ so much that any code effort of sharing could be spend coding the triple amount of usefulness.

    Besides, the new floss driver architecture is made to share code with all cards. Intel and nVidia included. So there is no point in sharing with just fglrx for very card specific details.

Posting Permissions

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