Historically, the design of GPUs are essentially about having extremely high data-parallelism of relatively tiny, simple codes (shaders) that all operate on the same massive data unit but have very little communication. The tradeoffs that get involved in making this code means that GPUs are effective at speeding up only certain kinds of computations. Workloads that are memory-latency bound or communication heavy--such as a BFS graph traversal--turn out to be utter crap on GPUs, and you can only claw back some of that performance with epic engineering effort.
Larrabee and its successor Xeon Phi concepts were actually fairly well-received in terms of giving you something that could tackle non-GPU-amenable problems. What caused Larrabee to suffer was that Intel basically tried to flog a "just write C/C++/Fortran and the autovectorizer will take care of everything" model for programming which, well, didn't work (as many compiler people could have predicted for you before you started). Nvidia also made sure to do a massive push to get CUDA working in terms of library support, educational cooperation, and language flogging to get people interested into CUDA, which Intel didn't attempt for Xeon Phi.
This reminds me of the story of ispc [1] One guy wrote a compiler based on SPMD while the rest of the company was focused on the doomed auto vectorization.