Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

Didnt stop AMD from disabling PCI Express Resizable BAR support, hidden behind AMD marketing wank "smart access memory (TM)" name, on older "chipsets" despite both memory and PCIE controllers being build INTO THE CPU ....

https://www.amd.com/en/technologies/smart-access-memory

Or that time x470 was going to support PCIE 4, but then it was made x570 exclusive



sort by: page size:

pcie resizable bar also works only on intel hardware despite being standard pcie feature available for ~5 years now (Zen 1).

This is interesting. I hope someone will do the same to re-add PCIe 4.0 support to AMD AM4 B450 chipset mainboards (it was available temporarily until AMD took it away again in later AGESA versions). Not a trivial hack i reckon.

Yes, but now that I look it up it's apparently a feature restricted to X370 and X470 boards. Doesn't really make sense to me considering the PCIe comes off the CPU.

Intel supported PCIE bifurcation it on desktop chipsets up to Sandy Bridge. Just like Intel once supported memory parity on desktop chipsets until deciding to use it to upsell server products.

Recent Intel chipsets were locked to Intel SSDs and only some magic hardware DRM handshake unlocked bifurcation https://www.asus.com/us/support/FAQ/1037507/ But apparently AMD competition forced their hand and at lest some got unlocked https://forum.level1techs.com/t/new-bios-update-unlocks-4x-p...

On AMD front there doesnt seem to be any problems, plenty of desktop boards with unlocked bifurcation BIOS menus.


Fixed large bar exists in some older accelerator cards like e.g. iirc the MI50/MI60 from AMD (the data center variant of the Radeon Vega VII, the first GPU with PCIe 4.0, also famous for dominating memory bandwidth until the RTX 40-series took that claim back. It had 16GB of HBM delivering 1TB/s memory bandwidth).

It's notably not compatible with some legacy boot processes and iirc also just 32bit kernels in general, so consumer cards had to wait for resizable BAR to get the benefits of large BAR (that being notably direct flat memory mapping of VRAM so CPUs and PCIe peers can directly read and write into all of VRAM, without dancing through a command interface with doorbell registers. AFAIK it allows a GPU to talk directly to NICs and NVMe drives by running the driver in GPU code (I'm not sure how/if they let you properly interact with doorbell registers, but polled io_uring as an ABI would be no problem (I wouldn't be surprised if some NIC firmware already allows offloading this).


Are you referring to pcie 4?

@Marcan shared some technical details around their PCI Express implementation recently here: https://social.treehouse.systems/@marcan/110494017883893557

It seems they didn't make any massive changes and instead just put switches on the existing PCI-E Lanes. That probably doesn't bode well for full GPU support :(


Unified memory doesn't stop you from implementing PCI, Apple did it on the Mac Pro.

The slides explicitly mentioned PCIe support. They just don’t make any M1 machines with standard slots yet.

The big surprise is the disabled PCIe 4 support. It makes sense in isolation, but since they plan on launching Zen2 ASAP with PCIe4 being one of its flagship features this would be very complementary. Doesn't the left hand of AMD talk to the right hand?

Wasn't the PCI version based on a different chip, and not fully compatible? I could be misremembering.

Agree with you, but a quick clarification: PCIe IOMMUs exist now, a PCIe device doesn't get DMA access to main memory.

Intel does the same, there is still a "north/south bridge" (AMD had on die memory controller since the Athlon 64 days IIRC) which adds "additional" (via a bridge, you aren't getting additional bandwidth unless you are using QPI with multiple CPU's) PCIE lanes and centralizes I/O in Intel's case it's the PCH. https://en.wikipedia.org/wiki/Platform_Controller_Hub

AMD will have something similar even if the CPU will control most of the PCIE lanes in the system (usually GPU + high speed storage is over the CPU, the rest of the IO is over the PCH).


I don't know what you specifically mean by a driver locking up PCI (and we've moved on to PCIe now), but I suspect the general category of (1) is largely addressed by the io virtualization facilities and RAS features that have recently come to amd64 hardware. That stuff has existed on big iron hardware since times immemorial.

PCIe does this in hardware

ULi got subsumed by nVidia shortly after PCI-Express became the norm.

They made a chipset which offered a fairly compatible AGP-like slot alongside PCI-e, and one with two full x16 slots when this otherwise required a very expensive nForce board. So of course, nVidia immediately blocked SLI support on it.


I think most (if not all) modern PCI-E GPUs still supports this. If I am not mistaken, this is what is preventing them from working on ARM right now (Raspberry PI 4, Apple M1, etc.), because the driver expect specific BIOS features

Either like the HAP bit, or less — only disabling its visibility to the OS on the PCIe bus.

There was some hope that someone would make a USB4 expansion card that didn't support PCIe tunneling, which wouldn't need those extra pins. If this card isn't it, then literally the only interesting thing about it is that it doesn't use an Intel controller. Which really is a negative.
next

Legal | privacy