Support for Metal 4

[christiangnrd]

Luckily it seems like all the Metal 3 stuff still works. This is a tracking issue for the new Metal 4 features.

To Do:

• [ ] MTLTensor
• [ ] Flesh out this issue with stuff from here
• [ ] Metal Performance Primitives
• [x] metallib_support (now 1.2.9), air_support (now 2.8.0 according to @gbaraldi), metal_support (4.0.0) #607
• [x] Versioning to avoid issues with Apple's magic compatibility shenanigans (wrappers, etc)

Resource: Metal Shading Language Specification

[maleadt]

Can confirm that all tests simply pass on macOS 26. The OS version reporting seems off though:

┌ Info: System information:
│ macOS 16.0.0, Darwin 25.0.0
│
│ Toolchain:
│ - Julia: 1.11.5
│ - LLVM: 16.0.6
│
│ Julia packages:
│ - Metal.jl: 1.6.0
│ - GPUArrays: 11.2.2
│ - GPUCompiler: 1.5.1
│ - KernelAbstractions: 0.9.34
│ - ObjectiveC: 3.4.1
│ - LLVM: 9.4.0
│ - LLVMDowngrader_jll: 0.6.0+0
│
│ 1 device:
└ - Apple M1 (64.000 KiB allocated)

[christiangnrd]

Same for me about the version reporting. It's also reported as 16 using the AppleAccelerate method of determining version, but properly as 26 when using what I assumed to be an equivalent method to the ObjectiveC.jl one in the command line. ($ sysctl kern.osproductversion)

I have a feeling this will be fixed in a later beta.

[maleadt]

From a quick scroll through https://developer.apple.com/videos/play/wwdc2025/205/, it looks like there's a whole new compiler API (MTL4Compiler).

[christiangnrd]

From a quick scroll through https://developer.apple.com/videos/play/wwdc2025/205/, it looks like there's a whole new compiler API (MTL4Compiler).

Where would that fit in? Would it replace some things in “Create Metal Library” part of compile? https://github.com/JuliaGPU/Metal.jl/blob/7ceb3e57eaade8e0a1f036ab280e2fc7de8dc01d/src/compiler/compilation.jl#L149

[christiangnrd]

Seems like all of Metal 3 will work as before, but we could rewrite the whole custom kernel backend for Metal 4.

[christiangnrd]

Seems like Apple is doing something similar to what they did when macOS 11 came out. ~Although this workaround doesn't work.~ Edit: it seems to work for the method used by Apple Accelerate mentioned below but not for the syscall.

This also happens when opening /System/Library/CoreServices/SystemVersion.plist in AppleAccelerate. What actually gets opened is /System/Library/CoreServices/SystemVersionCompat.plist...

Okay my findings. I check the version using 3 different methods:

1. Shell mode in Julia REPL: shell> cat /System/Library/CoreServices/SystemVersion.plist
2. read in Julia REPL: julia> String(read("/System/Library/CoreServices/SystemVersion.plist")) (How AcceleratedKernels does it)
3. Syscall sysctlbyname "kern.osproductversion" (How ObjectiveC.jl does it)

And I tested the following 3 Julia versions:

1. Released Julia 1.11.5: $ Julia
2. Released Julia 1.11.5: $ SYSTEM_VERSION_COMPAT=0 Julia
3. Julia 1.11.5 compiled from source on macOS 26: $ Julia

Results:

Julia 1.11.5	Shell	.plist	syscall
Release	26.0	16.0	16.0
Release SYSTEM_VERSION_COMPAT=0	26.0	26.0	16.0
Compiled from source	26.0	26.0	26.0

[gbaraldi]

Also

julia> _syscall_version("kern.osrelease")
v"25.0.0"

Though that one makes sense since it's the darwin version