Announcement

Collapse
No announcement yet.

AMD Pushes Out New R600/700 3D Code

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

  • #11
    Originally posted by bridgman View Post
    More like 3-4 years for a new generation. We're already hooked into future GPU development work so the delay from intro to open source driver support should be shorter than for previous generations when we were mostly playing "catch-up".
    So the future is being made today

    Originally posted by bridgman View Post
    One of the big changes with 6xx was at least partially separating the programming model from the hardware implementation, so big changesa in the hardware have relatively less impact on the driver than in previous generations. 6xx and 7xx are very different hardware implementations but the programming interface is pretty similar. The downside was that it took a lot of work to get drivers running on the new programming model in the first place, but we're mostly past that now.
    It is much appreciated nevertheless

    Originally posted by bridgman View Post
    The discussion about "separating" was for DRM and UVD, shouldn't have any impact on 3D. I obviously can't comment on status.
    Reading Wikipedia it sounds like quite a complicated task!

    http://en.wikipedia.org/wiki/Unified_Video_Decoder

    Comment


    • #12
      Originally posted by Louise View Post
      Bridgman shared in a post for some time ago, that the whole problem of releasing the 3D specs was the DRM (Digital Restrictions Management).

      For the R800 this was taken into account, so the 3D stuff and DRM was separated.

      So the R800 will maybe not (?) share much with R6xx and R7xx ?
      No! 3D is free! UVD the mpeg2 und generaly the viedeo part has the DRM di-re-ma part in it!

      so amd do not have bring the spec for the viedeo render part! becourse they can't

      the R800 will Hopefulle chance this but AMD run's Out of money so i think amd can't chance this!

      so i think... they bring DirectX11 by driver and microcode update to the rv740!

      and the don't chance the UVD part in the R800--- but if they have more money again the will chance this in the future. --->R900
      Last edited by Qaridarium; 04-18-2009, 08:22 PM.

      Comment


      • #13
        Hi,

        Do you know where the source code is published?
        Is it in mesa repo? I found two branches, r6xx-r7xx-support and radeon-rewrite.

        Is it in these?

        Comment


        • #14
          The 3d code is in r6xx-r7xx-support. The radeon-rewrite branch is where airlied and others are adding support for running over a drm with memory manager and kernel modesetting (KMS/GEM/TTM).

          There is a third branch, r6xx-rewrite, which is where we made a copy of radeon-rewrite and have started porting the 6xx/7xx 3d code into radeon-rewrite -- so the name is a hybrid of 6xx-7xx-support and radeon-rewrite

          Comment


          • #15
            Originally posted by bridgman View Post
            The 3d code is in r6xx-r7xx-support. The radeon-rewrite branch is where airlied and others are adding support for running over a drm with memory manager and kernel modesetting (KMS/GEM/TTM).

            There is a third branch, r6xx-rewrite, which is where we made a copy of radeon-rewrite and have started porting the 6xx/7xx 3d code into radeon-rewrite -- so the name is a hybrid of 6xx-7xx-support and radeon-rewrite
            So these are not different drivers then, just different branches of the same code base?

            Comment


            • #16
              Originally posted by duby229 View Post
              So these are not different drivers then, just different branches of the same code base?
              The r6xx-r7xx-support branch is the current 3D driver code we had internally which was started before Dave started reworking the radeon 3D driver code in the radeon-rewrite branch. We decided it would be easier going forward to rebase the r6xx/r7xx 3D driver on the radeon-rewrite code base. To do so, I created a new r6xx-rewrite branch that's based on radeon-rewrite. Over the coming weeks we'll be porting the code in r6xx-r7xx-support over to r6xx-rewrite. At the moment, there is no r6xx/r7xx specific code in r6xx-rewrite. So far it's all been infrastructural work to get the branch ready for r6xx/r7xx hw specific code.

              Comment


              • #17
                And here's the "Readers Digest" version :

                * master - no 6xx/7xx, doesn't work with memory manager

                * radeon-rewrite - no 6xx/7xx, works with memory manager

                * 6xx-7xx-support - works with 6xx/7xx, doesn't work with memory manager

                * 6xx-rewrite - merge of the previous two branches, so will have 6xx/7xx *and* work with memory manager once finished

                The most likely sequence of events is :

                1. radeon-rewrite merges to master, adding memory manager support for 5xx/690 and below

                2. 6xx-rewrite merges to master, adding 6xx/7xx support

                If, however, the 6xx/7xx port to rewrite goes more quickly than finishing radeon-rewrite, the sequence would be :

                1. 6xx-rewrite merges to radeon-rewrite

                2. radeon-rewrite merges to master
                Last edited by bridgman; 04-19-2009, 04:08 PM.

                Comment


                • #18
                  Well, I gotta be honest here... Readers Digest definitely helped me..

                  That makes sense. I can certainly understand the values of a well thought out project that goes exactly according to plan. Every new network I assemble is different, and requires a bit of planning to get it in working order.

                  Taking an object that is one way and making it communicate with another object that is a different way. I guess APIs and networks have something in common.

                  Comment


                  • #19
                    Originally posted by bridgman View Post
                    And here's the "Readers Digest" version :

                    * master - no 6xx/7xx, doesn't work with memory manager

                    * radeon-rewrite - no 6xx/7xx, works with memory manager

                    * 6xx-7xx-support - works with 6xx/7xx, doesn't work with memory manager

                    * 6xx-rewrite - merge of the previous two branches, so will have 6xx/7xx *and* work with memory manager once finished

                    The most likely sequence of events is :

                    1. radeon-rewrite merges to master, adding memory manager support for 5xx/690 and below

                    2. 6xx-rewrite merges to master, adding 6xx/7xx support

                    If, however, the 6xx/7xx port to rewrite goes more quickly than finishing radeon-rewrite, the sequence would be :

                    1. 6xx-rewrite merges to radeon-rewrite

                    2. radeon-rewrite merges to master
                    what happens with radeonhd ??

                    it might be a stupid question but i though that the code -when it was made available- would be simply merged to radeonhd and radeon

                    Comment


                    • #20
                      Originally posted by 89c51 View Post
                      what happens with radeonhd ??

                      it might be a stupid question but i though that the code -when it was made available- would be simply merged to radeonhd and radeon
                      No, this has nothing to do with the X drivers. It only has to do with the 3D drivers in Mesa.

                      Comment

                      Working...
                      X