[ET-VK][qlinear] Faster weight only quantized linear gemv kernel #12444

SS-JIA · 2025-07-14T15:33:19Z

Stack from ghstack (oldest at bottom):

-> [ET-VK][qlinear] Faster weight only quantized linear gemv kernel #12444

Changes

Introduce a new compute shader for int4 linear's gemv cases that performs much better than the existing shader. This shader is inspired from MNN's gemv_1x1_conv_buf.cl shader.

With this compute kernel, transformer models' text generation can execute much faster than before.

On Samsung Galaxy S24 for Llama 3.2 1B, generating 128 tokens:

Before: ~25 tok/s
After: ~49 tok/s

Why this new shader is faster

The biggest reason is due to vectorized loading of the uint4 weight buffer. This new shader loads the weight buffer as a buffer/image of uvec4, whereas the old shader loads the weight buffer as a buffer/image of u8vec4. Using the Adreno Offline Compiler, I found that in the former, only one load instruction was used to load from the weight tensor, whereas in the latter 16 load instructions were used to load from the weight tensor. It appears that the data loading was not being vectorized at the assembly level. This is potentially behaviour that can be approved in the SPIR-V shader compiler.

An additional factor is better weight packing layout. The new prepacking routine results in better memory coalescing between threads in a work group.

The final major factor is the use of tree based reduction to co-operatively reduce partial results into the final output. Previously, a single thread was responsible for the final reduction.

Future Work

Introduce faster shader for int4 linear gemm cases
Update QCSNW to also use these updated shaders

Differential Revision: D78275584

## Changes * Introduce a new compute shader for int4 linear's gemv cases that performs much better than the existing shader. This shader is inspired from MNN's gemv_1x1_conv_buf.cl shader. With this compute kernel, transformer models' text generation can execute much faster than before. On Samsung Galaxy S24 for Llama 3.2 1B, generating 128 tokens: Before: ~25 tok/s After: ~49 tok/s ## Why this new shader is faster The biggest reason is due to vectorized loading of the uint4 weight buffer. This new shader loads the weight buffer as a buffer/image of `uvec4`, whereas the old shader loads the weight buffer as a buffer/image of `u8vec4`. Using the Adreno Offline Compiler, I found that in the former, only one load instruction was used to load from the weight tensor, whereas in the latter 16 load instructions were used to load from the weight tensor. It appears that the data loading was not being vectorized at the assembly level. This is potentially behaviour that can be approved in the SPIR-V shader compiler. An additional factor is better weight packing layout. The new prepacking routine results in better memory coalescing between threads in a work group. The final major factor is the use of tree based reduction to co-operatively reduce partial results into the final output. Previously, a single thread was responsible for the final reduction. ## Future Work * Introduce faster shader for int4 linear gemm cases * Update QCSNW to also use these updated shaders Differential Revision: [D78275584](https://our.internmc.facebook.com/intern/diff/D78275584/) [ghstack-poisoned]

pytorch-bot · 2025-07-14T15:33:23Z

🔗 Helpful Links

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

📄 Preview Python docs built from this PR

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

❌ 2 New Failures

As of commit 40b33fa with merge base 924bbf8 ():

NEW FAILURES - The following jobs have failed:

pull / test-eval_llama-mmlu-linux / linux-job (gh)
RuntimeError: Command docker exec -t 3c8dd19a56144de48005111d0da74d01a4d9c47d607bdcd9ae4a1b5607d2e07f /exec failed with exit code 1
pull / unittest-nxp-neutron / linux-job (gh)
RuntimeError: Command docker exec -t 353192504efbd0a777b8bcb55eaae11b677eca29232dbb4696b9c267514ac451 /exec failed with exit code 1

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

