- Nov 14, 2011
- 9,155
- 2,377
- 136

Intel Starts to Close Omni-Path: OPA1 Xeon CPUs on EOL, OPA2 Axed
Phi is dead, Omnipath is dead. Intel's HPC visions have changed drastically in the last few years!
It's not like either of those were any good.Intel's HPC visions have changed drastically in the last few years!
They must be banking heavily on Xe by this point.Phi is dead, Omnipath is dead. Intel's HPC visions have changed drastically in the last few years!
Yeaaaah... Good luck with that. I can't see a new GPU competitor unseating CUDA at this point. AMD have had to basically give up and make a CUDA compatibility layer.They must be banking heavily on Xe by this point.
I would expect Intel to do the same. Either that or they can fork OpenCL and update it (or do both after a fashion).AMD have had to basically give up and make a CUDA compatibility layer.
Nah, they're leaning heavily on OCL and SYCL.I would expect Intel to do the same
I repeat... good luck with that one.Nah, they're leaning heavily on OCL and SYCL.
Intel has enough manpower to wrestle absolutely anything or anyone in sw.I repeat... good luck with that one.
For that to work though, Xe would have to be pretty competitive hardware wise.Intel has enough manpower to wrestle absolutely anything or anyone in sw.
True that, but the point still stands.For that to work though, Xe would have to be pretty competitive hardware wise.
That's not the issue. Getting customers to then use (and ideally actively ask for) it is the problem.Intel *can* make good sw.
Even if they do how exactly is it even a good idea to lean on OCL/SYCL for a compute stack ?Intel has enough manpower to wrestle absolutely anything or anyone in sw.
Portability is king now.Even if they do how exactly is it even a good idea to lean on OCL/SYCL for a compute stack ?
Why would they subject themselves to the torture of less powerful higher level APIs like OCL/SYCL in comparison to higher performing lower level APIs such as CUDA or HIP ? Intel is already going to be losing some performance on the table in the HPC space because they now have to deal with overhead due to the mismatch between SPIR-V kernels and their native hardware ...
Also by introducing an intermediate representations like SPIR-V, Intel risks making things far harder with potentially dealing SPIR-V compiler bugs ...
If this is their 'vision' for GPU compute then they'll soon figure out just how hard it truly is for industry to adopt standards like AMD has in the past with trying to push OpenCL and that ended up in failure ...
If only this were true ...Portability is king now.
End of the story.