-
Notifications
You must be signed in to change notification settings - Fork 35
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
Calls to malloc/free from inside HIP kernels #175
Comments
The basic plan so far has been to add a shadow buffer to the kernel which is basically the "heap" when the kernel calls malloc/free and implement dynamic memory management by returning chunks from the buffer. |
Can't we do this in SPIR-V? |
OpenCL (and thus SPIR-V in this case) doesn't support device-side dynamic memory allocation. We could define a new OpenCL extension that does, but it's better to provide a portable solution that works with the current Intel drivers. |
SPIR-V Specification Why can't we use this? |
It's for static (compile time size known) memory allocation. |
Ah, I see. |
Not much other way around this without an extension. The size of the buffer to allocate will be a problem though, and a hint (or upper bound) regarding the amount of memory involved would be very useful here, unfortunately in the general case this will be intractable. Drivers that have device side enqueue must have the necessary functionalities already, so it may be an easy extension for them to implement if we define it right. |
I played around device malloc implementation in CUDA11 and here is my observation :
With above observation I think as @pjaaskel mentioned in his response having buffer allocated a chunk of memory of fixed size will be a valid approach. Only point I have is this is device limit hence buffer/heap should be tied to per device not per kernel. Below is the test I used to check cuda behavior
|
https://reviews.llvm.org/rGa6213088812f this seems like an interesting work to build upon for device side malloc/free and possibly other services. @linehill |
ROCm/HIP#2975
How do we enable this? @pjaaskel @Kerilk
The text was updated successfully, but these errors were encountered: