Add ObjectCode.get_module() for legacy driver API integration#2339
Conversation
|
/ok to test 600176e |
This comment has been minimized.
This comment has been minimized.
| cdef cydriver.CUmodule mod | ||
| with nogil: | ||
| HANDLE_RETURN(cydriver.cuLibraryGetModule(&mod, as_cu(self._h_library))) | ||
| return driver.CUmodule(<intptr_t>mod) |
There was a problem hiding this comment.
Q: Shouldn't we use as_py() to do the return value conversion?
Q: How do we teach the difference between .get_module() and .handle?
There was a problem hiding this comment.
Sorry for not getting back sooner. I shifted focus to issue #2179, for which I need to set up cuda bindings development environment for the first time.
It looks as_py() does not provide support for CUmodule type yet. I am not sure if we should add the support there per CUmodule is deemed as legacy API. But let me know if you find the support favorable. Happy to add that.
For .handle vs .get_module(): I'll clarify in the docstring.
Document that .handle returns the native context-independent CUlibrary for cuda.core/newer APIs, while get_module() is a legacy-interop bridge returning a context-dependent CUmodule via cuLibraryGetModule.
|
/ok to test b56e37e |
isVoid
left a comment
There was a problem hiding this comment.
I think we can create a new as_py function in _resource_handle.hpp that accpets cumodule type. But this can be set as a follow up issue.
This comment has been minimized.
This comment has been minimized.
1 similar comment
|
Description
closes #489
Add
ObjectCode.get_module()to expose theCUmodulefor the current context viacuLibraryGetModule, so code using legacy driver APIs can interoperate withcuda.core's context-independentCUlibraryloading.Checklist