5 ms·

> the nonsense of Larrabee/making it out of x86 It only seems nonsense in retrospect. No one expected nVidia to improve flops/dollar in their GPUs that quickly

> the nonsense of Larrabee/making it out of x86 It only seems nonsense in retrospect. No one expected nVidia to improve flops/dollar in their GPUs that quickly. And Larrabee wasn’t the only architecture deprecated by GPGPUs, Cell Broadband Engine by Sony+Toshiba+IBM was another one.

pjmlp 2y ago
Cell required Assembly programming Demoscene skill level to make good use of them, there was a C sdk, but really you wanted to write Assembly, and relatively tricky Assembly at it. It is one of the reasons why Playstation 3 is the less celebrated one, and the console generation where XBox was able to pull ahead. Larrabee, I was at a GDCE 2009 session where it was demoed, and while the idea was promising, it didn't seem to actually pull off in practice, plus there was hardly much hardware where we could actually try it out ourselves. Xeon Phi didn't made it better regarding adoption, nor did AVX.
- kuschku 2y ago
  > Cell required Assembly programming Demoscene skill level to make good use of them, there was a C sdk, but really you wanted to write Assembly, and relatively tricky Assembly at it. > It is one of the reasons why Playstation 3 is the less celebrated one, and the console generation where XBox was able to pull ahead. In retrospect, Cell was a great architecture. In typical Sony fashion it was simply a few years too early. At the time games were single-threaded and many console games still expected CPU and GPU to be in sync. On the PS2, the difference between using the vector accelerator or not was 1.4x – many developers never bothered. But on the PS3 this was simply not an option, as the performance difference was 6x (!). The big issue at the time was dev tooling. Most existing engines had no support for dispatching jobs or any form of pipelining. Adding that required redesigning the engine from the ground up. On top of that the dispatcher/manager and the jobs use two different µarchs. Obviously, game and engine developers at the time hated cell with a passion.[1] But even on the PC and Xbox, frequency scaling ended with the Pentium 4. Multi-core CPUs became mainstream. As CPUs stalled, most of the performance increase on PCs came from GPUs, that had moved from a fixed-function pipeline to shaders. Slowly, even PC games had to do the bulk of their work in jobs dispatched across multiple cores. Engines that had adapted to Cell got a massive head start. Today, the very textbook for game development – "Game Engine Architecture", written by Jason Gregory – uses the architecture of the Uncharted games on PS3 as the prime example for how to build a modern engine. As result, nowadays even small indie games are built that way.[2] ________________________ 1. Gabe Newell: "Investing in the Cell, investing in the SPE gives you no long-term benefits. There's nothing there that you're going to apply to anything else" https://www.wired.com/2007/10/valves-gabe-new/ https://www.wired.com/2007/10/valves-gabe-new/ 2. e.g., Tiny Glade: https://www.youtube.com/watch?v=jusWW2pPnA0 https://www.youtube.com/watch?v=jusWW2pPnA0.
  - pjmlp 2y ago
    Yes, in that regard it was ahead of its time, and nowadays many game developers are exploring the possiblities to get rid of everything and explore pure compute for a full software rendering stack, running on GPGPU, agnostic from the actual rendering API. Although I think it would still be better to use specific shading languages as the hardware isn't the same architecture, thus there is only so much one can do with traditional languages without extensions, or GPGPU specific algorithms/data structures, but that is me as outsider with interest in the field. The experts seem to be enjoying exploring CUDA, SYCL, MSL, and similar for such purposes.
    - twoodfin 2y ago
      That sounds fascinating… any pointers here?
      - pjmlp 2y ago
        For example OTOY uses CUDA renderering. https://home.otoy.com/render/octane-render/ https://home.otoy.com/render/octane-render/ If you prefer actual code, https://advances.realtimerendering.com/s2015/aaltonenhaar_siggraph2015_combined_final_footer_220dpi.pdf https://advances.realtimerendering.com/s2015/aaltonenhaar_si... and "Mesh Shaders - The Future of Rendering" https://www.youtube.com/watch?v=3EMdMD1PsgY https://www.youtube.com/watch?v=3EMdMD1PsgY "GPU driven Rendering with Mesh Shaders in Alan Wake 2" https://www.youtube.com/watch?v=EtX7WnFhxtQ https://www.youtube.com/watch?v=EtX7WnFhxtQ
      - deleted 2y ago
        [deleted]
      - Const-me 2y ago
        About rendering triangle meshes with compute shaders, here’s a long technical video how UE5 does that: https://www.youtube.com/watch?v=TMorJX3Nj6U&t=3488s https://www.youtube.com/watch?v=TMorJX3Nj6U&t=3488s
