*insert Oprah's everyone get SAM meme*

would be nice if every CPU, chipset and GPU get this feature.

nguyen*insert Oprah's everyone get SAM meme*

would be nice if every CPU, chipset and GPU get this feature.

Well this sorta thing confuses me, is this something a motherboard just has to allow? or do the cpu and gpu need software/hardware to actually support it?
Could a "rogue" motherboard maker allow SAM to be used on ryzen 3000 series?

ZoneDymoWell this sorta thing confuses me, is this something a motherboard just has to allow? or do the cpu and gpu need software/hardware to actually support it?
Could a "rogue" motherboard maker allow SAM to be used on ryzen 3000 series?

as it's part of PCI-E specifications it technically is MoBo side and technically it doesn't Change a lot sw side except allowing bigger chunks than 128 to be transfered so reducing allocation time by allowing the package sizes to be any size they Need to be.

So technically yes, if the said MoBo was build after "BAR" was introduced into PCI-E specifications it could be allowed / integrated for this Mainboard by adjusting the BIOS (just like R5k cpu's can be used on MoBo's with the Right bios but can't if you didn't update it yet --- it's literally just a microcode injection making a function available or not Situation).


The only Question is, how well it would work and how much effort AMD put into their Version of it - if it's not optimized it could lead to lower Performance or, of Course, to similar gians as we've seen in the SAM Tests (with PCI-E 3 most likely a bit lower as there isn't as much Overhead bandwith as with PCI-E4 but in General, even PCI-E 3 is not totally/fully utilized at the Moment if you don't also use pci-e sata's/etc. )

Imagine a hypothetical situation, where Intel's platform could benefit a higher performance gain from enabling resizeable BAR...

13.37% performance increase :D

Object5513.37% performance increase :D

Ya gotta wonder if that was intentional or not. Pretty 'lite to me.

dj-electricImagine a hypothetical situation, where Intel's platform could benefit a higher performance gain from enabling resizeable BAR...

That would be really funny, a technique that was there for a while now that went un-used, brought forward by AMD, but then finding out it works better for Intel and losing the performance crown.

Looks like soon AMD will be forced to enable this for "older" Zen CPU's.

Arcdaras it's part of PCI-E specifications it technically is MoBo side and technically it doesn't Change a lot sw side except allowing bigger chunks than 128 to be transfered so reducing allocation time by allowing the package sizes to be any size they Need to be.

So technically yes, if the said MoBo was build after "BAR" was introduced into PCI-E specifications it could be allowed / integrated for this Mainboard by adjusting the BIOS (just like R5k cpu's can be used on MoBo's with the Right bios but can't if you didn't update it yet --- it's literally just a microcode injection making a function available or not Situation).


The only Question is, how well it would work and how much effort AMD put into their Version of it - if it's not optimized it could lead to lower Performance or, of Course, to similar gians as we've seen in the SAM Tests (with PCI-E 3 most likely a bit lower as there isn't as much Overhead bandwith as with PCI-E4 but in General, even PCI-E 3 is not totally/fully utilized at the Moment if you don't also use pci-e sata's/etc. )

Isn't this the same thing as aperture size option? From the looks of it I could actually enable it in my z170 bios 128MB/256MB/512MB/1GB/2GB/4GB.

InVasManiIsn't this the same thing as aperture size option? From the looks of it I could actually enable it in my z170 bios 128MB/256MB/512MB/1GB/2GB/4GB.

That setting is the amount of system RAM allocated to the Intel iGPU, no way it's related.

SAM is the new feature that allow CPU to access the entirety of dGPU VRAM in one go, instead of a series of 256MB chunks.

dj-electricImagine a hypothetical situation, where Intel's platform could benefit a higher performance gain from enabling resizeable BAR...

Harakiri (Seppuku). But seriously competition is useful for us the end-customers, though we still need a more practical way to activate and deactivate this feature.

I'm in a bar right now. It's resizable because of (Corona) restrictions. Life's good, illness bad.

dj-electricImagine a hypothetical situation, where Intel's platform could benefit a higher performance gain from enabling resizeable BAR...

I was thinking the same :-)

ZoneDymoWell this sorta thing confuses me, is this something a motherboard just has to allow? or do the cpu and gpu need software/hardware to actually support it?
Could a "rogue" motherboard maker allow SAM to be used on ryzen 3000 series?

It has to be implemented on the motherboard side, and the code feature maintained by AMD, Intel, and Nvidia, as Microsoft does not maintain the feature directly, unlike how Linux has support baked into the OS itself and is managed as part of the OS featureset. AMD can support the feature more easily simply because they produce both CPU and GPU and can validate everything within their own ecosystem, although they recently said they were working with Nvidia for Ryzen+Nvidia SAM compatibility and validation. No idea if Intel has reached out to work with AMD to support Intel+Radeon SAM compatibility, although Nvidia did say they were at least working with Intel on trying to get Intel+Nvidia SAM working.

The real issue here is having 3 different code bases managed by 3 very competitive companies, which could see features broken just to force upgrades or play hardball. AMD currently is the only one able to shelter themselves from a feature war if say, Nvidia was to lock some future-gen GPUs from SAM-linking with say, an old gen Ryzen or Intel, or Intel limiting the SAM feature to their high-end while ignoring the low end.

As for the last bit, in theory, a mobo maker could support SAM all the way back to Ryzen 1000, just as long as its on an AMD 400-series or 500-series chipset, as the feature is technically a PCIe 3.0+ specific feature. Maybe it could work on AMD 300-series chipsets, but I don't recall if all 300-series mobos had a PCIe 3.0 slot (IIRC, some budget ones only had 2.0), and even then, would only officially work with the PCIe 3.0 slot (usually the GPU slot). But considering that most support for AMD 300-series chipsets has since ended, in part due to AMD also ending it, it'll be up to dedicated coders to create custom BIOS that activate the feature on the 300-series.

ZoneDymoThat would be really funny, a technique that was there for a while now that went un-used, brought forward by AMD, but then finding out it works better for Intel and losing the performance crown.

That seems typical for AMD, pushing innovations first only to have others benefit from it, e.g. 64 bit CPU, GDDR3, GDDR5, HBM, Async Compute, etc. and I'm sure we'll see Intel do it with CPU chiplets

AnarchoPrimitivThat seems typical for AMD, pushing innovations first only to have others benefit from it, e.g. 64 bit CPU, GDDR3, GDDR5, HBM, Async Compute, etc. and I'm sure we'll see Intel do it with CPU chiplets

It was the similar as G-sync/Freesync. Nvidia brought it up and AMD also made it available. AMD still has some stuff it needs to make as an alternative to Nvidia solution, and on the other hand Nvidia also has to do the same.

nguyenThat setting is the amount of system RAM allocated to the Intel iGPU, no way it's related.

SAM is the new feature that allow CPU to access the entirety of dGPU VRAM in one go, instead of a series of 256MB chunks.

Can you explain the setting below it then? DVMT Total Gfx Mem indicates it selects the size of internal graphics device. To me that sounds like it sets the integrated graphics memory size setting. Also in the past aperture size was for external graphics settings that terms been around since AGP slot was used. Why would you have two settings that sets teh size of the integrated graphics memory!!? To me that doesn't add up and aperture size in AGP days still set the BAR size if I'm not mistaken.

On another note is the BAR setting in Nvidia bios intertwined with this BAR size like a frequency associated to it's speed limit I guess you could say while the BAR size itself is more like a wider highway.

MysteoaIt was the similar as G-sync/Freesync. Nvidia brought it up and AMD also made it available. AMD still has some stuff it needs to make as an alternative to Nvidia solution, and on the other hand Nvidia also has to do the same.

Err that's a tad wrong G-sync required monitor manufacturers to install a piece of hardware from nVidia whereas AMD only used part of an already available spec for Displayport connections and it's also available through HDMI 2.0/.1 now

ChomiqLooks like soon AMD will be forced to enable this for "older" Zen CPU's.

They should actually. It is very silly for them to limit this to the new Zen 3 CPU, when you consider the fact that they cannot even produce enough Zen 3 CPU to sell. In addition, there is no stopper for older hardware to support SAM, its just their skewed decision.

InVasManiIsn't this the same thing as aperture size option? From the looks of it I could actually enable it in my z170 bios 128MB/256MB/512MB/1GB/2GB/4GB.

Someone had the same idea as me...

I should see how hard it is to retrofit this ASUS work to other boards...

AnarchoPrimitivThat seems typical for AMD, pushing innovations first only to have others benefit from it, e.g. 64 bit CPU, GDDR3, GDDR5, HBM, Async Compute, etc. and I'm sure we'll see Intel do it with CPU chiplets

I think this is how the operate. In my opinion, if you look at their history of AMD introducing new technology features, i.e. Mantle, Tessellation, etc, they generally don't follow through in my opinion. It could be due to their market share which makes getting game developers' buy in difficult, that I don't know. In almost every case, eventually some company will scoop it up and integrate into their feature.

MysteoaIt was the similar as G-sync/Freesync. Nvidia brought it up and AMD also made it available. AMD still has some stuff it needs to make as an alternative to Nvidia solution, and on the other hand Nvidia also has to do the same.

The idea of VRR became popular when Nvidia introduced GSync. Where AMD did better is to implement an alternative that is non-proprietary. Perhaps FreeSync is not as good as some suggested, but still it works and I don't have to pay an Nvidia premium, which is great for consumers.

there is no reason this can't be brought to every board/gpu that supports pcie 3.0
its been in the spec for years

R-T-BSomeone had the same idea as me...

I should see how hard it is to retrofit this ASUS work to other boards...

I think it's already in place on my AsRock z170 I just might have to adjust the bios setting. It's rather confusing with how they have it worded and you've got to change 3 settings in all different area's of the bios in a specific manner. It sounds like I disable CSM support in boot menu region of the bios. I can then enable MMIO assignment in some other system menu. Finally I set the aperture size in yet another location of the bios to 4096MB. If I interpreted it the right way at least.

InVasManiI think it's already in place on my AsRock z170 I just might have to adjust the bios setting. It's rather confusing with how they have it worded and you've got to change 3 settings in all different area's of the bios in a specific manner. It sounds like I disable CSM support in boot menu region of the bios. I can then enable MMIO assignment in some other system menu. Finally I set the aperture size in yet another location of the bios to 4096MB. If I interpreted it the right way at least.

I think what you are viewing is AGP aperture size. Believe it or not it's still used as a setting on IGP with intel, just without the AGP bus. I don't think it's the same.

I'm not entirely convinced that the BAR size isn't the same setting as the aperture size with a interchangeable name changing to describe the same concept a bit more adequately. Think about aperture is a bit of a fuzzier term really more associated with camera's and fairly applicable, but not the best means to describe what the setting really represents as neatly as BAR size.

Also take a gander at this and notice the CSM disabled part and 4G decoding the latter also being kind of fuzzy and interchangeable with MMIO 4GB.
www.techarp.com/computer/smart-access-memory-guide/

Lastly you've got this which describes the VRAM aperture as BAR1 also rather coincidental in turn. I'm pretty self convinced it's the same unless someone can definitively in a strong way prove otherwise at least for the time being. I think we could know more for certain perhaps when Nvidia enables support to be fair. If it's supported at the driver level by Nvidia on GPU's it should work if the MB supports it and I think Nvidia knows as much or wouldn't be coming out so quickly quite so guns blazing on the matter.
envytools.readthedocs.io/en/latest/hw/bus/bars.html

I also found this by Nvidia that talks about the BAR and the MMIO so yeah I'm fairly convinced.
docs.nvidia.com/cuda/gpudirect-rdma/index.html

It wasn't showing up in bios like I thought initially, but it's also a previous bios version so idk if the naming changed. There defiantly isn't a "accessible" option with the same naming structure in P7.30 bios it could be something a bios mod needs to enable I think you change something extended user I don't recall there is a way to temper with some stuff and enable/disable some bios options though by modding them with the AMI tool. There is something called TOLUD MMIO with a 2.5GB/3.5GB/Dynamic option in the version of the bios I have though that could possibly be the same option with slightly different naming in the older bios used. The CSM option was present though and already disabled by default and from what I read AsRock does that along with most other MB makers though Gigabyte seems to enable it by default apparently.