## Changes * Introduce a new compute shader for int4 linear's gemv cases that performs much better than the existing shader. This shader is inspired from MNN's gemv_1x1_conv_buf.cl shader. With this compute kernel, transformer models' text generation can execute much faster than before. On Samsung Galaxy S24 for Llama 3.2 1B, generating 128 tokens: Before: ~25 tok/s After: ~49 tok/s ## Why this new shader is faster The biggest reason is due to vectorized loading of the uint4 weight buffer. This new shader loads the weight buffer as a buffer/image of `uvec4`, whereas the old shader loads the weight buffer as a buffer/image of `u8vec4`. Using the Adreno Offline Compiler, I found that in the former, only one load instruction was used to load from the weight tensor, whereas in the latter 16 load instructions were used to load from the weight tensor. It appears that the data loading was not being vectorized at the assembly level. This is potentially behaviour that can be approved in the SPIR-V shader compiler. An additional factor is better weight packing layout. The new prepacking routine results in better memory coalescing between threads in a work group. The final major factor is the use of tree based reduction to co-operatively reduce partial results into the final output. Previously, a single thread was responsible for the final reduction. ## Future Work * Introduce faster shader for int4 linear gemm cases * Update QCSNW to also use these updated shaders Differential Revision: [D78275584](https://our.internmc.facebook.com/intern/diff/D78275584/) ghstack-source-id: 296055475 Pull Request resolved: #12444

facebook-github-bot · 2025-07-14T15:33:48Z

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

github-actions · 2025-07-14T15:34:21Z

This PR needs a `release notes:` label

If your change should be included in the release notes (i.e. would users of this library care about this change?), please use a label starting with release notes:. This helps us keep track and include your important work in the next release notes.

To add a label, you can comment to pytorchbot, for example
@pytorchbot label "release notes: none"

For more information, see
https://github.com/pytorch/pytorch/wiki/PyTorch-AutoLabel-Bot#why-categorize-for-release-notes-and-how-does-it-work.

…kernel" ## Changes * Introduce a new compute shader for int4 linear's gemv cases that performs much better than the existing shader. This shader is inspired from MNN's gemv_1x1_conv_buf.cl shader. With this compute kernel, transformer models' text generation can execute much faster than before. On Samsung Galaxy S24 for Llama 3.2 1B, generating 128 tokens: Before: ~25 tok/s After: ~49 tok/s ## Why this new shader is faster The biggest reason is due to vectorized loading of the uint4 weight buffer. This new shader loads the weight buffer as a buffer/image of `uvec4`, whereas the old shader loads the weight buffer as a buffer/image of `u8vec4`. Using the Adreno Offline Compiler, I found that in the former, only one load instruction was used to load from the weight tensor, whereas in the latter 16 load instructions were used to load from the weight tensor. It appears that the data loading was not being vectorized at the assembly level. This is potentially behaviour that can be approved in the SPIR-V shader compiler. An additional factor is better weight packing layout. The new prepacking routine results in better memory coalescing between threads in a work group. The final major factor is the use of tree based reduction to co-operatively reduce partial results into the final output. Previously, a single thread was responsible for the final reduction. ## Future Work * Introduce faster shader for int4 linear gemm cases * Update QCSNW to also use these updated shaders Differential Revision: [D78275584](https://our.internmc.facebook.com/intern/diff/D78275584/) [ghstack-poisoned]

Pull Request resolved: #12444 ## Changes * Introduce a new compute shader for int4 linear's gemv cases that performs much better than the existing shader. This shader is inspired from MNN's gemv_1x1_conv_buf.cl shader. With this compute kernel, transformer models' text generation can execute much faster than before. On Samsung Galaxy S24 for Llama 3.2 1B, generating 128 tokens: Before: ~25 tok/s After: ~49 tok/s ## Why this new shader is faster The biggest reason is due to vectorized loading of the uint4 weight buffer. This new shader loads the weight buffer as a buffer/image of `uvec4`, whereas the old shader loads the weight buffer as a buffer/image of `u8vec4`. Using the Adreno Offline Compiler, I found that in the former, only one load instruction was used to load from the weight tensor, whereas in the latter 16 load instructions were used to load from the weight tensor. It appears that the data loading was not being vectorized at the assembly level. This is potentially behaviour that can be approved in the SPIR-V shader compiler. An additional factor is better weight packing layout. The new prepacking routine results in better memory coalescing between threads in a work group. The final major factor is the use of tree based reduction to co-operatively reduce partial results into the final output. Previously, a single thread was responsible for the final reduction. ## Future Work * Introduce faster shader for int4 linear gemm cases * Update QCSNW to also use these updated shaders Differential Revision: [D78275584](https://our.internmc.facebook.com/intern/diff/D78275584/) ghstack-source-id: 296122483

facebook-github-bot · 2025-07-14T19:44:58Z

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

…kernel" ## Changes * Introduce a new compute shader for int4 linear's gemv cases that performs much better than the existing shader. This shader is inspired from MNN's gemv_1x1_conv_buf.cl shader. With this compute kernel, transformer models' text generation can execute much faster than before. On Samsung Galaxy S24 for Llama 3.2 1B, generating 128 tokens: Before: ~25 tok/s After: ~49 tok/s ## Why this new shader is faster The biggest reason is due to vectorized loading of the uint4 weight buffer. This new shader loads the weight buffer as a buffer/image of `uvec4`, whereas the old shader loads the weight buffer as a buffer/image of `u8vec4`. Using the Adreno Offline Compiler, I found that in the former, only one load instruction was used to load from the weight tensor, whereas in the latter 16 load instructions were used to load from the weight tensor. It appears that the data loading was not being vectorized at the assembly level. This is potentially behaviour that can be approved in the SPIR-V shader compiler. An additional factor is better weight packing layout. The new prepacking routine results in better memory coalescing between threads in a work group. The final major factor is the use of tree based reduction to co-operatively reduce partial results into the final output. Previously, a single thread was responsible for the final reduction. ## Future Work * Introduce faster shader for int4 linear gemm cases * Update QCSNW to also use these updated shaders Differential Revision: [D78275584](https://our.internmc.facebook.com/intern/diff/D78275584/) [ghstack-poisoned]

Pull Request resolved: #12444 ## Changes * Introduce a new compute shader for int4 linear's gemv cases that performs much better than the existing shader. This shader is inspired from MNN's gemv_1x1_conv_buf.cl shader. With this compute kernel, transformer models' text generation can execute much faster than before. On Samsung Galaxy S24 for Llama 3.2 1B, generating 128 tokens: Before: ~25 tok/s After: ~49 tok/s ## Why this new shader is faster The biggest reason is due to vectorized loading of the uint4 weight buffer. This new shader loads the weight buffer as a buffer/image of `uvec4`, whereas the old shader loads the weight buffer as a buffer/image of `u8vec4`. Using the Adreno Offline Compiler, I found that in the former, only one load instruction was used to load from the weight tensor, whereas in the latter 16 load instructions were used to load from the weight tensor. It appears that the data loading was not being vectorized at the assembly level. This is potentially behaviour that can be approved in the SPIR-V shader compiler. An additional factor is better weight packing layout. The new prepacking routine results in better memory coalescing between threads in a work group. The final major factor is the use of tree based reduction to co-operatively reduce partial results into the final output. Previously, a single thread was responsible for the final reduction. ## Future Work * Introduce faster shader for int4 linear gemm cases * Update QCSNW to also use these updated shaders ghstack-source-id: 296437697 Differential Revision: [D78275584](https://our.internmc.facebook.com/intern/diff/D78275584/)

facebook-github-bot · 2025-07-15T22:42:57Z

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

digantdesai · 2025-07-16T10:30:26Z

backends/vulkan/runtime/graph/ops/glsl/linear_qga4w_coop.glsl


 #extension GL_EXT_control_flow_attributes : require
+#extension GL_EXT_debug_printf : require


remove this?

digantdesai · 2025-07-16T10:38:08Z

backends/vulkan/runtime/graph/ops/glsl/linear_qga4w_coop.glsl

+  const uint n = MUL_8(n8);
+  const uint K4 = DIV_UP_4(input_sizes.x);
+
+  const int block_num = input_sizes.x / group_size;


assert (!(input_sizes.x % group_size))?

digantdesai · 2025-07-16T10:43:27Z

backends/vulkan/runtime/graph/ops/glsl/linear_qga4w_coop.glsl

