Thanks everyone for the feedback. As mentioned above, the focus of this RFC is
for the calibration pass, which is an optional analysis pass that can be
applied by users. It does not necessarily need to be bound with BYOC. Moreover,
quantization is also not the focus of this RFC. We will open o
Thanks for the discussion.
I think we don't really need to tie this feature to the BYOC flow. The problem
it tries to solve is providing calibration data to 3rd codegen with quantizers
as @anijain2305 pointed out. This is not required by QNN or AutoQ. It is also
optional to 3rd codegen or BYO
Thanks for the good summarization. One concern that I have for this case is
mainly about the coupling of the quantization part with the customized code
generator.
While the application scenario is certainly understandable. We will need to
resolve two questions, as an overall goal of the proje
I think we are getting confused because of the overloaded term quantization. To
be precise, maybe we can stick to certain terms
* *QNN Dialect* - Framework (like TF/PyTorch/MXNet) performs quantization.
Relay parser reads this pre-quantized model and creates a QNN-dialect graph.
QNN ops are l
I agree with @matt-arm that we should be hesitant to use BYOC as a catch-all
for everything we haven't implemented in TVM.
What would help me better understand the motivation for this change is an
example of a quantization flow that isn't easily expressible with TVM's
*internal* facilities.
LGTM. I think we can rename to `get_calibration_data` or `get_profiling_data`
instead of `calibrate_partition_gaph`. I think calibration means more than
collecting i/o tensors (for quantization, it means choosing min/max such that
quantized data representation is similar to float32 data repres
@matt-arm For each BYOC backend such as DNNL, we could define a transform
sequence so that we can have `mod = transform.partition("dnnl")(mod)`. However,
there are some issues should be further discussed. For example, where should we
put those transform sequences (e.g., put them under `tvm.tr
This looks reasonable to me, it's not something we require for Ethos-N but I
can see why it may be desirable. I am noticing quite a bit of API creep around
BYOC though. We never really settled on a way to encapsulate the partitioning
passes and now we have another special pass that may or may
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/unsubsc
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
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 Topi
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
cc @anijain2305 as well
---
[Visit Topic](https://discuss.tvm.ai/t/rfc-byoc-data-calibration-flow/7099/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/da1ed6d19e3b968d5c39
Also cc @JoeyChou @abergeron
---
[Visit Topic](https://discuss.tvm.ai/t/rfc-byoc-data-calibration-flow/7099/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/e825d1e5ca1d063
## Motivation
Although TVM provides quantization flow for pre-quantized models, we do find
some developers would prefer to use their own quantization flow for their
accelerators, since they may have specialized calibration and quantization
flows other than TVM QNN. However, current BYOC flow
15 matches
Mail list logo
