Announcement

Collapse
No announcement yet.

Radeon HD 7000 Series Will Bring New 3D Driver

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

  • Radeon HD 7000 Series Will Bring New 3D Driver

    Phoronix: Radeon HD 7000 Series Will Bring New 3D Driver

    There's another update to the recent AMD Driver Support State For Radeon HD 7000 Series, Trinity article. The Radeon HD 7000 series will in fact bring a new Gallium3D Linux driver...

    http://www.phoronix.com/vr.php?view=MTAyNTA

  • #2
    This feels a bit scare for me, owning a Radeon 4850. How well will support for the "older" cards be maintained, etc etc? But since they haven't abandoned the R300 I guess there's not much to fear in the coming years. And eventually I think it's worth buying a new graphics card, even though it's a cheap-ass one with passive cooling, just to get a newer generation card. If I had a R300 today I would probably buy a $30 card since it will quadruple performance and at the same time allow me to use both Catalyst and FOSS drivers.
    On another note: It's very interesting that the 48*0 series is still the best performing generation when running the FOSS drivers.

    Comment


    • #3
      Gcn, vliw4, & vliw5

      As far as I understand it, only the top-end 7900 chips are using the new GCN arcitecture, while the weaker parts will be using a mix of the VLIW4 arch introduced with Cayman and, curiously, the older VLIW5 arch as well.

      Comment


      • #4
        Originally posted by Darkfire Fox View Post
        As far as I understand it, only the top-end 7900 chips are using the new GCN arcitecture, while the weaker parts will be using a mix of the VLIW4 arch introduced with Cayman and, curiously, the older VLIW5 arch as well.
        High-end chips should have a completely new SIMD approach. This is the main reason there should be a new driver.
        Slower chips will use the older VLIW4 architecture and Trinity chips should use VLIW4 architecture.

        Comment


        • #5
          Originally posted by blackshard View Post
          High-end chips should have a completely new SIMD approach. This is the main reason there should be a new driver.
          Slower chips will use the older VLIW4 architecture and Trinity chips should use VLIW4 architecture.
          ...isn't that exactly what I said?

          (well, minus the VLIW5 part)

          Comment


          • #6
            Just a reminder, current and GCN architectures are both SIMD -- it's just that current GPUs are VLIW SIMD while GCN is non-VLIW SIMD :

            http://developer.amd.com/afds/assets...2620_final.pdf

            See slide 19

            Maybe we need to introduce a new NPLIW architecture (Not Particularly Long Instruction Word) to avoid confusion

            Comment


            • #7
              Any VLIW5 chips are likely just rebadged from older generations, and not new

              The switch away from VLIW4 means that any shader compiler would be radically different, which is why i suspected they might start a new driver. All the compute features might impact that as well.

              Comment


              • #8
                Does this new driver stack will be developed "internally" by AMD or in a "open" manner (I mean a git repo during the development). If I remember, r600g was mainly created by Red Hat guys?

                Comment


                • #9
                  Originally posted by bridgman View Post
                  Just a reminder, current and GCN architectures are both SIMD -- it's just that current GPUs are VLIW SIMD while GCN is non-VLIW SIMD :

                  http://developer.amd.com/afds/assets...2620_final.pdf

                  See slide 19

                  Maybe we need to introduce a new NPLIW architecture (Not Particularly Long Instruction Word) to avoid confusion
                  I was under the impression that GCN was MIMD rather than SIMD. Is that not accurate?

                  http://www.brightsideofnews.com/news...itectures.aspx

                  Comment


                  • #10
                    It will all be public once we are able to release the initial code.

                    Comment


                    • #11
                      Originally posted by gigaplex View Post
                      I was under the impression that GCN was MIMD rather than SIMD. Is that not accurate?
                      Depends on who you ask, I guess. Current chips have multiple SIMDs each capable of executing a different program on a different set of data elements (although in most cases they run multiple instances of a small number of programs), so if that's all you require to call something MIMD then I guess both current and future architectures are MIMD.

                      GPUs are often classed as "multithreaded SIMD" rather than MIMD because of nuances in connectivity and data sharing. Each new generation of GPUs improves data sharing capabilities and efficiencies so I guess at some point they will start getting called MIMD by enough researchers to "make it official". Not sure where that point is though...

                      Originally posted by whitecat View Post
                      Does this new driver stack will be developed "internally" by AMD or in a "open" manner (I mean a git repo during the development).
                      As agd5f said, the bits specific to new hardware will be developed internally until we arrange and receive approval to release them, which I wouldn't expect to happen until after launch, then the rest of the work will happen in the open.

                      The new stack should be architecturally similar to the current stack, and in the areas where it's different (multiple ring support, memory management, compiler so far) we're planning to push those bits out early, once they move from ideas to at least semi-working code. Multiple ring support was pushed out a month or two ago, while the memory mgmt and compiler code are getting fairly close.

                      We discussed the memory management and compiler plans a bit at XDC, so the core ideas are already "out there". Current thinking is that we should be able to share some shader compiler work between graphics on GCN and clover on existing hardware plus GCN.

                      Originally posted by whitecat View Post
                      If I remember, r600g was mainly created by Red Hat guys?
                      600g is a bit of a special case in the sense that there was no new hardware info involved, but rather implementing a new driver using programming information which was already released and being used in the "classic" r600 driver, so it was not subject to the usual embargo issues related to new hardware info before launch.
                      Last edited by bridgman; 12-09-2011, 12:32 AM.

                      Comment


                      • #12
                        Gallim drivers development - code sharing

                        Hallo,
                        I just woul like to ask about gallium drivers development efficiency. The gallium is known to bring many advantages in much more efficient coding, compared to "classic" mesa drivers (avoiding code duplicity and so on, as usually claimed).

                        From the article it sounds to me, however, that the new driver, in fact, duplicates some amount of code from r600g. Could someone explain which parts of driver are "duplicated" from r600g (and why)?

                        Thank you very much for the explanation. Best regards
                        Dan T.

                        Comment


                        • #13
                          Originally posted by DanT View Post
                          Hallo,
                          I just woul like to ask about gallium drivers development efficiency. The gallium is known to bring many advantages in much more efficient coding, compared to "classic" mesa drivers (avoiding code duplicity and so on, as usually claimed).

                          From the article it sounds to me, however, that the new driver, in fact, duplicates some amount of code from r600g. Could someone explain which parts of driver are "duplicated" from r600g (and why)?

                          Thank you very much for the explanation. Best regards
                          Dan T.
                          I think you've misunderstood what gallium is, it isn't magic, it can't take a driver written for one set of hardware and make it work on a completely different hardware platform. Now all gallium drivers essentially share the same interface structure and framework and as such the fastest way to write one is to duplicate an existing one, remove stuff that doesn't apply and fill in the blanks.

                          gallium architecture avoids some duplicated code between drivers, not ever last possible single line of it.

                          Dave.

                          Comment


                          • #14
                            Originally posted by airlied View Post
                            I think you've misunderstood what gallium is, it isn't magic, it can't take a driver written for one set of hardware and make it work on a completely different hardware platform. Now all gallium drivers essentially share the same interface structure and framework and as such the fastest way to write one is to duplicate an existing one, remove stuff that doesn't apply and fill in the blanks.

                            gallium architecture avoids some duplicated code between drivers, not ever last possible single line of it.

                            Dave.
                            that only stands for the lower parts of the stack right??

                            i mean the state trackers are (or supposed to be) HW independent.

                            Comment


                            • #15
                              Originally posted by 89c51 View Post
                              that only stands for the lower parts of the stack right??

                              i mean the state trackers are (or supposed to be) HW independent.
                              They are in theory, in practice you still have to design them around an abstraction of hardware interfaces. You also have to test and prove each state tracker on each pipe driver, just because it builds doesn't in any way means its useful or runs.

                              Dave.

                              Comment

                              Working...
                              X