Nothing stops anyone from using the APIs, I'm talking about a working implementation.
OpenGL is supported on pretty much all available platforms and has a standard implementation on them: Windows has opengl32.dll, Linux has Mesa3d, and Apple also has a default implementation.
I guess the point I'm trying to make here that an API is worthless without an implementation: the library containing the actual functionality. What are you loading if you don't have a IHV implementation available? Nothing. Just like OpenGL, OpenCL will need a default, software, implementation supported on all platforms.
And I can promise you that Microsoft will not be jumping on this OpenCL bandwagon (providing a platform default software implementation) with their development Direct3D Compute Shaders and the fact that Microsoft is no longer a Khronos partner. If they do in the next version of Windows I'll be very pleasantly surprised.
CPUs are infamously bad at processing floating point operations, this is the reason that dedicated GPUs were invented in the first place. A graphics processor like the GTX 285 has 240 stream processors that are manufactured for processing floating point numbers but really bad at integer operations. A CPU like a Core 2 Quad has four cores that are really good at integer operations but requires CPU extensions like SSE to do high performance floating point operations.
Both Intel and AMD are currently manufacturing CPU/GPU hybrids that would kind of balance both these worlds: Larrabee a GPU-like addon, AMD Fusion an on-chip solution. We'll see what kind of API hell they will bring.
IMO, the fundamental problem with OpenCL is the same as with OpenAL, which is that Operating System vendors don't provide a standard implementation as is done with OpenGL.
(Bus) speed isn't an issue as creating a CPU or GPU context requires a specific creation flag, so one would know what the target platform is.
fortune: No such file or directory