Alpaka VecMem Interface, main branch (2025.05.01.) #959
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a proposal for how I'd imagine using Alpaka in the longer term. This was triggered by #958, whose code I didn't really like. But since I have very little experience with Alpaka, I wanted to try out for myself what sort of code could be written.
@CrossR, @StewMH, this is how I imagine that things could look like. 🤔
traccc::alpaka::queue
is the same sort of thing that you tried to make as well Ryan. I just simplified it so that it would only expose the underlying Alpaka queue, and not try to be too smart with the native devices/queues.traccc::alpaka::vecmem_objects
has the interface that Ryan made, just with a (in my mind) much simpler implementation.You see, once you hide the choice of VecMem objects behind such a non-specific interface, you can just use simple pre-processor statements in the background. There's no need to mix pre-processor formalism with traits in this case.
Please check if this sort of a setup could be made to work with the existing algorithms. Since that I didn't really try...