Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move wrap() methods for significant wrapper classes out of detail_:: #298

Closed
codecircuit opened this issue Feb 7, 2022 · 5 comments
Closed

Comments

@codecircuit
Copy link
Contributor

I might not found it, but there seems no way to construct a non-owning cuda::stream_t object from a native cudaStream_t without using a function from the detail_ namespace. I think this would be useful to improve the interoperability with other libraries. We could add a usage example in stream_management.cu.

@eyalroz
Copy link
Owner

eyalroz commented Feb 7, 2022

The relevant function is, indeed, in the detail_:: namespace: cuda::stream::detail_::wrap(). We also have cuda::event::detail_::wrap(). Do you think the wrap() functions should be outside the detail_ namespace?

@codecircuit
Copy link
Contributor Author

Every function in a detail namespace is not part of the exposed library interface and usage outside of the library is discouraged.

I do not have a reference for that, but intuitively this is what I expect from a detail/internal namespace. This enables also changes within the detail namespace of the library without breaking user code.

@eyalroz
Copy link
Owner

eyalroz commented Feb 8, 2022

@codecircuit : Well, if you interact with CUDA through the wrappers, you won't need to wrap any handles. But it's true that if you mix API wrappers code with other CUDA-related code, then you might. So I guess I can take the wrap() out of detail_.

@eyalroz eyalroz changed the title How to construct a non-owning stream_t object without using detail_ namespace? Move wrap() methods for significant wrapper classes out of detail_:: Feb 8, 2022
@eyalroz eyalroz added the task label Feb 8, 2022
@eyalroz eyalroz self-assigned this Feb 8, 2022
@eyalroz
Copy link
Owner

eyalroz commented Feb 8, 2022

@codecircuit : Please give v0.4.5-rc2 a spin...

@eyalroz
Copy link
Owner

eyalroz commented Feb 8, 2022

Wait a minute though.

Do you think that the function for wrapping a stream handle should be all-low-level? i.e. take the device handle? Or should it take a device_t? And similarly, when wrapping something with more context, e.g. both a CUDA device, and a CUDA context for a driver-API stream - should I also take the lower-level handles or the device_t and the context_t? In the non-detail_ function I mean?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants