Comment by rsp1984 | Hacker News Reader

Comment by rsp1984 | Hacker News Reader

I have no proof but a strong gut feeling the root cause of this is broken OpenGL drivers. Here's why:

Over the past several months we've been very busy porting our Android- and Windows-based 3D Capturing app to iOS. We have quite a bit of OpenGL (ES) code that needed to be migrated. After a couple of initial hiccups things appeared to work well, however something was off. OpenGL code that's fast and completely unproblematic on Win/Android caused weird CPU stalls and after some minutes of app usage typically everything just crashed. After some digging and debugging it became clear that certain OpenGL function calls were leaking memory like crazy, as in several MB per call. Concretely I'm talking about glBlitFramebuffer() and glCopyTex(Sub)Image2D() . Both of these operate on frame buffers (memory that's often as large as your app window size) and they were internally allocating new buffers on every call and apparently never freed them.

Now of course this is iOS and the article is talking about MacOS but it's quite likely that Apple derived their M1-targeted OpenGL implementation for MacOS from the iOS version which has always targeted Apple SoCs.

Given the amount of OpenGL-based software still out there and Apple's deprecation of OpenGL in favour of Metal (they just don't seem to care any more) those kinds of large scale memory leaks don't really surprise me. OpenGL is still pretty much everywhere and if you have bad memory leaks in core framebuffer operations things start to accumulate very quickly.

Great perspective, thanks.

FWIW, I notice the memory leaks particularly with “Control Center”, which is an Apple extension to the task bar. I wouldn’t expect any Apple-written code to be using any OpenGL; it should all be in Metal.

Heh just killed Control Center with 41GB of memory...

Virtual or resident memory?

Do you know how long the Carbon API survived inside the Finder?

macOS still uses Carbon for much of the menu bar and internal event routing.

The Carbon framework is no longer supported or present on the mac. It went away with other 32-bit support in Catalina.

  $ ls /System/Library/Frameworks/ | grep Carbon
  Carbon.framework

Yes, I see that now. Thanks. There seems to be a lot of confusion about what parts of Carbon are and are not going away or did not make the 64 bit transition. I haven't tried to build a Carbon app in a while. When you look in the frameworks, the ones that are present now seem to have arm64 bridge support, which I assume means arm native code for running Intel apps in Rosetta. Perhaps some very large user base app vendors like Microsoft and Adobe have not quite let go. Probably some old Apple code also. Apple keeps announcing it is disappearing but it can't seem to be killed.

No offense, but I laid out exactly what the framework is used for in my original comment: https://news.ycombinator.com/item?id=29144758. It's not (exclusively) there for Rosetta or third-party compatibility.

No offense taken. My mistake. None of my 32 bit Carbon apps have worked for a few years and I wrongly assumed the rest of it was gone.

If anyone wants to do any fun OS X GPU rabbitholing, this command will dump out a bunch of stuff from the IO Registry as an XML/plist:

ioreg -c IOGraphicsAccelerator2 -r -l -a

The PerformanceStatistics and IOReportChannels dicts are particularly juicy, and under IORegistryEntryChildren you can see which processes (IOUserClientCreator) are using what OS-level GPU resources, including Metal vs OpenGL API.

It's unclear to me if these issues are happening when you are running the iOS app on your Mac (emulating during development)?

If so, try setting Mac to use the discrete GPU all the time and see if it keeps happening. MacOS flip/flopping between discrete and integrated GPU was an issue for me. I can only imagine what MacOS might be doing during development of a graphics app such as yours.

Reply on news.ycombinator.com