One: Compiler FE: enhance one-cmds arguments interface

[seanshpark]

Problem:

• Users or upper level tools(like SDK) will call our one-cmds command line tools with lots of arguments
• One time calling is OK but periodic calling with long arguments may be inconvenient (we may copy-paste or use bash history)
• With one or two argument changes to test artifacts

One solution that came up:

• To provide a easy-to-edit simple text configuration file(like old ini or cfg file) that can cover all the arguments
• We can then use existing arguments to override the configuration file items

Let's talk about this...

• Objective of this issue is to define the solution/specification to solve this problem
• And to provide this in Oct or Nov release

[seanshpark]

An example

one-import tf -c detectimage.cfg

where there is detectimage.pb file as an input model

[seanshpark]

specification

To be added

[mhs4670go]

suggestion

one-compile.config

# This configuration file is used to configure the parameters and initial settings for ONE command driver.

# input_path                    Path to input model
input_path=""
# output_path                   Path to output model
output_path=""

### one-import-tf ### one-import-bcq ###
# input_arrays                  Names of the input arrays, comma-separated
input_arrays=""
# input_shapes                  Input shapes, colon-separated
input_shapes=""
# output_arrays                 Names of the output arrays, comma-separated
output_arrays=""
# v2                            Use TensorFlow 2.x interface (default is 1.x interface)
v2="false"

### one-import-tflite ###

### one-optimize ###
# all                           Enable all optimization algorithms
all="true"
# fuse_bcq                      Enable FuseBCQ Pass
fuse_bcq="false"
# fuse_instnorm                 Enable FuseInstanceNormalization Pass
fuse_instnorm="false"
# resolve_customop_add          Enable ResolveCustomOpAddPass Pass
resolve_customop_add="false"
# resolve_customop_batchmatmul  Enable ResolveCustomOpBatchMatMulPass Pass
resolve_customop_batchmatmul="false"
# resolve_customop_matmul       Enable ResolveCustomOpMatMulPass Pass
resolve_customop_matmul="false"

### one-quantize ###
# input_dtype                   Input data type (supported: float32, default=float32)
input_dtype=""
# quantized_dtype               Output quantized data type (supported: uint8, default=uint8)
quantized_dtype=""
# granularity                   Quantize granularity (supported: layer, channel, default=layer)
granularity=""
# min_percentile                Minimum percentile (0.0~100.0, default=1.0)
min_percentile=""
# max_percentile                Maximum percentile (0.0~100.0, default=99.0)
max_percentile=""
# mode                          Record mode (supported: percentile/moving_average, default=percentile)
mode=""
# input_data                    Path to input data
input_data=""

### one-pack ###
# nnpackage_path                Path to nnpackage folder
nnpackage_path=""

### one-codegen ###
# BACKEND dirvers
#backend_drivers="driver1;driver2;..."

[seanshpark]

If we use one-compile.config file for all one-cmds, each input path and output path may be different.
For this, @lemmaa suggested using section, something like this;

[import]
input_path="..."
output_path="..."

[optimize]
input_path="..."
output_path="..."

[quantize]
input_path="..."
output_path="..."

...

[lemmaa]

FYI, various INI parsers by googling. Didn't checked in detail. :)

• C++: https://github.com/mcmtroffaes/inipp
• Python : https://docs.python.org/3/library/configparser.html
• Bash: https://github.com/albfan/bash-ini-parser
• ...

[mhs4670go]

@seanshpark @lemmaa
Both of comments sound good for me.

FYI, I had considered the things you pointed before posting above my comment. Here is what I thought of them.

only one input and output path or each

each input path and output path may be different

I thought most of users want to just run all the ONE drivers at once. This is a consideration of whether the user cares about "each" driver's input and output. If the user wants the output of a specific driver, they can either modify input in the config file or override the input directly from the command line. Also, by the way, latter looks too verbose.

INI format or not

Actually, my suggestion came out for convenience of implementation. I just wanted to source the config file, which makes it easy to write a one-compile bash script. Moreover, in the former case, we have to create a parser in any language or have a dependency on a specific library.

