Skip to content

[ET] enabling half dtype output for dequantization and making logic consistent #11669

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: gh/ahmtox/12/orig
Choose a base branch
from

Conversation

pytorchbot
Copy link
Collaborator

This PR was created by the merge bot to help merge the original PR into the main branch.
ghstack PR number: #11552 by @ahmtox
^ Please use this as the source of truth for the PR details, comments, and reviews
ghstack PR base: https://github.com/pytorch/executorch/tree/gh/ahmtox/17/base
ghstack PR head: https://github.com/pytorch/executorch/tree/gh/ahmtox/17/head
Merge bot PR base: https://github.com/pytorch/executorch/tree/gh/ahmtox/12/orig
Merge bot PR head: https://github.com/pytorch/executorch/tree/gh/ahmtox/17/orig
@diff-train-skip-merge

…onsistent

Pull Request resolved: #11552


# Context
Currently the cpu implementation for the dequantization operator (which includes `dequantize_per_token`, `dequantize_per_tensor`, and `dequantize_per_channel`), does not inherently support half (fp16) input scalar types. In order to align with the PyTorch implementation that accepts fp16 and bfp16 inputs, this diff aims to enable half input dtype support for the quantization operators. We will be comparing this implementation against the vulkan operators.

Furthermore, there is a casting bug when applying the zero_point, as only in the `dequantize_per_tensor` implementation does it cast the zero_point to int32, while comparitively for `dequantize_per_channel` and `dequantize_per_token` they do not cast the zero_point. In an environment that only supports 32bit integers, understandbly there will be some inconsistencies in dequantization logic as per_tensor will contain different overflow logic compared to its respective per_token and per_channel partner since the latter eliminates the overflow by utilizing a 64bit value.

# Changes
As defined in ExecuTorch [scalar_type_util.h](https://github.com/pytorch/executorch/blob/053686242c1687f0d51b3bb8befd14b047d7b025/runtime/core/exec_aten/util/scalar_type_util.h), the changes in this diff include adding a new macro `ET_FORALL_FLOATH_TYPES_WITH` to `util/scalar_type_util.h`, updating the `CALCULATE_INT_TYPE` macro to handle the new dtype. This enables support for Half (fp16), Float (fp32), and Double (fp64).

I have also included more comprehensive testing against the input dtypes, including adding double testing since it didn't already exist before. Instead of just confirming that all the output dtypes are supported, we also have a check that all input dtypes are supported now as well.

In order to align both dequantization implementations, we cast the zero_point to 32bit for both to maintain the overflow logic carried over from `dequantize_per_tensor`.
ghstack-source-id: 290376483
@exported-using-ghexport

Differential Revision: [D76289181](https://our.internmc.facebook.com/intern/diff/D76289181/)
Copy link

pytorch-bot bot commented Jun 14, 2025

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/11669

Note: Links to docs will display an error until the docs builds have been completed.

❌ 1 New Failure

As of commit a6ffb06 with merge base 56392aa (image):

NEW FAILURE - The following job has failed:

  • Lint / lintrunner / linux-job (gh)
    RuntimeError: Command docker exec -t addb68fba68bf884a617a7117f7b6670103bdadea06a5a0aaa3ec177624822dc /exec failed with exit code 127

This comment was automatically generated by Dr. CI and updates every 15 minutes.

@facebook-github-bot facebook-github-bot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Jun 14, 2025
@ahmtox ahmtox self-requested a review June 14, 2025 03:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants