Announcement

Collapse
No announcement yet.

ATI R600g Gains Mip-Map, Face Culling Support

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Pretty much, yeah

    Comment


    • #22
      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

      Comment


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

        Comment


        • #24
          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?

          Comment


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

            Comment


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

              Comment


              • #27
                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).

                Comment


                • #28
                  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

                  Comment


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

                    Comment


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

                      Comment

                      Working...
                      X