Announcement

Collapse
No announcement yet.

Gallium3D OpenCL GSoC Near-Final Status Update

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

  • #46
    Originally posted by bridgman View Post
    One minor terminology point -- the AMD GPUs are all SIMD today (SIMD "this way" and VLIW "that way", eg a 16x5 or 16x4 array). In the future, they will still be SIMD, just not SIMD *and* VLIW.
    Any better readings on the topic. I though that they are all VLIW. Recently made jump from VLIW5 to VLIW4.
    Bridgman, you probably will want to empty your private message inbox

    Comment


    • #47
      Originally posted by Plombo View Post
      A more major point - all GPU shader architectures are SIMD.
      Maybe I am mistaken with the term SIMD. I read that there will be major redesign with HD8xxx. Let me check.
      There you go: http://www.anandtech.com/show/4455/a...ts-for-compute
      Last edited by Drago; 08-20-2011, 11:12 AM.

      Comment


      • #48
        Originally posted by Plombo View Post
        A more major point - all GPU shader architectures are SIMD.
        I wasn't sufficiently sure to say "all", but certainly "most" are.

        Drago, mailbox has room now, thanks. The "full" warning is now at the bottom of the page rather than the top

        Comment


        • #49
          QUOTE=Drago;224103]Maybe I am mistaken with the term SIMD. I read that there will be major redesign with HD8xxx. Let me check.
          There you go: http://www.anandtech.com/show/4455/a...ts-for-compute[/QUOTE]

          The wording in that article is a bit confusing in places -- they talk about going "from VLIW to non-VLIW SIMD" which can be interpreted in more than one way.

          Adding parentheses for clarity, most people would interpret the string as "(VLIW) to (non-VLIW SIMD)", implying that the SIMD-ness is new, although the correct interpretation is actually "(VLIW to non-VLIW) SIMD" ie still SIMD but with each SIMD made up of single-operation blocks rather than VLIW blocks.

          If you look at the diagrams you'll see references to "Cayman SIMDs" and "GCN SIMDs". Getting your head around the idea of a SIMD made up of VLIW blocks is hard, although once you've done that going away from it is easy
          Last edited by bridgman; 08-20-2011, 12:39 PM.

          Comment


          • #50
            Originally posted by bridgman View Post
            "from VLIW to non-VLIW SIMD" which can be interpreted in more than one way.
            why not call it VLIW+SIMD to RISC+VLIW or CISC+VLIW.

            the CISC can also only be a Firmware stuff and the firmware translate the CISC into RISC.

            modern cpus are also "Complex Instruction Set Computer" with an firmware translator to Reduced Instruction Set Computer or VLIW PLUS + SIMD SSE units.

            i think the r900 will be 1 RISC core instead of a VLIW core and 5 SIMD cores added to the RISC core and maybe an firmware layer to CISC to protect the internal chip logic.

            Comment


            • #51
              Originally posted by Qaridarium View Post
              why not call it VLIW+SIMD to RISC+VLIW or CISC+VLIW.
              That would be even more confusing, if such a thing is possible

              Seriously, GPU instructions have always been much closer to RISC than CISC, especially ATI/AMD GPUs. They're all single-clock, and there are relatively few instructions -- lots of opcodes but those are mostly subtle variants of the same basic function (eg 6.02*10^23 different compare operations).

              One could argue that VLIW RISC and CISC are both "complex" from a sufficiently abstract point of view but I don't think they are generally regarded as interchangeable. The transition really is from VLIW RISC to non-VLIW RISC.

              Originally posted by Qaridarium View Post
              i think the r900 will be 1 RISC core instead of a VLIW core and 5 SIMD cores added to the RISC core and maybe an firmware layer to CISC to protect the internal chip logic.
              The slides presented at AFDS talked about 1 scalar unit plus 4 SIMDs (sometimes called vector ALUs) per compute unit (CU) - see pdf for session 2620 at :

              http://developer.amd.com/afds/pages/sessions.aspx

              I think it's fair to say that the instruction sets for both scalar and vector units can be considered RISC, just like the instruction set for the VLIW core, but the RISC vs CISC topic is almost as dangerous and open to debate as religion or coding standards.

              The whole discussion is made more complicated because we used to talk about "vector operations" (eg the RGBA components of a pixel) being handled in a single vector instruction on 3xx-5xx GPUs or by using 4 of the VLIW slots on a 6xx-Cayman GPU. With GCN and beyond "vector" is being used the other way, referring to the 16 elements of the SIMD as a vector.

              That's why the SIMD aspect seems new -- VLIW was visible to the programmer while SIMD was not, so it got talked about the most. Now that VLIW is out of the picture SIMD is the most visible thing, and we have to talk about it because a CU contains SIMDs *and* a scalar engine, so the natural terminology is "vector" for the SIMDs and "scalar" for the... um... scalar engine.

              What we call a SIMD used to work on a 16x4 or 16x5 array of data, now it works on a 1D vector of data.

              But it's still RISC
              Last edited by bridgman; 08-20-2011, 01:43 PM.

              Comment


              • #52
                BTW if you use Rxxx terminology didn't we already ship R900 ?

                R6xx - HD2xxx, HD3xxx
                R7xx - HD4xxx
                R8xx - HD5xxx aka Evergreen
                R9xx - HD6xxx aka Northern Islands

                Now you get to guess about numbers as well as names

                Comment


                • #53
                  Originally posted by bridgman View Post
                  But it's still RISC
                  in easy words amd switch from VLIW+SIMD to an RISC+SIMD Design.

                  means bigger chip and more heat but easier to write drivers for it.

                  for opensource drivers this is a good news because of the lag of manpower..

                  Comment


                  • #54
                    Originally posted by bridgman View Post
                    BTW if you use Rxxx terminology didn't we already ship R900 ?

                    R6xx - HD2xxx, HD3xxx
                    R7xx - HD4xxx
                    R8xx - HD5xxx aka Evergreen
                    R9xx - HD6xxx aka Northern Islands

                    Now you get to guess about numbers as well as names

                    o yes bullshit bingo..... you can not name all hd6000 cards to 1 architecture because an hd6870 is an different architecture than hd6950...

                    the hd6950+HD6970 are the HD7000 architecture with and old production size 40nm

                    in my point of view all cards from hd2000 up hd4000 are 1 architecture
                    and all cards from hd5000 to the hd6870 are another architecture.
                    and the 6950-6970 are 1 architure themself.

                    why i think so? because there is no real different for the consumer .. directX10.1 is a joke no one use it no ohne need it and hd2000-hd4000 are broken by design for openCL and the old style amd compute stuff do not have marketshare no critical mass of market share and all cards are dx10.

                    then the dx11 cards with opencl support

                    and then the new hd7000 architecture.


                    from a consumer point of view it shows different than on an technical point of view.

                    example: how cares about the UVD unit on the hd2900 chip if the chip is broken by design ? and then amd need to support this stuff in shader?

                    but technicaly its the same UVD architecture than the hd3000 only with bugs.

                    another example is the OpenCL "nvidia style" cache buffers the hd4000 do have all the cache buffers but broken by design so only 1 of 2 can be used.

                    but for an consumer how cares?

                    but hey,, you are right there are no adequate numbers but the orginal ATI plan for R900 was an complete new architecture like the RISC+SIMD architecture "HD8000"

                    Comment


                    • #55
                      Originally posted by Qaridarium View Post
                      in easy words amd switch from VLIW+SIMD to an RISC+SIMD Design.

                      means bigger chip and more heat but easier to write drivers for it.

                      for opensource drivers this is a good news because of the lag of manpower..
                      Lack of manpower isn't entirely true. It's more a lack of money/funding. There are probably plenty of people who which to work (full time) on an open source project like this, as long as they get a decent salary.

                      Comment


                      • #56
                        Originally posted by Silverthorn View Post
                        Lack of manpower isn't entirely true. It's more a lack of money/funding. There are probably plenty of people who which to work (full time) on an open source project like this, as long as they get a decent salary.
                        for me its the same.
                        lag of manpower or lag of money to pay manpower.
                        its the same!
                        call it lag of POWER

                        the Humble Indie bundle shows Linux do not lag on money.

                        Linux only Lag on organization. its to much chaos.

                        we just need open-source fan-boy hardware to fund super ultra MAREK ...

                        i send 13,37 euro to Marek in the past !
                        everyone should do the same!
                        just search your personal hacker you like and send him 13,37euro.

                        Comment


                        • #57
                          Originally posted by Silverthorn View Post
                          Lack of manpower isn't entirely true. It's more a lack of money/funding. There are probably plenty of people who which to work (full time) on an open source project like this, as long as they get a decent salary.
                          lack of manpower usually refers to the current situation. ie small amount of payed devs + contributors


                          of course you cannot demand from anyone to work for free unless he wants to.

                          Comment


                          • #58
                            Originally posted by Qaridarium View Post
                            in easy words amd switch from VLIW+SIMD to an RISC+SIMD Design.
                            Yeah, I guess, but that implies RISC is new, which it isn't. Probably more clear to say VLIW + RISC + SIMD to RISC + SIMD, at which point RISC becomes redundant so you drop it out anyways.

                            Comment


                            • #59
                              Originally posted by Qaridarium View Post
                              means bigger chip and more heat but easier to write drivers for it.
                              Hmm... the easiest chip to write drivers for is the one that is already supported by the drivers we have. The new architecture is easier to write applications for, but on balance it's probably harder to write drivers for the new architecture than for the old one.

                              The new architecture does open up the possibility of using some new tools in the driver stack (ie ripping out what already works and putting something new and unfamiliar in its place then going through another few years of learning curve) but that doesn't align with any definition of "easy" I have ever used
                              Last edited by bridgman; 08-20-2011, 02:46 PM.

                              Comment


                              • #60
                                Originally posted by bridgman View Post
                                Hmm... the easiest chip to write drivers for is the one that is already supported by the drivers we have. The new architecture is easier to write applications for, but on balance it's probably harder to write drivers for the new architecture than for the old one.

                                The new architecture does open up the possibility of using some new tools in the driver stack (ie ripping out what already works and putting something new and unfamiliar in its place then going through another few years of learning curve) but that doesn't align with any definition of "easy" I have ever used
                                if you can answer this question with yes then it is easier : "would it be more complex and harder to learn of amd do the same new architecture with VLIW ?"

                                then its easy compared to an VLIW version.

                                Comment

                                Working...
                                X