Resolve Metal shader sources relative to the executable#575
Open
rinaldofesta wants to merge 1 commit into
Open
Resolve Metal shader sources relative to the executable#575rinaldofesta wants to merge 1 commit into
rinaldofesta wants to merge 1 commit into
Conversation
Launching ds4 binaries from outside the repo silently falls back to the CPU backend because metal/*.metal only resolves against the current directory. Try the executable's own directory (symlinks followed) as a last candidate, so the binaries work from any working directory or a PATH symlink without --chdir. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
OPS-NeoRetro
approved these changes
Jul 20, 2026
| * from any working directory (e.g. inside another project). */ | ||
| NSString *exe_dir = nil; | ||
| { | ||
| char exe_path[4096]; |
There was a problem hiding this comment.
Suggested change
| char exe_path[4096]; | |
| char exe_path[32768]; |
You have to do that because APFS can have 32768-char and longer paths, and unlimited folders, and APFS can only have filenames and folder names up to 255 characters long. APFS is the filesystem for Apple Silicon Macs.
Comment on lines
+3076
to
+3082
| uint32_t exe_len = sizeof(exe_path); | ||
| if (_NSGetExecutablePath(exe_path, &exe_len) == 0) { | ||
| NSString *resolved = [[NSString stringWithUTF8String:exe_path] | ||
| stringByResolvingSymlinksInPath]; | ||
| exe_dir = [resolved stringByDeletingLastPathComponent]; | ||
| } | ||
| } |
Comment on lines
+3093
to
+3094
| if (exe_dir) | ||
| [paths addObject:[exe_dir stringByAppendingPathComponent:spec[1]]]; |
| @@ -1,5 +1,6 @@ | |||
| #import <Foundation/Foundation.h> | |||
| #import <Metal/Metal.h> | |||
| #include <mach-o/dyld.h> | |||
There was a problem hiding this comment.
You used _NSGetExecutablePath, which is a private dyld function, so you correctly included the right header
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Launching any ds4 binary from outside the repo silently falls back to the CPU backend: the Metal kernel sources only resolve as
metal/*.metalagainst the current directory, so from another working directory the library build fails and the engine starts withbackend=cpuand CPU-speed prefill, with no error pointing at the cause. The README's--chdirnote covers it, but that requires knowing the trap exists.The fix adds one more candidate path per kernel source: the directory containing the executable, obtained via
_NSGetExecutablePathwith symlinks resolved (so a symlink from~/binor/usr/local/binalso works). Lookup order is unchanged otherwise: per-file env override first, then the two cwd-relative forms, then the executable-relative path. In-repo launches behave exactly as before; the file is Darwin-only so CUDA/ROCm paths are untouched.Validation:
makeon top of current main, zero warnings (-Wall -Wextra). On an M5 Max with the patch applied, launchingds4-agentfrom an unrelated directory now starts withbackend=metalin the context-buffers banner (previouslybackend=cpu), and the same holds when launched through a PATH symlink. Not run here: CUDA/ROCm builds (no change to those paths).Implemented with the help of a coding agent (Claude Code) and reviewed locally by the author.