Memory issue when using virtio-ramfb in 2.2.0 Beta

[js-john]

The total memory that UTM consumed reached to 5GB though I have set the memory to 2048M.

Configuration

• UTM Version: 2.2.0 Beta
• OS Version: iOS 14.6
• Device Model: iPad Pro 2021 12.9'
• Is it jailbroken (name jailbreak used)? No
• How did you install UTM?
  ios appsigner, resigned by paid developer account. Launched by jitterbug / Xcode

Guest OS: Ubuntu 18.04 X86_64
System: q35
Display card: virtio-ramfb

[js-john]

[conath]

Thanks for this. A couple of questions: is this new behavior in the 2.2.0 beta? Did you change the JIT cache setting for this VM?

Anyway, this does seem off, as the estimate in the Config code comes to just 3200MB used when setting RAM to 2GB and JIT cache at default.

UTM/Platform/Shared/VMConfigSystemView.swift

Line 88 in d915297

let estMemoryUsage = UInt64(memorySizeMib + jitMirrorMultiplier*actualJitSizeMib + baseUsageMib) * bytesInMib

[js-john]

Yes, this issue only appears in 2.2.0 Beta. I leave the JIT catch setting as default.

[osy]

I think this is inevitable with OpenGL because the video memory used is counted separately by iOS.

[conath]

I have what must be a memory leak when running 3D OpenGL on macOS:

[coreycusick]

Ah. So not just me having issues with memory. Crashes when 3D acceleration is used at all with an out of memory error on M1 iPad Pro 11 inch. Crashes as soon as any OpenGL application is used

[lulor]

I have what must be a memory leak when running 3D OpenGL on macOS:

I have encountered the same issue with UTM 2.2.0 Beta on an M1 Mac

[deja-geek]

I've encountered the same memory leak on UTM 2.2.0 Beta on an M1 Mac using both the virtio-ramfb and virtio-gpu-gl-pci adapter. VM running is Ubuntu 20.04 LTS running GNOME

[mdillavou]

I tried the 2.2.0 Beta on an M1 Mac and had to revert back to 2.1.2 as I kept running out of memory. I also had switched to virtio-gpu-gl-pci adapter, which gave me rendering artifacts, so I then switched to virtio-ramfb

[osy]

I've spent the weekend trying to root cause the issue and I'm still stuck. For some reason, textures allocated in ANGLE are not being deallocated properly. Using the Metal GPU debugger, we find that a lot of the textures are left in memory even though they look like stale data. I'm not sure exactly why the resources are not being freed. It may be an issue with the autoreleasepool but I can't find anything there.

utmapp/angle@ea46664 is a workaround by marking the memory as purgeable when it's being deallocated by ANGLE. It fixes the memory leak issue but is not a good solution because you get random GPU artifacts sometimes as it tries to use the purged memory. In fact, if you set it to force deallocate with MTLPurgeableStateEmpty then a lot of graphics won't render. So there is some race between ANGLE being done with a texture and it being rendered on screen.

@akihikodaki Have you had any issues with memory leak using ES profile with ANGLE on your QEMU implementation?

[akihikodaki]

@osy No, I'm not aware of memory leak. I assume you use Metal backend, but it is not ready and should be used only for limited inputs or testing.

[osy]

Thanks for the hint. I was surprised to learn that the backend is not ready considering https://github.com/kakashidinho/metalangle advertises 90% complete (yes I've tried that branch too and same memory leak issues). I guess I will file a ticket with ANGLE's issue tracker and see if it gets fixed in the future when GL is no longer supported on Apple platforms. For now, I've changed both the macOS and iOS backends to use GL and the memory leak is magically gone.

ea9f6b4