##
This RFC is a case study on unifying the lower API, which had implementations
in both Python and C++. I'll call the duplication of APIs in Python and C++
"bifurcation" or "bifurcation of the API". I'll conclude by analyzing how this
bifurcation happened in the first place, and then presen
Also, as part of the standardization of QNN, we could ensure that all QNN
"compute" ops go from `int8 -> int8` . I believe that `qnn.conv2d` is the only
QNN op that outputs an accumulation dtype, so we could change `qnn.conv2d` to
take in bias in addition to the data and weight.
---
[Visi
[quote="anijain2305, post:20, topic:9775"]
I am trying to understand why we need `qnn.conv2d*` (* represents operator
along the lines of `qnn.simulated_conv2d`) during calibration. The only reason
would be if you want to propagate the error from previous operators while
**calibrating** current
@mikeseven
Yes, the goal is to create a fully quantized graph, and we do recognize that
this transformation will change the output of the graph. For this reason, we're
not going to present the rewrite as a Relay pass. And I definitely agree that
we should let there be user-defined handling.
A
@altanh Thanks for the input. I think you're right, knowledge of the layout is
not required, and I can remove that.
With regard to your concern about the list of ndarrays -- the ndarrays in the
list are meant to be batched (I should make this clearer in the documentation,
though). The intenti
I guess having the user transform them into numpy before comparison is OK for
now, and to be consistent I'll make both data and labels
`tvm.runtime.ndarrays`. I can put a note in the documentation that they need to
convert them to numpy arrays before comparing them.
It would be nice if there
Also, it appears that `tvm.runtime.ndarray` only has one method for comparing
ndarrays, same_as, and same_as checks object identity equality, not value
equality.
If the output of running a relay mod is a `tvm.runtime.ndarray`, and the labels
are also a `tvm.runtime.ndarray`, it seems that th
Thanks for the feedback @tqchen @jwfromm. I'll move the the code to the
namespace `tvm.utils.data`, and set batch_size and num_batches through the
@property decorator.
I do agree that future support of zero copy through DLPack is interesting, so
it's worth considering using `tvm.runtime.ndar
