The software ecosystem is very interesting - I'd like to hear more about the CUDA to One conversion kit. ROCm had a similar tool with 90% support, but that last 10% on every program killed the margin difference we'd get from AMD. If they're actually able to keep it up-to-date, they might be able to unseat Nvidia in the workstation compute space, at least a bit.
Is it actually comparable to new Nvidia or AMD offerings? I have a feeling that Intel wastes environment by polluting the earth with sub par products lately. They need to release something remarkably better than the competition or it is likely game over.
Yes, Xe for laptops is comparable with AMD's Ryzen 4xxx for laptops and Nvidia's MX350 for laptops (in particular, replacing a discrete MX350 with a Xe IGP reduces the number of chips needed). The MX450 tends to be faster but you can't win them all.
The high-performance gaming variant (Xe-HPG) has not been released so we don't know if it's any good.
It's different. Xe LP, which exists right now in integrated and discrete forms, is comparable to low-end discrete GPUs from Nvidia and AMD and AMD's APUs. The most distinctive feature of the Xe LP variant is the emphasis on video encoding hardware.
The real question, though, is what sort of performance Xe HP/HPG/HPC will bring when they're released. They don't need to significantly outperform the competition (AMD has more than demonstrated in the past that superior GPU performance alone is not enough), they just need to be close enough with a good enough software story. Cuda and Nvidia's driver stack are both reasonably nice and a pain in the ass to work with, so if Intel can (1) competently support major ML frameworks, (2) reasonably support porting from Cuda, and (3) maintain a competent OpenCL implementation that could be enough to be competitive. They'll likely eat market share from AMD first, since the AMD software stack has more rough edges.
I will take any discrete GPU that works stably on Linux and is 75W peak draw or under. I hear good things about the newer AMD lineup with the open-source AMD drivers, but even the most low-end of those all take an external power-connector, which puts them over 75W of peak draw.
Hopefully there's some way to get it when it's released
According to videocardbenchmark.net Intel Xe graphics are about 20% faster than the GT1030, that currently leads in the world of single slot low power GPUs
I have a 1050Ti and there is no combination of graphics drivers and KDE compositor settings that will let me browse the web stably with firefox and webrender.
I don't care if it's 20% slower than the GT1030 if I can browse the web in firefox under KDE with default settings! Since I replace my graphics card less often than I replace my CPU, I would pay a premium for such a device.
I want it for that same reason, but with another bit which isn't known yet (I think). If the discrete card supports gvt-g then it'll be the cheapest and easiest way to share full hardware acceleration of a gpu in a vm with a single card. This then also still lets the host use the gpu at the same time. All the offerings from amd and nvidia cost a lot and nvidias even require special licensing.
If I could get an Intel NUC-like device that could run Windows games at the level of a Snapdragon 835, and get it under $500, I'd be pretty happy right now. I'd be able to tell Facebook that their enterprise Oculus licensing can go stuff itself and buy Windows MR headsets and these dream NUCs and be happy in life again.
If the world moves on to ARM from x86, it will be interesting to see what happens in the GPU/Accelerated computing space. I'm guessing AMD/Intel will probably not support an ARM pairing anytime soon.
Jim Keller apparently not only worked on Ryzen but also on an arm CPU named K12 [1] until 2015. It is likely that AMD still has the blueprint for that CPU stashed away to focus on the x86 market but still have a plan b if arm becomes dominant.
AMD processors already have an ARM trustzone core. I think the official policy is use whatever hardware is suitable for the purposes and sometimes embedded ARM is the correct choice.
If they don't support ARM servers, they are done for in some cloud/supercomputer markets. Hence they will support it.
In principle, graphics is different - they have to do graphics development given their need for integrated graphics, and they have an established (if quite rocky) history of highly parallel HPC accelerators/processors.
Cell modem development was always something of an odd fit for Intel - it came in from an acquisition, and due to the complexities of patents and Qualcomm's domination of the modem market they only had one major customer (Apple) who used them primarily as legal leverage. Once that customer went away, it became unsustainable given the high R&D costs combined with questionable demand for discrete modems.
Intel's flirtation with low-end embedded devices makes sense on the basis that they already were using low-power Pentium-derived cores as embedded controllers, so why not offer them as standalone products. I think they clearly underestimated the costs of packaging and support for external customers, as well as the dominance ARM's Cortex-M series would establish.
They did also used to actually make ARM processors. Originally they acquired StrongARM from Digital, and then went on to replace the brand with their own XScale, and found some pretty good success in embedded systems and were at one point near-universal in PDAs and high-end mobiles (a huge customer at the time was RIM who put them in all of their Blackberries at one point). They sold that off though and it fell behind, but they actually still hold DEC's ARM license.
So they did have some prior experience in that space, but that experience was built on the shoulders of what Digital was doing.
I don't think it was a lack of experience with what ARM designs could do. If I were to guess, their hope was that a nominally-familiar architecture would make porting easier for customers interested in building low-end embedded + server/cloud products from the same codebase; i.e. both your embedded client devices and servers would use the same libraries IPC/encryption/etc (same idea that node lets you reuse code between client and server).
Of course the stumbling block there is that the Cortex-M family (rather than 8051, AVR, and PIC generations before) was already designed around good C/C++ support, and the server->embedded code reuse jump is bigger than the work involved in switching architectures. And, of course, the Cortex-M vendors already had lots of experience producing all the microcontroller variants with the particular peripherals their customers want, which is just as, if not more important than the architecture.
Certainly, I wasn't trying to suggest that, and was more just raising the point that they did once have a competitive embedded line, but sold it and then came back to the market down the road with a much weaker approach.
It's an ISA licence, so they're allowed to design their own processors that implement ARM, but they would have to design them themselves (which is why they haven't)
Actually, through their Altera acquisition, they must have design licenses for a number of recent Cortex-A variants as well, since a number of their FPGAs have ARM cores.
29 comments
[ 4.9 ms ] story [ 51.3 ms ] threadAnd how is even pronounced in different languages? 'He' in Greek?
The high-performance gaming variant (Xe-HPG) has not been released so we don't know if it's any good.
The real question, though, is what sort of performance Xe HP/HPG/HPC will bring when they're released. They don't need to significantly outperform the competition (AMD has more than demonstrated in the past that superior GPU performance alone is not enough), they just need to be close enough with a good enough software story. Cuda and Nvidia's driver stack are both reasonably nice and a pain in the ass to work with, so if Intel can (1) competently support major ML frameworks, (2) reasonably support porting from Cuda, and (3) maintain a competent OpenCL implementation that could be enough to be competitive. They'll likely eat market share from AMD first, since the AMD software stack has more rough edges.
Hopefully there's some way to get it when it's released
According to videocardbenchmark.net Intel Xe graphics are about 20% faster than the GT1030, that currently leads in the world of single slot low power GPUs
I don't care if it's 20% slower than the GT1030 if I can browse the web in firefox under KDE with default settings! Since I replace my graphics card less often than I replace my CPU, I would pay a premium for such a device.
Edit: just saw you said discrete. Oops.
[1] https://en.wikipedia.org/wiki/AMD_K12
If they don't support ARM servers, they are done for in some cloud/supercomputer markets. Hence they will support it.
After bailing on the embedded/microcontroller stuff and then their cell radio products, it makes me wonder if this is the flavor of the month.
Are they on the slope down to become a company more like IBM or HP which are primarily financial engineering enterprises.
Cell modem development was always something of an odd fit for Intel - it came in from an acquisition, and due to the complexities of patents and Qualcomm's domination of the modem market they only had one major customer (Apple) who used them primarily as legal leverage. Once that customer went away, it became unsustainable given the high R&D costs combined with questionable demand for discrete modems.
Intel's flirtation with low-end embedded devices makes sense on the basis that they already were using low-power Pentium-derived cores as embedded controllers, so why not offer them as standalone products. I think they clearly underestimated the costs of packaging and support for external customers, as well as the dominance ARM's Cortex-M series would establish.
So they did have some prior experience in that space, but that experience was built on the shoulders of what Digital was doing.
Of course the stumbling block there is that the Cortex-M family (rather than 8051, AVR, and PIC generations before) was already designed around good C/C++ support, and the server->embedded code reuse jump is bigger than the work involved in switching architectures. And, of course, the Cortex-M vendors already had lots of experience producing all the microcontroller variants with the particular peripherals their customers want, which is just as, if not more important than the architecture.
Does that give them modern ARM processors or just the ones of the time?