Is Resizable Bar or SAM Available with AMD EPYC 7002 or Newer?

Intel’s GPU’s require Resizable Bar or Smart Access Memory (SAM) to be used fully.
SAM is only explicitly stated to be used with consumer desktop CPU form AMD Ryzen 3000 series + but is never stated that it can’t be used with EPYC.

Let me know if you know of or have seen it work, and what motherboard it works with.

Thanks in Advance!!

As-is, SAM only being brought to spotlight, on the consumer front…

Unless mistaken, wouldn’t both the processor AND mainboard, need to support such an interaction?
The Zen2 callout I’d imagine, being they have PCIe 4.0 [otherwise ANY older Zen CPU, would’ve worked]

I’d see TR-Pro at better odds, getting their hands on it, even if it involved a sizeable bios / patches applied
Esp. since their R+D window would’ve overlapped, with 500 series boards [+ the Zen3 refinements]

1 Like

TR-Pro should have 1 or 2 boards that support it. To me, it looks like the mainboard is the critical piece that is lacking SAM for EPYC. I don’t know if that has something to do with EPYC’s chipset implementation being different from Ryzen & TR-Pro or if they are too lazy to certify the feature.

Is enabling SAM in a bios even necessary on Linux. There is conflicting information that you can get the benefits of SAM by just enabling “Above 4G Decoding” for Linux.

Looking though Motherboard manuals lead me to find only 1 TR-Pro board had it, the ASUS Pro WS WRX80E-SAGE SE WIFI.

ASrock, Gigabyte and Supermicro don’t support it.

I couldn’t confirm if the MSI WS WRX80 supports it since they have already removed it from their website only after a couple of months. :thinking:

I couldn’t find it stated in any server board I looked at (20 of them) from different vendors.

This is really disappointing. They all have it on their consumer platform, why not give us the feature on higher end platforms?

Not that this is what you want to hear but it’s a new ish feature that benefits tasks that epyc platforms are not aimed at by the vendor.

Can confirm H11SSL-I and H12SSL-I both have it.

One other curiosity point, to all this, is the handling of MULTIPLE SAM interactions

The consumer side is easy, since it would be effectively 1 GPU
But an EPYC/TR-Pro/TR, capable of affixing several GPU / GP-GPUs, to a single board
… Would their be a hard limit, of SAM support? Or a priority order, within GPU units?

I just skimmed both the H11SSL-I and H12SSL-I manuals and couldn’t find SAM. Did they add it in a firmware update and not change documentation?

I don’t 100% agree. Maybe I’m misunderstanding SAM, but it isn’t just a gamer focused feature is it? Wouldn’t most high compute applications that use GPU’s benefit from this? If a server doesn’t use GPU’s that is fair enough, but I would still think a sizable potion of customers use GPU’s with EPYC and especially with Threadripper. Epyc there is an argument for, but TR only having 1 board is kind of ridiculous.

My guess is that most enterprise workloads aren’t being bottlenecked by the 256MB VRAM chunk limitation that resizeable bar fixes. Most workloads upload heaps of data, process it, then copy it back off. Where as a game engine wants to make random writes all over vram to update information. Not to mention that for maximum speed you’d really want to fit the entire workload in VRAM in the first place.

3 Likes

Workstation compute is threadripper domain.

Servers (proper ones) are likely using cards with much more local vram and focus more on driver stability etc.

Not saying it’s no benefit in that application; more that the vendors and customers in that space are far more conservative. Expect support for this in that space to be more common in a few years rather than now.

“Above 4G Decoding” is not SAM or Rebar. If it was why is it a separate toggle in other bios menus? 4G decoding needs to be on for SAM to work, but it shouldn’t be confused for it.

Great Explanation

I’m a bit annoyed at the technical decision to change this particular spec. There’s no technical reason why without ReBAR/Smart Access Memory older PCIe wouldn’t have been able to share any address space - why not just leave it up to the OS drivers to setup the PCIe root complex / page tables.

1 Like

This topic was automatically closed 273 days after the last reply. New replies are no longer allowed.