[seanshpark]

only one input and output path or each

If we provide only one input and one output, I think there will be no problem if intermediate paths can be generated and avoid conflicts.

[mhs4670go]

Also, FYI, here is how above suggestion came out.

1. I put the required options of each one-cmds driver in one place.
2. Among these, duplicates were removed, and in this case, the duplicates were input_path and output_path.

(one-import-tflite and one-codegen section got notthing because they only need input and output)

One thing to consider here is whether or not to combine the nnpackage_path of one-pack into the output_path. Here is what I thought.

$ cat one-compile.config
...
output_path="inception_v3.circle"
...
nnpackage_path="nnpack"
...

The result would be

└── nnpack # -> `nnpackage_path`
    └── inception_v3 
        ├── inception_v3.circle # -> `output_path`
        └── metadata
            └── MANIFEST

[parjong]

It may be handy if a user could load configuration from a file first, and then override its parameter via command line

$ one-import tf -c detectimage.cfg --output-arrays "..."

(ADDED) It is sometimes useful to compose multiple configurations ;-)

$ one-import tf -c input.cfg -c for_detection.cfg
$ one-import tf -c input.cfg -c for_feature_extraction.cfg

[parjong]

FYI, various INI parsers by googling. Didn't checked in detail. :)

* C++: https://github.com/mcmtroffaes/inipp

* Python : https://docs.python.org/3/library/configparser.html

* Bash: https://github.com/albfan/bash-ini-parser

* ...

YAML/TOML fit well for this purpose IMHO.

[seanshpark]

To support input/output types for use cases

1. Inputs
   
   
   
   • TF model (frozen, saved, keras)
   
   
   • TF lite
   
   
   • TF lite quantized
   
   
2. Output
   
   
   
   • nnpackage
   
   
   • specific backend
   
   

[lemmaa]

/cc @Samsung/sdk

[seanshpark]

/cc @Samsung/sdk

[winstone77]

1. MDK wants to compile using an integrated driver. (Similar to current tf2nnpkg) It seems that the input/output path does not need to be classified by driver. Would it be a burden to manage intermediate files internally? (In the MDK view, these intermediated files are not needed.) I haven't yet thought of a scenario in which individual drivers are called sequentially or conditionally. Is this usecase necessary? (The requirement to create a sub-pipeline within the compile phase is currently not considered.)
2. Can I know when to receive the integrated driver roughly? Regarding the final output (nnpackage and specific backend type), it would be nice if the final output type could be determined by an argument of integrated driver.
3. In the case of model info (## one-import-tf), nnCompress is currently providing relevant information. We need to consult with nnCompress developer in advance.
4. I am going to create a default config file in MDK and create a menu with UI for options expected to be used a lot. (In this case, the modified option can be passed as an argument, is it possible to handle override?) If you inform the option that requires user input, we will first work on the UI.

[llFreetimell]

@winstone77

Then can it be summarized as follow?

• Using .cfg file is okay. Thus MDK will try to create default config file for MDK and related UI after consulting with NNCompress.
  
  
  
  • Meanwhile, MDK wants to know what configuration options are mandatory and whether overriding options is possible or not.
  
  
• However, MDK do not want to care about configurations related with intermediate files if possible, since MDK do not need it.
• In addition, sequential calling the driver is not considered yet. If this is necessary usecase, discussion is needed.

---

the modified option can be passed as an argument, is it possible to handle override?

@mhs4670go Can we implement to enable overriding options?

---

Can I know when to receive the integrated driver roughly?

@seanshpark Can you answer for this question?

[seanshpark]

@seanshpark Can you answer for this question?

This too will be answered by @mhs4670go :)

[lemmaa]

https://github.com/Samsung/ONE/issues/4278#issuecomment-693758144

I thought most of users want to just run all the ONE drivers at once. ...

@mhs4670go , Yes, most, not all.

We are not discussing this to support a single representative scenario. MDK's requirements are just one of the many scenarios we have to do. Therefore, we expect to be able to handle the input and output at the beginning and end, as well as at various parts in the middle of chains, in the configuration file.

[seanshpark]

close?