- Const-me 2y ago
  > required Assembly programming Demoscene skill level to make good use of them Yeah, but writing efficient CUDA kernels, or D3D compute shaders, is not particularly straightforward either. At least GPU cores have direct access to global memory but still, for good throughput that memory access needs to be coalesced. Then there’re manually managed groupshared memory, atomics, wave/warp intrinsics in D3D12/CUDA, and now these special low-precision matrix multiplication instructions for AI. People accepted all that complexity because performance is too good to ignore, both flops/dollar and flops/watt. Contemporary mainstream GPUs were just better than SPEs on Cell, or AVX-512 on Xeon Phis. Specifically, PS3 (2006) delivered up to 200 GFlops FP32, first-generation Xeon Phi (incredibly expensive devices released in 2010) 750 GFlops, but GeForce 460 (released in 2010 for the price of $200) delivered up to 900 GFlops.
  - pjmlp 2y ago
    True, but it is much easier than Demoscene Assembly skill level.
    - touisteur 2y ago
      Same for AVX instrinsics. Very fun to use (for some of us), powerful when correctly used, but so hard to actually get right and to get the expected performance. I wish Intel had put more into ISPC back then.
- actionfromafar 2y ago
  Larrabee (or something similar) could have been an amazing real-time operating system target. Each little (Pentium!) core having truly its own local memory, no contention. But it was pitched as a GPU and the raw performance was not there. Intel sucks at software and should have leaned in to their strengths - documenting the hell out of the low level workings of Larrabee. Workloads tuned to it would have been a great moat.
- touisteur 2y ago
  Another way to see this is NVIDIA invested heavily, heavily in making a language and its compiler useable (for some level of useable.......) on enthusiast-affordable and poor-scrappy-researcher-affordable hardware on a complex weird-to-program-from-asm architecture and provided good-enough performance (and showcasing lots of very good optimizations) on standard HPC libraries and a bit of HW/SW co-design and kept at it for a long long time... with some level of backwards compatibility too. The recipe is here.

pjmlp 2y ago

Cell required Assembly programming Demoscene skill level to make good use of them, there was a C sdk, but really you wanted to write Assembly, and relatively tricky Assembly at it. It is one of the reasons why Playstation 3 is the less celebrated one, and the console generation where XBox was able to pull ahead. Larrabee, I was at a GDCE 2009 session where it was demoed, and while the idea was promising, it didn't seem to actually pull off in practice, plus there was hardly much hardware where we could actually try it out ourselves. Xeon Phi didn't made it better regarding adoption, nor did AVX.

