-
Notifications
You must be signed in to change notification settings - Fork 12k
cmake: fix paths for vulkan shaders compilation on Windows #8573
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Just got successful Vulkan builds with MSBuild/cl and ninja/clang on Windows 11 x64 with this PR, thank you! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me. No issues on Linux. I can't test Windows, but other commenters confirmed that it works there. Thank you.
Compilation fails on w64Devkit with this update:
|
Seconding this, not fixed, from my limited perspective into the code it's bit perplexing because the build seems to be fixed at -std=c++11 while std::replace is c++20 onwards, how is this supposed to work anywhere? |
I agree the way it is shown by default in the documentation makes it look like Maybe the problem for w64Devkit is just that |
Yes, it seems to be the case #8880 |
Not critical, but the algorithm part is in a Windows-only section. |
…8573) * Vulkan-shaders: attempt fix compilation on windows * fix miss-matched parenthesis
They were shoehorned through a Windows-style string representation, where the entire command line is just a space-separated string of arguments. If any arguments contain spaces, you have to escape them. This was implemented in ggml-org#8573, however, the issue remains on Unix. Usually, this would NOT be an issue on Unix, because it doesn't have the braindead Windows-style API that only takes a flat string as a command line. In Unix, you can pass the arguments as a legit array. However, Llama.cpp didn't make use of that; instead running `sh -c <the flattened argument string>`. Thereby inflicting the same problems onto itself as Windows has. Instead of bandaid-fixing this by also slapping quotes around the path arguments (which would also break apart as soon as the path contains quote characters), I decided to fix it properly. So, the code now doesn't wrap the command line in `sh -c`, but passes the arguments directly, circumventing the need to do any brittle escaping. This also necessitated replacing the `coopmat ? "" : "-O"` parameter with a proper conditional parameter. Because the empty string parameter (rightfully) confused glslc.
Fixes #8562
I hope it's not breaking it for others.