Page 6 of 8 FirstFirst ... 45678 LastLast
Results 51 to 60 of 72

Thread: Gallium3D OpenCL GSoC Near-Final Status Update

  1. #51
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,386

    Default

    Quote 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.

    Quote 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 at 01:43 PM.

  2. #52
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,386

    Default

    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

  3. #53
    Join Date
    Nov 2008
    Location
    Germany
    Posts
    5,411

    Default

    Quote 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..

  4. #54
    Join Date
    Nov 2008
    Location
    Germany
    Posts
    5,411

    Default

    Quote 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"

  5. #55
    Join Date
    Aug 2009
    Posts
    152

    Default

    Quote 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.

  6. #56
    Join Date
    Nov 2008
    Location
    Germany
    Posts
    5,411

    Default

    Quote 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.

  7. #57
    Join Date
    Jan 2009
    Posts
    1,603

    Default

    Quote 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.

  8. #58
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,386

    Default

    Quote 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.

  9. #59
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,386

    Default

    Quote 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 at 02:46 PM.

  10. #60
    Join Date
    Nov 2008
    Location
    Germany
    Posts
    5,411

    Default

    Quote 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.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •