Announcement

Collapse
No announcement yet.

AMD Pushes Out New R600/700 3D Code

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

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


            • #21
              Originally posted by 89c51 View Post
              what happens with radeonhd ??
              Why should anyone care?

              Comment


              • #22
                sorry i got confused with all the mesa radeons 2D 3D stuff

                my mistake



                sorry again

                Comment


                • #23
                  Originally posted by elanthis View Post
                  Why should anyone care?
                  Now now, of course people should care. It's just not an imminent matter and can be safely ignored for the time being. (maybe even for years)

                  Comment


                  • #24
                    I've just seen that Google released a plugin for some browsers to be able to render 3d. It requires opengl 2.0, maybe it's time to ask them to contribute with manpower to the development of free drivers.
                    I understood they were pushing hard amd and nvidia for open drivers, now that they want the web to take advantage of opengl, pushing open source drivers could be a good way to promote their plugins, by offering a more out of the box experience ?

                    Comment


                    • #25
                      Could always be better...

                      This is great, though it's still programming for a single chipset. What is needed is a standardized unified driver system for graphics cards like what exists for USB devices now, and like other standards such as firewire. Graphics card makers need to form and support open graphics driver standards so that driver development isn't wasted by only being compatible with specific card chipsets. If you combined the devs in the various driver projects under a single umbrella, Linux graphics would be in a much better state today.
                      Last edited by Yfrwlf; 05-06-2009, 06:43 PM.

                      Comment


                      • #26
                        That's one of the goals of Gallium3D. If it works as hoped, it reduces the amount of device-specific acceleration code significantly and puts it all in one place.

                        The current Gallium3D implementation assumes the existence of DRI2, which in turn requires video memory management in the kernel. Once that is stable and merged into the upstream kernel tree you should see greater progress with and usage of Gallium3D by both the 3D and X drivers.

                        There's a reasonable chance that most cards will be able to use a "generic" X driver which uses KMS for modesetting and Gallium3D for 2D and video acceleration.
                        Last edited by bridgman; 05-06-2009, 06:50 PM.

                        Comment


                        • #27
                          Originally posted by bridgman View Post
                          That's one of the goals of Gallium3D. If it works as hoped, it reduces the amount of device-specific acceleration code significantly and puts it all in one place.

                          The current Gallium3D implementation assumes the existence of DRI2, which in turn requires video memory management in the kernel. Once that is stable and merged into the upstream kernel tree you should see greater progress with and usage of Gallium3D by both the 3D and X drivers.

                          There's a reasonable chance that most cards will be able to use a "generic" X driver which uses KMS for modesetting and Gallium3D for 2D and video acceleration.
                          So while it's not the complete focus of Gallium3D, it *will* allow "generic" cards to use it? I can only hope these generic features will be quite good, and that effort will focus on improving the API so that "generic" cards can be extremely good, featureful, and fast, hopefully to the point at which AMD, Intel, Nvidia, and others can release "generic" cards which won't even require any driver updates.

                          Plug-n-play, like UVC/firewire/etc, is what I'm hopin' for. Greatly simplifies life for everyone. ^^

                          Comment


                          • #28
                            Originally posted by Yfrwlf View Post
                            So while it's not the complete focus of Gallium3D, it *will* allow "generic" cards to use it? I can only hope these generic features will be quite good, and that effort will focus on improving the API so that "generic" cards can be extremely good, featureful, and fast, hopefully to the point at which AMD, Intel, Nvidia, and others can release "generic" cards which won't even require any driver updates.

                            Plug-n-play, like UVC/firewire/etc, is what I'm hopin' for. Greatly simplifies life for everyone. ^^
                            The way I understood it was that you do have to write a basic card-specific driver for Gallium but the benefits come on high level. As in, every card that has a Gallium driver gets to benefit of all state trackers. As in, you do need to have a card-specific basic access (including KMS and memory manager) to the card but higher level stuff (including access to for X.org (whatever it means, I don't exactly know; I'd guess 2D accel), DRI2, video acceleration using Motion Compensation etc) are done with the state trackers - and might from one perspective come for free. Especially after Gallium matures, a completely new card that someone writes a Gallium driver for would immediately tap into a set of powerful working state trackers so it's a big future investment.
                            A developer can correct me if I was misleading or imprecise.
                            Last edited by nanonyme; 05-08-2009, 05:01 AM.

                            Comment


                            • #29
                              Yeah, there isn't really such a thing as a "generic" graphics card or GPU (ie one with a standard programming model or register set shared across multiple vendors), and it seems unlikely there will ever be one.

                              The programming model for each GPU is constantly evolving, primarily to support new programming standards, both for graphics and for compute. The drivers have to keep changing at the same pace, in order to provide a standard API to other parts of the graphics stack.

                              Comment


                              • #30
                                Even individual CPUs, bus architectures, and so on need specific drivers. Even the "generic driver" interfaces that exist (intel-hda, ac97, usb) all end up having tons of per-device tweaks and fixes. Generic is pretty pointless. It's done in the industry as is mostly to save time on engineering, not for consumer or FLOSS friendliness.

                                Comment

                                Working...
                                X