hi @manupa-arm,
I think going forward graph executor might be able to load a packed function of the tvm_main instead of json – it’ll be less confusing as how the graph executor runtime is positioned as of today which is more of a (a very thin – as its supposed to be
) middleware that connect the graph json and the compiled operator library.
Could you say more about how this proposal relates to GraphPlanMemory? I’m wondering if this proposal aims to modify GraphPlanMemory (e.g. to generate the same BufferInfo and then use a similarly pluggable planning function)?
Here I am referencing what is being discussed here : [RFC] [uTVM] Embedded C Runtime Interface - #6 by Mousius. I think its better to reach an agreement there. Here Im trying to illustrate and motivate the design using the APIs.
Ack, will follow-up there.
Yes, the USMP will only touch tir.allocates that could be evaluated in the compile time will be translated to offset. We could just leave the rest untouched to be TVMBAWs that is ultimately handled in the runtime (using malloc or stack_allocator). I think thats the only thing we require. Do we miss anything here? – I’ll adjust the original text to reflect this.
I think this makes sense to me.
Step 3 : Use the updated Map<tir::Var, BufferInfo> to generate Array, Map<String, Integer> pool_sizes
Step 4 : Call the provided/default algorithm (void (*foo)(Array buffers, Map<String, Integer> pool_sizes) to populate pool_id and pool_offset.
Could you clarify Step 3 here? How do we pass BufferInfo to the provided planning algorithm? Can it be a PackedFunc?
T1. --with-parameter-buffer & --with-workspace-buffer
T2. --with-constant-buffer & --with-workspace-buffer
T3. --parameter-buffer & --workspace-buffer
T4. --constant-buffer & --workspace-buffer
Could you give some more information about the arguments to these parameters?