René Widera
René Widera
After starting the first try to fix it I realized that fixing this issue would take very long because it would affect all accelerators and many traits because we merged...
copied from: https://github.com/alpaka-group/alpaka/pull/2219#issuecomment-1892393476 I am wondering if it makes more sense to remove `alpaka::exec()` and provide `alpaka::enqueue(queue, workdiv, kernel)` or `alpaka::enqueue(alpaka::TagGpuCudaRt, queue, workdiv, kernel)`? I do not see a real...
offline discussed in the dev meeting: We will keep both methods. `alpaka:exec()` is heavily used by CERN and will for compatibility reasons stay. @fwyzard also mentioned that we need to...
As I know @SimeonEhrig is working on bringing CPU CI tests to GitLab, I assume the analysis test will be moved too.
As I know there are currently no plans. One issue is that fp16 is not supported for atomics but the question is if this is important. In general, there was...
In newer alpaka version we check the CUDA requirement that a kernel and all arguments passed to the kernel must be trivially copyable. In your case, one of the parameters...
I opened #1992 and will check if I can provide tomorrow an PR to help you with the debugging,
As soon as #1993 is merged finding the argument which is not trivially copyable should be easier.
> While the work in #1993 is certainly useful, isn't this failing for the kernel itself? So the thing that encapsulates `operator()(TAcc acc, ...)` isn't trivially copyable. Only user arguments...
Do you have the internal bug ID of your ticket?