Issue Report: Launch Constructor Ambiguity and Compilation Problems

[AnamicX]

Problem Description

When using the MUDA library, ambiguity issues were found in the Launch constructor, along with related compilation and static assertion problems.

Test Code:

void case1() {
  muda::DeviceBuffer<float> buffer(17);
  muda::Launch(16)
      .apply(buffer.size(), [buf = buffer.viewer()] __device__(
                                int idx) mutable { buf(idx) = idx; })
      .wait();
  std::vector<float> out;
  buffer.copy_to(out);
  printVector(out);
}

void case2() {
  muda::DeviceBuffer<float> buffer(17);
  muda::Launch(dim3(16))
      .apply(dim3(buffer.size()), [buf = buffer.viewer()] __device__(
                                      int idx) mutable { buf(idx) = idx; })
      .wait();
  std::vector<float> out;
  buffer.copy_to(out);
  printVector(out);
}

Observed Behavior:

• case1() throws error: m_grid_dim.x == 0 failed. grid_dim should be \dim3{0}
• case2() outputs all zeros, neither executing normally nor throwing an error

Problem Details

1. Launch Constructor Ambiguity

muda::Launch(16) matches the third constructor:

MUDA_HOST Launch(dim3 blockDim, size_t sharedMemSize = 0, cudaStream_t stream = nullptr) MUDA_NOEXCEPT
    : LaunchBase(stream),
      m_grid_dim(0),  // grid_dim is set to 0
      m_block_dim(blockDim),
      m_shared_mem_size(sharedMemSize)
{
}

The check for m_grid_dim in the apply function fails because a valid grid dimension is expected

2. Static Assertion Problem

In generic_kernel_with_range, when detecting callable objects that accept int or unsigned int parameters, a static assertion should trigger to recommend using ParallelFor(), but the current implementation has issues:

else if constexpr(std::is_invocable_v<F, int>
                  || std::is_invocable_v<F, unsigned int>)
{
    static_assert("You should use `ParallelFor()` instead of `Launch()` for better semantics");
}

3. C++20 Syntax Compilation Problem with xmake
   Error Message:

muda\src\muda\buffer\details/buffer_3d_view.inl(115): error: expected an expression
      return cudaPitchedPtr{.ptr   = remove_const(m_data),
                            ^

Cause: The code uses C++20 designated initialization syntax, but the project is configured for C++17 in xmake.lua.

Environment Information:

Compiler: CUDA 13
Version: 2025.10.9

[MuGdxy]

Thank you for the feedback.

For a workaround, you can use ParallelFor in this case.

And please check the test in muda, to see if they can be compiled and run correctly.

https://github.com/MuGdxy/muda/blob/mini20/test/unit_test/launch_test.cu

[AnamicX]

Yes, I was able to compile and run the tests successfully (in cxx20).

ParallelFor works great, but since it doesn’t accept a dim3 parameter, I switched to using Launch instead. When passing an int as the block size, I expected it to behave similarly to ParallelFor (I admit I was being a bit lazy and didn’t use dim3 explicitly🥲).

I’m currently learning CUDA and MUDA, so I’m quite curious what’s the design reason for keeping ParallelFor and Launch separate? And was there a particular reason not to provide a dim3 interface for ParallelFor?

[MuGdxy]

Hmm, to be honest, in my opinion, multi-dim is not a good design. (though cuda does so).

Traversal in multi-dim can be simulated by 1-dim traversal, and sometimes we need user-defined traversal strategy like morton code order, not simply index by index traversal. 🤣

The muda::Launch api is for a fallback to cuda kernel <<<>>>. Say you want to implement advanced WarpBased algorithm. Then it's a good choice.

Otherwise, muda::ParallelFor is what you need.

For my aspect, parallel computation is a task to map a const index sequence 0...N-1, to proper task payload, mapping itself is users' response.

[AnamicX]

Thanks for the clarification and your explanation!

I think it would be great if the static assertion static_assert("You should use ParallelFor()instead ofLaunch() for better semantics"); could be updated to properly trigger and help catch potential issues more effectively.

I’ll go ahead and close the issue. Thanks again for your time and assistance!

[MuGdxy]

Keep the issue open until I fix it.