Resizeable BAR support issues

I own quite some nice games on Linux that have benchmarks tools, I will see if i can run some

 

These are not issues, that configuration is not supported.

 

I'd wait until CES 2021 for an official statement from AMD and Nvidia regarding official driver support.

 

Please see: Mesa 21.0 Begins Landing Optimizations For AMD Smart Access Memory - Phoronix

Once mesa 21.0 Dev becomes available, it's currently building for ubuntu, I will do some more testing.

 

Heads up that on windows some drivers do not like the expanded MMIO address space, so it may be unrelated to the amd driver or graphics card support. this feature can be seen here causing issues unrelated to SAM .

 

Not too surprising, but the same issues still happen with the latest non-beta BIOS too (5809).

According to an Oculus log, its Dash uses Vulkan, and apparently GPU memory while in this state isn't reported correctly, and explains why it's broken:

Code:

11/12 17:53:41.826 {!ERROR!} [Dash] [dash_error] { message: "[S]: Vulkan verify failure (-2) at line 506 of c:\\cygwin\\data\\sandcastle\\boxes\\trunk-hg-ovrsource-null\\software\\apps\\clay-2019-06\\code\\render\\src\\vulkan\\renderdevicevulkan.cpp\r\n",  }
11/12 17:53:41.827 {WARNING} [Client] pid: 9760, file: OculusDash.exe
OVR Error:
  Code: -1006 -- ovrError_ServiceError
  System error: -2 (fffffffe) -- VK_ERROR_OUT_OF_DEVICE_MEMORY

 

Here are some linux benchmarks!

AMD Smart Access Memory / Resizable BAR On Linux Still Ripe For Improvement - Phoronix

 

Asus board owners got AGESA 1.1.8.0 releases with SAM support.

 

I enabled Above 4G Decoding and Resizable BAR in settings, and seems to be working on Linux and Windows 10.
I have an ASUS z490 motherboard, an i7 10700k and a RX 5700XT, but i didn't see any improvements in games like Cyberpunk 2077, but i don't know if this Resiable Bar is implented.

 

i believe to see it enabled it would need to have "Large Memory Range" within device manager on the pcie device of choice, ie your 5700xt.

 

Yes, i have "Large Memory Range" in my RX 5700XT in Windows 10, and in Linux i have it like this:

https://www.phoronix.com/forums/for...ll-ripe-for-improvement?p=1225921#post1225921

So why Resizable BAR it's for the RX 6000 series GPU?

 

You need to try it with some applications, previous testing on older cards had issues.

 

In any case, don't expect any great fps increases

 

I did some benchmarks, using Unigine Superposition and BasemarkGPU, i got the same average scores on linux, using Fedora 33 and mesa-git repositories.
I couldn't get stable scores on Linux with BasemarkGPU in repeated benchmarks, with Resizable BAR activated or not, but i got almost the same average scores.
As for FPS increases, what type of benchmark could make use of Resizable BAR to get different scores?

 

Older CPU's can use it but are severe crippled when using it. 5000 series CPU's can complete the required instructions needed for BAR around 250 times faster than the previous gen ZEN cpu's can.

TechPowerUp notes that the new Ryzen 5000 CPUs are the only AMD series to integrate the PCIe physical layer feature called full-rate _pdep_u32/64, which allows processors to see the GPU’s entire video memory as a single addressable block instead of separate 256 MB apertures. It is true that Zen2 CPUs use the same IO die and PCIe controller as Zen3, but AMD SAM is actually controlled through a new ISA CPU instruction set. These specific instructions are only emulated in microcode using other similar instructions in the Zen2 and older cores, and this makes everything predating the new Ryzen 5000 essentially too slow to benefit from the performance uplift offered by SAM.

 

I believe it can shift larger data amounts anyway but I've seen a lot of information as to how the data would be loaded and if this aids the PCI Express bus or certain swizzle functions with textures if these optimizations have anything to do with AMD's performance claims or not.

Once the code finalizes in the newer AGESA builds (1.1.9.0 looks like it's being sent out now to bios engineers.) and there's additional supplies of the 6000 series GPU's maybe we'll see more comparisons between the new Intel CPU's, AMD's Zen2 and the Zen3 using some of the same games AMD tested or others that show a above 1 - 2% scaling gains.

Also if some titles now encounter issues because it's been so long established that 256 MB and that's it, hopefully not but it wouldn't surprise me even if this should hopefully be less troublesome than some of the hardware GPU scheduling problems were.
(Mainly for NVIDIA as AMD's still holding on this though again small gains but if combined the 4 - 5% total is nice free performance so there's that.)


EDIT: Good coding would also use this 256 MB slice and from there you have the rest of it, this isn't as big of a limit as it seems like also why even heavier VRAM usage titles or software don't show huge gains.

Not much of a coder myself or very in-depth on these things but I've been trying to catch up and read into why sending GB instead of MB wasn't showing major benefits and it's slowly coming together that this limit is less severe than expected or what I was thinking though this can still be important and it's good to have it supported.


It does shift around a bit though from my understanding when you can send more through PCI-E at a time thus bandwidth as a bottleneck potentially (PCI-E 4.0 versus 3.0 testing?) instead of having it more on the GPU VRAM.

I am not sure if this can tie into direct storage either as I would have thought or if there's other advantages or functions involved here, get a big bit of data from that to get at slow loading of whatever.
(Still going to need developers to actually optimize and code for it though, not going to happen immediately and might also see further gains over time as this improves.)


EDIT: And a realistic outlook with a bias towards cynicism or pessimism perhaps much as I'd prefer a optimistic outlook please don't collapse optimization entirely as devs can give zero regards and just shunt data around like it's nothing instead of having to be clever and use what resources are given, it's not always a good thing.
(It'll improve given time though, or at least there's some attempt at optimism ha ha.)

 

The instruction you speak of has nothing to do with Re-sizeable bar.

 

But i think we need some Benchmark tools that could make use of Resizable BAR capabilities, i didn't get any noticeable differences between Above 4G Decoding/Resizable BAR Enabled or not in my benchmarks with BasemarkGPU (With OpenGL , Vulkan and DirectX12) and Unigine Superposition (almost the same score in Linux), but thats a good thing because i had no issues while benchmarking because of Resizable BAR settings.

 

Does the Linux drivers only support the large size bit or does it actually use it fully?
I can see it from the task manager on the GPU device properties once Above 4G's on and the BAR option is set as auto (With CSM off and pure UEFI but I was already using that mode.) but as the current AMD display drivers doesn't utilize it for the Navi10's (yet?) it's just there but it does nothing the feature goes unused.

Would imagine that might be it compared to on a 6000 series GPU where the display driver does take advantage of this functionality and for other GPU's well it exists but it currently does nothing or can't be utilized although it shows up.

But this doesn't affect anything until a newer driver adds support for Navi10 at least hopefully more if possible.
(Vega and Polaris are still popular after all, if nothing else restricts this working for these then that's just a software limit in the current drivers not a hardware limitation.)

 

there are indeed some optimizations enabled when resizable bar is working., dont know how they compare to windows however.
you can see it working here from the phoronix article