[XNNPACK] resolve ambiguity around 2d affine quantized tensors by mcr229 · Pull Request #8958 · pytorch/executorch

mcr229 · 2025-03-05T04:30:53Z

Summary

There is some ambiguity around deriving per_token and per_channel_group semantics from quantize affine. Specifically when rank is two. Take for example the following input shape with the following group size:

input_shape (5, 2048)
group_size (1, 2048)

This tensor has 5 scales, and can be seen has having one scale per batch dimension. Or one scale per token. However, this can also be seen as a single weight in which each group is the size of a channel, effectively giving per_channel semantics. This ambiguity does not play well within the XNNPACK Backend as we are must parse these differing quantization types. For now we rely on the fact that per_token quantization happens dynamically. Meaning that the scales and zero points are dynamically choosen. As a result, we check that the scales come from getitem and is dynamically chosen. We further ensure that per_channel_group checks are not per_token.

Test plan

python -m unittest backends.xnnpack.test.ops.test_linear.TestLinear.test_linear_qd8_f32_per_token_weight_per_channel_group_int4

pytorch-bot · 2025-03-05T04:30:57Z

🔗 Helpful Links

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

📄 Preview Python docs built from this PR

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

✅ You can merge normally! (1 Unrelated Failure)

As of commit 89a248a with merge base 1011fdc ():

BROKEN TRUNK - The following job failed but were present on the merge base:

👉 Rebase onto the `viable/strict` branch to avoid these failures

pull / android / run-emulator (gh) (trunk failure)
Process completed with exit code 9.

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

jackzhxng

This is needed to resolve numerical inaccuracies introduced by switching to the quantize_ API here: #8772. Will leave to @digantdesai / @kimishpatel for final stamp

facebook-github-bot · 2025-03-06T18:49:54Z

@mcr229 has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

Summary: There is some ambiguity around deriving per_token and per_channel_group semantics from quantize affine. Specifically when rank is two. Take for example the following input shape with the following group size: - input_shape (5, 2048) - group_size (1, 2048) This tensor has 5 scales, and can be seen has having one scale per batch dimension. Or one scale per token. However, this can also be seen as a single weight in which each group is the size of a channel, effectively giving per_channel semantics. This ambiguity does not play well within the XNNPACK Backend as we are must parse these differing quantization types. For now we rely on the fact that per_token quantization happens dynamically. Meaning that the scales and zero points are dynamically choosen. As a result, we check that the scales come from getitem and is dynamically chosen. We further ensure that per_channel_group checks are not per_token. Test Plan: ``` python -m unittest backends.xnnpack.test.ops.test_linear.TestLinear.test_linear_qd8_f32_per_token_weight_per_channel_group_int4 ``` Reviewed By: GregoryComer Differential Revision: D70719546 Pulled By: mcr229

facebook-github-bot · 2025-03-14T22:45:46Z

This pull request was exported from Phabricator. Differential Revision: D70719546

Differential Revision: D70719546 Pull Request resolved: pytorch#8958

mcr229 · 2025-03-05T04:30:53Z

Summary

There is some ambiguity around deriving per_token and per_channel_group semantics from quantize affine. Specifically when rank is two. Take for example the following input shape with the following group size:

input_shape (5, 2048)
group_size (1, 2048)

This tensor has 5 scales, and can be seen has having one scale per batch dimension. Or one scale per token. However, this can also be seen as a single weight in which each group is the size of a channel, effectively giving per_channel semantics. This ambiguity does not play well within the XNNPACK Backend as we are must parse these differing quantization types. For now we rely on the fact that per_token quantization happens dynamically. Meaning that the scales and zero points are dynamically choosen. As a result, we check that the scales come from getitem and is dynamically chosen. We further ensure that per_channel_group checks are not per_token.

Test plan

python -m unittest backends.xnnpack.test.ops.test_linear.TestLinear.test_linear_qd8_f32_per_token_weight_per_channel_group_int4

pytorch-bot · 2025-03-05T04:30:57Z

🔗 Helpful Links

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

📄 Preview Python docs built from this PR

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

✅ You can merge normally! (1 Unrelated Failure)

As of commit 89a248a with merge base 1011fdc ():

