Announcement

Collapse
No announcement yet.

Radeon HD 7000 Series Will Bring New 3D Driver

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

  • #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; 09 December 2011, 01: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


            • #16
              Originally posted by Darkfire Fox View Post
              ...isn't that exactly what I said?

              (well, minus the VLIW5 part)
              Well actually you were right, there will be some VLIW5 parts too (Brazos 2.0).

              Comment


              • #17
                Originally posted by airlied View Post
                ... 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.
                The underlined part covers another important point -- the GCN architecture is different from current hardware but not *totally* different. For the parts of the hardware that don't change (or don't change much) it's a lot easier to start with working code for the previous generation than to write everything from scratch.
                Last edited by bridgman; 09 December 2011, 03:55 PM.

                Comment


                • #18
                  Originally posted by blackshard View Post
                  Well actually you were right, there will be some VLIW5 parts too (Brazos 2.0).
                  You mean the (not) new mobility parts?

                  Comment


                  • #19
                    Originally posted by Smask View Post
                    You mean the (not) new mobility parts?
                    I meant those installed in the low power APUs:

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

                    As far as I understand, radeon 7200 and 7300 are just a rebranding.

                    Comment


                    • #20
                      Originally posted by bridgman View Post
                      Multiple ring support was pushed out a month or two ago, while the memory mgmt and compiler code are getting fairly close...
                      ... and compiler code is now out (minus the GCN-specific bits, of course)

                      Comment

                      Working...
                      X