Thanks for the reply! I already filed FB14074014 for this. I also attached a small sample project now.

On iOS, there is a watch dog that kills processes on the GPU that run too long. I don't think there is much you can do to change the timing limit. The only way to prevent that is to improve the runtime of your algorithm. You could also try splitting up the work into multiple steps, if possible. E.g., by splitting up the images into regions and performing the regression on the regions first, and then once more on the results of step one.

Tested with macOS 15.2 RC 2.

What device did you test on? The trick only works on iPad, not on iPhone and also not on the Simulator (not even in supported countries). It also has to be an iPad that supports Apple Intelligence (M1 or newer).

All I did was to set the system & Siri language to English (US) and log in with a US sandbox account under Media & Purchases. Then I could enable Apple Intelligence on my iPad in Germany.

Deferred here means that it's doing the bulk of the work later, but gives you something you can use and show the user quickly. So you can quickly show a preview of the capture (the 12 MP image) and a few seconds later update it with the fully processed 48 MP image. Since you want to use CIRawFilter, I'm afraid you have to wait for the full image to arrive before you can present the user with editing controls. But you can use the smaller image to bridge the UI transition.

How does the crash look like? Where does it crash? Do you have a crash log?

When you call CIRAWFilter(imageURL: rawURL, options: [:]) you are calling the old, deprecated CIFilter RAW API. What happens if you just use CIRAWFilter(imageURL: rawURL) (the actual initializer of CIRAWFilter)?

But shouldn't the stack trace be longer in this case?

It's still not working. Do we need to remove the previous toolchain download somehow?

I can confirm what @ihomway says: it works after a reboot. 👍

Hmm, this looks to me like a problem with profiling itself. If you run the experiment just in Xcode and watch the memory graph, you'll see that memory will return to normal a little while after rendering. Even if spamming the button, memory stays well within the resource limits. I don't know why, when profiling with instruments, those small 4 MiB surfaces don't get released. 🤷‍♂️

Good question. I would recommend to use the startTask(...) APIs of CIContext to render to a CIRenderDestionation. You get a CIRenderTask object back, on which you can call waitUntilCompleted() to get a CIRenderInfo object. When you Quick Look that in Xcode (mark the variable and press space), you get a very detailed render graph that, among many other useful info, shows how much memory the render pass required.

How did you write your kernels before? In CI Kernel Language? If so, I would highly recommend to not mix Metal and CIKL kernels in one rendering. It's best if you can translate all your kernels to Metal.