BROKEN TRUNK - The following job failed but were present on the merge base:

👉 Rebase onto the `viable/strict` branch to avoid these failures

pull / android / run-emulator (gh) (trunk failure)
Process completed with exit code 9.

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

jackzhxng

This is needed to resolve numerical inaccuracies introduced by switching to the quantize_ API here: #8772. Will leave to @digantdesai / @kimishpatel for final stamp

facebook-github-bot · 2025-03-06T18:49:54Z

@mcr229 has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

Summary: There is some ambiguity around deriving per_token and per_channel_group semantics from quantize affine. Specifically when rank is two. Take for example the following input shape with the following group size: - input_shape (5, 2048) - group_size (1, 2048) This tensor has 5 scales, and can be seen has having one scale per batch dimension. Or one scale per token. However, this can also be seen as a single weight in which each group is the size of a channel, effectively giving per_channel semantics. This ambiguity does not play well within the XNNPACK Backend as we are must parse these differing quantization types. For now we rely on the fact that per_token quantization happens dynamically. Meaning that the scales and zero points are dynamically choosen. As a result, we check that the scales come from getitem and is dynamically chosen. We further ensure that per_channel_group checks are not per_token. Test Plan: ``` python -m unittest backends.xnnpack.test.ops.test_linear.TestLinear.test_linear_qd8_f32_per_token_weight_per_channel_group_int4 ``` Reviewed By: GregoryComer Differential Revision: D70719546 Pulled By: mcr229

facebook-github-bot · 2025-03-14T22:45:46Z

This pull request was exported from Phabricator. Differential Revision: D70719546

Differential Revision: D70719546 Pull Request resolved: pytorch#8958

mcr229 · 2025-03-05T04:30:53Z

Summary

There is some ambiguity around deriving per_token and per_channel_group semantics from quantize affine. Specifically when rank is two. Take for example the following input shape with the following group size:

input_shape (5, 2048)
group_size (1, 2048)

This tensor has 5 scales, and can be seen has having one scale per batch dimension. Or one scale per token. However, this can also be seen as a single weight in which each group is the size of a channel, effectively giving per_channel semantics. This ambiguity does not play well within the XNNPACK Backend as we are must parse these differing quantization types. For now we rely on the fact that per_token quantization happens dynamically. Meaning that the scales and zero points are dynamically choosen. As a result, we check that the scales come from getitem and is dynamically chosen. We further ensure that per_channel_group checks are not per_token.

Test plan

python -m unittest backends.xnnpack.test.ops.test_linear.TestLinear.test_linear_qd8_f32_per_token_weight_per_channel_group_int4

pytorch-bot · 2025-03-05T04:30:57Z

🔗 Helpful Links

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

📄 Preview Python docs built from this PR

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

✅ You can merge normally! (1 Unrelated Failure)

As of commit 89a248a with merge base 1011fdc ():

BROKEN TRUNK - The following job failed but were present on the merge base:

👉 Rebase onto the `viable/strict` branch to avoid these failures

pull / android / run-emulator (gh) (trunk failure)
Process completed with exit code 9.

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

jackzhxng

This is needed to resolve numerical inaccuracies introduced by switching to the quantize_ API here: #8772. Will leave to @digantdesai / @kimishpatel for final stamp

facebook-github-bot · 2025-03-06T18:49:54Z

@mcr229 has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

Summary: There is some ambiguity around deriving per_token and per_channel_group semantics from quantize affine. Specifically when rank is two. Take for example the following input shape with the following group size: - input_shape (5, 2048) - group_size (1, 2048) This tensor has 5 scales, and can be seen has having one scale per batch dimension. Or one scale per token. However, this can also be seen as a single weight in which each group is the size of a channel, effectively giving per_channel semantics. This ambiguity does not play well within the XNNPACK Backend as we are must parse these differing quantization types. For now we rely on the fact that per_token quantization happens dynamically. Meaning that the scales and zero points are dynamically choosen. As a result, we check that the scales come from getitem and is dynamically chosen. We further ensure that per_channel_group checks are not per_token. Test Plan: ``` python -m unittest backends.xnnpack.test.ops.test_linear.TestLinear.test_linear_qd8_f32_per_token_weight_per_channel_group_int4 ``` Reviewed By: GregoryComer Differential Revision: D70719546 Pulled By: mcr229

facebook-github-bot · 2025-03-14T22:45:46Z

This pull request was exported from Phabricator. Differential Revision: D70719546

Differential Revision: D70719546 Pull Request resolved: pytorch#8958

mcr229 · 2025-03-05T04:30:53Z

Summary

There is some ambiguity around deriving per_token and per_channel_group semantics from quantize affine. Specifically when rank is two. Take for example the following input shape with the following group size:

input_shape (5, 2048)
group_size (1, 2048)

This tensor has 5 scales, and can be seen has having one scale per batch dimension. Or one scale per token. However, this can also be seen as a single weight in which each group is the size of a channel, effectively giving per_channel semantics. This ambiguity does not play well within the XNNPACK Backend as we are must parse these differing quantization types. For now we rely on the fact that per_token quantization happens dynamically. Meaning that the scales and zero points are dynamically choosen. As a result, we check that the scales come from getitem and is dynamically chosen. We further ensure that per_channel_group checks are not per_token.

Test plan

python -m unittest backends.xnnpack.test.ops.test_linear.TestLinear.test_linear_qd8_f32_per_token_weight_per_channel_group_int4

pytorch-bot · 2025-03-05T04:30:57Z

🔗 Helpful Links

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

📄 Preview Python docs built from this PR

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

✅ You can merge normally! (1 Unrelated Failure)

As of commit 89a248a with merge base 1011fdc ():

BROKEN TRUNK - The following job failed but were present on the merge base:

👉 Rebase onto the `viable/strict` branch to avoid these failures

pull / android / run-emulator (gh) (trunk failure)
Process completed with exit code 9.

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

jackzhxng

This is needed to resolve numerical inaccuracies introduced by switching to the quantize_ API here: #8772. Will leave to @digantdesai / @kimishpatel for final stamp

facebook-github-bot · 2025-03-06T18:49:54Z

@mcr229 has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

Summary: There is some ambiguity around deriving per_token and per_channel_group semantics from quantize affine. Specifically when rank is two. Take for example the following input shape with the following group size: - input_shape (5, 2048) - group_size (1, 2048) This tensor has 5 scales, and can be seen has having one scale per batch dimension. Or one scale per token. However, this can also be seen as a single weight in which each group is the size of a channel, effectively giving per_channel semantics. This ambiguity does not play well within the XNNPACK Backend as we are must parse these differing quantization types. For now we rely on the fact that per_token quantization happens dynamically. Meaning that the scales and zero points are dynamically choosen. As a result, we check that the scales come from getitem and is dynamically chosen. We further ensure that per_channel_group checks are not per_token. Test Plan: ``` python -m unittest backends.xnnpack.test.ops.test_linear.TestLinear.test_linear_qd8_f32_per_token_weight_per_channel_group_int4 ``` Reviewed By: GregoryComer Differential Revision: D70719546 Pulled By: mcr229

facebook-github-bot · 2025-03-14T22:45:46Z

This pull request was exported from Phabricator. Differential Revision: D70719546

Differential Revision: D70719546 Pull Request resolved: pytorch#8958

mcr229 · 2025-03-05T04:30:53Z

Summary

There is some ambiguity around deriving per_token and per_channel_group semantics from quantize affine. Specifically when rank is two. Take for example the following input shape with the following group size:

input_shape (5, 2048)
group_size (1, 2048)

This tensor has 5 scales, and can be seen has having one scale per batch dimension. Or one scale per token. However, this can also be seen as a single weight in which each group is the size of a channel, effectively giving per_channel semantics. This ambiguity does not play well within the XNNPACK Backend as we are must parse these differing quantization types. For now we rely on the fact that per_token quantization happens dynamically. Meaning that the scales and zero points are dynamically choosen. As a result, we check that the scales come from getitem and is dynamically chosen. We further ensure that per_channel_group checks are not per_token.

Test plan

python -m unittest backends.xnnpack.test.ops.test_linear.TestLinear.test_linear_qd8_f32_per_token_weight_per_channel_group_int4

