[TVM Discuss] [Development/RFC] [RFC] Improvements to Automatic Quantization for Bare-Metal
@cbalint13 Ahh. My branch is trailing behind `master` a bit, so I missed this. Thanks for the heads up! --- [Visit Topic](https://discuss.tvm.ai/t/rfc-improvements-to-automatic-quantization-for-bare-metal/7108/3) to respond. You are receiving this because you enabled mailing list mode. To unsubscribe from these emails, [click here](https://discuss.tvm.ai/email/unsubscribe/b2f65f8fc074e91ccbf5eebb5e324ff3ba65cdf56a07c36c20d338e1bcf7d444).
Re: [apache/incubator-tvm] [VOTE] Release Apache TVM (incubating) v0.6.1.rc1 (#5947)
+1 -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/apache/incubator-tvm/issues/5947#issuecomment-651300467
Re: [apache/incubator-tvm] [VOTE] Release Apache TVM (incubating) v0.6.1.rc1 (#5947)
+1 -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/apache/incubator-tvm/issues/5947#issuecomment-651300572
Re: [apache/incubator-tvm] [VOTE] Release Apache TVM (incubating) v0.6.1.rc1 (#5947)
+1 -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/apache/incubator-tvm/issues/5947#issuecomment-651301091
Re: [apache/incubator-tvm] [VOTE] Release Apache TVM (incubating) v0.6.1.rc1 (#5947)
+1 -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/apache/incubator-tvm/issues/5947#issuecomment-651301867
Re: [apache/incubator-tvm] [VOTE] Release Apache TVM (incubating) v0.6.1.rc1 (#5947)
+1 -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/apache/incubator-tvm/issues/5947#issuecomment-651304553
Re: [apache/incubator-tvm] [VOTE] Release Apache TVM (incubating) v0.6.1.rc1 (#5947)
+1 -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/apache/incubator-tvm/issues/5947#issuecomment-651307711
Re: [apache/incubator-tvm] [VOTE] Release Apache TVM (incubating) v0.6.1.rc1 (#5947)
+1 -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/apache/incubator-tvm/issues/5947#issuecomment-651326848
Re: [apache/incubator-tvm] [VOTE] Release Apache TVM (incubating) v0.6.1.rc1 (#5947)
+1 (binding) I checked hashes and performed a default build on Ubuntu 20.04 on Windows 2004. Markus On Mon, Jun 29, 2020 at 12:57 PM Cody Yu wrote: > > +1 > > -- > You are receiving this because you are subscribed to this thread. > Reply to this email directly or view it on GitHub: > https://github.com/apache/incubator-tvm/issues/5947#issuecomment-651326848 - To unsubscribe, e-mail: dev-unsubscr...@tvm.apache.org For additional commands, e-mail: dev-h...@tvm.apache.org
[TVM Discuss] [RFC] Canonicalizing AutoTVM Log Format
addressing @mdw-octoml's points: - I will add a comment addressing the semantics of the dtype field in the proto. - I will further refine the spec to avoid Any. I originally included google.protobuf.Any to capture the current tuple argument semantics, which seemingly supports arbitrary nesting here https://github.com/apache/incubator-tvm/blob/master/python/tvm/autotvm/task/task.py#L43-L63. It looks like stakeholders prefer to improve the format rather than use it as a snapshot, so this will warrant further discussion. - re: tightening up the proto semantics. I will add comments to the proto to elucidate the following: `version` refers to log format schema version as a SemVer string. An example of `tvm_version` is "0.7.dev1" and afaik that doesn't follow SemVer, but I will comment on the expected format. I agree that timestamp should be an ISO-8601 formatted timestamp and will make this change. - It looks like Config will have some drastic changes, so I will convert the Config message to containing a oneof field. --- [Visit Topic](https://discuss.tvm.ai/t/rfc-canonicalizing-autotvm-log-format/7038/21) to respond. You are receiving this because you enabled mailing list mode. To unsubscribe from these emails, [click here](https://discuss.tvm.ai/email/unsubscribe/ff94f38a6467f771b166a646801e2fcaa67baed3c25b66b5ac02bbade110e009).
[TVM Discuss] [RFC] Canonicalizing AutoTVM Log Format
@comaniac ~~I will change `workload` to `task`.~~ Since ansor is not op-based,
I think it makes sense to keep the `workload` syntax to prepare for ansor's log
format changes.
I agree that the list-based representation of arguments is less than ideal --
currently it's hard to understand the semantics of any particular argument.
If we go with a "kwargs" approach I think we should not support "arbitrary"
kwargs, since the proto would necessarily need to look like
```go
message Task {
string task_name = 1;
map args = 2;
}
```
or
```
message Task {
string task_name = 1;
map args = 2;
}
```
The "arbitrary kwarg" approach doesn't restrict the type of a particular
argument in any meaningful way, and I feel the point of formalizing a schema is
to add these restrictions. I think it would be better to have a full
enumeration of the possible arguments for the task. @comaniac what do you
think? Is the example you provided an exhaustive representation of possible
arguments? If not and you agree that we should restrict possible arguments,
could you provide or point me to where I can find the right enumeration?
---
[Visit
Topic](https://discuss.tvm.ai/t/rfc-canonicalizing-autotvm-log-format/7038/22)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click
here](https://discuss.tvm.ai/email/unsubscribe/72933130888c3eb94a8fa76ba0cc3d9884905064b8885702b15d09dec1fff074).
[TVM Discuss] [RFC] Canonicalizing AutoTVM Log Format
@anwang Ansor also has a "task" concept. A task is not necessary to be just for one operator. It just means a "tuning" task. As a result, I still vote for task. In addition, I don't think full enumeration is proper for several reasons. 1. Full enumeration will lose the flexibility when adding new tasks. 2. It would make the log too long and tedious, because the task arguments (attributes) are very different. For example, this is the task arguments for `conv2d_NCHWc.x86`: https://github.com/apache/incubator-tvm/blob/master/topi/python/topi/x86/conv2d.py#L149 And this is `dense.nopack.x86`: https://github.com/apache/incubator-tvm/blob/master/topi/python/topi/x86/dense.py#L138 You can basically search for `autotvm.register_topi_compute` in TOPI to see all task function arguments. Unless we can also canonicalize the task arguments, it seems impractical have a full enumeration argument list. Consequently, IMHO, supporting arbitrary kwargs arguments would be more practical. --- [Visit Topic](https://discuss.tvm.ai/t/rfc-canonicalizing-autotvm-log-format/7038/23) to respond. You are receiving this because you enabled mailing list mode. To unsubscribe from these emails, [click here](https://discuss.tvm.ai/email/unsubscribe/aab74f165fa33fdbbd90ee6e519c21457cbb90c0acd92c78b7bfe01d21c3d33a).
[TVM Discuss] [Development/RFC] [RFC][BYOC] Data Calibration Flow
Gentle ping for comments @anijain2305, @masahi, @matt-arm, @tqchen :) --- [Visit Topic](https://discuss.tvm.ai/t/rfc-byoc-data-calibration-flow/7099/4) to respond. You are receiving this because you enabled mailing list mode. To unsubscribe from these emails, [click here](https://discuss.tvm.ai/email/unsubscribe/ccc662f7f0481f509386fe9e4bdf7fbfc2f9a7ad1a90991b61032b606885c5ee).
[TVM Discuss] [RFC] Canonicalizing AutoTVM Log Format
I see. Thanks for clarifying @comaniac, I agree with your comments.
Addressing @merrymercy's points:
- One possible solution to the redundancy of repeating items such as target
string would be to encode something like this: `message AutoTVMLogs{ string
target; repeated AutoTVMLog; ...} ` where the inner AutoTVMLog no longer
indicates the target string. However, this change would make it more difficult
to adhere to the "one record per line" json standard AutoTVM currently holds.
For simplicity I prefer keeping the redundancy, but since I haven't worked very
closely with the logs myself, I will defer to others' takes.
- The proposed implementation will allow manipulation of readable json.
- The major differences you indicated can modify the proto as desired when
ansor is ready.
Here is an updated proposal of the protobuf given everyone's feedback.
```go
syntax = "proto3";
package autotvm.log;
import "google/protobuf/any.proto";
message Target {
// For now this is the string representation of a target; e.g. "llvm
-mcpu=broadwell"
// This should be replaced once the rfc "TVM Target specification" is
finalized
string target_string = 1;
}
message AutoTVMLog {
// The compilation target
Target target = 1;
// Represents a tuning task
Task task = 2;
// The configuration used by this task
Config config = 3;
// Tuning results
Result result = 4;
// SemVer string describing the AutoTVM log format version
string version = 5;
// SemVer string with qualifiers attached as a suffix. e.g. "0.7.dev1"
string tvm_version = 6;
}
message Task {
// Human-readable task name
string task_name = 1;
// Map of keyword arguments where the key indicates argument name
map args = 2;
}
message Argument {
oneof arg {
Tensor tensor = 1;
// Possible tuple values are not well specified and may require more
sorting out
//
https://github.com/apache/incubator-tvm/blob/master/python/tvm/autotvm/task/task.py#L43-L63
Tuple tuple = 2;
string value = 3;
}
}
message Tensor {
repeated uint32 shape = 1;
// Indicates a numpy dtype
string dtype = 2;
}
message Tuple {
repeated google.protobuf.Any values = 1;
}
// Config for AutoTVM v1
message Config_v1 {
// code hash
string code_hash = 1;
repeated Entity entities = 2;
uint32 index = 3;
}
message Config {
oneof config {
Config_v1 config_v1 = 1;
}
}
message Entity {
// Entities are previously output as `[["tile_ow", "sp", [-1, 1]],
]`
// The proposed encoding clarifies entity type in the schema itself instead
of as a string
string knob_name = 1;
oneof entity {
SplitEntity split = 2;
ReorderEntity reorder = 3;
AnnotateEntity annotate = 4;
OtherOptionEntity other_option = 5;
}
}
message SplitEntity {
repeated int32 size = 1;
}
message ReorderEntity {
repeated uint32 order = 1;
}
message AnnotateEntity {
repeated string annotations = 1;
}
message OtherOptionEntity {
google.protobuf.Any value = 1;
}
message Result {
// The measured runtime costs of this configuration
repeated float costs = 1;
// The error type defined by MeasureErrorNo
int32 error_no = 2;
// End-to-end cost of benchmarking, including rpc, compilation, test runs
float all_cost = 3;
// ISO-8601 formatted timestamp
string timestamp = 4;
}
```
One further question I have is regarding the `Tuple` argument. It is serialized
arbitrarily in branches that include possible recursion here
https://github.com/apache/incubator-tvm/blob/master/python/tvm/autotvm/task/task.py#L53-L54
and it's unclear to me what these different serializations should map to in
logical structures. Could someone (perhaps @haichen) clarify what each branch
is meant to represent? Everything that I've marked `Tuple` below represents a
structure that is unclear to me.
```python
if isinstance(x, tensor.Tensor): # message Tensor { shape, dtype }
return ('TENSOR', get_const_tuple(x.shape), x.dtype)
if isinstance(x, (tuple, list, container.Array)): # message Tuple { repeated
Any }
return tuple([_encode(a) for a in x])
if isinstance(x, (str, int, float, np.int, np.float, expr.Var)): # message
Tuple { repeated Any }
return x
if isinstance(x, (expr.StringImm, expr.IntImm, expr.FloatImm)): # message
Tuple { repeated Any }
return x.value
if isinstance(x, runtime.container.String): # string value
return str(x)
```
---
[Visit
Topic](https://discuss.tvm.ai/t/rfc-canonicalizing-autotvm-log-format/7038/24)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click
here](https://discuss.tvm.ai/email/unsubscribe/d96effa95be13962d2389f4043e01d331999f02a4899202ba22d71281be6490d).
[TVM Discuss] [Development/RFC] [RFC][BYOC] Data Calibration Flow
This makes sense to me. I'm curious to see how `calib_data` is going to be used during codegen. Assuming you want to upstream this pass, how are you going to add tests for this? I can imagine you can use the DNNL codegen to run a dummy calibration pass, but not quantize. --- [Visit Topic](https://discuss.tvm.ai/t/rfc-byoc-data-calibration-flow/7099/5) to respond. You are receiving this because you enabled mailing list mode. To unsubscribe from these emails, [click here](https://discuss.tvm.ai/email/unsubscribe/8e6169c45c2c6e3a22aba513d8e3e24f7754e8007aacf86185e065c69bc41dd4).
[TVM Discuss] [Development] [VTA] Bringing depthwise convolution support
Hi @liangfu, thank you for this important topic. So, if I understand correctly, the present infra-structure do support group conv2d (as I have seen), but not depth-wise conv2d. For this reason, we can run the benchmark tests on MobileNet layers, but not the full MobileNet network for inference on VTA as depth-wise convolution is not yet supported. What's the present status of this support? What additional features do you think is required from the compiler to support the second option that you mentioned? --- [Visit Topic](https://discuss.tvm.ai/t/vta-bringing-depthwise-convolution-support/5742/2) to respond. You are receiving this because you enabled mailing list mode. To unsubscribe from these emails, [click here](https://discuss.tvm.ai/email/unsubscribe/49c39f0a749e85c7c8f8b633e8921cd1b0ea2ab818caf59b60ffbff418f74b54).
[TVM Discuss] [Development/RFC] [RFC][BYOC] Data Calibration Flow
Hi, for now, the `calib_data` will be sent in as an argument of `PassContext`, which is accessible by the BYOC pass triggered by `relay.build`. Users can use the calibration data to perform quantization. You can imagine that users can build a helper quantizer that takes in the calibration data during codegen. For testing, as you mentioned, we plan to use DNNL codegen to test our flow. Since DNNL supports `int8` data type, we can generate random input data for calibration and write a very simple quantizer that takes in the calibration data. And we can test the accuracy of the quantized DNNL code. This tests will also become an example to show how we use the `calib_data` during codegen. --- [Visit Topic](https://discuss.tvm.ai/t/rfc-byoc-data-calibration-flow/7099/6) to respond. You are receiving this because you enabled mailing list mode. To unsubscribe from these emails, [click here](https://discuss.tvm.ai/email/unsubscribe/f68efb78504fb0134e1ed0ef65751a42e8ad489e58b856cb8df192c32dc7da6b).
[TVM Discuss] [Development/RFC] [RFC][BYOC] Data Calibration Flow
cc @ziheng @weberlo who might also be interested --- [Visit Topic](https://discuss.tvm.ai/t/rfc-byoc-data-calibration-flow/7099/7) to respond. You are receiving this because you enabled mailing list mode. To unsubscribe from these emails, [click here](https://discuss.tvm.ai/email/unsubscribe/f5ee6bd0822dd8983c4083ba374facb974c83d84db4fc9d100b3ec93e2e54077).
Re: [apache/incubator-tvm] [VOTE] Release Apache TVM (incubating) v0.6.1.rc1 (#5947)
LICENSE exists Signature file exists and looks good Checksum file exists and looks good DISCLAIMER file exists NOTICE file exists No binary files in source package +1 (binding) On Sat, Jun 27, 2020 at 2:00 PM Yizhi Liu wrote: > Dear TVM community, > > This is a call for vote to release Apache TVM (incubating) version 0.6.1. > This is a maintenance release incorporating important bug fixes. All users > of Apache TVM (incubating) 0.6.0 are advised to upgrade. > > Link to release notes: > https://github.com/apache/incubator-tvm/releases/tag/v0.6.1.rc1 > > Link to release candidate: > https://dist.apache.org/repos/dist/dev/incubator/tvm/tvm-v0.6.1-rc1 > > The vote will be open for at least 72 hours. Everyone is welcomed to vote. > Please vote by replying to this thread explicitly. > > +1 = approve > +0 = no opinion > -1 = disapprove (provide reason) > > NOTE: this thread is being mirrored in dev@ > > -- > You are receiving this because you are subscribed to this thread. > Reply to this email directly or view it on GitHub: > https://github.com/apache/incubator-tvm/issues/5947
