AMD EPYC Rome 2P Will Have 128-160 PCIe Gen4 Lanes and a Bonus

High performance networking on the whole, of which HPC GPU solutions are only one use case. And there's the continuing trend of sticking offload engines in the form of ARM ASICs alongside devices that connect over PCIe.

A bit farther into the future: https://genzconsortium.org The idea of everything being connected by a shared high speed fabric enables ideas like shared memory pools across a fabric for 'composable' configurations. https://drivescale.com/software-composable-infrastructure/

Not an expert, but at least on the gaming side of GPUs my understanding is that you usually aren't using the bandwidth much. For rendering your average frame, all the data you need is already in VRAM.

But if there's new model or textures that aren't yet on the GPU, you want to move them over quickly because the next frame needs to go out ASAP. For a game running at 60hz you've got 16ms to avoid a frame delay. At 144hz you have 7ms. So it can be helpful to be able to dump stuff to VRAM very quickly, which the GPU can grab from system memory via DMA at very high speeds.

For most model/texture loading you know an object is coming into the scene and would have put it on the GPU ahead of time, so this a sort of worst case scenario shouldn't really come up unless you have a huge number of possible things that could spawn in and you don't know which until the last minute. Pretty unlikely.

For the biggest transfers, like loading in an entire level worth of assets, you can hide it with loading screens, or load low resolution textures to start with and stream in the high resolution versions to catch up. Having more PCIe bandwidth will help speed that up if it's in system RAM, but if you're loading it all from disk that's going to be your limiting factor.

I saw some benchmarks years ago where running a high end GPU at x8 or even x4 had pretty minimal impact. With high res textures coming in for 4K now I'd be curious to see someone run that again.

Realistically, I don't think gamers should care about it beyond the spec one-upmanship. HPC would get a lot more use out of it. Maybe also a shift toward fast PCIe based storage solutions like Intel's Optane?

It is not just about throughput, it is about the flexibility of how you can use the lanes.

Working with desktop computers I've often been frustrated by the limitations of PCIe lanes on Intel processors which are exacerbated by limitations of the motherboards. Frequently I find that "I can't get from here to there" when I am adding cards because the machine has an i5 processor or that particular motherboard, or... Often I can turn off some features on the motherboard i don't need to free up some lanes or shuffle the cards around, but it reminds me of the bad old days when I had to set jumpers for the interrupts on all the cards.

There are numerous holes in the hardware industry that have been caused by Intel's stinginess on I/O. You don't feel the pain on laptops or the tablets and cell phones that Intel had vainglorious ambitions for, but it's been one less reason for people to build machines for which Intel could wipe the floor of their competitors.

It's also been a big aid to IBM's Power architecture because one of the few things keeping that alive is better I/O.

A good target is storage, ie a lot of NVMe drives.

Nvme and 8k displays?

Virtualization does, most virtualization platforms require dedicated lanes for each VM and devices assigned to the VM for dedicated situations.

NVMeOF (NVMe Over Fabrics) comes to mind, having multiple NVMe drives (mostly PCIe x4) + networking (100GbE uses x16 PCIe) consumes a lot of PCIe lanes.

Also note that current two-socket AMD Epyc servers use 64 lanes from each CPU for inter-CPU communication, so the entire server has only 128 lanes (out of 256) left for peripherals.

This will give us servers for deep learning that can have 8 GPUs and a couple of NVMe disks on PCI 4.0 (32 GB/s). With very good inter-GPU I/O and access to NVMe, it will enable commodity servers that are competitive with Nvidia's DGX-1 or DGX2, that include SXM2 (Nvlink with 80GB/s between GPUs).

The 16x links will usually get split out to 4x nvme slots, and that's where you're going to get limited by the PCIe bandwidth.

GPU training of ML/DL models is bottlenecked in bizarre locations. Generally when doing distributed training on multiple GPUs with a large dataset you move all at once enough data to fill the GPU RAM during training and let it crunch for a little while, then push the next batch in. People have come up with workarounds like doing multiple training passes over each batch of data, but ideally you would not do that and would refresh the whole 12/16GB of training data on each pass. If you have enough RAM on the board to keep the whole training dataset in memory (likely) then you can easily find that the bottleneck in your system is bandwidth to the GPU. People like to be able to train with a large number of GPUs in parallel, but they really don't like cutting down to 8x PCIe lanes/GPU.

Off the top of my head this would be great for massive enterprise VDI installations and game streaming services (which is just VDI by another name), ML, AI applications, and NVMe storage.

Personally, this will be good for me because everything I do is bandwidth-starved.

I'm not a radar scientist but I am a systems engineer supporting radar scientists working on air- and space-based Synthetic Aperture Radar (SAR) systems. We use GPUs, FPGAs, and other accelerators to generate images from SAR data.

Here's an "old and busted" image made from SAR data: https://hackadaycom.files.wordpress.com/2014/02/image-from-s...

In 2002, it took more than 24 hours to generate a single low-resolution picture from low-bandwidth SAR data on a $1.5 million Sunfire 15K cluster with 70-ish SPARC CPUs. Today, on a single 3U server with two Xeons and four Tesla V100s it takes about 15 seconds-- and that's an extremely high resolution image from very high data rate SAR data.

But our goal is real-time VIDEO from SAR data, so everything needs to be faster. Network speeds need to be faster, CPUs need to be faster, GPUs need to be faster and we need more of them, storage needs to be faster, everything needs to be faster.

I could see a 3/4U box with 16+ 16x PCIe slots each stuffed with a 1-slot GPU with an NVMe (4x PCIe lanes each!) storage array and a couple of 100GBe dual-port NICs blasting through SAR data like a hungry hungry hippo.

As far as PCIe lanes go, if I have a 24-drive NVMe array that's 96 PCIe lanes all by itself.

Virtualization.

Remember that these EPYC systems will have up to 64 cores per chip. 128 cores / 256 threads per 2P platform, with 128x to 160x PCIe 4.0 lanes depending on the motherboard.

Lets say you split up your system into 32 VMs (4-cores / 8-threads per VM). That's only 4x to 6x PCIe 4.0 lanes per VM. Doesn't seem very spacious anymore, does it? That's barely enough room for a NVMe drive per VM + a small, shared chunk of graphics (modern enterprise GPUs can be virtualized and split between VMs. So one x16 link to a beefy GPU can be shared between 8 VMs)

If your current customer is using NVMe drives + thick-client workstations for docker / testing / etc. etc, it may be difficult to convince them to switch to a virtualized infrastructure. But a beefy machine with this much I/O would definitely catch their eyes.

Dual port 100 and 200 Gbit/s network adapters.

HPC as you mentioned, but also 200Gbps NICs need it, and those are available today.

Here is the easy example:

A dual 100GbE NIC requires a PCIe Gen4 x16 slot to run both ports at full speed. Mellanox ConnectX-6 200GbE cards require either 2x Gen4 or 1x Gen5 slot for full dual port bandwidth. Most of the larger NVMEoF nodes we are seeing are using more than one 100GbE NIC.

Enterprise SSDs will rapidly fill Gen4 x4 lanes later this year as we start to see them launch alongside more mainstream platforms. Four of those will fill a x16 slot.

GPUs and PCIe switches are also great examples of uses.

You are right that for the high-volume server segment, 160 PCIe lanes are overkill, as is even 128 today frankly. For some context, there is a huge portion of servers sold with less than 1 DIMM per RAM channel installed.

How about 30-40 7GB/s NVMe devices.

Deep learning training, especially distributed training solutions can utilize greater pcie bandwidth.

What about a bunch of NVMe drives?

Likely is there because it requires that AMD's partners release servers in this configuration, and those servers are unreleased. In theory, something during validation could prevent it or partners could decide not to release this configuration (which are unlikely but still possible.)

They claim to have confirmed this with AMD partners. So it's more than just speculation.

From the article, "Over the past few weeks, we have managed to confirm with a number of AMD’s ecosystem partners that our theory is not only valid, but it is indeed what we will see." Essentially, there is significant evidence that supports their hypothesis. This is far more than mere speculation and I see no reason to assume they have fabricated (hehe) this story.

Yeah:

> I did give AMD the heads-up that it would be going live just after the Cascade Lake launch. They did not sanction this article (indeed, they will not be overly excited to see it is live.)

That seems to justify some doubts.

PCIe 4.0 support has got to cost some die area/power, and not many PCI devices will support it at first. That might point towards starting with a mix of 3.0 and 4.0 lanes.

If they did upgrade all lanes, and some devices show up, could be cool for some bandwidth-hungry GPU and/or HPC-networking use cases. Or for servers that wanted to load up on any kind of compatible device (SSDs, whatever): you can fit more 4.0 x4 than 3.0 x8 anythings in a given number of lanes.

Still think we'll have to wait a gen, though.

AMD's been adding more PCIe lanes across their hardware lineup than Intel has to be sure, but EPYC is server-class stuff with 64 cores to a chip. The Ryzen 2 2700X only has 20 lanes for 8 cores.

Intel just dropped a bunch of details about the actual competitor to EPYC, Cascade Lake AP. These server chips will have 48 PCI-E 3.0 lanes, still not anywhere near the EPYC's claimed amount, but definitely better than what they are selling to the niche high-end gamers.

A big part of Intel's pricing structure was around number of PCIE lanes.

They had the monopoly for a long time, so they turned into a money-making machine first and a chip company a distant 4th or 3rd.