Announcement

Collapse
No announcement yet.

ATI R600g Gains Mip-Map, Face Culling Support

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

  • #31
    @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.

    Comment


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

      Comment


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

        Comment


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

          Comment


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

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

            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.

            Comment


            • #36
              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***

              Comment


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

                Comment


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

                  Comment


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

                    Comment


                    • #40
                      @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.

                      Comment


                      • #41
                        Like Vincent said, it's not just a "driver", as a separate piece of code.

                        The open source drivers are distributed between the kernel (drm), the X driver and Mesa (which does OpenGL). Now all drivers are migrating over to the Gallium3d infrastructure.

                        Fglrx and the Nvidia blob do all of this inside the kernel blob, and they duplicate much of the code that sits in the X server and the linux kernel as a result.

                        Either you port fglrx to match the open stack (which is a lot of work), or you carefully separate out the parts that can be released into a separate branch, and then develop it with no community help whatsoever and maintain the whole thing on your own. Neither is a good proposition.

                        The most reasonable thing to do is to do the open drivers the Linux way -- by building on the OSS technology like Gallium3d and the kernel drm infrastructure, KMS, etc. This makes the fglrx code difficult to port directly, and the effort it would take is probably no less than writing the thing from scratch.

                        The important thing is opening the docs and providing the basic infrastructure and getting the community involved. I think that AMD are doing it the right way. The problem that few people in the community have both the know-how and the time to contribute is a real one, but a different issue altogether.

                        Comment


                        • #42
                          Originally posted by V!NCENT View Post
                          @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.
                          If fglrx/Catalyst were to be opened, it could be used as a full standalone OpenGL stack, without using Mesa and DRM.

                          Alternatively, it could be turned into a Gallium driver: the Gallium driver interface is very similar to the Direct3D 10/11 one, so it should be relatively feasible to convert the Catalyst Direct3D 10/11 driver to become a Gallium driver. The kernel interface would need to be replaced with libdrm-radeon.

                          A third option would be to just integrate the VLIW shader optimizer into r600g. I'd say this is likely the most interesting (i.e. hard to rewrite well, and most self-contained) part of fglrx, and the one easiest to actually reuse in a Mesa/Gallium driver. It is also very AMD-specific, so it shouldn't provide a competitive advantage.

                          Even in this case, the generic parts of the 3D driver could be rather useful to have available when writing equivalent functionality for r600g, especially for advanced stuff like Evergreen tessellation support that the Mesa classic driver probably won't get soon.

                          The source code of their OpenGL 4 implementation, while probably not directly usable in Mesa, could still be insightful and speed up work on GL3 and GL4 for Mesa. nVidia already has their own, so it might be possible to open (unless deeply intertwined with 3rd-party licensed code).

                          Comment


                          • #43
                            @Agrd,
                            gallium is not like Direct3D at al. Not even remotely close.

                            Gallium is not a driver, nor a 3D library. Gallium is a layer for modern GPU's. That layer is a sort of API. On top of that API functionality can be written, like OpenGL, OpenCL, DirectX, Glide, X.org, vector graphics acceleration, database crawlers, number crushers and whatever you can think of, which is why you _do NOT_ want fglrx take its place.
                            Below that layer is a driver that exposes that Gallium API and _that_ is where the floss drivers kick in.

                            Comment


                            • #44
                              Originally posted by V!NCENT View Post
                              @Agrd,
                              gallium is not like Direct3D at al. Not even remotely close.

                              Below that layer is a driver that exposes that Gallium API and _that_ is where the floss drivers kick in.
                              The Gallium API is very close to the Direct3D 10/11 API, especially the user-mode "DDI" API that Windows device drivers implement.

                              If you actually look at it, you'll notice that Gallium functions essentially map 1:1 to Direct3D functions (e.g. pipe_context::create_rasterizer_state vs ID3D10Device::CreateRasterizerState).

                              Of course there are some differences, and some features that one supports and the other doesn't, but the general structure is identical (unlike OpenGL, which is a completely different API).

                              Comment


                              • #45
                                All good questions, although I've answered them all a few times before. Maybe I need to write a book

                                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?
                                Somewhere on the order of "a few percent", certainly less than 5%. The primary reason for the performance difference between proprietary and open driver stacks is that the proprietary drivers get maybe 50x the development resources because the work is shared across the entire PC market rather than being specific to one OS.

                                Originally posted by Agdr View Post
                                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.
                                On the DRM side, the problem is that we have to protect not only the bits of code which are actually doing DRM-ey things (which are as small as you expect) but also all of the code *below* them (ie between that code and the hardware) in order to protect against attackers interposing code between the DRM-specific bits and the hardware.

                                The 3D part of the driver uses all many of the same lower level bits (surface management, memory management, command submission etc..).

                                Originally posted by Agdr View Post
                                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.
                                The problem is that IHVs (HW vendors like us) are required to meet specific standards of robustness rather than "not making things any worse than they already are", ie our DRM-related obligations do not go down if other parts of the DRM stack are broken. For better or for worse, that's how content providers ensure that DRM does not collapse into rubble as soon as the first big cracks start to appear.

                                Originally posted by Agdr View Post
                                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.
                                Yep, on the 3D side the reasons for not opening the code are more related to competition than to DRM. Two main issues :

                                1. We regard our shader compiler technology as part of the "secret sauce" which allows us to use a VLIW hardware approach which, in turn, gives us advantages in performance vs transistor count / die size / cost.

                                2. If you limit the discussion to our major competitor in the discrete GPU market, we both have roughly the same features and performance but I'm sure our code has clever ideas that our competitor doesn't have and that their code has clever ideas we don't have. If one competitor opens their code while the other does not, that tips the balance subtly (again, probably only a few percent but those few percent are worth a lot of $$).

                                Originally posted by Agdr View Post
                                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
                                Yep, there are definitely benefits, but again the number of outside developers who can *and* are likely to work on the drivers is sufficiently small that it's *really* hard to make the costs and benefits work out. We have driver developers with source access working side-by-side with outside ISV developers already so I *think* the largest potential area of gain from opening the driver is already covered.

                                Opening code is about a thousand times as cumbersome as a source license agreement, and maybe 10 thousand times as cumbersome as an NDA

                                Originally posted by Agdr View Post
                                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).
                                Yep, and that's what we are doing. It's just that the "parts of the driver where DRM, third party code, or competitive advantage concerns don't apply" are much smaller than you might think. The driver stack was not written with an eye to opening it, and so opening almost any part of it requires some refactoring to move out the sensitive stuff which doesn't *have* to be in that part of the code but which was put there anyways because it made the code simpler/cleaner/faster.

                                I don't really see much chance of opening up the Windows parts of the code, but we would like to open up some more of the Linux-specific bits over time.

                                Originally posted by rohcQaH View Post
                                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.
                                Yep, and we're talking about >>10 million lines of code here.

                                Originally posted by Agdr View Post
                                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.
                                Sure, but the whole point is that we are not rewriting it from scratch. The open source driver is not trying to duplicate fglrx, it's trying to be "<5% of the code size delivering 80-90% of the results", so the comparison is between inspecting and sanitizing the entire stack vs rewriting 5% of it.

                                Originally posted by Agdr View Post
                                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).
                                Nope, you need to consider the "catch-up" work that has been happening, with community and AMD developer resources working first on getting support in place for older GPUs and second on bringing the open source graphics architecture up to date (KMS, GEM/TTM, Gallium3D) before working on the newest GPUs. Even Evergreen support work started well after launch because the devs were finishing off support for previous generations.

                                Our goal is to be more or less caught up by the time the first Fusion parts start to ship, and from that point on I expect we should be able to start at least some of the open source support work before subsequent parts are launched.

                                Our launch-time focus will still be on the proprietary drivers because the ability to share common code across 100% of the PC market is too useful to ignore, but everyone needs to avoid falling into the trap of believing that just because we restarted open source support in 2007 and worked in part on hardware dating back to 2000 that means we'll be stuck with that initial backlog forever.

                                Comment

                                Working...
                                X