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.
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]
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.
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 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.
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.
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.