+    // new quantization group.
+    if (group_idx != cur_group_idx) {
+      // The qparams tensor contains the quantization scales and zeros, with
+      // shape [2, N, K / group_size, 1].


is this accurate? Seems like 2 and 1 are flipped? i.e. for a given group, both qparams are next to each other, right?

digantdesai · 2025-07-16T14:48:37Z

backends/vulkan/runtime/graph/ops/glsl/pack_int4_linear_weight_transposed_block_4x8.glsl

@@ -0,0 +1,154 @@
+/*


Curious why do we pack at runtime for Vulkan?

digantdesai · 2025-07-16T14:53:45Z

backends/vulkan/runtime/graph/ops/impl/QuantizedLinearQGANW.cpp

  const uint32_t group_size_val = graph.extract_scalar<uint32_t>(group_size);

-  ValueRef mat2 =
-      prepack_int4_linear_weight_transposed_interleaved(graph, mat2_data);
+  ValueRef mat2 = is_gemv


I would imagine we will change this condition once we introduce gemm and use block_4x8 weight packing for both shaders?

digantdesai · 2025-07-16T14:55:19Z

backends/vulkan/runtime/graph/ops/glsl/qlinear_utils.glslh

+#else // TEXTURE_WEIGHT
+
+uvec4 load_transposed_weight_block(const uint k4, const uint n8, const uint K4) {
+  return texelFetch(t_qmat2, ivec2(k4, n8), 0);


so this load was slow and wasn't vectorizing?

digantdesai · 2025-07-16T15:01:57Z

backends/vulkan/runtime/graph/ops/glsl/qlinear_utils.glslh

+float extract_4bit_from_transposed_block(const uvec4 block, const uint col, const uint row) {
+  return float(int((block[row] >> (4 * (7 - col))) & 15) - 8);
+}


Any way to optimize this extracting multiple values to or something?

digantdesai · 2025-07-16T15:02:36Z

backends/vulkan/runtime/graph/ops/impl/QuantizedLinearQGANW.cpp

-  ValueRef mat2 =
-      prepack_int4_linear_weight_transposed_interleaved(graph, mat2_data);
+  ValueRef mat2 = is_gemv
+      ? prepack_int4_linear_weight_transposed_block_4x8(graph, mat2_data)


packing shader tests?

digantdesai

LGTM. Stamping. :)

…kernel" ## Changes * Introduce a new compute shader for int4 linear's gemv cases that performs much better than the existing shader. This shader is inspired from MNN's gemv_1x1_conv_buf.cl shader. With this compute kernel, transformer models' text generation can execute much faster than before. On Samsung Galaxy S24 for Llama 3.2 1B, generating 128 tokens: Before: ~25 tok/s After: ~49 tok/s ## Why this new shader is faster The biggest reason is due to vectorized loading of the uint4 weight buffer. This new shader loads the weight buffer as a buffer/image of `uvec4`, whereas the old shader loads the weight buffer as a buffer/image of `u8vec4`. Using the Adreno Offline Compiler, I found that in the former, only one load instruction was used to load from the weight tensor, whereas in the latter 16 load instructions were used to load from the weight tensor. It appears that the data loading was not being vectorized at the assembly level. This is potentially behaviour that can be approved in the SPIR-V shader compiler. An additional factor is better weight packing layout. The new prepacking routine results in better memory coalescing between threads in a work group. The final major factor is the use of tree based reduction to co-operatively reduce partial results into the final output. Previously, a single thread was responsible for the final reduction. ## Future Work * Introduce faster shader for int4 linear gemm cases * Update QCSNW to also use these updated shaders Differential Revision: [D78275584](https://our.internmc.facebook.com/intern/diff/D78275584/) [ghstack-poisoned]

Pull Request resolved: #12444 ## Changes * Introduce a new compute shader for int4 linear's gemv cases that performs much better than the existing shader. This shader is inspired from MNN's gemv_1x1_conv_buf.cl shader. With this compute kernel, transformer models' text generation can execute much faster than before. On Samsung Galaxy S24 for Llama 3.2 1B, generating 128 tokens: Before: ~25 tok/s After: ~49 tok/s ## Why this new shader is faster The biggest reason is due to vectorized loading of the uint4 weight buffer. This new shader loads the weight buffer as a buffer/image of `uvec4`, whereas the old shader loads the weight buffer as a buffer/image of `u8vec4`. Using the Adreno Offline Compiler, I found that in the former, only one load instruction was used to load from the weight tensor, whereas in the latter 16 load instructions were used to load from the weight tensor. It appears that the data loading was not being vectorized at the assembly level. This is potentially behaviour that can be approved in the SPIR-V shader compiler. An additional factor is better weight packing layout. The new prepacking routine results in better memory coalescing between threads in a work group. The final major factor is the use of tree based reduction to co-operatively reduce partial results into the final output. Previously, a single thread was responsible for the final reduction. ## Future Work * Introduce faster shader for int4 linear gemm cases * Update QCSNW to also use these updated shaders ghstack-source-id: 296831307 Differential Revision: [D78275584](https://our.internmc.facebook.com/intern/diff/D78275584/)

…kernel" ## Changes * Introduce a new compute shader for int4 linear's gemv cases that performs much better than the existing shader. This shader is inspired from MNN's gemv_1x1_conv_buf.cl shader. With this compute kernel, transformer models' text generation can execute much faster than before. On Samsung Galaxy S24 for Llama 3.2 1B, generating 128 tokens: Before: ~25 tok/s After: ~49 tok/s ## Why this new shader is faster The biggest reason is due to vectorized loading of the uint4 weight buffer. This new shader loads the weight buffer as a buffer/image of `uvec4`, whereas the old shader loads the weight buffer as a buffer/image of `u8vec4`. Using the Adreno Offline Compiler, I found that in the former, only one load instruction was used to load from the weight tensor, whereas in the latter 16 load instructions were used to load from the weight tensor. It appears that the data loading was not being vectorized at the assembly level. This is potentially behaviour that can be approved in the SPIR-V shader compiler. An additional factor is better weight packing layout. The new prepacking routine results in better memory coalescing between threads in a work group. The final major factor is the use of tree based reduction to co-operatively reduce partial results into the final output. Previously, a single thread was responsible for the final reduction. ## Future Work * Introduce faster shader for int4 linear gemm cases * Update QCSNW to also use these updated shaders Differential Revision: [D78275584](https://our.internmc.facebook.com/intern/diff/D78275584/) [ghstack-poisoned]

Pull Request resolved: #12444 ## Changes * Introduce a new compute shader for int4 linear's gemv cases that performs much better than the existing shader. This shader is inspired from MNN's gemv_1x1_conv_buf.cl shader. With this compute kernel, transformer models' text generation can execute much faster than before. On Samsung Galaxy S24 for Llama 3.2 1B, generating 128 tokens: Before: ~25 tok/s After: ~49 tok/s ## Why this new shader is faster The biggest reason is due to vectorized loading of the uint4 weight buffer. This new shader loads the weight buffer as a buffer/image of `uvec4`, whereas the old shader loads the weight buffer as a buffer/image of `u8vec4`. Using the Adreno Offline Compiler, I found that in the former, only one load instruction was used to load from the weight tensor, whereas in the latter 16 load instructions were used to load from the weight tensor. It appears that the data loading was not being vectorized at the assembly level. This is potentially behaviour that can be approved in the SPIR-V shader compiler. An additional factor is better weight packing layout. The new prepacking routine results in better memory coalescing between threads in a work group. The final major factor is the use of tree based reduction to co-operatively reduce partial results into the final output. Previously, a single thread was responsible for the final reduction. ## Future Work * Introduce faster shader for int4 linear gemm cases * Update QCSNW to also use these updated shaders ghstack-source-id: 296855751 Differential Revision: [D78275584](https://our.internmc.facebook.com/intern/diff/D78275584/)

facebook-github-bot · 2025-07-17T16:58:28Z

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

…kernel" ## Changes * Introduce a new compute shader for int4 linear's gemv cases that performs much better than the existing shader. This shader is inspired from MNN's gemv_1x1_conv_buf.cl shader. With this compute kernel, transformer models' text generation can execute much faster than before. On Samsung Galaxy S24 for Llama 3.2 1B, generating 128 tokens: Before: ~25 tok/s After: ~49 tok/s ## Why this new shader is faster The biggest reason is due to vectorized loading of the uint4 weight buffer. This new shader loads the weight buffer as a buffer/image of `uvec4`, whereas the old shader loads the weight buffer as a buffer/image of `u8vec4`. Using the Adreno Offline Compiler, I found that in the former, only one load instruction was used to load from the weight tensor, whereas in the latter 16 load instructions were used to load from the weight tensor. It appears that the data loading was not being vectorized at the assembly level. This is potentially behaviour that can be approved in the SPIR-V shader compiler. An additional factor is better weight packing layout. The new prepacking routine results in better memory coalescing between threads in a work group. The final major factor is the use of tree based reduction to co-operatively reduce partial results into the final output. Previously, a single thread was responsible for the final reduction. ## Future Work * Introduce faster shader for int4 linear gemm cases * Update QCSNW to also use these updated shaders Differential Revision: [D78275584](https://our.internmc.facebook.com/intern/diff/D78275584/) [ghstack-poisoned]

Pull Request resolved: #12444 ## Changes * Introduce a new compute shader for int4 linear's gemv cases that performs much better than the existing shader. This shader is inspired from MNN's gemv_1x1_conv_buf.cl shader. With this compute kernel, transformer models' text generation can execute much faster than before. On Samsung Galaxy S24 for Llama 3.2 1B, generating 128 tokens: Before: ~25 tok/s After: ~49 tok/s ## Why this new shader is faster The biggest reason is due to vectorized loading of the uint4 weight buffer. This new shader loads the weight buffer as a buffer/image of `uvec4`, whereas the old shader loads the weight buffer as a buffer/image of `u8vec4`. Using the Adreno Offline Compiler, I found that in the former, only one load instruction was used to load from the weight tensor, whereas in the latter 16 load instructions were used to load from the weight tensor. It appears that the data loading was not being vectorized at the assembly level. This is potentially behaviour that can be approved in the SPIR-V shader compiler. An additional factor is better weight packing layout. The new prepacking routine results in better memory coalescing between threads in a work group. The final major factor is the use of tree based reduction to co-operatively reduce partial results into the final output. Previously, a single thread was responsible for the final reduction. ## Future Work * Introduce faster shader for int4 linear gemm cases * Update QCSNW to also use these updated shaders ghstack-source-id: 296864718 Differential Revision: [D78275584](https://our.internmc.facebook.com/intern/diff/D78275584/)

facebook-github-bot · 2025-07-17T17:26:37Z

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

This was referenced Jul 14, 2025

[ET-VK] Fix caching mechanism to account for included files #12441

Merged

[ET-VK] Split up prepack command buffer #12442

Merged

[ET-VK][ez] Rename run_prepack() to prepack() and replace encode_prepack() + prepack() with just prepack() #12443

Merged

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 Jul 14, 2025

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

digantdesai reviewed Jul 16, 2025

View reviewed changes

digantdesai approved these changes Jul 16, 2025

View reviewed changes

facebook-github-bot merged commit b4c2c8f into gh/SS-JIA/259/base Jul 17, 2025
99 of 103 checks passed

facebook-github-bot deleted the gh/SS-JIA/259/head branch July 17, 2025 20:51

facebook-github-bot temporarily deployed to cherry-pick-bot July 17, 2025 20:51 — with GitHub Actions Inactive

pytorchbot mentioned this pull request Jul 17, 2025

[ET-VK][qlinear] Faster weight only quantized linear gemv kernel #12610

Merged


		#extension GL_EXT_control_flow_attributes : require
		#extension GL_EXT_debug_printf : require

[ET-VK][qlinear] Faster weight only quantized linear gemv kernel #12444

[ET-VK][qlinear] Faster weight only quantized linear gemv kernel #12444

Uh oh!

Conversation

SS-JIA commented Jul 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Changes

Why this new shader is faster

Future Work

Uh oh!

pytorch-bot bot commented Jul 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🔗 Helpful Links

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

❌ 2 New Failures

Uh oh!

facebook-github-bot commented Jul 14, 2025

Uh oh!

github-actions bot commented Jul 14, 2025

This PR needs a release notes: label

Uh oh!

facebook-github-bot commented Jul 14, 2025

Uh oh!

facebook-github-bot commented Jul 15, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

digantdesai left a comment

Choose a reason for hiding this comment

Uh oh!

facebook-github-bot commented Jul 17, 2025

Uh oh!

facebook-github-bot commented Jul 17, 2025

Uh oh!

Uh oh!

Uh oh!

SS-JIA commented Jul 14, 2025 •

edited

Loading

pytorch-bot bot commented Jul 14, 2025 •

edited

Loading

This PR needs a `release notes:` label