Hi All,
I had a go at it implementing the some of the discussed changes :
https://github.com/apache/incubator-tvm/pull/6950.
---
[Visit
Topic](https://discuss.tvm.apache.org/t/external-modules-in-utvm/7993/13) to
respond.
You are receiving this because you enabled mailing list mode.
To
Yes, we should build a solution that directly bake the weight into the rodata
section without having to decode from a meta-data. I think we have a good path
to make it working.
---
[Visit
Topic](https://discuss.tvm.apache.org/t/external-modules-in-utvm/7993/12) to
respond.
You are recei
that sounds pretty reasonable to me. I need to read more about the metadata
encoding, but it seems like we should avoid copying data out of flash.
---
[Visit
Topic](https://discuss.tvm.apache.org/t/external-modules-in-utvm/7993/11) to
respond.
You are receiving this because you enabled m
Sounds good!. I ll take a look at your fork for now and see what we can do.
Regarding PackConstantsToLLVM, I think this is the intention behind the design
of the metadata module (cc : @comaniac @zhiics). I believe a solution lies
where we could generally support it rather than using it to cate
@manupa-arm yeah exactly--the main difference is that µTVM wants a static
library by default. i'm okay with O1 (reusing export_library) so long as we
don't need to change export_library too much to accommodate µTVM (i don't
believe any changes are needed, after reviewing it here).
for my auto
@tqchen, I think we should handle the weights more generally. Here I was
referring to binary artifacts that are produced (which are not present in the
relay graph initially as weights do) as part of the lowering of the external
function that is required in the runtime.
---
[Visit Topic](h
I agree that putting weight as constant would be an import question. This is
something that is probably orthogonal to the C source module, as we might be
able to create a similar util via LLVM(like what we did in the PackImports)
---
[Visit Topic](https://discuss.tvm.apache.org/t/external-
@areusch looking at the design of export_library, it seems it is designed to
generate a shared object. Thus, the difference in uTVM (w.r.t. TVM) would be
that we would want to statically link it with the runtime in the compile time
itself. What are your thoughts of re-using the export_library
@manupa-arm ah I don't necessarily think use of `fcompile` is a bad idea, but
for µTVM then that does mean that you *must* pass `fcompile`, so we just need
to make sure the API is easy/obvious enough to use (or build another API on top
of this).
re: the `SaveToBinary`: I agree that would be
O1 is the most ideal, since we want to have a single export_library function
for all backends( with linking behavior customed via fcompile)
---
[Visit Topic](https://discuss.tvm.apache.org/t/external-modules-in-utvm/7993/4)
to respond.
You are receiving this because you enabled mailing li
hi @areusch,
Thanks for the reply!
We dont have a strict requirement per se to generate a c-source module. In
fact, even if we did it would be the same source -- just binary artifacts being
different. That sounds to me like we could go with O1 ?
Anyhow, micro-specific or not, why do you thin
hi @manupa-arm,
seems like we have two options:
O1. build a library version of this [StaticRuntime fcompile
function](https://github.com/areusch/incubator-tvm/blob/utvm-runtime/python/tvm/micro/build.py#L217)
and make `export_library` call this function to create something like a DSO
(instea
I've seen that current uTVM flow uses module.save(..) interface to save the "c"
module prior to compiling it to the micro binary that is fed to the runtime. I
was wondering if we use the BYOC on the flow and create our own external
c-source module/function additionally to the single dso_module
13 matches
Mail list logo
