feat: python bindings for host and device memory resources#5492
feat: python bindings for host and device memory resources#5492paradajzblond wants to merge 5 commits into
Conversation
|
@paradajzblond the title prefix should not contain ` also using @ in the description will result in it being copied into the commit message and people will be notified by github every time the commit gets pushed somewhere |
| void bind_traccc_host(py::module_& m) { | ||
| // ---- traccc types ---- | ||
| py::class_<traccc::memory_resource, std::shared_ptr<traccc::memory_resource>>( | ||
| m, "TracccMemoryResource") |
There was a problem hiding this comment.
With this the type name in Python would end up being acts.traccc.TracccMemoryResource? 🤔
It's not a black or white question, but as long as we keep the C++ type names with their current naming convention, I would prefer the Python name to be acts.traccc.memory_resource. 🤔
|
|
||
| void bind_traccc_cuda(py::module_& m) { | ||
| py::class_<traccc::cuda::stream, std::shared_ptr<traccc::cuda::stream>>( | ||
| m, "CudaStream") |
There was a problem hiding this comment.
So, what's the conclusion here? Is it not possible to achieve a type name of acts.traccc.cuda.stream?
If not, then I would still prefer acts.traccc.cuda_stream.
But I'd really be interested in the opinion of people more experienced with pybind11 on whether we could add "additional namespaces" into these names. 🤔
There was a problem hiding this comment.
apparently you can do this with submodules, so will change this
feat: python bindings for host and device memory resources04d4696 to
1ff4239
Compare
|
|
I have already created a
|
We need a safe guard against building cuda components, originally I had everything in a single file because I wanted to construct composites ie you can retrieve the correct bundle of memory resources, stream and copy in a single call. However, Stefl suggested that we rather have separate files and the compilation is safeguarded by the stub mechanism, so this is where those changes come from. |
|
where do we stand here @paradajzblond @asalzburger ? apart from the discussion there seem to be cmake configuration errors in the CI |



As discussed with krasznaa this builds on top of asalzburger #5449 and adds the resources needed in #5348