qiskit-aer icon indicating copy to clipboard operation
qiskit-aer copied to clipboard

Universal CPU Build Support for Qiskit Aer with CUDA and ROCm

Open basnijholt opened this issue 6 months ago • 4 comments

This PR introduces an update to the qiskit_aer build process, ensuring that the CPU variant of controller_wrappers is always built, alongside CUDA and ROCm variants. This ensures that builds targeting CUDA or ROCm can still operate on systems that only have CPU capabilities.

Key Changes:

  1. CPU Build as a Default: The CPU backend (controller_wrappers_cpu) is now always built. This is independent of whether CUDA (controller_wrappers_cuda) or ROCm (controller_wrappers_rocm) backends are being built.

  2. Conditional CUDA and ROCm Builds: Compilation of CUDA and ROCm backends remains conditional based on the AER_THRUST_BACKEND setting. This ensures that these backends are built only when specified, without affecting the CPU build.

  3. Organized Build Process: The build process in CMakeLists.txt is organized to handle CPU, CUDA, and ROCm backends separately. Each backend has its specific compiler flags, definitions, and dependencies, ensuring a clean and manageable build process.

This update significantly improves the flexibility and applicability of Qiskit Aer, enabling it to run on a broader range of systems, from specialized CUDA and ROCm environments to general-purpose CPU-only machines.

I my case this is useful because we distribute a single environment / container that run both on CPU and GPU machines. ATM qiskit-aer is our only dependency that doesn't allow this mode of operation.

basnijholt avatar Jan 12 '24 23:01 basnijholt

CLA assistant check
All committers have signed the CLA.

CLAassistant avatar Jan 12 '24 23:01 CLAassistant

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
You have signed the CLA already but the status is still pending? Let us recheck it.

CLAassistant avatar Jan 12 '24 23:01 CLAassistant

@doichanj, thanks a lot for looking at this PR!

This problem is still very annoying for us because we're maintaining 2 locked environments for CUDA and non-CUDA now. It would be awesome to be able to use one installation that works both on CPU and CUDA.

basnijholt avatar Mar 15 '24 19:03 basnijholt

I could not build with this PR when setting -DAER_THRUST_BACKEND=CUDA, it seems CPU build is not correctly configured and failed

doichanj avatar Mar 21 '24 01:03 doichanj