HI All, I was wondering, whether we can use
[flatbuffer](https://google.github.io/flatbuffers/) for serializing params.
In that way we can customize the framework according to our suit as its
opensource and it will be target agnostic.
I am working on a prototype currently. However i wanted
It would be helpful to ask why and why not when introducing new dependencies.
See some of the examples in the design decision above. Flatbuffer coould be
useful when we need to serialize a complicated set of objects, but also
introduces an additional layer of abstraction.
Given that we are on
@tqchen: Thank you very much for your enlightening response!
I agree it will introduce an additional layer, but it may have an additional
performance benefit as well even when the store is for simple objects with
Flatbuffer or more precisely Flexbuffers used. I was thinking of a scenario
wh
Note that the parameter has to be loaded into DRAM, so there is no place where
we could do partial weight load.
For memory limited scenarios like embedded devices, we would certainly need to
go for a different solution, for example directly store weights in the rodata
section to remove the ne
Thanks! Agree we can utilize rodata for that case.
May be that is for another thread of discussion.
Would you please help me about the basic question i raised? What i am trying to
figure out here is from the user perspective - the standard way to save and
reuse weights. As in the current thre
Please start another discuss thread for new questions(of weight serialization).
The current proposal does have a `package_params` option that packages the
weight.
---
[Visit
Topic](https://discuss.tvm.ai/t/discuss-module-based-model-runtime-interface/5025/68)
to respond.
You are receivi
Thank you, will start a new thread about that.
About the original post in the thread, i do have one small concern.
Whenever we provide Export_library a path, it always has to be accompanied with
correct extension name.
Like below:
`mod.export_library("xx.so")`
As we are coming up with a Pack
Hi Everyone (especially fellow uTVM fans)
I've been looking at micro.device.arm.*, micro.Session and related code like
openocd_low_level_device.cc in src/runtime/micro.
At first blush I feel like we should be looking at other means to drive a
session besides perhaps OpenOCD especially when I
Thanks for bringing this up, this is definitely on our radar! The initial [uTVM
PR](https://github.com/apache/incubator-tvm/pull/5417) was intended to sync our
prototype work, based on the [original
RFC](https://github.com/apache/incubator-tvm/issues/2563), up to master. We'll
have some initi
https://github.com/apache/incubator-tvm/pull/5572
---
[Visit
Topic](https://discuss.tvm.ai/t/ci-lint-enabling-clang-format-based-lint-checks/6170/13)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click
here](https://discuss.
10 matches
Mail list logo
