Hi Manupa,
> So the RPC feels like an optional layer above the runtime that calls into the > runtime. When you have an fully fledged OS we can rely on dlopen to perform > the necessary linking, thus it was not an issue in the non-micro TVM use > cases. > So for tvm micro use-cases that does not want a RPC in the middle of the > application, following is the approach we are currently pursuing. Feel free > to suggest if there is something else that is better. Got it. Thanks for the example provided. I was missing that use-case. So, for use-cases like in that example, I'm wondering if we should support anything special on the `tvmc` side. The only thing I see specific to that use-case is that it has an runtime "adapter" for TVM C and C++ interfaces (in bundle.c and bundle.cc) that will be used by the application and will be linked by an ad hoc (per project or application that wants to build the static runtime without a RPC server) against the model_c.o or model_cpp.o objects generated via the TVM `build.relay` API. Currently `tvmc` uses `runtime.Module.export_library` when generating `.tar` archive, but for that use-case I believe _it should provide a .o instead_, i.e. use `runtime.Module.save` (like in the example script)? If that is true I think that this document should address at least a way to specify a `.so` or `.o` (as required in that use-case). Then Makefile will call `tvmc` accordingly just passing the model (for instance, `mobilenet0.25`) + a flags specifying that a `.o` must be generated and `tvmc` take care of generating ".o" to be used. Now, how about the "adapters" (`bundle.c` and `bundle.cc`), it seems to me that they are just boilerplate code that we could put into a template dir just like the template dir for a Project-API and copy from it accordingly when generating the Module Library, as @areusch suggested? > In this use case, we in the run we dont have an RPC component at all and the > makefile of the bundle_static is the one generating the final .elf/.hex/.bin > incoporating sources/binaries/static archive built by tvm. Let’s just say tvm > produces the sources as you say (lib0,1,n.c and devc.c) for now. I think > Model Library is proposed as .tar to encapture these. Yeah I agree Model Library should encapsulate the `.c` and `.cpp` and other source files (btw I think this name is a bit misleading, like it takes the name "Library" in it and has more than just libraries inside its guts... but I'll discuss that in the other RFC related to it). So in the very same example (apps/bundle_deploy), lilb0-n.c, dev.c and other sources would land into `src/` and `model_c.o` and `model_cpp.o` would land into `lib/`? Did I get you right? > There is a place inside the proposed Model Library. Maybe we can use that. Yep, I think that too, but would that bundle be inside the project (always) or the working dir where `tvmc` was executed (by default)? > However, my point is we should enable a Model Library pathway as that is the > primary artifact that is produced by tvm that is naturally compiled for the > model given. Yep, definitely. --- [Visit Topic](https://discuss.tvm.apache.org/t/rfc-tvmc-add-support-for-tvm/9049/8) to respond. You are receiving this because you enabled mailing list mode. To unsubscribe from these emails, [click here](https://discuss.tvm.apache.org/email/unsubscribe/cf6b9d7178499eca7365e3c8d0d426363bd7d1b884caa242eeb2f8bcde0a8345).
