Intel Xe-HP Graphics: Early Samples Offer 42 TFLOPs of FP32 Performance

Afaik AMD is buggy when passed to virtualized guest. nvidia also requires hacks to make it work. Intel is the only party where it's supported out of the box.

Edit: incorrect terminology

Using the 5700XT with amdgpu has been a complete shit show since day one, and you have success depending on your set-up since QA appears to be "if it works on a dev's machine ship it".

Mainline (let alone stable kernels) was almost unusable for like 4-5 months after release, you were completely out of luck unless you followed the right incantations and used a precise firmware binary that had been available at some point at an AMD developer's personal repo but you later had to get through someone else's Dropbox. After that period it got stable-ish for me. Occasionally Mesa/kernel updates made some games stop working or freeze the system but workarounds. Yesterday I swapped a monitor for a higher res one, and I triggered a bug where DPM essentially shits its pants and you have to switch to manual power management. Meaning a year after release the card can't handle basic multi-monitor stuff.

I've had AMD CPUs exclusively ever since Athlon II, always coupled with Nvidia cards. I wanted to support them also in GPUs given their open source work but for me it's been a complete mess. If Intel GPUs are actually any good and don't shit the bed I'll sell this card for whatever I can get.

Kind of, not if you are serious about GPGPU and not stuck with a laptop card.

However the 3D programming experience still beats Intel drivers.

AMD has revised its silicon (decoupled HDCP stuff from video encoder/decoder to be able to open source video hardware) to enable unencumbered open source drivers while nVidia obfuscates everything deeper and deeper.

It's a big disservice to compare them to nVidia about driver quality at this point.

Can confirm :)

I once bought a pci card with Intel Gigabit. Slashdot comments were very positive about this being the best card with the best drivers. Oh wow, just looking at the kernel dmesg was infuriating. Reset upon reset, where the NIC would just be unavailable for seconds. Even a major update (I don't know, 4x to 5x or something) did not even change anything.

Currently my laptop updated to linux kernel 5.7, where Xfce and Xfwm just break down and get stuck. Going back to 5.6 makes everything work. Nope, I don't trust Intel to make good Linux drivers. Will not buy again :( I never had this in 20 years of using AMD/ATI.

I agree. I'm running prop nVidia driving 4x 4k monitors under X11 and it. just. works. Nouveau driver crashes every few days.

Intel has freezes in Mesa. It is a known issue.

Same. I don’t really remember what it was like before the 4xx series but the proprietary driver has worked fine for me on Gentoo. Both for gaming and for passthrough for virtualized envs (although this is recent).

I ran into an amdgpu when I built my most recent desktop (the card would randomly lock up and turn its fans on full speed with some combination of OpenGL and power management.). I think it’s been fixed, though, I haven’t had any issues for several months now.

I have been running open source AMD drivers on my desktop since I got it (early 2018, Vega 64 GPU). They work well, and after so many years, it felt like a revelation to have problem-free high-performance 3D acceleration after a fresh installation of a default Linux kernel. The only place where AMD is still wonky is when you want to do GPGPU, but that is mostly down to AMDs byzantine and schizophrenic software strategy (just try to pin down which parts of ROCm you need, or what they do). You don't have to worry about that for graphics, though, as the amdgpu driver is in the kernel, and the default Mesa OpenGL works perfectly with it.

I've been running a rx480 for quite a while and the amdgpu drivers in the kernel are completely without problems (I've recently started gaming a bit again and fallout 4 runs on highest settings under proton without issues) . At some time I tried the pro drivers and performance actually degraded. I can second what somebody else posted, that doing gpugpu is a bit of a pain because it's difficult to figure out what to install. On the other hand Intel isn't really better there.

At work my workstation has a Radeon pro, with Kubuntu 18LTS. The most noticable thing is that the KDE taskbar freezes (interestingly enough, the taskbar is my biggest driver issue, as on Nvidia it will render as garbage, and the garbage changes when I scroll in Firefox. With nouveau, Xorg just crashed about 4x per week).

Switching to a text console and back clears up the issues for a few hours to a few days.

This is one of the reasons I really enjoy Pop. The GPU support is really at the top of the class for Linux, and it seems like System76 spends a lot of time making sure it stays that way.

I could care less about how it works with free-sync HDR gaming, &c. My laptop with 3 year old Intel Pro graphics is fast enough for everything I do on Linux, but my two workstations with an nvidia 1050Ti and A 3 year old Radeon Pro are both unusable for me.

If Intel made a 8+ core Xeon with built-in graphics for under $1000 I would buy it over a $300 Ryzen and a $200 discrete GPU just to have stable graphics on Linux because I'm experiencing $500 worth of pain in my graphics not working on a near daily basis.

It was fine when only 3d games could cause crashes, but now that firefox and KDE's window-manager all use hardware-acceleration it's just terrible. The binary drivers are definitely better than nouveau though for stability, except maybe for some older hardware.

Most issues fix themselves when I switch to a text console then back to X11, but every now and then I have to restart X11 to fix things.

You would have 600W in a single socket.

Mainly because what you're saying isn't true for many workloads? (Also this already works for most existing integrated GPUs.)

The types of workloads run on GPUs typically like very high memory bandwidth and are usually willing to live with higher memory latency to get it. Onboard GPU memory is usually built with this in mind (trade off capacity and latency for increases in bandwidth). This is generally speaking the opposite of what you want in a CPU where people often want very high memory capacity and lower latencies, but may not limited by memory bandwidth, so simply sticking a GPU on die and giving it access to a memory subsystem that was not designed to feed a GPU is not going to make anything better.

Besides the massive heat/power issues you would have, main memory like DDR4 is optimized for different characteristics than graphics memory like GDDR5 (mostly trade offs in latency vs bandwidth).

> I've heard that memory is a bottleneck for the GPU, specifically the time it takes to move stuff from RAM (main memory) to the GPU's RAM/memory. If it is such a big bottleneck, then why don't we (yet) see powerful GPU sharing the same die as the CPU and accessing/using/sharing RAM with the CPU (like integrated GPUs do)? Then there'd be a zero bottleneck. You would just give load whatever into RAM, and just give the (super-powerful integrated) GPU a pointer/address. Bam, done. Why hasn't this happened yet? / What am I missing/misunderstanding here?

That is not the only bottleneck involved.

Historically, GPUs have used GDDR ram as opposed to general purpose DDR memory. One of the key differences between GDDR and DDR is the bus width, which can be as large as 1024 bits, compared to conventional ram with a 64 bit bus width (although dual channel is effectively 128 bits). This much wider bus results in much higher memory bandwidth which is generally necessary to feed the truly enormous number of functional units in a GPU.

I suppose you could ask: why doesn't everyone just standardize on GDDR?

1. This would dramatically increase cache line size. I don't have data, but I assume this would generally be bad.

2. My recollection (but I don't have a source for this) is that DDR has lower latency than GDDR ram, so for branchy code (which CPUs often have to deal with, but GPUs typically never have to deal with), DDR could actually be faster.

3. DDR is cheaper to manufacture. Aside from being higher volume, a lower bus width just makes is simpler to manufacture.

GPUs can hide memory latency very well, because they are basically SMT on steroids. (Imagine instead of 2 threads per "core" you have 32-64 threads)

But they are starved of memory bandwidth! And the lower latency memory CPUs prefer is not the same as the high bandwidth memory that GPUs like.

Also there is different kind of caching. Modern APUs often have two ways to access memory. Over there own cache, or over the CPUs cache. So shared memory for CPU<->GPU gets the full advantage of a cache, but still it is a trade off.

If you want some work done by the GPU part of an APU, by sharing a pointer, you can do that today. But from the point of view of the CPU there is no prediction beyond the "GPU do X" commands. And a very high latency until the job is done. So you need a minimum GPU job size for it to make sense.

The intel Kaby Lake G processors are Radeon RX Vega M GL/GH paired on-die with an 8th gen core series processor over an internal PCIE 3 x8 link. Seems like they could do much better, but its the only such product I know of.

https://fuse.wikichip.org/news/1634/hot-chips-30-intel-kaby-...

It's more of a bandwidth problem. The arithmetic intensity of a non-HBM GPU is around 100, meaning the GPU can perform 100 FLOPs for every float load/store.

> What am I missing/misunderstanding here

Some (not all) GPU memory types are not cache coherent with the CPU. Some of the cache-coherent cases have poorer performance relative to the non-coherent memory from the perspective of the GPU's memory bandwidth and access latency.

That's one bottleneck, but you're missing another bottleneck entirely. In many problems, we load the entirety of the data into the GPU's RAM anyways (some games do so with the entirety of their assets during load times). It doesn't matter that the data is already in RAM, because we care about how much data can come from GDDR to registers (in GB/s). You have to get the data to your compute units. This is your memory bandwidth.

GDDR RAM wants to be accessed in bulk - large rows at once. Things are easy when each thread wants a subsequent byte, but if not things become much slower. Caching and other techniques can help mitigate this, and they're (imo) the place for a lot of creativity in architecture design. Having more potential FLOPS just means more ALUs.

What you're describing actually exists, it's called Heterogeneous Systems Architecture. https://en.wikipedia.org/wiki/Heterogeneous_System_Architect... It's nifty, but it's generally only used as a cost saving measure, not a performance one. It does, as you mention, broaden the scope of what is a useful target for GPU compute operations.

Memory bandwidth is typically the bottleneck in GPUs. Meanwhile, the access patterns are typically very predictable. So they're able to prefetch data, so latency is generally not a problem. So GPU memory is designed to have very high bandwidth, even if it means completely tanking the latency.

On the other hand, CPUs typically always need better memory latency, and most workloads do not saturate the memory bandwidth. Unlike in a GPU, many memory access patterns are unpredictable. The bottleneck of operations that are pointer heavy tends to be limited by latency. All tree operations and linked list iteration tend to be latency limited. Languages like C#, Java, Python and Javascript where all data lives behind a pointer tend to benefit significantly from improving latency. So while improvement memory bandwidth up to a point is important, there's much more attention given to latency.

Yes and it goes as far back as Saga Dreamcast. And the technique itself is now used in pretty much all of the current GPU from Nvidia to AMD and ARM.

Still a little pissed at how Apple handled IMG / PowerVR.

How was KNL too slow for HPC, like Cori? It does need to be the right sort of HPC that can use the SIMD and/or benefit from the memory bandwidth. Just the large core count (for the time and Intel) helps with MPI communication, keeping more of it local, or all of it for small enough jobs. However, we did have 64-core Bulldozers rather earlier.

Like Roadrunner, they have to deliver something but it doesn't have to be broadly applicable. I expect that Ponte Vecchio and OneAPI will never be used outside of Aurora.

Except they are building on top of SYCL, which is already late to the game, as CUDA does C++17 as well, and is polyglot, whereas One API is C++ only and hopes someone else will create bindings, Khronos style in not understanding how to widespread adoption.

I sat on Intel's Larrabee session at GDCE 2009, they were selling the world how Larrabee would wipe out the competition, without really understanding why everyone else was moving into GPGPU.

Apparently they still don't get it.

That'd place them at a slightly better position than AMD, that has been in the (discrete) GPU for years. All in all, this is still theoretical and we'll have to see how they behave under real workloads (be that games or compute).

Intels iGPUs have always looked great on paper and then hit a wall in the real world.

No, that would be rather good for Intel to have a card that competed well with the most popular cards that Nvidia offers, the 60 and 70 series.

And that’s with one “tile”. The presentation from Intel discussed 2 and 4 tile configurations.

Any estimate of the die size ?

Agreed. But just the thought that a petaflop could fit in a spare bedroom is pretty neat.

I thought intel said during architecture day that GPUs will be done on outside fabs (presumably tsmc or samsung).