ONE
ONE copied to clipboard
Revise circle schema
Let's revise circle schema base from TF 2.7.0, schma_v3b.fbs.
Related #6216
CC @hseok-oh , @chunseoklee
Background
- revise common schema may break compile/runtime build
Preliminary plan for compiler modules
- introduce schema copy in res for compiler
- revise mio-circle to use the copy
- (runtime can start upgrading)
- add new (based on v3b) schema as v0.4 and introduce mio-circle04
- revise modules to use mio-circle04 one by one
- after runtime finishes revision, change mio-circle04 to use common schema
Schema draft: #8442
Modules to work
- [x] add mio-circle04
- [x] circledump
- [ ] circlechef
- [ ] forward
- [ ] reverse
- [x] tflite2circle
- [x] luci import
- [x] luci export
- [x] circle-inspect
- [x] ciecle-tensordump
- [x] circle-verify
- [x] pota-quantization-value-test
- [ ] tflite2circle SignatureDef
- [ ] and input/output tensor order match
- [ ] luci import/export with SignatureDef ?
- [ ] ...
- [x] modules with
require("mio-circle")
in CMakeLists.txt
@chunseoklee , @hseok-oh , new schema has now SignatureDef field in the format (currently not migrated from tflite but will work on this soon). Do you think we need this? If so, can you share any benefits you can think of?
@chunseoklee , @hseok-oh , new schema has now SignatureDef field in the format (currently not migrated from tflite but will work on this soon). Do you think we need this? If so, can you share any benefits you can think of?
- I am not used to SignatureDef field(seems like custom IO description)
- Not planned to process it on onert side. But, we may need in the future.
@chunseoklee , OK. I think it would be better to take some time and understand SignatureDef
.
In short, my short understanding of one of the feature is that, this provides input and output node order.
Previous version was the tensor (operand) order itself was the input/output order.
Now, SignatureDef provides the order and the tensor (operand) may be in unordered sequence.
I also don't fully understand the purpose of SignatureDef
.
OK. I think it would be better to take some time and understand SignatureDef.
I agree. I will take a look at sugnaturedef from TFL's viewpoint.
At a glance, (maybe I am wrong)
- In TFL interpreter, signature itself is experimental
- In schema, signaturedef is optional.
It is strange that SignatureDef affects conversion process even although optional. Anyway, I will take a look