How about using Relay Legalize pass to add an explicit padding at the graph
level?
---
[Visit
Topic](https://discuss.tvm.ai/t/loop-partitioning-padding-and-tensorization/7753/2)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [
Hi @giuseros
You are correct that `qnn.conv2d` and `qnn.requantize` are different operators.
And both of them are lowered to a sequence of Relay operators. But, here the
strength of Relay comes in. Relay fuses `nn.conv2d` followed by a large number
of elemwise ops into one operator. This can
@tqchen The problem arises because LLVM codegen is not able to use suitable
instructions. A fixed point multiply at Relay level will have to upcast the
input tensors to int64. ARM instructions that @giuseros shared take int32
tensors and perform the upcasting internally in the HW (please corre
Thanks for the nice RFC.
Trying to understand if I missed anything. What will happen for non-ARM
machines? Are we going to use fixed_point_multiply relay operator for non-ARM
machines and then use injective schedule?
---
[Visit
Topic](https://discuss.tvm.ai/t/rfc-using-arm-intrinsics-to
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
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
Also cc @FrozenGene @thierry @masahi
---
[Visit
Topic](https://discuss.tvm.ai/t/rfc-improve-quantized-convolution-performance-for-armv8-architectures/6920/2)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click
here](https://
Ping @ziheng, I was wondering if you are pursuing this direction and have any
update.
---
[Visit
Topic](https://discuss.tvm.ai/t/rfc-search-based-automated-quantization/5483/18)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [
Hi @ziheng, I was wondering if you got a chance to work on this further. Any
kind of update?
---
[Visit
Topic](https://discuss.tvm.ai/t/rfc-search-based-automated-quantization/5483/17)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these em
Currently, Relay conv2d internally decides whether a Relay Conv2d operator is
depthwise or not. This makes code somewhat messy - lots of it conditions and
indirections, quite confusing HWOI vs HWOI kernel layout. In addition, it is
difficult to understand from the debug runtime if the conv ope
It seems like NHWC problem. The conv should have a arg called data_layout =
"NHWC" here
---
[Visit
Topic](https://discuss.tvm.ai/t/tflite-an-internal-invariant-was-violated-while-typechecking-your-program/2784/3)
to respond.
You are receiving this because you enabled mailing list mode.
11 matches
Mail list logo
