Converting to a standalone adapter by kayaercument · Pull Request #2 · Munich-Quantum-Software-Stack/MQSS-CUDAQ-Adapter

kayaercument · 2026-07-20T14:18:22Z

This PR aims to convert the existing implementation into a standalone implementation.

How to run it:

# Install CUDA Quantum
wget -O install_cuda_quantum https://github.com/NVIDIA/cuda-quantum/releases/download/0.15.0/install_cuda_quantum_cu12.x86_64 && bash install_cuda_quantum

#Compile the adapter with the CUDA Quantum's Clang
cmake .. -DCMAKE_CXX_COMPILER=/${CUDA_INSTALL_DIR/lib/llvm/bin/clang -DCMAKE_C_COMPILER=${CUDA_INSTALL_DIR/lib/llvm/bin/clang -DCUDAQ_DIR=${CUDA_INSTALL_DIR}/lib/cmake/cudaq

#Build and install
make && make install

A couple of things need to be improved:

Better naming for the parameters.
Improve the code quality.
Better dependency management.

FYI: @ctminh @echavarria-mqv

mnfarooqi · 2026-07-21T08:51:02Z

+FetchContent_Declare(
+  mqss-client
+  GIT_REPOSITORY https://github.com/kayaercument/MQSS-Client.git
+  GIT_TAG develop


A version tag would be more stable as the develop is going to change over time.

mnfarooqi · 2026-07-21T09:08:30Z

+  # Define the JIT lowering pipeline
+  jit-mid-level-pipeline: "lower-to-cfg,quake-to-cc-prep,func.func(expand-control-veqs,combine-quantum-alloc,canonicalize,combine-measurements)"
+  # Tell the rest-qpu that we are generating OpenQASM 2.0.
+  codegen-emission: qasm2


Any option for the user to set it to a different IR type? e.g. quake or qir?

mnfarooqi · 2026-07-21T09:10:21Z

@@ -0,0 +1,39 @@
+set(LIBRARY_NAME mqss-adapter)


Would it be a good idea to move this CMake file to the root folder?

mnfarooqi · 2026-07-21T09:18:46Z

+  /// @brief the platform file path
+  std::filesystem::path platformPath;
+
+  mqss::client::MQSSClient client;


Does it need to be public?

mnfarooqi · 2026-07-21T09:19:47Z

+                             const cudaq::AnyModule &module,
+                             cudaq::KernelArgs args) {
+  throw std::runtime_error(
+      "MQSSQPU does not support launching the async_sample_policy.");


Why MQSS can't support async? What is needed to support async?

akshay9594 · 2026-09-25T07:26:43Z

@mnfarooqi @kayaercument Are we going to use this adapter in its current form and integrate new MQSS Quantum Compilation Suite and MQSS client?

mnfarooqi · 2026-09-25T07:34:21Z

@mnfarooqi @kayaercument Are we going to use this adapter in its current form and integrate new MQSS Quantum Compilation Suite and MQSS client?

Yes, the idea is that the MQSS client will offload the Quantum MLIR (Quake), and the MQSS Quantum Compilation Suite will then convert it into a format that the backends can understand.

akshay9594 · 2026-09-25T07:48:52Z

In that case, I think this adapter would need major updates. E.g. currently it uses an older cudaq-quantum version (maybe 0.13.0 or older; from one year ago). Another thing I see is a forked version of cudaq is being fetched from gitlab and a patch is being applied from upstream cudaq. Also, from the build scripts it seems that entire cudaq is being built from source.

I guess for an adapter we need to build and use only the frontend infrastructure of cudaq.

kayaercument · 2026-09-25T08:41:42Z

In that case, I think this adapter would need major updates. E.g. currently it uses an older cudaq-quantum version (maybe 0.13.0 or older; from one year ago). Another thing I see is a forked version of cudaq is being fetched from gitlab and a patch is being applied from upstream cudaq. Also, from the build scripts it seems that entire cudaq is being built from source.

I guess for an adapter we need to build and use only the frontend infrastructure of cudaq.

Hello Akshay 👋

Thank you for your comment. The implementation you described was the older version of the adapter, which requires the entire CUDAQ. However, the current implementation is just a backend that can be built and installed on the existing CUDAQ 0.15.0.

akshay9594 · 2026-09-25T10:59:10Z

In that case, I think this adapter would need major updates. E.g. currently it uses an older cudaq-quantum version (maybe 0.13.0 or older; from one year ago). Another thing I see is a forked version of cudaq is being fetched from gitlab and a patch is being applied from upstream cudaq. Also, from the build scripts it seems that entire cudaq is being built from source.
I guess for an adapter we need to build and use only the frontend infrastructure of cudaq.

Hello Akshay 👋

Thank you for your comment. The implementation you described was the older version of the adapter, which requires the entire CUDAQ. However, the current implementation is just a backend that can be built and installed on the existing CUDAQ 0.15.0.

Forgot to check your @kayaercument branch. Sorry about that. So, you are using the using the pre-built cudaq-0.15.0 wheels. That is fine for a first version, though I prefer selectively building targets. Besides that and other issues like code quality and testing that have been mentioned, for now I do not have other concerns.

Signed-off-by: Ercüment Kaya <49598189+kayaercument@users.noreply.github.com>

kayaercument · 2026-09-26T17:38:31Z

In that case, I think this adapter would need major updates. E.g. currently it uses an older cudaq-quantum version (maybe 0.13.0 or older; from one year ago). Another thing I see is a forked version of cudaq is being fetched from gitlab and a patch is being applied from upstream cudaq. Also, from the build scripts it seems that entire cudaq is being built from source.
I guess for an adapter we need to build and use only the frontend infrastructure of cudaq.

Hello Akshay 👋
Thank you for your comment. The implementation you described was the older version of the adapter, which requires the entire CUDAQ. However, the current implementation is just a backend that can be built and installed on the existing CUDAQ 0.15.0.

Forgot to check your @kayaercument branch. Sorry about that. So, you are using the using the pre-built cudaq-0.15.0 wheels. That is fine for a first version, though I prefer selectively building targets. Besides that and other issues like code quality and testing that have been mentioned, for now I do not have other concerns.

Thank you very much @akshay9594.

I understand your concern, and I agree. My initial goal is to ensure we have a working prototype. Therefore, I would like to merge this PR (Of course, after we improve the existing code quality based on your review). Then, we can work on the testing. This way, we can keep the PRs short.

FYI @ipryanis @ctminh

akshay9594

No more comments from my side.

kayaercument added 2 commits July 20, 2026 15:58

🎨 implementing the stand alone version

286cb84

🎨 update the Dockerfile

f0e9790

kayaercument requested a review from mnfarooqi July 20, 2026 14:18

kayaercument self-assigned this Jul 20, 2026

mnfarooqi reviewed Jul 21, 2026

View reviewed changes

kayaercument added 2 commits September 24, 2026 12:10

🎨 Refactoring and provinding async support

68064f2

🎨 update the dependency

be7a7dd

kayaercument marked this pull request as ready for review September 24, 2026 12:54

mnfarooqi requested a review from akshay9594 September 24, 2026 15:10

mnfarooqi requested a review from ipryanis September 25, 2026 07:51

Delete .DS_Store

0e037d4

Signed-off-by: Ercüment Kaya <49598189+kayaercument@users.noreply.github.com>

akshay9594 approved these changes Sep 28, 2026

View reviewed changes

Navigation Menu

Converting to a standalone adapter - #2

Converting to a standalone adapter#2
kayaercument wants to merge 5 commits into
Munich-Quantum-Software-Stack:developfrom
kayaercument:develop

kayaercument commented Jul 20, 2026

Uh oh!

mnfarooqi Jul 21, 2026

Uh oh!

mnfarooqi Jul 21, 2026

Uh oh!

mnfarooqi Jul 21, 2026

Uh oh!

mnfarooqi Jul 21, 2026

Uh oh!

mnfarooqi Jul 21, 2026

Uh oh!

akshay9594 commented Sep 25, 2026

Uh oh!

mnfarooqi commented Sep 25, 2026

Uh oh!

akshay9594 commented Sep 25, 2026

Uh oh!

kayaercument commented Sep 25, 2026

Uh oh!

akshay9594 commented Sep 25, 2026

Uh oh!

kayaercument commented Sep 26, 2026

Uh oh!

akshay9594 left a comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

kayaercument commented Jul 20, 2026

Uh oh!

mnfarooqi Jul 21, 2026

Choose a reason for hiding this comment

Uh oh!

mnfarooqi Jul 21, 2026

Choose a reason for hiding this comment

Uh oh!

mnfarooqi Jul 21, 2026

Choose a reason for hiding this comment

Uh oh!

mnfarooqi Jul 21, 2026

Choose a reason for hiding this comment

Uh oh!

mnfarooqi Jul 21, 2026

Choose a reason for hiding this comment

Uh oh!

akshay9594 commented Sep 25, 2026

Uh oh!

mnfarooqi commented Sep 25, 2026

Uh oh!

akshay9594 commented Sep 25, 2026

Uh oh!

kayaercument commented Sep 25, 2026

Uh oh!

akshay9594 commented Sep 25, 2026

Uh oh!

kayaercument commented Sep 26, 2026

Uh oh!

akshay9594 left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants