TheRock aims to support as many subprojects as possible on "native" Windows (as opposed to WSL 1 or WSL 2) using standard build tools like MSVC.
Warning
While Windows source builds of TheRock (including PyTorch!) are working for some expert developers, this support is relatively new and is not yet mature. There are several known issues and active development areas on the Windows platform support bringup. If you encounter any issues not yet represented there, please file an issue.
ROCm is composed of many subprojects, some of which are supported on Windows:
- https://rocm.docs.amd.com/en/latest/what-is-rocm.html
- https://rocm.docs.amd.com/projects/install-on-windows/en/latest/reference/component-support.html
- https://rocm.docs.amd.com/projects/install-on-windows/en/latest/conceptual/release-versioning.html#windows-builds-from-source
This table tracks current support status for each subproject in TheRock on Windows. Some subprojects may need extra patches to build within TheRock (on mainline, in open source, using MSVC, etc.).
| Component subset | Subproject | Supported | Notes |
|---|---|---|---|
| base | aux-overlay | ✅ | |
| base | amdsmi | ❌ | Unsupported |
| base | rocm-cmake | ✅ | |
| base | rocm-core | ✅ | |
| base | rocm_smi_lib | ❌ | Unsupported |
| base | rocprofiler-register | ❌ | Unsupported |
| base | rocm-half | ✅ | |
| compiler | amd-llvm | ✅ | Limited runtimes |
| compiler | amd-comgr | ✅ | |
| compiler | hipcc | ✅ | |
| compiler | hipify | ✅ | |
| core | ROCR-Runtime | ❌ | Unsupported |
| core | rocminfo | ❌ | Unsupported |
| core | hipInfo from hip-tests | ✅ | |
| core | clr | 🟡 | Needs a folder with prebuilt static libraries |
| debug-tools | amd-dbgapi | ❌ | Unsupported |
| debug-tools | rocr-debug-agent | ❌ | Unsupported |
| debug-tools | rocgdb | ❌ | Unsupported |
| profiler | rocprofiler-sdk | ❌ | Unsupported |
| profiler | rocprofiler-compute | ❌ | Unsupported |
| profiler | rocprofiler-systems | ❌ | Unsupported |
| comm-libs | rccl | ❌ | Unsupported |
| math-libs | rocRAND | ✅ | |
| math-libs | hipRAND | ✅ | |
| math-libs | rocPRIM | ✅ | |
| math-libs | hipCUB | ✅ | |
| math-libs | rocThrust | ✅ | |
| math-libs | rocFFT | ✅ | |
| math-libs | hipFFT | ✅ | |
| math-libs (support) | mxDataGenerator | ❌ | Unsupported |
| math-libs (BLAS) | hipBLAS-common | ✅ | |
| math-libs (BLAS) | rocRoller | ❌ | Unsupported |
| math-libs (BLAS) | hipBLASLt | ✅ | |
| math-libs (BLAS) | rocBLAS | ✅ | |
| math-libs (BLAS) | rocSPARSE | ✅ | |
| math-libs (BLAS) | hipSPARSE | ✅ | |
| math-libs (BLAS) | hipSPARSELt | ❌ | Unsupported |
| math-libs (BLAS) | rocSOLVER | ✅ | |
| math-libs (BLAS) | hipSOLVER | ✅ | |
| math-libs (BLAS) | hipBLAS | ✅ | |
| math-libs | rocWMMA | ✅ | |
| math-libs | libhipcxx | ❌ | Unsupported |
| ml-libs | Composable Kernel | ❌ | Unsupported |
| ml-libs | MIOpen | ✅ | |
| ml-libs | hipDNN | ✅ | |
| ml-libs | MIOpen Legacy Plugin | ✅ |
These instructions mostly mirror the instructions in the root README.md, with some extra Windows-specific callouts.
-
You will need a powerful system with sufficient RAM (16GB+), CPU (8+ cores), and storage (200GB+) for a full source build. Partial source builds bootstrapped from prebuilt binaries are on our roadmap to enable.
-
To set expectations, on powerful build servers, the full source build can still take over an hour.
-
The Windows build uses hard links to save space, but storage sizes do not often account for this savings. Reported size used and actual size used may differ substantially.
-
-
Long path support is required. As needed, enable long paths for your system:
-
There are some known issues with preexisting HIP SDK / ROCm installs causing errors during the build process. Until these are resolved, we recommend uninstalling the HIP SDK before trying to build TheRock.
-
A Dev Drive is recommended, due to how many source and build files are used. See the Set up a Dev Drive on Windows 11 article for setup instructions.
-
Symlink support is recommended. If symlink support is not enabled, enable developer mode and/or grant your account the "Create symbolic links" permission. These resources may help:
-
We recommend cmd or git bash over PowerShell. Some developers also report good experiences with Windows Terminal and Cmder.
Tip
These tools are available via package managers like winget on Windows:
winget install --id Microsoft.VisualStudio.2022.BuildTools --source winget --override "--add Microsoft.VisualStudio.Component.VC.Tools.x86.x64 --add
Microsoft.VisualStudio.Component.VC.CMake.Project --add Microsoft.VisualStudio.Component.VC.ATL --add
Microsoft.VisualStudio.Component.Windows11SDK.22621"
winget install --id Git.Git -e --source winget --custom "/o:PathOption=CmdTools"
winget install cmake -v 3.31.0
winget install ninja-build.ninja ccache python strawberryperl bloodrock.pkg-config-lite
winget install --id Iterative.DVC --silent --accept-source-agreementsIf you prefer to install tools manually, you will need:
-
The MSVC compiler from https://visualstudio.microsoft.com/downloads/ (Using either "Visual Studio" or "Build Tools for Visual Studio"), including these components:
- MSVC
- C++ CMake tools for Windows
- C++ ATL
- C++ AddressSanitizer (optional)
-
Git: https://git-scm.com/downloads
- With "Use Git and optional Unix tools from the Windows Command Prompt" as certain build scripts use Bash.
-
CMake: https://cmake.org/download/, version < 4.0.0 (see Issue#318)
-
Ninja: https://ninja-build.org/
-
(Optional) ccache: https://ccache.dev/, or sccache: https://github.com/mozilla/sccache
-
gfortran, recommended from Strawberry Perl: https://strawberryperl.com/
-
patch, available in Strawberry Perl or Git.
-
Python: https://www.python.org/downloads/ (3.11+ recommended)
Warning
Prefer to install Python for the current user only and to a path
without spaces like
C:\Users\<username>\AppData\Local\Programs\Python\Python312.
Important
Git should be configured with support for symlinks and long paths:
git config --global core.symlinks true
git config --global core.longpaths trueImportant
After installing MSVC, use its 64 bit tools in your build environment.
- If you use the command line, see
Use the Microsoft C++ toolset from the command line.
Typically this means either
Start > x64 Native Tools Command Prompt for VS 2022or runningvcvars64.batin an existing shell. - If you build from an editor like VSCode, CMake can discover the compiler among other "kits".
- You can also tell CMake to use MSVC's tools explicitly with
-DCMAKE_C_COMPILER=cl.exe -DCMAKE_CXX_COMPILER=cl.exe -DCMAKE_LINKER=link.exe
If the build system is a non-English system. Make sure to switch to utf-8.
chcp 65001# Clone the repository
git clone https://github.com/ROCm/TheRock.git
cd TheRock
# Init python virtual environment and install python dependencies
python -m venv .venv
.venv\Scripts\Activate.bat
pip install -r requirements.txt
# Download submodules and apply patches
python ./build_tools/fetch_sources.pyUnsupported subprojects like RCCL are automatically disabled on Windows. See the instructions in the root README for other options you may want to set.
cmake -B build -GNinja . -DTHEROCK_AMDGPU_FAMILIES=gfx110X-all
# If iterating and wishing to cache, add these:
# -DCMAKE_C_COMPILER_LAUNCHER=ccache \
# -DCMAKE_CXX_COMPILER_LAUNCHER=ccache \
# -DCMAKE_MSVC_DEBUG_INFORMATION_FORMAT=Embedded \Tip
ccache does not support
MSVC's /Zi flag which may be set by default when a project (e.g. LLVM) opts
in to
policy CMP0141.
Setting
-DCMAKE_MSVC_DEBUG_INFORMATION_FORMAT=Embedded
instructs CMake to compile with /Z7 or equivalent, which is supported by
ccache.
Tip
Ensure that MSVC is used by looking for lines like these in the logs:
-- The C compiler identification is MSVC 19.42.34436.0
-- The CXX compiler identification is MSVC 19.42.34436.0
If you see some other compiler there, refer to the MSVC setup instructions up in Important tool settings.
cmake --build build --target therock-dist
cmake --build build --target therock-archivesThis will start building using MSVC. Once the amd-llvm subproject is built,
subprojects like the ROCm math libraries will be compiled using clang.exe and
other tools from the amd-llvm toolchain.
When the builds complete, you should have a build of ROCm / the HIP SDK
in build/dist/rocm/ and artifacts in build/artifacts. See the
Build Artifacts guide for more information about the build
outputs.
To build Python wheels, you will need an "artifacts" directory, either from a
source build of therock-archives (see above) or by running the
fetch_artifacts.py script to download
artifacts from a CI run.
Once you have an artifacts directory, you can run the
build_python_packages.py script.
PyTorch builds require Python wheels, either by building from source (see above) or by downloading from one of TheRock's release indices. See the instructions at external-builds/pytorch.
Test builds can be enabled with -DBUILD_TESTING=ON (the default).
Some subproject tests have been validated on Windows, like rocPRIM:
ctest --test-dir build/math-libs/rocPRIM/dist/bin/rocprim --output-on-failureIf the build looks for a source file with a long path that does not exist, ensure that you have long path support enabled in git (see Important tool settings), then re-run
python ./build_tools/fetch_sources.pyOnce the git operations have run with the new setting, confirm that the missing files now exist.
Errors like this indicate that the value of -DTHEROCK_AMDGPU_FAMILIES= or
-DTHEROCK_AMDGPU_TARGETS= is currently unsupported by one or more libraries.
Several developers have reported link errors in rocBLAS and rocSPARSE like
[rocSPARSE] lld-link: error: duplicate symbol: __hip_cuid_2f7b343d50a9613
[rocSPARSE] >>> defined at library/CMakeFiles/rocsparse.dir/src/level3/csrmm/row_split/csrmm_device_row_split_256_16_8_3_4.cpp.obj
[rocSPARSE] >>> defined at library/CMakeFiles/rocsparse.dir/src/level3/csrmm/row_split/csrmm_device_row_split_256_16_8_7_4.cpp.obj
[rocBLAS] lld-link: error: duplicate symbol: rocblas_stbsv_batched
[rocBLAS] >>> defined at library/src/CMakeFiles/rocblas.dir/blas2/rocblas_tbsv_batched.cpp.obj
[rocBLAS] >>> defined at library/src/CMakeFiles/rocblas.dir/handle.cpp.obj
[rocBLAS]
[rocBLAS] lld-link: error: duplicate symbol: rocblas_dtbsv_batched
[rocBLAS] >>> defined at library/src/CMakeFiles/rocblas.dir/blas2/rocblas_tbsv_batched.cpp.obj
[rocBLAS] >>> defined at library/src/CMakeFiles/rocblas.dir/handle.cpp.obj
[rocBLAS]
[rocBLAS] lld-link: error: duplicate symbol: __hip_cuid_a201499d9a86b1da
These have been worked around by disabling ccache.
- Windows paths may have spaces in them, so properly quote paths
- Windows paths may use
\instead of/as a component delimiter- The
\character is often an escape character in raw strings, so properly escape paths if passing them between systems - In Python,
pathlibhas good support for performing transformations on paths like joining or splitting components in a cross-platform way, but some outgoing uses still need to use.resolve(),.as_posix(), and other functions to resolve symlinks, convert slashes, etc. - In C++,
<filesystem>has good support for performing transformations on paths like joining or splitting components in a cross-platform way. See ROCm/rocm-libraries#948 for example. - In CMake, take care when loading environment variables into strings and treating them as paths. Use https://cmake.org/cmake/help/latest/command/file.html#path-conversion and https://cmake.org/cmake/help/latest/command/cmake_path.html instead of working with strings directly, like so:
-set(HIP_PATH $ENV{HIP_PATH}) +file(TO_CMAKE_PATH "$ENV{HIP_PATH}" HIP_PATH)`
- The
- Windows paths (and commands) can have max length limitations, so avoid long file names
- Windows paths do not allow some characters (https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file)
- Symlink support on Windows is not always available
- Windows uses
[library].dllfiles instead oflib[library].sofiles, which use different APIs for loading/linking (and have different versioning in the file names too). CMake can use https://cmake.org/cmake/help/latest/variable/CMAKE_SHARED_LIBRARY_PREFIX.html and https://cmake.org/cmake/help/latest/variable/CMAKE_SHARED_LIBRARY_SUFFIX.html - Windows uses the .exe extension for executables while Linux uses files with no suffix. CMake can use https://cmake.org/cmake/help/latest/variable/CMAKE_EXECUTABLE_SUFFIX.html
- GitHub actions can use bash.exe, cmd.exe, and powershell on Windows. Switching workflows to use Python scripts helps a bit, but some actions / steps / tools / scripts still expect paths in a certain format or with a certain escaping style, or expect certain tools to be available (e.g.
sed,grep)
We are working on enabling flexible open source builds of
https://github.com/ROCm/clr (notably for amdhip64_7.dll) on Windows.
Historically this has been a closed source component due to the dependency on
Platform Abstraction Library (PAL)
and providing a fully open source build will take more time. As an incremental
step towards a fully open source build, we are using an interop folder
containing header files and static library .lib files for PAL and related
components.
An incremental rollout is planned:
- The interop folder must be manually copied into place in the source tree. This will allow AMD developers to iterate on integration into TheRock while we work on making this folder or more source files available.
- The interop folder will be available publicly (currently at https://github.com/ROCm/rocm-systems/tree/develop/shared/amdgpu-windows-interop).
- (We are here today) The interop folder will be included automatically from a git repository using dvc.
- A more permanent open source strategy for building the CLR (the HIP runtime) from source on Windows will eventually be available.
If configured correctly, outputs like
build/core/clr/dist/bin/amdhip64_6.dll should be generated by the build.
If the interop folder is not available, sub-project support is limited and features should be turned off:
-DTHEROCK_ENABLE_CORE=OFF \
-DTHEROCK_ENABLE_MATH_LIBS=OFF \
-DTHEROCK_ENABLE_ML_LIBS=OFF \