pytorch-bot · 2025-03-05T04:30:57Z

🔗 Helpful Links

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

📄 Preview Python docs built from this PR

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

✅ You can merge normally! (1 Unrelated Failure)

As of commit 89a248a with merge base 1011fdc ():

BROKEN TRUNK - The following job failed but were present on the merge base:

👉 Rebase onto the `viable/strict` branch to avoid these failures

pull / android / run-emulator (gh) (trunk failure)
Process completed with exit code 9.

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

jackzhxng

This is needed to resolve numerical inaccuracies introduced by switching to the quantize_ API here: #8772. Will leave to @digantdesai / @kimishpatel for final stamp

facebook-github-bot · 2025-03-06T18:49:54Z

@mcr229 has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

Summary: There is some ambiguity around deriving per_token and per_channel_group semantics from quantize affine. Specifically when rank is two. Take for example the following input shape with the following group size: - input_shape (5, 2048) - group_size (1, 2048) This tensor has 5 scales, and can be seen has having one scale per batch dimension. Or one scale per token. However, this can also be seen as a single weight in which each group is the size of a channel, effectively giving per_channel semantics. This ambiguity does not play well within the XNNPACK Backend as we are must parse these differing quantization types. For now we rely on the fact that per_token quantization happens dynamically. Meaning that the scales and zero points are dynamically choosen. As a result, we check that the scales come from getitem and is dynamically chosen. We further ensure that per_channel_group checks are not per_token. Test Plan: ``` python -m unittest backends.xnnpack.test.ops.test_linear.TestLinear.test_linear_qd8_f32_per_token_weight_per_channel_group_int4 ``` Reviewed By: GregoryComer Differential Revision: D70719546 Pulled By: mcr229

facebook-github-bot · 2025-03-14T22:45:46Z

This pull request was exported from Phabricator. Differential Revision: D70719546

Differential Revision: D70719546 Pull Request resolved: pytorch#8958

mcr229 · 2025-03-05T04:30:53Z

Summary

There is some ambiguity around deriving per_token and per_channel_group semantics from quantize affine. Specifically when rank is two. Take for example the following input shape with the following group size:

input_shape (5, 2048)
group_size (1, 2048)

This tensor has 5 scales, and can be seen has having one scale per batch dimension. Or one scale per token. However, this can also be seen as a single weight in which each group is the size of a channel, effectively giving per_channel semantics. This ambiguity does not play well within the XNNPACK Backend as we are must parse these differing quantization types. For now we rely on the fact that per_token quantization happens dynamically. Meaning that the scales and zero points are dynamically choosen. As a result, we check that the scales come from getitem and is dynamically chosen. We further ensure that per_channel_group checks are not per_token.

Test plan

python -m unittest backends.xnnpack.test.ops.test_linear.TestLinear.test_linear_qd8_f32_per_token_weight_per_channel_group_int4

pytorch-bot · 2025-03-05T04:30:57Z

🔗 Helpful Links

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

📄 Preview Python docs built from this PR

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

✅ You can merge normally! (1 Unrelated Failure)

As of commit 89a248a with merge base 1011fdc ():

BROKEN TRUNK - The following job failed but were present on the merge base:

👉 Rebase onto the `viable/strict` branch to avoid these failures

pull / android / run-emulator (gh) (trunk failure)
Process completed with exit code 9.

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

jackzhxng

This is needed to resolve numerical inaccuracies introduced by switching to the quantize_ API here: #8772. Will leave to @digantdesai / @kimishpatel for final stamp

facebook-github-bot · 2025-03-06T18:49:54Z

@mcr229 has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

Summary: There is some ambiguity around deriving per_token and per_channel_group semantics from quantize affine. Specifically when rank is two. Take for example the following input shape with the following group size: - input_shape (5, 2048) - group_size (1, 2048) This tensor has 5 scales, and can be seen has having one scale per batch dimension. Or one scale per token. However, this can also be seen as a single weight in which each group is the size of a channel, effectively giving per_channel semantics. This ambiguity does not play well within the XNNPACK Backend as we are must parse these differing quantization types. For now we rely on the fact that per_token quantization happens dynamically. Meaning that the scales and zero points are dynamically choosen. As a result, we check that the scales come from getitem and is dynamically chosen. We further ensure that per_channel_group checks are not per_token. Test Plan: ``` python -m unittest backends.xnnpack.test.ops.test_linear.TestLinear.test_linear_qd8_f32_per_token_weight_per_channel_group_int4 ``` Reviewed By: GregoryComer Differential Revision: D70719546 Pulled By: mcr229

facebook-github-bot · 2025-03-14T22:45:46Z

This pull request was exported from Phabricator. Differential Revision: D70719546

Differential Revision: D70719546 Pull Request resolved: pytorch#8958

mcr229 · 2025-03-05T04:30:53Z

Summary

There is some ambiguity around deriving per_token and per_channel_group semantics from quantize affine. Specifically when rank is two. Take for example the following input shape with the following group size:

input_shape (5, 2048)
group_size (1, 2048)

This tensor has 5 scales, and can be seen has having one scale per batch dimension. Or one scale per token. However, this can also be seen as a single weight in which each group is the size of a channel, effectively giving per_channel semantics. This ambiguity does not play well within the XNNPACK Backend as we are must parse these differing quantization types. For now we rely on the fact that per_token quantization happens dynamically. Meaning that the scales and zero points are dynamically choosen. As a result, we check that the scales come from getitem and is dynamically chosen. We further ensure that per_channel_group checks are not per_token.

Test plan

python -m unittest backends.xnnpack.test.ops.test_linear.TestLinear.test_linear_qd8_f32_per_token_weight_per_channel_group_int4

pytorch-bot · 2025-03-05T04:30:57Z

🔗 Helpful Links

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

📄 Preview Python docs built from this PR

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

✅ You can merge normally! (1 Unrelated Failure)

As of commit 89a248a with merge base 1011fdc ():

BROKEN TRUNK - The following job failed but were present on the merge base:

👉 Rebase onto the `viable/strict` branch to avoid these failures

pull / android / run-emulator (gh) (trunk failure)
Process completed with exit code 9.

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

jackzhxng

This is needed to resolve numerical inaccuracies introduced by switching to the quantize_ API here: #8772. Will leave to @digantdesai / @kimishpatel for final stamp

facebook-github-bot · 2025-03-06T18:49:54Z

@mcr229 has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

Summary: There is some ambiguity around deriving per_token and per_channel_group semantics from quantize affine. Specifically when rank is two. Take for example the following input shape with the following group size: - input_shape (5, 2048) - group_size (1, 2048) This tensor has 5 scales, and can be seen has having one scale per batch dimension. Or one scale per token. However, this can also be seen as a single weight in which each group is the size of a channel, effectively giving per_channel semantics. This ambiguity does not play well within the XNNPACK Backend as we are must parse these differing quantization types. For now we rely on the fact that per_token quantization happens dynamically. Meaning that the scales and zero points are dynamically choosen. As a result, we check that the scales come from getitem and is dynamically chosen. We further ensure that per_channel_group checks are not per_token. Test Plan: ``` python -m unittest backends.xnnpack.test.ops.test_linear.TestLinear.test_linear_qd8_f32_per_token_weight_per_channel_group_int4 ``` Reviewed By: GregoryComer Differential Revision: D70719546 Pulled By: mcr229

facebook-github-bot · 2025-03-14T22:45:46Z

This pull request was exported from Phabricator. Differential Revision: D70719546

Differential Revision: D70719546 Pull Request resolved: pytorch#8958

mcr229 · 2025-03-05T04:30:53Z

Summary

There is some ambiguity around deriving per_token and per_channel_group semantics from quantize affine. Specifically when rank is two. Take for example the following input shape with the following group size:

input_shape (5, 2048)
group_size (1, 2048)

This tensor has 5 scales, and can be seen has having one scale per batch dimension. Or one scale per token. However, this can also be seen as a single weight in which each group is the size of a channel, effectively giving per_channel semantics. This ambiguity does not play well within the XNNPACK Backend as we are must parse these differing quantization types. For now we rely on the fact that per_token quantization happens dynamically. Meaning that the scales and zero points are dynamically choosen. As a result, we check that the scales come from getitem and is dynamically chosen. We further ensure that per_channel_group checks are not per_token.

