Find SwiftPM metallib bundle near test binary#3562
Conversation
93232ea to
1a75e1a
Compare
|
Ping @davidkoski for review. |
|
At the moment I prefer adding an API to set the path to metallib directly, i.e. #3597, and I plan to close this PR, please let me know if the API would not be able to solve your use case. |
|
I think API to set a path would be fine, but I don't know how early it needs to be called. IIRC the worker threads start via static initializers and there is no way to guarantee being able to get in before that (perhaps that has changed?). Anyway I think the automatic scheme we have is ok and having an override would be useful. |
|
Ah, it looks like it is changed -- it happens when you first ask for |
|
Yeah the metal initialization has been delayed until a stream is actually created, it was to solve issues like #3148. So the API only needs to be called before the stream was explicitly or implicitly created. I think we should keep current metallib discovery behavior unchanged, and ask users to use the API if they have some unusual bundle layout, do you think whether it is a good idea? |
|
That seems like a good plan -- then if somebody has custom lookup needs they can implement it in application code. |
Summary
Fixes SwiftPM package/test layouts where
default.metallibis copied to the generatedSWIFTPM_BUNDLE.bundlenext to the test binary, but MLX only checks nested bundle locations.This keeps the existing lookup order and adds:
SWIFTPM_BUNDLE.bundlenext to the current binary, walking a few parent directoriesNSBundle.allBundles()already contains the SwiftPM resource bundleValidation
pre-commit run --all-filespassedmlx-swiftSwiftPM packaging branch:swift test --filter StreamTests/testDeviceTypepasses after applying this MLX loader patch and generatingdefault.metallibFailed to load the default metallib