ONE
ONE copied to clipboard
Samsung
[one-cmds] Introduce 'workflow' in onecc
This issue is organize new "workflow" concect for new tools and to add flexibility in onecc.
Current onecc as of now
- model compilation steps are fixed and user can only swith it on or off
- one-import --> one-optimize --> one-quantize --> one-partition --> one-pack / one-codegen --> one-profile
Needs
- introduce new steps with in onecc, like one-infer and others
- change order of tool execution
- run two or more times for a tool
NOTE: please add a comment or edit this main comment if there is something missing
onecc configuration file is ini format. But, this format is not proper one for supporting workflow. It would become too verbose and get complicated.
So, let's support workflow with json format.
Here is what I think the spec looks like.
{
"workflows": [
"WORKFLOW_NAME0",
"WORKFLOW_NAME1"
],
"WORKFLOW_NAME0": {
"steps": [
"IMPORT0",
"OPTIMIZE0",
"PACK0"
],
"IMPORT0": {
"one-cmd": "one-import-tf",
"commands": {
"input_path": "/path/to/input/path/",
"output_path": "/path/to/output/path/"
}
},
"OPTIMIZE0": {
"pre-configuration": {
"format": "ini",
"path": "/path/to/ini/format/file",
"one-cmd": "one-optimize"
}
},
"PACK0": {
"pre-configuration": {
"format": "json",
"path": "/path/to/json/format/file",
"workflow": "W1",
"step": "PACK2"
}
}
},
"WORKFLOW_NAME1": {
"..."
}
}
This spec has lots of functinality.
Flexible ordering
Current ini format configuration file supports fixed order compilation.
one-import --> one-optimize --> one-quantize --> one-partition --> one-pack / one-codegen --> one-profile
But, with this spec, it'd become more flexible. Note that steps is not fixed order.
{
"workflows": [
"TF_WORKFLOW",
"BACKEND_WORKFLOW",
],
"TF_WORKFLOW": {
"steps": [
"IMPORT0",
"OPTIMIZE0",
"PACK0"
],
},
"BACKNED_WORKFLOW": {
"steps": [
"IMPORT0",
"OPTIMIZE0",
"QUANTIZE0",
"OPTIMIZE1",
"INFER0"
],
}
}
Multiple executions
Current ini format configuration file supports only single execution of each one-cmds tools.
But, with this spec, multiple executions of a single tool would become possible. Note that INFER0 and INFER1 step use the same tool but it can be executed.
{
"workflows": [
"TF_WORKFLOW",
"BACKEND_WORKFLOW",
"COMPARE_WORKFLOW"
],
"TF_WORKFLOW": {
"..."
},
"BACKEND_WORKFLOW": {
"..."
},
"COMPARE_WORKFLOW": {
"steps": [
"INFER0",
"INFER1",
"COMPARE0"
],
"..."
}
}
Reusability of pre-configuration
With this spec, the previously created configuration file can be reused. Not only existing ini format but also json format can be reused. Not only the section of configuration files but also the workflows of them can be reused. Also, pre-configuration contents can be overridden.
{
"workflows": [
"w0",
"w1"
],
"w0": {
"steps": [
"TFimport0",
"optimize0",
"pack0"
],
"TFimport0": {
"one-cmd": "one-import-tf",
"commands": {
"input_path": "/path/to/input/path"
}
},
"optimize0": {
"pre-configuration": {
"format": "ini",
"path": "/path/to/ini/format/file",
"one-cmd": "one-optimize"
}
},
"pack0": {
"pre-configuration": {
"format": "json",
"path": "/path/to/json/format/file",
"workflow": "w1",
"step": "pack2"
}
}
},
"w1" : {
"pre-configuration" : {
"format" : "ini",
"path" : "/path/to/ini/format/file"
}
}
}
@lemmaa @seanshpark @jyoungyun @hyunsik-yoon Please feel free to review this spec.
@mhs4670go , I have a question. How can we describe following workflow in singe *.json file?
W0 ---> W1 ---> W4
|-> W2 -|
+-> W3 -+
@lemmaa It can be like below.
{
"workflows": [
"workflow0"
],
"workflow0": {
"steps": [
"w0",
"w1",
"w2",
"w3",
"w4"
],
"w0": {
"one-cmd": "one-import-tf",
"commands": {
"input_path": "/path/to/input/path"
}
},
"w1": {
"one-cmd": "one-partitioner",
"commands": {
"input_path": "/path/to/input/path"
}
},
"w2": {
"one-cmd": "one-partitioner",
"commands": {
"input_path": "/path/to/input/path"
}
},
"w3": {
"one-cmd": "one-partitioner",
"commands": {
"input_path": "/path/to/input/path"
}
},
"w4": {
"one-cmd": "one-pack",
"commands": {
"input_path": "/path/to/input/path"
}
}
}
}
@lemmaa It can be like below.
@mhs4670go , I'm sorry. My question was not sufficient. In my question, every W* is workflow not a single one-cmd. So, in other words, is there a way to describe complex workflow which consists of branch and merge of other workflows?
@lemmaa Yeah, each workflows and steps runs in sequence so it can act as if they have its dependencies.
{
"workflows": [
"W0",
"W1",
"W2",
"W3",
"W4"
],
"W0": {
"steps": [
"..."
]
},
"W1": {
"steps": [
"..."
]
},
"W2": {
"steps": [
"..."
]
},
"W3": {
"steps": [
"..."
]
},
"W4": {
"steps": [
"..."
]
}
}
If you think it is not sufficient to show their dependencies, dependencies key can be introduced.
{
"workflows": [
"W0",
"W1",
"W2",
"W3",
"W4"
],
"W0": {
"steps": [
"..."
]
},
"W1": {
"dependencies": [
"W0"
],
"steps": [
"..."
]
},
"W2": {
"dependencies": [
"W0"
],
"steps": [
"..."
]
},
"W3": {
"dependencies": [
"W0"
],
"steps": [
"..."
]
},
"W4": {
"dependencies": [
"W1",
"W2",
"W3"
],
"steps": [
"..."
]
}
}
@lemmaa Yeah, each
workflowsandstepsruns in sequence so it can act as if they have its dependencies.
Cool! I understood.
Now it seems that we only need to refine the key name more easily and neatly. For that purpose, how about use a key name of the form reference or cfg-reference instead of pre-configuration? If dependencies is introduced, a key name such as run-after would be good.
Anyway, this is just my personal opinion. It would be nice to get suggestions from several people who will use it and decide on it. :)
(optional) How about using needs keyword? The dependencies means that there is dependence on some other workflows, but it seems to be different from the meaning that the execution is necessary.
Could you explain a little more about workflow and step in pre-configuration? Is it different from dependencies keyword?
Reusability of pre-configuration
With this spec, the previously created configuration file can be reused. Not only existing ini format but also json format can be reused. Not only the section of configuration files but also the workflows of them can be reused. Also, pre-configuration contents can be overridden.
{ "workflows": [ "w0", "w1" ], "w0": { "steps": [ "TFimport0", "optimize0", "pack0" ], "TFimport0": { "one-cmd": "one-import-tf", "commands": { "input_path": "/path/to/input/path" } }, "optimize0": { "pre-configuration": { "format": "ini", "path": "/path/to/ini/format/file", "one-cmd": "one-optimize" } }, "pack0": { "pre-configuration": { "format": "json", "path": "/path/to/json/format/file", "workflow": "w1", "step": "pack2" } } }, "w1" : { "pre-configuration" : { "format" : "ini", "path" : "/path/to/ini/format/file" } } }
This is similar to the workflow feature you wanted. This feature is literally about reusing the parts of existing configuration file. Say you have a ini configuration file like below.
$ cat inception.cfg
[one-import-tf]
input_path=/path/to/inception
output_path=inception_v3.circle
input_arrays=input
input_shapes=1,299,299,3
output_arrays=InceptionV3/Predictions/Reshape_1
converter_version=v1
model_format=graph_def
And, you want to reuse this section in the workflow that you are writing. Then, you can do what you want with pre-configuration key.
"TFimport0": {
"pre-configuration": {
"format": "ini",
"path": "inception.cfg",
"one-cmd": "one-import-tf"
}
},