AMD Ryzen 3000 and Older Zen Chips Don't Support SAM Due to Hardware Limitation, Intel Chips Since Haswell Support it

[InVasMani]

Give these three links a read you'll find a lot of decent information to glean. On that note TechArp said it best "
AMD Smart Access Memory : How To Enable It?
If you have all of those supported components above, and updated your motherboard BIOS, you need to manually enable Smart Access Memory.

Now, the method will vary from motherboard to motherboard, and it probably won’t even be called Smart Access Memory.

Instead, look for variations of Above 4G Decoding, or Resizing BAR, or Resizable BAR."

https://www.techarp.com/computer/smart-access-memory-guide/

https://envytools.readthedocs.io/en/latest/hw/bus/bars.html

https://docs.nvidia.com/cuda/gpudirect-rdma/index.html

On my AsRock z170 I believe aperture size is BAR size adjust afrom 256MB to 4096GB adjustable amounts doubling it in step intervals upward from 256MB. MMIO 4GB enable/disable is 4G decoding which you enable above 2GB aperture size seems to follow Windows system memory PAE limits perfectly though doesn't appear there is a 3GB PAE switch or doesn't make any mention of it, but maybe it can work similarly technically not sure the PAE limit is to do with 32-bit and 64-bit with the PDEP support. In fact a Microsoft article on PAE mentions DEP the P portion represent paging and I think is just another difference in the name acronym of it tech industry is wishy washing on naming of different features that's nothing new. If Zen 1/Zen 2 lacks a 64-bit PDEP register on the CPU and/or on earlier chipsets than x570/B550 that most zen 1/zen 2 CPU's would be utilizing it could be limited to at best 2GB to 3GB aperture sizes is my speculation on the matter given how PAE works with system memory for 32-bit.

 

[employee24601]

Behold! My i7-4790k will never die!

 

[Dyatlov A]

It is really screwd up AMD, they introduced it as game booster, but their processors not compatible with it, insted the Intel one .

 

[R-T-B]

It's not about I/O or PCIe controller, it's a CPU instruction, an ISA extension of the https://en.wikipedia.org/wiki/Bit_manipulation_instruction_set. In ZEN2 it is apparently emulated in microcode using other instructions which is why it is too slow for any benefit here.

Here lies the real answer.

 

[TumbleGeorge]

AMD must insert bigger L1 instruction cache to have place for most or all of new (and important older) instructions and algorithms. 64KB will be good but 128KB(per core) will be much more good size for that. Today L1(I) is too small only 32KB(before with Bulldozer/Vishera L1(I) was 64KB) and AMD were cut it in a half in Ryzen. I think that AMD is guilty for that and their actions for cut L1(I) cache size is to the detriment of consumers. For example, Ryzen does not support the 3D Now! Instructions, which were and still are really impressive, and in their absence we all lost good functionality. And as it becomes clear from the discussion in this discussion, AMD has "passed" us and other useful instructions ...

 

[InVasMani]

I'm still wondering if the BAR size on Zen/Zen 2 is limited to 256MB or if it just can't go beyond 2GB that would still provide a x8 improvement plus I imagine it has diminishing returns on the upside beyond a certain point.

 

[owen10578]

This sounds bullshit considering that Ryzen 3000 and 5000 both uses the SAME IO DIE that controls PCIE...what is going on?

 

[RainingTacco]

AMD shooting their own foot again?

 

[medi01]

It is really screwd up AMD, they introduced it as game booster, but their processors not compatible with it, insted the Intel one .

That's one weird way of seeing it.
The other is: it was there for years, but was put to use only after AMD implemented it.

Remind me, which Haswell mainboard supports it.

 

[Steevo]

Here lies the real answer.

So a set of instructions that otherwise would require high CPU use to perform if not present. Still might provide better performance is implemented on high core count machines than if not for minimum frame rates.

Some instructions are present in Excavator but not in Zen 1 or 2.

 

[Sora]

This is false as the ryzen 3000 and 5000 have the exact same IO chiplet.

full-rate _pdep_u32/64 is not required for Resizable bar, its an optional improvement for certain DirectX Swizzle operations but is not required for large block transactions to and from the graphics card, its also a non standard method of swizzle in any case.

I've asked in the usual channel and one knowledgeable guy answered that they misinterpreted Sebastian Aaltonen comments to mean that PDEP is necessary for "SAM", which it isn't and that he was just excited to talk about it since AMD took so long to support the instruction.
Radv developer Bas Nieuwenhuizen also said that it's unrelated to any interaction with the GPU since it would be non-standard and better done at texture packing time.

 

[Max(IT)]

AMD shooting their own foot again?

exactly.
So Intel "inferior" products are receiving it, while our "superior" and modern 3900X, 3800X and XT series are not.
On a marketing point of view, it would have be better for AMD not to release the feature at all...

 

[InVasMani]

If PDEP decode can be enabled up to 2GB for u32 on Zen/Zen2 that really needs to be highlighted by AMD. The gap between 256MB aperture size and 2GB is pretty wide. There is even the off chance it works like PAE with a /3GB switch as well in regard to the 32-bit address.

 

[TumbleGeorge]

A little conspiracy questions?: Is there any external reason that was valid until before ZEN3 that prevented this instruction from being used(in AMD CPUs)? Does Microsoft want to be paid extra money for products that support this set of instructions?

 

[InVasMani]

Above 4G decoding which allows 64-bit PCI decoding aka aperture/bar size appears to be present as a option in AMI bios tool in AsRock's x470 bios for Fatl1ty board snooping into the bios for it though it's disabled. Something labeled IOMMU seems to be their as well perhaps that's the same as MMIO with a slight name altercation. Seems to be quite a lot of infinity fabric divider options in the bios seems to go from 667MHz upward in options to 3GHz. I tried to look at x570 bios, but AMI bios tool didn't work with it at least not the version of the tool I have.

I think there could be some validity to AMD's claims. From looking at the AsRock x470 bios I spotted a few key difference between it and my skylake z170 bios. A bios option labeled Above 4G decoding was present, but disabled on x470 and is to do with 64-bit PCIE decode assuming that's the 64-bit PDEP decode that enabled BAR size/Aperture size adjustments in particular above 2GB. It doesn't have MMIO, but did have something labeled IOMMU I'm thinking it's a interchangeable name difference. What was lacking was anything with the name BAR/aperture size thus no configuration options for that. I presume it's got a bios string for 256MB aperture size written somewhere in the bios, but no configuration option for it. I'm uncertain if it could be manipulated and coded to a value higher than that upward of 2GB/3GB or not.

My conclusion is AMD isn't trying to pull the wool over anyone's eyes on the matter. The BAR/aperture size and options are a new feature to the AMD platform that's been introduced with x570/B550 and Zen 3 CPU's. If the CPU having the proper hardware for the 4G decoding (PDEP 64-bit) is required that's understandable enough. I can certainly see now why Nvidia is pressuring Intel to support it since it is already capable of supporting it.

It's a weird situation overall AMD/HP seemed to push and fund behind the scenes the original address space research into the PCIE spec for it from what It looked like. Seems Intel then beat them to the punch on feature complience of the spec itself, but never pro-actively exploited it. I think in Nvidia's case it's simply a instance of we could be actively using this same tech and do some already on Intel platforms from a few generations back so rather than being at some self imposed disadvantage and restriction perhaps we shouldn't. I think this is also a great instance where Intel could show some good will toward it's customers especially in light of all the security flaws and performance impact they've caused. They could restore a bit of that performance and at no real cost and give back a bit of the performance customers paid for in the first place that was effectively thrown out. It's the right thing to do from a PR standpoint to restore customer sentiment if you're Intel not doing so will leave a much greater scar people will look at it and say yeah Intel doesn't care about customer satisfaction and not just able, but willing to screw them over.

 

[Caring1]

Something labeled IOMMU seems to be their as well perhaps that's the same as MMIO with a slight name altercation.

A simple explanation from Wiki:
"In computing, an input–output memory management unit (IOMMU) is a memory management unit (MMU) that connects a direct-memory-access–capable (DMA-capable) I/O bus to the main memory."
It's present in B450 Bios also from MSI.
Also above 4G.

 

[biffzinker]

In ZEN2 it is apparently emulated in microcode using other instructions which is why it is too slow for any benefit here.

Wikipedia mentions a faster method called zp7 instead of the PEXT and PDEP instructions using microcode.

For example, Excavator through Zen 2 processors implement PEXT and PDEP instructions using microcode resulting in the instructions executing significantly slower than the same behaviour recreated using other instructions.[15] (A software method called "zp7" is, in fact, faster on these machines.)

 

[InVasMani]

I was going to give a bios flash with a modded aperture size, but "Secure Flash check fail!" for some reason my z170 AsRock doesn't allow me flash a modded bios now, but it was able to a few years ago very odd.

 

[Caring1]

I was going to give a bios flash with a modded aperture size, but "Secure Flash check fail!" for some reason my z170 AsRock doesn't allow me flash a modded bios now, but it was able to a few years ago very odd.

Probably a M.E. update, disable if possible and try.

 

[TumbleGeorge]

I was going to give a bios flash with a modded aperture size, but "Secure Flash check fail!" for some reason my z170 AsRock doesn't allow me flash a modded bios now, but it was able to a few years ago very odd.

ASRock say stop any overclocks before flash. System must be running by default.

 

[InVasMani]

I tried UEFI defaults reset and it didn't seem to help. Also tried AMI windows flash and instant flash in the bios, but neither wanted to budge they were firm in their stance my wares weren't legit.

 

[Nephilim666]

Digging the DFI NF4 Lanparty SLI-DR pic in the news article

 

[R-T-B]

I was going to give a bios flash with a modded aperture size, but "Secure Flash check fail!" for some reason my z170 AsRock doesn't allow me flash a modded bios now, but it was able to a few years ago very odd.

ASRock has updated their protections since then, primarily due to yours truly if I had to guess... lol. There are ways around it. PM me if interested and I'll see if I can't help you out. Keep in mind above 4GB decoding is only half of the needed features though.

I've already madea few experimental bioses here:

Z390 Taichi / ASRock Board users: Resized BAR bioses available for testing. Z390 Taichi featured. PM me for details.

I have an experimental bios mod for this board that forces the PCIe BAR from 256MBs to 2048MBs, I'm curious of the following and need testers: 1.) Does this help performance? Is it similar to or perhaps even recognized as "AMD SAM support?" This isn't technically a resizable BAR, but it is a...

www.techpowerup.com

 

[ratirt]

Again, the same thing as with the 370x boards not supporting 5000 series processors. It turned out you can use 5000 series CPUs on 370x (with modified BIOS) and of course people say AMD lied. When is supporting same as will work with?
Same here in this situation. 3000 series probably would work with SAM but they are not supported. This probably means the gains from SAM with 3000 series are not worth it.
I'm sure Haswell will work with SAM (Intel version) but what's the point of it if it gives you nothing or a boost in an area of margin of error.
I'd rather wait for this feature release and tests its capabilities with older CPUs before jumping into any conclusions.

 

[mirh]

Remind me, which Haswell mainboard supports it.

Even without a modded BIOS, on linux probably every one

Resizeable PCI BAR support - Patchwork

patchwork.kernel.org

EDIT: AMD is in fact already using it