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
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
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
@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
@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
[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
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
##
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
