Core: Implement Device Mapping & GPU SMMU

[FernandoS27]

Memory in Tegra X1 works very differently to how it's currently emulated. Normally there's physical memory of (4Gb), a virtual memory address space used by processes (applications like games for example) and device virtual memory spaces used by peripherals (GPU, DSP, bluetooth, etc). This device memory space is normally called (SMMU) System Memory Management Unit or IOMMU. With this address space, the different devices can map over physical memory used by many different applications to one they can only see. This has the advantage that it allows sharing memory among many multiple processes in the OS with each device.

This PR implements a general simplified version of the SMMU and implements it for the GPU. With some differences, first, we use full 34 bits of the AS instead of just 32 bits for pinning memory, second, we use a common SMMU page file for every process in the GPU instead of switching it per channel.

Currently in yuzu., the GPU uses a memory model of GMMU (GPU's MMU) -> PMMU (the main application's virtual space) -> physical memory to handle memory overall. This is great when there is only one application using the GPU at a time and it's never shared with other processes. 95% of the time this is what happens in the switch. However, it is possible to have multiple processes running and rendering concurrently as is the case of overlays and applets like inline software keyboard. It's also possible to have an application suspended while another is running (an applet is running while the game is suspended). With the implementation of the SMMU, it is now possible to share the GPU resources without any issues whatsoever.

Advantages of new SMMU:

• Not perfect but more accurate than before.
• Uses less memory overall for tracking GPU memory.
• More optimizations possible, in the future.
• Multiprocess use of the emulated GPU.
• Other devices can use the device mapper in case it's needed or be extended through correct implementation of KDevicePageTable.
• Total memory usage of the SMMU is about 80Mb counting tracking. The tracking alone on none-SMMU version costed 256MBs.

Disadvantages of the new SMMU.

• Harder tracking of resources.
• Complicated.
• More accurate than before but not perfectly accurate to avoid sacrificing performance.

Current issues:

• Pikmin 4 seems to get some vertex explosions after transitioning in many worlds. (Fixed)
• There's some memory leaking after closing an application. (Unrelated, the leak is on master)
• It's not working with 6Gb/8Gb memory layouts. (fixed)
• Needs more cleanup.

[FernandoS27]

l hope to test this feature

this alone means almost nothing to users but it will allow a LOT of cool stuffs soon.

[Slexer]

How much work is left for a complete UMA implementation? Is SMMU a big chunk of it or just a little bit?

[FernandoS27]

How much work is left for a complete UMA implementation? Is SMMU a big chunk of it or just a little bit?

For a real good and accurate UMA implementation; a lot of work. SMMU makes it easier for making the mirrors needed for DMI.

After that We'll do only DMI for downloads, which will improve things a bit.

Doing full DMI will be a challenge if we want to keep or even increase the compatibility we have. It will take a lot of time. I can't give an ETA.

[brujo5]

by DMI do they refer to direct memory import? If yes, I remember that in Skyline they said that it only worked perfectly on a7xx and on a6xx you had to restart the phone or the games start to crash and it was a hardware bug, is that true?

[FernandoS27]

by DMI do they refer to direct memory import? If yes, I remember that in Skyline they said that it only worked perfectly on a7xx and on a6xx you had to restart the phone or the games start to crash and it was a hardware bug, is that true?

Yes. It's true.