5 ms·

This article says that AMD GPUs are vector in nature, but I think that stopped being the case with GCN; before that they had some weird vector stuff with 5 elem

This article says that AMD GPUs are vector in nature, but I think that stopped being the case with GCN; before that they had some weird vector stuff with 5 elements or something.

dragontamer 5y ago
Wrong. GPUs are definitely vector (GCN in particular being 64 x 32-bit wide vectors). What you're confusing is "Terascale" (aka: the 6xxx series from the 00s), which was VLIW _AND_ SIMD. Which was... a little bit too much going on and very difficult to optimize for. GCN made things way easier and more general purpose. Terascale was theoretically more GFLOPs than the first GCN processors (after all, VLIW unlocks a good amount of performance), but actually utilizing all those VLIW units per clock tick was a nightmare. Its hard enough to write good SIMD code as it is.
- Jasper_ 5y ago
  Eh, it's sort of a naming conflict. There were two dimensions of "vector" -- whether you used XMM-style registers, requiring the compiler to auto-vectorize different operations. The old vector ISAs had things like dot product instructions. Those things are now all gone, because it turns out it's hard to optimize. We in the industry call scalar-for-each-thread ISAs as "scalar ISAs" these days. For instance, Mali describes their transition from a vec4-for-each-thread-based ISA to a scalar-for-each-thread-based ISA as transitioning from "vector to scalar" [0]. [0] Compare 4:26 and 6:29 in the "Mali GPU Family" video on this page https://developer.arm.com/solutions/graphics-and-gaming/arm-mali-gpu-training https://developer.arm.com/solutions/graphics-and-gaming/arm-...
  - dragontamer 5y ago
    Connection Machine / Thinking Machines Corporation use of "scalar-like SIMD" was around in the late 1980s and early 1990s. Look up *Lisp, the parallel language that Thinking Machines Corporation used. You can still find *Lisp manuals today. https://en.wikipedia.org/wiki/*Lisp https://en.wikipedia.org/wiki/*Lisp Intel implemented SIMD using a technique they called SWAR: SIMD within a Register (aka: the 64-bit MMX registers), which eventually evolved into XMM (SSE), YMM (AVX), and ZMM (AVX512). Today's GPUs are programmed using the old 1980s style / Connection Machine *Lisp, which is clearly the source of inspiration for HLSL / GLSL / OpenCL / CUDA / etc. etc. Granted, today's GPUs are still SWAR (GCN's vGPR really is just a 64-wide x 32-bit register). We can see with languages like ispc (Intel's SPMD program compiler), that we can indeed implement a CUDA-like language on top of AVX / XMM registers.*
    - Jasper_ 5y ago
      I don't think any of it was based on *Lisp. Graphics mostly developed independently. And as such, we use different words and different terminology sometimes, like saying "scalar ISA" when we talk about designing ISAs that don't mandate cross-lane interaction in one thread. Sorry! As far as I know, the first paper covering using SIMD for graphics was Pixar's "Channel Processor", or Chap [0], in 1984. This later became one of the core implementation details of their REYES algorithm [1]. By 1989, they had their own RenderMan Shading Language [2], an improved version of Chap, and you can see the similarities from just the snippet at the start of the code. This is where Microsoft took major inspiration from when designing HLSL, and which NVIDIA then started to extend with their own Cg compiler. 3dlabs then copy/pasted this for GLSL. [0] http://www.cs.cmu.edu/afs/cs/academic/class/15869-f11/www/readings/levinthal84_chap.pdf http://www.cs.cmu.edu/afs/cs/academic/class/15869-f11/www/re... [1] https://graphics.pixar.com/library/Reyes/paper.pdf https://graphics.pixar.com/library/Reyes/paper.pdf [2] https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.210.5592&rep=rep1&type=pdf https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.21...
  - deleted 5y ago
    [deleted]
  - atq2119 5y ago
    The terms are definitely overloaded and can differ subtly between vendors. Those "scalar-for-each-thread" instructions are prefixed v_ on AMD's GCN. The "v" doesn't stand for "scalar" ;)
    - Jasper_ 5y ago
      Yeah, certainly having "V"GPRs in a "scalar ISA" is a bit off. In graphics parlance, the term really just refers to the lack of things like dot products and matrix multiply instructions where the compiler has to line numbers into "per-thread" vectors for the instructions to work out. Turns out you can save a lot of work by not having that kind of ISA, and just moving to ones where you operate on number registers (which are then "vector"'d to be thread-count wide). Wouldn't be graphics unless we overloaded a piece of terminology 20 times.

This article says that AMD GPUs are vector in nature, but I think that stopped being the case with GCN; before that they had some weird vector stuff with 5 elements or something.

dragontamer 5y ago

Wrong. GPUs are definitely vector (GCN in particular being 64 x 32-bit wide vectors). What you're confusing is "Terascale" (aka: the 6xxx series from the 00s), which was VLIW _AND_ SIMD. Which was... a little bit too much going on and very difficult to optimize for. GCN made things way easier and more general purpose. Terascale was theoretically more GFLOPs than the first GCN processors (after all, VLIW unlocks a good amount of performance), but actually utilizing all those VLIW units per clock tick was a nightmare. Its hard enough to write good SIMD code as it is.

Jasper_ 5y ago
Eh, it's sort of a naming conflict. There were two dimensions of "vector" -- whether you used XMM-style registers, requiring the compiler to auto-vectorize different operations. The old vector ISAs had things like dot product instructions. Those things are now all gone, because it turns out it's hard to optimize. We in the industry call scalar-for-each-thread ISAs as "scalar ISAs" these days. For instance, Mali describes their transition from a vec4-for-each-thread-based ISA to a scalar-for-each-thread-based ISA as transitioning from "vector to scalar" [0]. [0] Compare 4:26 and 6:29 in the "Mali GPU Family" video on this page https://developer.arm.com/solutions/graphics-and-gaming/arm-mali-gpu-training https://developer.arm.com/solutions/graphics-and-gaming/arm-...
- dragontamer 5y ago
  Connection Machine / Thinking Machines Corporation use of "scalar-like SIMD" was around in the late 1980s and early 1990s. Look up *Lisp, the parallel language that Thinking Machines Corporation used. You can still find *Lisp manuals today. https://en.wikipedia.org/wiki/*Lisp https://en.wikipedia.org/wiki/*Lisp Intel implemented SIMD using a technique they called SWAR: SIMD within a Register (aka: the 64-bit MMX registers), which eventually evolved into XMM (SSE), YMM (AVX), and ZMM (AVX512). Today's GPUs are programmed using the old 1980s style / Connection Machine *Lisp, which is clearly the source of inspiration for HLSL / GLSL / OpenCL / CUDA / etc. etc. Granted, today's GPUs are still SWAR (GCN's vGPR really is just a 64-wide x 32-bit register). We can see with languages like ispc (Intel's SPMD program compiler), that we can indeed implement a CUDA-like language on top of AVX / XMM registers.*
  - Jasper_ 5y ago
    I don't think any of it was based on *Lisp. Graphics mostly developed independently. And as such, we use different words and different terminology sometimes, like saying "scalar ISA" when we talk about designing ISAs that don't mandate cross-lane interaction in one thread. Sorry! As far as I know, the first paper covering using SIMD for graphics was Pixar's "Channel Processor", or Chap [0], in 1984. This later became one of the core implementation details of their REYES algorithm [1]. By 1989, they had their own RenderMan Shading Language [2], an improved version of Chap, and you can see the similarities from just the snippet at the start of the code. This is where Microsoft took major inspiration from when designing HLSL, and which NVIDIA then started to extend with their own Cg compiler. 3dlabs then copy/pasted this for GLSL. [0] http://www.cs.cmu.edu/afs/cs/academic/class/15869-f11/www/readings/levinthal84_chap.pdf http://www.cs.cmu.edu/afs/cs/academic/class/15869-f11/www/re... [1] https://graphics.pixar.com/library/Reyes/paper.pdf https://graphics.pixar.com/library/Reyes/paper.pdf [2] https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.210.5592&rep=rep1&type=pdf https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.21...
- deleted 5y ago
  [deleted]
- atq2119 5y ago
  The terms are definitely overloaded and can differ subtly between vendors. Those "scalar-for-each-thread" instructions are prefixed v_ on AMD's GCN. The "v" doesn't stand for "scalar" ;)
  - Jasper_ 5y ago
    Yeah, certainly having "V"GPRs in a "scalar ISA" is a bit off. In graphics parlance, the term really just refers to the lack of things like dot products and matrix multiply instructions where the compiler has to line numbers into "per-thread" vectors for the instructions to work out. Turns out you can save a lot of work by not having that kind of ISA, and just moving to ones where you operate on number registers (which are then "vector"'d to be thread-count wide). Wouldn't be graphics unless we overloaded a piece of terminology 20 times.