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

Document CUDA behavior #28

Open
mbechard opened this issue Mar 31, 2022 · 2 comments
Open

Document CUDA behavior #28

mbechard opened this issue Mar 31, 2022 · 2 comments

Comments

@mbechard
Copy link

Since CUDA is used under the hood, I'd be useful to know what is happening to the calling thread's CUDA context. Is the .dll creating it's own context and pushing/popping it? Could we add a way to just use the calling thread's CUDA context instead?

@josh-disguise
Copy link
Contributor

Renderstream on nvidia systems currently uses a mix of the CUDA runtime API and the CUDA driver API, and so will submit kernels and allocate memory/streams on the default runtime context (created implicitly with cudaSetDevice(0)), which will be set as the current driver context using cuCtxSetCurrent(). If there is already a default context active then we should reuse it.

We haven't had an issue so far where we've conflicted with another use of CUDA in the host application (or needed to use a specific device) but we're aware of the potential issues and we'd definitely be willing to make changes if one arose.

@mbechard
Copy link
Author

We run on multi-GPU systems, so using cudaSetDevice(0) can cause issues for sure. If you can just use the current context that I have setup then that's be easiest. In that case the documentation should suggest that CUDA be setup before calling init(), if the host process uses CUDA.

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

No branches or pull requests

2 participants