Use Visual Studio 2019 for CUDA 11.x

[carterbox]

Comment:

We've been having trouble getting CMake (via scikit-build) to recognize NVCC as a working compiler for Windows in the tomocupy feedstock.

It seems that the default VM image for conda-forge presently is Visual Studio 2022 [1]. However, CUDA <=11.2,>=11.0 only officially supports Visual Studio 2019,2017,2015 [2].

Although the conda-forge-pinnings still use the vs2019 conda package on x86, I don't think this actually installs Visual Studio 2019.

In fact, during our testing we generated the following error when using Visual Studio 2022 and the CUDA 11.2 toolkit:

C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.2\include\crt/host_config.h(160): fatal error C1189: #error:  -- unsupported Microsoft Visual Studio version! Only the versions between 2017 and 2019 (inclusive) are supported! The nvcc flag '-allow-unsupported-compiler' can be used to override this version check; however, using an unsupported host compiler may cause compilation failure or incorrect run time execution. Use at your own risk.

We were eventually able to pass NVCC validation checks on the feedstock by manually setting the Windows VM back to 2019 with conda-forge.yml.

azure:
  settings_win:
    pool:
      vmImage: windows-2019

I'd like to have conda-smithy automatically choose the windows-2019 VM for CUDA<=11.2 instead of having to manually set it in the (undocumented?) conda-forge.yaml since it is the officially supported version for the CUDA 11.x series and because it may be helpful for others. How can I do that?

[1] https://github.com/actions/runner-images/blob/win22/20230508.3/images/win/Windows2022-Readme.md
[2] https://docs.nvidia.com/cuda/archive/11.2.2/cuda-installation-guide-microsoft-windows/index.html#system-requirements

[jakirkham]

Currently the compiler version is zipped with CUDA on Linux. Maybe we should consider doing the same thing on Windows

Side note: In CuPy, VS2019 doesn't work; so, VS2017 is used

[isuruf]

The compiler and the windows image are two different things. We use the VS2019 compiler in a windows-2022 image. You should check why VS2022 compiler is used instead of VS2019. Also, please link to an error. Your bug report does not give any usable info.

[carterbox]

Here's logs for a build with the windows-2022 image.

https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=717530&view=logs&jobId=e5cdccbf-4751-5a24-7406-185c9d30d021&j=e5cdccbf-4751-5a24-7406-185c9d30d021&t=66e4a587-a723-53e9-873c-6c9a2c5971ea

Here's logs for a build with the windows-2019 image.

https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=717518&view=logs&jobId=e5cdccbf-4751-5a24-7406-185c9d30d021&j=e5cdccbf-4751-5a24-7406-185c9d30d021&t=66e4a587-a723-53e9-873c-6c9a2c5971ea

These logs honestly aren't that helpful because the only explanation that CMake provides is "No CUDA toolset found." The more detailed message which prompted us to check the Official Docs for CUDA Toolkit was generated locally with a dummy project.

We use the VS2019 compiler in a windows-2022 image. You should check why VS2022 compiler is used instead of VS2019

My understanding is that the vs2019_win-64 conda package is just an activation script which helps locate whatever Windows compiler (MSVC) is available on the system because we don't have the rights to redistribute Visual Studio. There are two MSVC versions available on the windows-2022 image, but there is only one Visual Studio version (Visual Studio Enterprise 2022). So unless, we are installing Visual Studio 2019 to the windows-2022 image manually as part of the build process (I didn't see it in any of the build steps?) or it's there but not listed in the docs, I don't see how we are using Visual Studio 2019 in the windows-2022 image.

https://en.wikipedia.org/wiki/Microsoft_Visual_C%2B%2B#Internal_version_numbering

[carterbox]

You should check why VS2022 compiler is used instead of VS2019.

Assuming that CUDA 11.2 works with MSVC=19.29 regardless of whether it was installed as part of Visual Studio 2019 or 2022, I need to figure out why CMake is choosing MSVC=19.35 instead of MSVC=19.29.

Thanks for the hint. Please wait while I investigate this.

[carterbox]

Thanks for the help, @isuruf. It seems that scikit-build tries use the most recent MSVC compiler installed on the machine, so I need to explicitly set the full cl.exe path to use 19.29 instead of 19.35 on the windows-2022 vm.

[Tobias-Fischer]

Hi @carterbox - I've run into a similar issue in conda-forge/pycolmap-feedstock#16

When using scikit-build, I get a "No CUDA toolset found." for CUDA 12.0 (see log) and CUDA 11.8 (see log). Going back to a setup.py based build resolves the issue.

I can see in the tomocupy feedstock that you use a weird https://github.com/conda-forge/tomocupy-feedstock/blob/main/recipe/bld.bat but that didn't solve the issue for me.

Do you have any tips?

[carterbox]

My general tips are to use the latest CMake CUDA features such as enable_language(CUDA) and/or find_package(CUDAToolkit) (not find_package(CUDA)).

[Tobias-Fischer]

Hmm, that’s both already the case. I might stick with setuptools for now then.