Starcraft 2 In Wine & Select Games Could See Nice Performance Win With RadeonSI Patches

[Venemo]

I had been following the original bug report from the gallium-nine bug tracker the last few days. Whats interesting is the original report seems to suggest with the patches it's even faster now with nine than on native windows..

Let me try to clear that up. I don't think it's faster on nine than windows, though I guess it depends on the settings. All the tests that I did there were on medium shaders. I don't currently have Windows on my computer so can't do a direct comparison, but you are welcome to do make one if you want.

From my experience SC2 performance nose-dives when there is a lot of units on screen even on nine. I'm hoping this patch will bring the performance up above 60fps constantly.

Yes, it can nose dive here too. The patch does help stabilize it, but the fps still gets lower when you have a lot of units. Just not as low as before.

[agd5f]

Traditionally GPUs used a 256 MB window of VRAM mapped into address space. It made sense to keep it small on 32 bit due to lack of address space. But on 64 bit, there is more than enough address space.

I know there were some plans to map all of the VRAM on 64 bit. Is this still unimplemented?

It depends on the system bios and how it sets up the MMIO aperture on the platform. All of the MMIO resources on the devices in the system have to fit into that aperture. The MMIO aperture setup is platform specific so there is no generic way to do it in the OS. There is an ACPI interface to provide MMIO aperture adjustments, but I've never seen it actually implemented on any platforms. Most server platforms support a large MMIO aperture by default or an option to enable it, but most desktop platforms still set up a small MMIO aperture for 32 bit compatibility. If you look in the bios settings, if your system offers it, it's often called ">4G MMIO". Besides servers, it's often available on mining boards in order to provide enough MMIO space to accommodate a large number of devices like GPUs.

The amdgpu driver supports resizing the PCI BARs if there is enough MMIO space on the platform, so as long as your platform supports it, the driver can too.

[agd5f]

Maybe this can be a huge gain on APUs. It would be nice to test it on Intel and AMD.

There is no VRAM aperture limitation on APUs. The driver can access the entire "VRAM" aperture on APUs because it's just carved out system memory. No need to go through the PCI BAR interface.

[brent]

If you look in the bios settings, if your system offers it, it's often called ">4G MMIO". Besides servers, it's often available on mining boards in order to provide enough MMIO space to accommodate a large number of devices like GPUs.

The amdgpu driver supports resizing the PCI BARs if there is enough MMIO space on the platform, so as long as your platform supports it, the driver can too.

Thanks for the hint. I indeed remember such a setting from the BIOS setup, and it is disabled at the moment. i'll try to enable it.

If amdgpu manages to resize the BAR, is this reflected in kernel log and lspci?

Right now it says:

[    2.786195] [drm] Detected VRAM RAM=8192M, BAR=256M

So I'd expect the BAR to be resized to 8192 MB if it works out. Is this assumption correct?

[brent]

Nice, it worked perfectly:

[    2.767936] amdgpu 0000:23:00.0: BAR 2: releasing [mem 0x1ff0000000-0x1ff01fffff 64bit pref]
[    2.767937] amdgpu 0000:23:00.0: BAR 0: releasing [mem 0x1fe0000000-0x1fefffffff 64bit pref]
[    2.767953] pcieport 0000:00:03.1: BAR 15: releasing [mem 0x1fe0000000-0x1ff01fffff 64bit pref]
[    2.767962] pcieport 0000:00:03.1: BAR 15: assigned [mem 0x500000000-0x7ffffffff 64bit pref]
[    2.767964] amdgpu 0000:23:00.0: BAR 0: assigned [mem 0x600000000-0x7ffffffff 64bit pref]
[    2.767971] amdgpu 0000:23:00.0: BAR 2: assigned [mem 0x500000000-0x5001fffff 64bit pref]
[    2.767998] [drm] Detected VRAM RAM=8192M, BAR=8192M

So this should speed up the scenario Marek's patches also address, right? With so much mapped VRAM available, there won't be any congestion.

Is it known if this results in any other notable speedups? I assume in the best case, it could speed up some host<->GPU copies.

[agd5f]

Is it known if this results in any other notable speedups? I assume in the best case, it could speed up some host<->GPU copies.

Depends on the specific applications/workloads. It removes contention for CPU access to vram because the CPU can access all of vram directly, but not all apps run into this contention.

[nuetzel]

It depends on the system bios and how it sets up the MMIO aperture on the platform. All of the MMIO resources on the devices in the system have to fit into that aperture. The MMIO aperture setup is platform specific so there is no generic way to do it in the OS. There is an ACPI interface to provide MMIO aperture adjustments, but I've never seen it actually implemented on any platforms. Most server platforms support a large MMIO aperture by default or an option to enable it, but most desktop platforms still set up a small MMIO aperture for 32 bit compatibility. If you look in the bios settings, if your system offers it, it's often called ">4G MMIO". Besides servers, it's often available on mining boards in order to provide enough MMIO space to accommodate a large number of devices like GPUs.

The amdgpu driver supports resizing the PCI BARs if there is enough MMIO space on the platform, so as long as your platform supports it, the driver can too.

Hello Alex,

as you know a have a server system (yes, plane old PCIe 2...), but no BIOS option (FUJITSU PRIMERGY TX150 S7).
Do we have a kernel parameter to enable this, too?

[ 4.299969] [drm] vm size is 128 GB, 2 levels, block size is 10-bit, fragment size is 9-bit
[ 4.300035] [drm] Detected VRAM RAM=8192M, BAR=256M

Or do I have to dig on Christian's x86-PCI-WIP-add-a-64bit-PCI-root-window-for-Intel-CPU (my chipset), again?

[nuetzel]

The SDMA series is now fixed (no system hangs).

https://lists.freedesktop.org/archives/mesa-dev/2019-February/215579.html

[agd5f]

Hello Alex,

as you know a have a server system (yes, plane old PCIe 2...), but no BIOS option (FUJITSU PRIMERGY TX150 S7).
Do we have a kernel parameter to enable this, too?

Every CPU/Chipset controls the MMIO window differently. Someone would need to implement support for adjusting the MMIO window for your platform. Not sure if the Intel chipset/CPU documentation has this info or not. Christian implemented support for some recent AMD CPUs.