kuschku 2y ago
> Cell required Assembly programming Demoscene skill level to make good use of them, there was a C sdk, but really you wanted to write Assembly, and relatively tricky Assembly at it. > It is one of the reasons why Playstation 3 is the less celebrated one, and the console generation where XBox was able to pull ahead. In retrospect, Cell was a great architecture. In typical Sony fashion it was simply a few years too early. At the time games were single-threaded and many console games still expected CPU and GPU to be in sync. On the PS2, the difference between using the vector accelerator or not was 1.4x – many developers never bothered. But on the PS3 this was simply not an option, as the performance difference was 6x (!). The big issue at the time was dev tooling. Most existing engines had no support for dispatching jobs or any form of pipelining. Adding that required redesigning the engine from the ground up. On top of that the dispatcher/manager and the jobs use two different µarchs. Obviously, game and engine developers at the time hated cell with a passion.[1] But even on the PC and Xbox, frequency scaling ended with the Pentium 4. Multi-core CPUs became mainstream. As CPUs stalled, most of the performance increase on PCs came from GPUs, that had moved from a fixed-function pipeline to shaders. Slowly, even PC games had to do the bulk of their work in jobs dispatched across multiple cores. Engines that had adapted to Cell got a massive head start. Today, the very textbook for game development – "Game Engine Architecture", written by Jason Gregory – uses the architecture of the Uncharted games on PS3 as the prime example for how to build a modern engine. As result, nowadays even small indie games are built that way.[2] ________________________ 1. Gabe Newell: "Investing in the Cell, investing in the SPE gives you no long-term benefits. There's nothing there that you're going to apply to anything else" https://www.wired.com/2007/10/valves-gabe-new/ https://www.wired.com/2007/10/valves-gabe-new/ 2. e.g., Tiny Glade: https://www.youtube.com/watch?v=jusWW2pPnA0 https://www.youtube.com/watch?v=jusWW2pPnA0.
- pjmlp 2y ago
  Yes, in that regard it was ahead of its time, and nowadays many game developers are exploring the possiblities to get rid of everything and explore pure compute for a full software rendering stack, running on GPGPU, agnostic from the actual rendering API. Although I think it would still be better to use specific shading languages as the hardware isn't the same architecture, thus there is only so much one can do with traditional languages without extensions, or GPGPU specific algorithms/data structures, but that is me as outsider with interest in the field. The experts seem to be enjoying exploring CUDA, SYCL, MSL, and similar for such purposes.
  - twoodfin 2y ago
    That sounds fascinating… any pointers here?
    - pjmlp 2y ago
      For example OTOY uses CUDA renderering. https://home.otoy.com/render/octane-render/ https://home.otoy.com/render/octane-render/ If you prefer actual code, https://advances.realtimerendering.com/s2015/aaltonenhaar_siggraph2015_combined_final_footer_220dpi.pdf https://advances.realtimerendering.com/s2015/aaltonenhaar_si... and "Mesh Shaders - The Future of Rendering" https://www.youtube.com/watch?v=3EMdMD1PsgY https://www.youtube.com/watch?v=3EMdMD1PsgY "GPU driven Rendering with Mesh Shaders in Alan Wake 2" https://www.youtube.com/watch?v=EtX7WnFhxtQ https://www.youtube.com/watch?v=EtX7WnFhxtQ
    - deleted 2y ago
      [deleted]
    - Const-me 2y ago
      About rendering triangle meshes with compute shaders, here’s a long technical video how UE5 does that: https://www.youtube.com/watch?v=TMorJX3Nj6U&t=3488s https://www.youtube.com/watch?v=TMorJX3Nj6U&t=3488s
Const-me 2y ago
> required Assembly programming Demoscene skill level to make good use of them Yeah, but writing efficient CUDA kernels, or D3D compute shaders, is not particularly straightforward either. At least GPU cores have direct access to global memory but still, for good throughput that memory access needs to be coalesced. Then there’re manually managed groupshared memory, atomics, wave/warp intrinsics in D3D12/CUDA, and now these special low-precision matrix multiplication instructions for AI. People accepted all that complexity because performance is too good to ignore, both flops/dollar and flops/watt. Contemporary mainstream GPUs were just better than SPEs on Cell, or AVX-512 on Xeon Phis. Specifically, PS3 (2006) delivered up to 200 GFlops FP32, first-generation Xeon Phi (incredibly expensive devices released in 2010) 750 GFlops, but GeForce 460 (released in 2010 for the price of $200) delivered up to 900 GFlops.
- pjmlp 2y ago
  True, but it is much easier than Demoscene Assembly skill level.
  - touisteur 2y ago
    Same for AVX instrinsics. Very fun to use (for some of us), powerful when correctly used, but so hard to actually get right and to get the expected performance. I wish Intel had put more into ISPC back then.
actionfromafar 2y ago
Larrabee (or something similar) could have been an amazing real-time operating system target. Each little (Pentium!) core having truly its own local memory, no contention. But it was pitched as a GPU and the raw performance was not there. Intel sucks at software and should have leaned in to their strengths - documenting the hell out of the low level workings of Larrabee. Workloads tuned to it would have been a great moat.
touisteur 2y ago
Another way to see this is NVIDIA invested heavily, heavily in making a language and its compiler useable (for some level of useable.......) on enthusiast-affordable and poor-scrappy-researcher-affordable hardware on a complex weird-to-program-from-asm architecture and provided good-enough performance (and showcasing lots of very good optimizations) on standard HPC libraries and a bit of HW/SW co-design and kept at it for a long long time... with some level of backwards compatibility too. The recipe is here.