Adds a sharedmem CuHandle + python bindings#954
Conversation
|
@neilmacintyre An alternative idea: simply use a new type of CuHandle that can be shared over a memory pool: reasoning, most of the copy overhead will be over large memory buffers (images, point clouds) and having them over cuhandles allow us to safely share them. Python on its side can recover a view & use it in numpy. |
| "def process(ctx, inp, state, output):\n\ | ||
| \x20\x20\x20\x20view = inp.data.memoryview()\n\ |
There was a problem hiding this comment.
Not exactly related to this PR but does the python ctx have a well defined python dataclass?
Also for input and output ideally there would be a interop struct (probably a flatbuffer?) that we could pass into the inp and output types as a generic. In the copperconfig.ron python tasks would be annotated with the expected input and output types.
Ideally there would be some sort of handshake when the cu runtime starts the python subprocesses to make sure that the python process methods agree with the flatbuffer struct specified in the copperconfig.ron.
def process(ctx:Context, inp: Input<Generic_Type>, state: State<Generic_Type>, output):
There was a problem hiding this comment.
this is a little bit orthogonal to this PR. The python types are contructed from cu29-values in the passed message if they are out of process, I'll see if I can infer the actual python type annotation.
Summary
This adds a new type of CuHandle that is sharedmem type. This helps for sharing safely 0 copy large buffers with other processes like python tasks.
Related issues
Changes
Testing
just fmtjust lintjust testjust std-ci(if std/runtime paths are impacted)just nostd-ci(if embedded/no_std paths are impacted)pro-tip:
justwith no parameters in the root defaults tojust fmt,just lint, andjust test.Checklist
Breaking changes (if any)
Additional context