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
• metallib_support (now 1.2.9), air_support (now 2.8.0 according to @gbaraldi), metal_support (4.0.0) Tahoe versions #607
• 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?

Metal.jl/src/compiler/compilation.jl

Line 149 in 7ceb3e5

@signpost_interval log=log_compiler() "Create Metal library" begin

[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