Hello, I'm interested in trying the new JAX Metal plug-in and followed the steps in https://developer.apple.com/metal/jax/. Upon installation, I don't see any difference between the backend device detected by JAX and a pure CPU setup: >>> import jax >>> jax.devices() [CpuDevice(id=0)] >>> jax.devices()[0].platform 'cpu' >>> jax.devices()[0].device_kind 'cpu' >>> jax.devices()[0].client.platform 'cpu' >>> jax.devices()[0].client.runtime_type 'tfrt' Is this really using a Metal backend? How can I determine for sure? Thank you!

The preview image for RAW captures renders colors incorrectly, for some textures or patterns. A customer of our app reported this problem when shooting photos of dresses for their business. We have been able to replicate it in dresses, too, when they contain high-frequency silvery areas. The rendered preview shows a clear green color cast that is far from accurate. See example here: https://www.dropbox.com/s/ma0s5mbzdxhpjdl/Preview%20in%20Files.pdf?dl=0. Original files attached to FB9674554. We have observed this behaviour in iPhone 12 Pro and iPhone 13 Pro, but not in iPhone 11 Pro. It was first seen in iOS 14, but the problem still remains in iOS 15. This is a summary of the tests we performed to try to isolate the problem: It only happens in RAW mode, not in Auto, Manual, or ProRAW. Manually changing the exposure in RAW mode does not fix it. Setting a lower quality in the capture APIs does not fix it. If we capture the RAW image without requesting a preview or thumbnail to be embedded inside the DNG file, the problem still occurs when the image is previewed in Photos app. If we develop the DNG using third party RAW-editing apps, the problem does not occur. Previewing the DNG in a Mac, using Quick Look or Preview, does not show the problem. It looks like the default RAW-development engine suffers from this problem in those devices.

Hello, The metal compiler is crashing for me when attempting to compile a metal source file that contains Core Image kernel implementations. This is a minimal version of a file that produces the crash: extern "C" { namespace coreimage { inline void swap(thread float4 &a, thread float4 &b) { float4 tmp = a; a = min(a, b); b = max(tmp, b); } typedef sample_t s; float4 median_reduction_3(s v0, s v1, s v2) { swap(v1, v2); swap(v0, v2); swap(v0, v1); return v1; } }} Some observations: If inline is removed, the code compiles fine. I'm not sure if there's a performance impact, as the backend llvm compiler might as well decide to inline it on its own. If the calls to swap are commented in the median reduction function, the code compiles. If the -fcikernel compilation flag is not used, it also compiles fine (doesn't crash). Of course, that configuration doesn't allow the use of functions inside the file as Core Image kernels. I'm using the build settings recommended in this WWDC20 session (without indicating the location of the header files, since it's empty in my project and the new compiler interprets the argument following -I as a directory).