Several comments :) > Regarding @anijain2305 's [ReLU > proposal](https://github.com/dmlc/tvm/issues/2351#issuecomment-508956237).
The symmetric and asymmetric path may merge into one - the asymmetric - where the zero point for symmetric approach is 0. Actually, this is a bit more complicate regarding the input tensor type, and what is the expected output tensor type, when handling the **ReLU family**: | input type | output type| how to handle| |-----------|------------|-----------------| | int8/uint8| int8/uint8| Clipping out the *unwanted value range*, taking zero point into consideration| | int32 | int32 | Assuming the int32 is symmetric, such that clipping out the *unwanted value range* should be fine for ReLU. But, what about ReLU6? | |int32| int8/uint8| the scale and zero point of the input and output may take into consideration. This will break into ReLU with input/output type int32 and a Requantization in the proposal. Considering ReLU6, the integer representation of the FP32 6.0 should be calculated, otherwise, we can hardly know the expected output integer value range. | The listed is not necessarily the all. As I stated before, we need to keep in mind **how the floating point is represented in integer, and how can we arrange the arithmetic to maintain the floating point computing which is been represented**. > Similarly for quantized avg pool2d, as @FrozenGene mentioned, we will still > need to upcast the tensor to int32 to avoid saturation. Additionally, we > would need to handle the zero points. Zero point it not needed in handling pooling. The UINT8 representation of FP32 doesn't need to update in the semantic of pooling. It seems that we have put many Quantize/Dequantize to make the quantization ops reusing existing nn ops, either explicitly or implicitly. This could be bad for performance. Maybe some passes need to be introduced to handle I guess. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/dmlc/tvm/issues/2351#issuecomment-508966587
