Just wanted to share my observations about performance on Apple M1 (although I suspect similar for A series). I had done something similar and was surprised (yup, I'm a noob) to find that creating a whole new matrix doesn't impact performance at all... Confirmed with official Xcode compiler statistics (with and without float3x3 conversion)... Hurray scalar ALUs and optimizing compilers.

Reran reproduction with Beta 5 (MacOS 22A5321d / Xcode 14A5294e), it appears to be fixed! Hurray!

FYI - Still seems to be an issue with Beta 4. Updated my reproduction repo (peterwmwong/x-metal-source-on-harvested-gpu-archive) with Beta 4 results and using trying air-lipo before metal-source (doesn't create a JSON file, but a directory of .metallib files). I have an open ticket for this FB10274656.

I also have had no luck with metal-source, even with the new beta 2 (MacOS and XCode). Here's my single swift, command line reproduction project: https://github.com/peterwmwong/x-metal-source-on-harvested-gpu-archive https://github.com/peterwmwong/x-metal-source-on-harvested-gpu-archive/blob/main/x-metal-source-on-harvested-gpu-archive/main.swift I'm excited to plug this into my project once it works!

Update: No longer crashes after updating to MacOS Monterey 12.3 and XCode 13.3 (13E113). Not sure which update fixed the issue, but works nonetheless!

:( Same issue. Even tried creating a brand new Swift Package (blank w/one test) and still seeing the issue, so it doesn't seem project specific...

Thanks @Qwiff for the link. This is a bit of a bummer. Given ICB's have been out for a number of years, not sure I should be holding my breath on support anytime soon... I wonder what Apple's guidance is on development/debug workflow without support... I can only think of: Feature flag app code to switch between using/not-using ICBs (huge pain when ICBs are encoded on the GPU) Whatever the GPU equivalent of "put a printf there" is ... Don't use ICBs for non-trivial things that may change/need-debugging in the future