-
Notifications
You must be signed in to change notification settings - Fork 407
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
Windows Support #1533
Comments
Does this mean compiling with Clang on Windows without Cygwin? |
@j8asic I'm not sure about Clang on Windows. Our initial target was MSVC 2017. If you can point us to a Clang workflow we may look into that as well. |
If you're going with MSVC, probably no need for a specific Clang workflow -- seems that |
@j8asic yes, the build system will be tricky. I'm thinking of focusing on our CMake build system, although even that makes some use of the Makefile system... |
CMake is supposed to be able to dump MS project files. That was the whole justification for Trilinos adopting it circa 2009. CMake dumps Ninja just fine (yay!) so I'm a bit hopeful perhaps? Oh wait I forgot Kokkos drives everything through Makefiles.... |
@mhoemmen yes, I think CMake support for outputting MSVC project files is widely used and robust. We just have to make a few minor tweaks in the Kokkos CMake files to make sure we only use pure CMake logic on Windows (and don't go calling Linux-specific external things from CMake). This shouldn't be too bad. |
In particular, on Windows we'll just avoid calling our Makefile system to determine things like compiler flags, and instead just determine things like compilers flags with some pure-CMake logic that only covers the Windows case. |
We discussed this shortly today. The vast majority of all our Makefile logic is compiler and architecture detection and the combinatorial issues with all possible combinations. It looks to me like the non-cygwin (i.e. non-gnu-make compatible) ecosystem on Windows should be quite bit simpler. We don't have to deal necessarily with gcc, clang, pgi, cray, XL and intel, and we don't have to support ARM, Power, BGQ, Xeon Phi etc. We probably can get away initially with some simple logic and just assume we have an AVX compatible CPU and are using MSVC. |
Windows 10 runs on ARM: https://www.theverge.com/2017/12/5/16737288/microsoft-windows-10-qualcomm-arm-laptops-launch Target for that looks like low-power laptops, though, so it might not be so urgent to support it. |
Here is a helpful comment posted on Trilinos github.io site trilinos/trilinos.github.io#24 (comment) @alessiocacciatori this is a good place for discussion regarding the fixes you've worked on for MSVC, thanks for posting! Thanks @william76 for helping direct the comment this way! |
Here we go: we got Windows support with MSVC in develop! For now only the Serial backend is supported. CUDA comes next. Not sure yet about OpenMP since MSVC only promises OpenMP 2.0. |
Wonderful! Eager to try it! Thank you! |
I've tried to test compile with Clang 9, i.e. clang-cl, from VS and it almost goes through :) 1st problem is that Kokkos_Macros.hpp defines STACKTRACE and CXXABI, which I guess, are not available on Windows:
2nd problem arises in
The solution was to add |
Any progress on building Kokkos on windows? Is it available now? |
We have CI for Windows. Which backends are you interested in, though? |
Hi, I am especially interested in GPU acceleration with Nvidia. |
We have now Sandia internal customers in addition to external folks who want to run Kokkos based apps on Windows including GPU support. To make this work we need to do a couple things starting with buying a Windows Server with a GPU (preferably a TitanV).
One big advantage is that this will remove an obstacle for commercial customers to use Kokkos.
The text was updated successfully, but these errors were encountered: