Remove cu::Context class #316
Conversation
|
I do not think that I like it. It is a major deviation from the idea to stay close to the CUDA driver API. Also, it breaks basically all the libraries and applications that we have. |
|
Going forward, I see a couple of options. In no particular order:
For 1. and 2., we would also have to revert the deprecation message to improve the user experience. I would be strongly in favour of option 3. or 4. Option 3. maintains compatibility with existing code, but could also confuse the user. People arguably shouldn't use the There is one thing that still may be need to be addressed for 3. or 4., the |
include/cudawrappers/cu.hpp
Outdated
| if (active) { | ||
| checkCudaCall(cuDevicePrimaryCtxRetain(&_pctx, _obj)); | ||
| } else { | ||
| checkCudaCall(cuCtxCreate(&_pctx, flags, _obj)); |
There was a problem hiding this comment.
If you create it here you are responsible for it so maybe you can set the the context inside a ptr and change the manager to do nothing in the first two cases
There was a problem hiding this comment.
Good point, we should indeed clean-up afterwards. I now added a _context_manager member that does this. It releases the context in case there was already a primary context, or it destroys it when it created one.
|
If we leave it as is we should print something during compilation when using HIP. The context functions are doing nothing... |
|
Can't we just make them noops for AMD only? Can a Context::setCurrent() be safely ignored on AMD GPUs? |
The Context Management is now done in the constructor of the cu::Device class.
To this end, even when the primary context is retained, the returned Cucontext object must be stored in the _context_manager.
With HIP on an AMD GPU, allocating CU_MEMORYTYPE_UNIFIED has type CU_MEMORYTYPE_HOST, causing the check to fail. It is weird that this didn't cause problems before changing the Context class. Alternatively, we could query and store the memory type in the constuctor.
for more information, see https://pre-commit.ci
and @john-romein
Can you check the latest code to see how I solved it? There is no need for no-ops. Both in CUDA and HIP mode, you can use the same The only difference between the two is that CUDA will complain about an invalid device context when you try to use the device without calling |
Remove the
cu::Contextclass. The Context Management is now done in the constructor of the cu::Device class.When a Primary Context was already active, e.g. when combining cudawrappers with the NVIDIA Runtime API, that context is retained. If not, a new Context is created.
Some tests had to be removed, while others were adapted slightly. When building in HIP mode, the Context code is disabled. The code is tested locally on NVIDIA en AMD en all pass.
Description
Related issues:
Instructions to review the pull request