AMD's HSA is intended to enable memory sharing between the CPU and GPU.

If you look at Skylake-SP architecture vs. recent GPUs, the chip design at first glance doesn't seem so different anymore between these two, CPUs are just much less focused, which pays a 2x price in theoretical performance for the same die space, even using Intel's superior process technology. Now that being said, I think the GPU/SIMT model of vector computing is just much smarter. Why let me jump through all these hoops of masking and compiler optimizations if all I want is a branch and an early exit for a specific set of values? GPU schedulers and drivers make this easy to use and with somewhat predictable performance results. Furthermore (and probably more importantly), why is Intel putting this amount of compute power on a CPU without significantly upgrading memory bandwidth? A 28 core Skylake-SP using full vectorization now has 3x (!) the FLOP/Byte system balance compared to NVIDIA P100. Seriously? System balance was once an argument against GPUs, but not anymore apparently...

Fun fact: AVX-512 came from the design that is now known as Xeon Phi.

You can read Tom Forsyth's story on it on his ask.fm (https://ask.fm/tom_forsyth)

I paste it here because I couldn't figure out how to link to the ask.fm post:

"Q: How did you get involved in the development of Larrabee, and what concepts do you have to know to do such a thing? by Foo Bar

8 months ago

A: It was a rather convoluted process! * Michael Abrash and Mike Sartain at Rad Game Tools were working with Intel to make a new processor called Simple, Massive Array of Cores (SMAC) * I was also at Rad Game Tools working on Granny3D and was asked to be the DirectX expert, since I knew the details of the API very well. * As well as doing general coding on the whole software rendering stack, I helped capture a bunch of shader workloads from existing games, and then wrote a compiler for the SSE-based instruction set SMAC used at the time to prove it would be efficient at running these shaders. * It wasn't. * The compiler helped us add instructions to SSE to make it more efficient. * It still kinda sucked. * We threw SSE away and started again with a new vector instruction set we called "SMAC New Instructions" (SMACNI). Didn't really know what it had to be, except "not SSE". * All of us contributed ideas to the new instruction set, and then I'd make the compiler understand each idea, and we'd see how well it worked on these real shader workloads. * Feature by feature we created SMACNI, and bit by bit I became more of an instruction architect, less of a software coder. I learned a ton about hardware on the way, mainly by asking real architects stupid questions and trying to understand their answers. Hardware is nothing at all like software people imagine it is. * At some point, SMAC was given an official codename "Larrabee", SMACNI became Larrabee New Instructions (LRBNI), and I stopped working for Rad being a contractor for Intel, and instead became a full time Intel hardware architect - although I still sat at the same desk doing the same job with the same people. * We made Larrabee 1, aka Knights Ferry, and I started work on the next version of the instruction set and architecture. * We made Larrabee 2, aka Knights Corner, aka the first Xeon Phi. All exactly the same bit of silicon, just running slightly different software. * At this point there was a big push to make the next chip, Knights Landing, run all the existing MMX, SSE and AVX code (KNF and KNC didn't run any of those, it was just x86-64 and LRBNI), and conversely to push LRBNI onto the mainstream Intel cores. So I worked with all the rest of the architects at Intel in a massive board for a couple of years to hammer out how to merge these two instruction sets and encodings. The result was AVX512. * Those meetings were exhausting frustrating work and moved so agonizingly slowly, that once it was completed, it didn't take much persuading from Michael Abrash to go to Valve and work on virtual reality with him instead. * AVX512 has now shipped inside Knights Landing (the latest Xeon Phi chip), and inside the Skylake Xeon cores. Hopefully we'll see it in the mainstream desktop cores shortly. It's pretty cool seeing an instruction set I designed shipping in so many high-profile cores. "

I don't want to overstate it; I've written a lot of SIMD in my life too. If you've got audio processing that needs to run in a realtime thread, I can see how SIMD is appealing, because we don't really have mechanisms to achieve realtime on GPU (yet). However, for a lot of seriously heavy computation, it seems like doing it on the GPU is a win. For the cases where memory transfer back and forth to the GPU is expensive, even integrated GPU should offer significantly more computational resources than even AVX-512.

One of the use cases I'm thinking of is font rendering, where I published a SIMD-heavy prototype a couple years ago, and it's blown out of the water by a newer GPU-based approach: http://pcwalton.github.io/blog/2017/02/14/pathfinder/

Have you looked at RISC-V Vector proposal yet? Same person who did AVX-512 for Intel.

What models don't slow down? Are you claiming the slowdown isn't actually necessary to keep the chip stable?