Page 3 of 20 FirstFirst 1234513 ... LastLast
Results 21 to 30 of 200

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

  1. #21
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,279

    Default

    Pretty much, yeah

  2. #22
    Join Date
    Aug 2009
    Posts
    122

    Default

    Quote Originally Posted by Otus View Post
    I don't really care that much about games, but anyone know how close this is to running Compiz?
    it already can, but - shadows doesnt work, and screen rotatin on cube - all broken, but windows wobling

  3. #23
    Join Date
    Aug 2008
    Location
    Finland
    Posts
    1,567

    Default

    Quote Originally Posted by bridgman View Post
    I still believe that the open source drivers will get sufficiently close to fglrx features and performance that most consumer users won't care about the difference and will be very happy with the open drivers, but for some other markets (3D workstation, hardcore gaming) the difference will probably always be important.
    Hopefully it will make people complain less anyway.

  4. #24
    Join Date
    Aug 2009
    Posts
    2,264

    Default

    So Bridgman, if your fglrx team would have the same documentation (not counting DRM) as AMD is going to give to the public, how much of a performance decreas would we be talking about? Zero?

  5. #25
    Join Date
    Dec 2007
    Posts
    2,272

    Default

    It really depends how much work the community puts into the open source driver. As John mentioned before, above a certain level the amount of driver work grows exponentially as performance increases.

  6. #26
    Join Date
    Aug 2009
    Posts
    2,264

    Default

    Quote Originally Posted by agd5f View Post
    It really depends how much work the community puts into the open source driver. As John mentioned before, above a certain level the amount of driver work grows exponentially as performance increases.
    I read that. What I wanted to know is how, if any, the possible lack of documentation is going to be of impact on the speed of the FLOSS drivers, not counting optimisation work, which is why I brought the fglrx team into the equation.

  7. #27
    Join Date
    Jul 2010
    Posts
    46

    Default

    Quote Originally Posted by bridgman View Post
    The downside of sharing code across OSes is that most of the other OSes are proprietary and require robust DRM, so the shared driver code needs to remain proprietary as well.
    I'd like to thank you for engaging the community, but I find this reasoning quite puzzling.

    The only DRM that I can think of is the one related to the playback of BluRay and other HDCP protected media, and that surely doesn't impact the 3D driver.

    It seems you should be able to open source both fglrx and the Windows driver except for the video acceleration+DRM parts relatively easily.
    Besides, all video DRM seems completely cracked and BluRay releases seem widely available on public BitTorrent sites, so I don't think you could possibly make the situation worse for content producers.

    If this is not the case, what am I missing?

    The argument of wanting to keep the driver secret to not give a free gift to competitors seems instead much more understandable. Is this the real reason?

    However, opening some things like your AMD IL -> r600+ ISA compiler/optimizer shouldn't give any competitive advantage to Intel/nVidia since they use completely different non-VLIW architectures.

    It would be great and very interesting to have a much more detailed and accurate rationale for why you could or cannot open each component of fglrx/Catalyst.

    And opening fglrx and your Windows driver would have several advantages:
    1. Having bugs actually fixed by third parties, or at least more detailed bug reports
    2. Rock solid Linux support and dominance of the Linux market (all Linux distributions and enthusiasts would be in the position to recommend buying ATI GPUs exclusively)
    3. More mindshare among commercial game programmers, resulting in games that work better on your hardware. This would be due to the obvious advantage of being able to find out exactly what the driver is spending CPU time on and look intimately at what 3D calls are being translated to and how the hardware actually works.
    4. Possibly getting commercial game developers to help you in tuning your drivers for their games (without needing cumbersome NDAs), resulting in better performance on your cards compared to competitors, especially in things like multi-GPU support

    So, for parts of the driver where DRM, third party code, or competitive advantage concerns don't apply, I think you should consider opening the code (for both Linux and Windows).

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

    Default

    Quote Originally Posted by V!NCENT View Post
    So Bridgman, if your fglrx team would have the same documentation (not counting DRM) as AMD is going to give to the public, how much of a performance decreas would we be talking about? Zero?
    the true is the opensource one can beat the FGLRX thats because FGLRX is a userspace driver!

    you know? a kernel space driver do have less overhead.

    fglrx do have a usersprace vram managment radeon do have kernel based vram managment..

    Theoretical radeon can beat FGLRX very hard IF the radeon driver becomes the 'LOVE' of more DEV's

  9. #29
    Join Date
    Nov 2008
    Posts
    755

    Default

    Quote Originally Posted by Agdr View Post
    It seems you should be able to open source both fglrx and the Windows driver except for the video acceleration+DRM parts relatively easily.
    you're making the assumption that fglrx is neatly modularized with clean inter-module APIs. I wouldn't count on that.

    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.

  10. #30
    Join Date
    Dec 2008
    Posts
    980

    Default

    Quote Originally Posted by Qaridarium View Post
    the true is the opensource one can beat the FGLRX thats because FGLRX is a userspace driver!
    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.

Posting Permissions

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