Test plan

python -m unittest backends.xnnpack.test.ops.test_linear.TestLinear.test_linear_qd8_f32_per_token_weight_per_channel_group_int4

pytorch-bot · 2025-03-05T04:30:57Z

🔗 Helpful Links

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

📄 Preview Python docs built from this PR

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

✅ You can merge normally! (1 Unrelated Failure)

As of commit 89a248a with merge base 1011fdc ():

BROKEN TRUNK - The following job failed but were present on the merge base:

👉 Rebase onto the `viable/strict` branch to avoid these failures

pull / android / run-emulator (gh) (trunk failure)
Process completed with exit code 9.

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

jackzhxng

This is needed to resolve numerical inaccuracies introduced by switching to the quantize_ API here: #8772. Will leave to @digantdesai / @kimishpatel for final stamp

facebook-github-bot · 2025-03-06T18:49:54Z

@mcr229 has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

Summary: There is some ambiguity around deriving per_token and per_channel_group semantics from quantize affine. Specifically when rank is two. Take for example the following input shape with the following group size: - input_shape (5, 2048) - group_size (1, 2048) This tensor has 5 scales, and can be seen has having one scale per batch dimension. Or one scale per token. However, this can also be seen as a single weight in which each group is the size of a channel, effectively giving per_channel semantics. This ambiguity does not play well within the XNNPACK Backend as we are must parse these differing quantization types. For now we rely on the fact that per_token quantization happens dynamically. Meaning that the scales and zero points are dynamically choosen. As a result, we check that the scales come from getitem and is dynamically chosen. We further ensure that per_channel_group checks are not per_token. Test Plan: ``` python -m unittest backends.xnnpack.test.ops.test_linear.TestLinear.test_linear_qd8_f32_per_token_weight_per_channel_group_int4 ``` Reviewed By: GregoryComer Differential Revision: D70719546 Pulled By: mcr229

facebook-github-bot · 2025-03-14T22:45:46Z

This pull request was exported from Phabricator. Differential Revision: D70719546

Differential Revision: D70719546 Pull Request resolved: pytorch#8958

mcr229 requested a review from kimishpatel March 5, 2025 04:30

mcr229 requested a review from digantdesai as a code owner March 5, 2025 04:30

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 Mar 5, 2025

mcr229 force-pushed the q_affine_ambiguity branch from 4febe74 to 0a6b599Compare March 5, 2025 04:39

mcr229 added the topic: not user facing label Mar 5, 2025

mcr229 requested review from digantdesai and removed request for digantdesai March 5, 2025 04:39

jackzhxng approved these changes Mar 6, 2025
View reviewed changes

GregoryComer approved these changes Mar 7, 2025
View reviewed changes

github-actionsBot mentioned this pull request Mar 10, 2025
Weekly pr metrics report - 2025-03-01..2025-03-07 wdvr/pytorch#16
Open

mcr229 force-pushed the q_affine_ambiguity branch from 0a6b599 to 89a248aCompare March 14, 2025 22:45

facebook-github-bot added the fb-exported label Mar 14, 2025

facebook-github-bot merged commit 0ccf509 into pytorch:mainMar 15, 2025

This was referenced Mar 17, 2025
Weekly pr metrics report - 2025-03-01..2025-03-07 wdvr/pytorch#18
Open
Weekly pr metrics report - 2025-03-01..2025-03-07 wdvr/pytorch#20
Open

github-actionsBot mentioned this pull request Mar 31, 2025
Weekly pr metrics report - 2025-03-01..2025-03-07 wdvr/pytorch#22
Open

DannyYuyang-quic pushed a commit to CodeLinaro/executorch that referenced this pull request Apr 2, 2025
[XNNPACK] resolve ambiguity around 2d affine quantized tensors
2e9dc93
Differential Revision: D70719546 Pull Request resolved: pytorch#8958

github-actionsBot mentioned this pull request Apr 7, 2025
Weekly pr metrics report - 2025-03-01..2025-03-07 wdvr/pytorch#26
Open

mcr229 deleted the q_affine_ambiguity branch July 25, 2025 22:43