Skip to content

Don't try to use NAX at run-time if kernels aren't there#2982

Merged
awni merged 1 commit into
mainfrom
no_nax
Jan 13, 2026
Merged

Don't try to use NAX at run-time if kernels aren't there#2982
awni merged 1 commit into
mainfrom
no_nax

Conversation

@awni

@awni awni commented Jan 9, 2026

Copy link
Copy Markdown
Member

In some cases an MLX binary built for macOS 14 or 15 can end up running on a machine with OS 26.2. It will try to load the NAX kernels since it's a run-time check and it will crash.

@awni awni requested a review from angeloskath January 9, 2026 22:08
std::unique_ptr<void, std::function<void(void*)>> new_scoped_memory_pool();

inline bool is_nax_available() {
#ifdef MLX_METAL_NO_NAX

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't it be better to positively define MLX_METAL_NAX instead when NAX is present?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well this is the minimum edit distance version since there is one path in the cmake that we want to turn off the NAX support for but multiple in the cmake that we want it on for.

Over time I think this makes more sense as by default we will want to build to support neural accelerators... but I'm not so attached to it.. I can rearrange it if needed.

@awni awni merged commit 8654b82 into main Jan 13, 2026
15 checks passed
@awni awni deleted the no_nax branch January 13, 2026 23:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants