Adjust tol - #95
Open
aws-zhenguo wants to merge 72 commits into
Open
Conversation
) * [release 2.13] Apply Release only changes to 2.13 branch Release-only changes for the release/2.13 branch cut, produced by running scripts/release/apply-release-changes.sh. The script repoints reusable workflows and composite actions from @main to @release/2.13, rewrites templates to release/2.13 (with checkout_pr_head=False so PRs build the merge base rather than the PR head), pins the XLA checkout to the r2.13 branch, pins the disabled/unstable jobs and disabled-tests S3 JSON blobs to fixed versionIds, sets RELEASE_VERSION_TAG=2.13 for the workflow-regeneration lint check, and drops the pull_request-specific checkout ref from the linux binary build/test workflows. Only files that are tracked in release/2.13 are included. The 2.12 PR additionally touched .ci/manywheel/build_cuda.sh and a few workflow files (torchbench/nitpicker/quantization-periodic) that are not tracked in this checkout, so they are intentionally omitted here. Test Plan: Ran the release script and linter: ``` DRY_RUN=disabled ./scripts/release/apply-release-changes.sh lintrunner -a ``` lintrunner reported only pre-existing ACTIONLINT shellcheck warnings on generated workflow lines unrelated to the release-version edits, and made no changes to the staged files. Verified every staged hunk is a release-only edit (@main -> @release/2.13, main -> release/2.13, XLA r2.13 pin, S3 versionId pins, RELEASE_VERSION_TAG=2.13, and the pull_request ref removal) with no submodule or unrelated changes. This PR was authored with the assistance of Claude Code. * [release 2.13] Pin Linux manywheel builder docker images Release builds should use a fixed, reproducible build toolchain instead of the floating builder image tags that main tracks (e.g. pytorch/manylinux2_28-builder:cuda12.6). For 2.12 the binary build workflows resolved the image dynamically via calculate-docker-image; for 2.13 we freeze that resolved image as a literal pin. The pin is applied in the generator (generate_binary_build_matrix.py) rather than in the generated YAML directly, so re-running .github/regenerate.sh (and the lint job that asserts the generated files are up to date) reproduces the pinned tags. wheel_container_image_tag_prefix() appends the pin only for the linux manywheel OSes (linux, linux-aarch64, linux-s390x), since only those builds run inside these containers; windows and macos keep the plain tag prefix. The pin suffix is the .ci/docker tree hash, f38ba0b (git rev-parse HEAD:.ci/docker), which is exactly the tag that .github/actions/binary-docker-build (and the s390x equivalent) publish as ${prefix}-${CI_FOLDER_SHA}. It matches the image already published on Docker Hub, e.g. pytorch/manylinux2_28_aarch64-builder:cpu-aarch64-f38ba0b10220982e39441d29d203d803a2b56c92 Test Plan: Regenerated the workflows in release mode and verified the result: ``` RELEASE_VERSION_TAG=2.13 python3 .github/scripts/generate_ci_workflows.py ``` - Every `image:` and matrix `docker_image_tag_prefix` in the three linux manywheel generated workflows now carries the `-f38ba0b...` suffix (cpu, cpu-aarch64, cuda12.6/13.0/13.2, rocm7.1/7.2, xpu, cpu-s390x); no linux builder image remains floating. - Windows and macos generated workflows are unchanged (plain `cpu`, `cuda12.6`, ...), confirming the pin is linux-only. - Re-running the generator a second time produced byte-identical output (md5sum unchanged), so the regeneration/lint up-to-date check is stable. Note: the local linters that shell out to `uv` could not run in this environment; the change was format-checked manually. This PR was authored with the assistance of Claude Code.
pytorch#186992) The release-only DOCKER_IMAGE_PIN appends the .ci/docker tree hash to the manywheel builder image tags so the release uses a reproducible toolchain. This was applied to all manywheel OSes, including s390x. Root cause: unlike the x86_64 and aarch64 builder images, the s390x builder image is built locally on the self-hosted linux.s390x runners and is never published to docker.io under the pinned tag. The pinned pull therefore fails: Error: initializing source docker://pytorch/manylinuxs390x-builder:cpu-s390x-<hash>: reading manifest ... requested access to the resource is denied Fix: drop linux-s390x from MANYWHEEL_OSES so s390x falls back to the floating "cpu-s390x" tag, while x86_64 and aarch64 keep their pinned tags. Regenerated the s390x nightly workflow accordingly. Test Plan: - Regenerated workflows and confirmed the pin is gone only for s390x: ``` python3 .github/scripts/generate_ci_workflows.py grep -c "cpu-s390x-f38ba0b" .github/workflows/generated-linux-s390x-binary-manywheel-nightly.yml # 0 grep -m2 docker_image_tag_prefix .github/workflows/generated-linux-aarch64-binary-manywheel-nightly.yml # still pinned ``` Authored-with: Claude (AI assistant)
Update torch-xpu-ops commit pin (pytorch#186768) Update the torch-xpu-ops commit to [intel/torch-xpu-ops@bc2942](intel/torch-xpu-ops@bc29424), includes: Fixes pytorch#186661 for build warnings: - [-Werror=template-id-cdtor] caused by SYCLTLA with GCC15 - [-Werror=int-in-bool-context] caused by ‘*’ in boolean context - [-Wdeprecated-attributes] caused by deprecated attribute intel::reqd_sub_group_size Migrate std::exp2, std::expm1, std::frexp and std::copysign to sycl:: namespace for SYCL compatibility. Add compiler version check for SymmetricMemory. Pull Request resolved: pytorch#186768 Approved by: https://github.com/guangyey, https://github.com/EikanWang, https://github.com/atalman (cherry picked from commit ddc3c36) Co-authored-by: Cui, Yifeng <yifeng.cui@intel.com> Co-authored-by: Wang, Chuanqi <chuanqi.wang@intel.com>
pytorch#187001) Release candidate builds triggered by a tag (e.g. v2.13.0-rc1) were producing wheels that pinned triton to a dev-style version such as triton==3.7.1+git5d6048aa instead of the release triton==3.7.1, which then fails to install in the test job because that version does not exist on the test index. Root cause: the unified inline manywheel build job (cpu/cpu-aarch64/ cuda/cuda-aarch64) checks out the raw commit via `ref: github.sha` with `fetch-depth: 2`. Checking out a bare SHA does not fetch the tag ref, so `tagged_version()` in .ci/pytorch/binary_populate_env.sh (`git describe --tags --exact`) fails and the build falls through to the `<version>.dev<DATE>` default. binary_populate_env.sh then takes its `.*dev.*` branch and appends `+git<triton-shorthash>` to the triton requirement that gets baked into the wheel metadata. Fix: add `fetch-tags: true` to the inline build job checkout in the linux binary build template so the tag pointing at the checked-out commit is fetched, letting `git describe --tags --exact` succeed and the build resolve to the release version. The ROCm/XPU/s390x builds use the reusable _binary-build-linux.yml whose checkout has no pinned ref (it uses the default tag ref for a tag push) and are unaffected. This is the same class of bug fixed for the older checkout-pytorch path in pytorch#180508; this covers the inlined unified build job introduced since. Test Plan: Regenerated the workflows from the template and confirmed only the two linux manywheel workflows change, each gaining `fetch-tags: true` on its four unified build jobs: ``` python3 .github/scripts/generate_ci_workflows.py git diff --stat .github/workflows grep -c 'fetch-tags: true' \ .github/workflows/generated-linux-binary-manywheel-nightly.yml \ .github/workflows/generated-linux-aarch64-binary-manywheel-nightly.yml ``` Validated the regenerated YAML parses and passes actionlint (the only reported shellcheck warnings are pre-existing on the base files): ``` python3 -c "import yaml; yaml.safe_load(open(f)) for f in (...)" lintrunner --take ACTIONLINT \ .github/workflows/generated-linux-binary-manywheel-nightly.yml \ .github/workflows/generated-linux-aarch64-binary-manywheel-nightly.yml ``` This PR was authored with the assistance of an AI coding assistant.
…ag (pytorch#187055) Full git fetch on tag pushes so release manywheel builds detect the tag (pytorch#187042) The unified inline manywheel build jobs (cpu/cpu-aarch64/cuda/cuda-aarch64) check out a pinned commit SHA with a shallow `fetch-depth: 2`. On a release tag push (e.g. v2.13.0-rc1) the tag ref is never written into that shallow checkout, so `tagged_version()` in .ci/pytorch/binary_populate_env.sh (`git describe --tags --exact`) fails and the build falls through to the `<version>.dev<DATE>` default, producing wheels versioned `2.13.0.devYYYYMMDD` and pinning triton to a `+git<hash>` version that does not exist on the test index. Root cause: pytorch#187001 added `fetch-tags: true` but kept `fetch-depth: 2`. `fetch-tags` is ineffective when `ref` is a bare SHA and the fetch is shallow; git does not write the tag ref locally. The proven path (the checkout-pytorch action) works because it uses `fetch-depth: 0`, where a full fetch brings all tags regardless. Fix: in the linux binary build template, set `fetch-depth` to 0 on tag pushes (`github.ref_type == 'tag'`) and keep 2 for nightlies so they stay fast. With a full fetch the tag is present, `git describe --tags --exact` succeeds, and the build resolves to the release version with a clean triton requirement. Needs to be cherry-picked onto release/2.13 for the RC builds to pick it up. Test Plan: PR: pytorch#187047 Regenerated the workflows from the template and confirmed only the two linux manywheel workflows change, each unified build job getting the conditional fetch-depth and fetch-tags: ``` python3 .github/scripts/generate_ci_workflows.py git diff --stat .github/workflows grep -c "github.ref_type == 'tag' && 0 || 2" \ .github/workflows/generated-linux-binary-manywheel-nightly.yml \ .github/workflows/generated-linux-aarch64-binary-manywheel-nightly.yml ``` Validated the regenerated YAML parses and passes actionlint (the only reported shellcheck warnings are pre-existing on the base files): ``` python3 -c "import yaml, sys; [yaml.safe_load(open(f)) for f in sys.argv[1:]]" \ .github/workflows/generated-linux-binary-manywheel-nightly.yml \ .github/workflows/generated-linux-aarch64-binary-manywheel-nightly.yml lintrunner --take ACTIONLINT \ .github/workflows/generated-linux-binary-manywheel-nightly.yml \ .github/workflows/generated-linux-aarch64-binary-manywheel-nightly.yml ``` This PR was authored with the assistance of an AI coding assistant. Pull Request resolved: pytorch#187042 Approved by: https://github.com/NicolasHug, https://github.com/albanD, https://github.com/jeanschmidt (cherry picked from commit 80bd062) Co-authored-by: atalman <atalman@meta.com>
…etect the tag (pytorch#187058) Followup - Full git fetch on tag pushes so release manywheel builds detect the tag (pytorch#187047) ## Problem The unified inline manywheel build jobs (`cpu` / `cpu-aarch64` / `cuda` / `cuda-aarch64`) check out a pinned commit SHA with a shallow `fetch-depth: 2`. On a release tag push (e.g. `v2.13.0-rc1`) the tag ref is never written into that shallow checkout, so `tagged_version()` in `.ci/pytorch/binary_populate_env.sh` (`git describe --tags --exact`) fails. The build then falls through to the `<version>.dev<DATE>` default, producing wheels versioned `2.13.0.devYYYYMMDD` and pinning triton to a `+git<hash>` version that does not exist on the test index. ## Root cause pytorch#187001 added `fetch-tags: true` but kept `fetch-depth: 2`. `fetch-tags` is ineffective when `ref` is a bare SHA and the fetch is shallow -- git does not write the tag ref locally. The proven path (the `checkout-pytorch` action) works because it uses `fetch-depth: 0`, where a full fetch brings all tags regardless. ## Fix Do a full fetch (`fetch-depth: 0`) on tag pushes and keep the shallow `fetch-depth: 2` for nightlies: ```yaml fetch-depth: ${{ github.ref_type != 'tag' && 2 || 0 }} fetch-tags: ${{ github.ref_type == 'tag' }} ``` ### Why the expression is written this way GitHub Actions has no ternary, so the `A && B || C` idiom is used -- but it only works when `B` is **truthy**. The naive `github.ref_type == 'tag' && 0 || 2` is broken because `0` is falsy: on a real tag push it evaluates `true && 0` -> `0`, then `0 || 2` -> `2`, so it **always** yields `2` and the full-fetch branch is unreachable. An earlier revision shipped this broken form, which is why tag builds kept getting `fetch-depth: 2`. Negating the condition keeps the truthy literal (`2`) as the `&&` operand so the value is never swallowed: | trigger | expression | result | |---|---|---| | tag | `false && 2` -> false -> `false \|\| 0` | **0** (full fetch) | | branch / nightly | `true && 2` -> 2 | **2** (shallow) | With a full fetch the tag is present, `git describe --tags --exact` succeeds, and the build resolves to the release version with a clean triton requirement. > Needs to be cherry-picked onto `release/2.13` (superseding the broken expression) for the RC builds to pick it up. ## Test Plan Regenerated the workflows from the template and confirmed only the two linux manywheel workflows change, each of the 4 unified build jobs getting the conditional `fetch-depth` and `fetch-tags`: ``` python3 .github/scripts/generate_ci_workflows.py git diff --stat .github/workflows grep -c "github.ref_type != 'tag' && 2 || 0" \ .github/workflows/generated-linux-binary-manywheel-nightly.yml \ .github/workflows/generated-linux-aarch64-binary-manywheel-nightly.yml ``` Validated the regenerated YAML parses and passes actionlint (the only reported shellcheck warnings are pre-existing `SC1090` on `source "${BINARY_ENV_FILE}"`): ``` python3 -c "import yaml,sys;[yaml.safe_load(open(f)) for f in sys.argv[1:]]" \ .github/workflows/generated-linux-binary-manywheel-nightly.yml \ .github/workflows/generated-linux-aarch64-binary-manywheel-nightly.yml lintrunner --take ACTIONLINT \ .github/workflows/generated-linux-binary-manywheel-nightly.yml \ .github/workflows/generated-linux-aarch64-binary-manywheel-nightly.yml ``` This PR was authored with the assistance of an AI coding assistant. Pull Request resolved: pytorch#187047 Approved by: https://github.com/jeanschmidt, https://github.com/albanD (cherry picked from commit 1e97809) Co-authored-by: atalman <atalman@meta.com>
… tag (pytorch#187172) Full git fetch on tag pushes so macOS release wheel builds detect the tag (pytorch#187139) ## Problem Same issue as pytorch#187058, but for the **macOS arm64 binary wheel** build. The `wheel-build` job checks out a pinned commit SHA with the default shallow `actions/checkout` (depth 1, no tags). On a release tag push (e.g. `v2.13.0-rc1`) the tag ref is never written into that checkout, so `tagged_version()` in `.ci/pytorch/binary_populate_env.sh` (`git describe --tags --exact`, invoked per-iteration by `.ci/wheel/build_all_macos_wheels.sh`) fails. The build then falls through to the `<version>.dev<DATE>` default, producing wheels versioned `2.13.0.devYYYYMMDD` instead of the release version. ## Fix Do a full fetch (`fetch-depth: 0`) on tag pushes and keep the shallow checkout for nightlies: ```yaml fetch-depth: ${{ github.ref_type != 'tag' && 1 || 0 }} fetch-tags: ${{ github.ref_type == 'tag' }} ``` The condition is negated (matching pytorch#187058) because GitHub Actions has no ternary and the `A && B || C` idiom only works when `B` is truthy; the naive `github.ref_type == 'tag' && 0 || 2` always yields the shallow value because `0` is falsy. Only the `wheel-build` checkout is changed; the libtorch `*-extract` job uses a sparse checkout of the already-built wheel artifact and does not need the tag. > Needs to be cherry-picked onto `release/2.13` for the RC builds to pick it up. ## Test Plan Regenerated the workflows from the template and confirmed only the macOS wheel workflow changed, with the conditional fetch on the build job's checkout: ``` python3 .github/scripts/generate_ci_workflows.py git diff --stat .github/workflows ``` Validated the regenerated YAML parses and passes actionlint (the only reported shellcheck warning, `SC2086` on `uv python install $DESIRED_PYTHONS`, is pre-existing and unrelated): ``` python3 -c "import yaml; yaml.safe_load(open('.github/workflows/generated-macos-arm64-binary-wheel-nightly.yml'))" lintrunner --take ACTIONLINT .github/workflows/generated-macos-arm64-binary-wheel-nightly.yml ``` *This PR was authored with the assistance of an AI coding agent.* Pull Request resolved: pytorch#187139 Approved by: https://github.com/malfet (cherry picked from commit fb17c34) Co-authored-by: atalman <atalman@meta.com>
pytorch#185760)" (pytorch#187347) Revert "Skip cudagraphs for kernel-free inductor graphs (pytorch#185760)" This reverts commit b1e3edd. Reverted pytorch#185760 on behalf of https://github.com/wdvr due to reverting due to failing signal on D108074417 - discussed with author ([comment](pytorch#185760 (comment))) (cherry picked from commit 82a2694) Co-authored-by: PyTorch MergeBot <pytorchmergebot@users.noreply.github.com>
…gorithms (pytorch#186653)" (pytorch#187349) Revert "Make topk deterministic under deterministic algorithms (pytorch#186653)" This reverts commit 1100802. Reverted pytorch#186653 on behalf of https://github.com/wdvr due to failing some internal ads tests - see D108014200 for signal ([comment](pytorch#186653 (comment))) (cherry picked from commit ca8348e) Co-authored-by: PyTorch MergeBot <pytorchmergebot@users.noreply.github.com>
[BE] Make spmd_type a CI rather than CD dependency (pytorch#187067) Alas, it could not be added to `requirements-ci.txt`, as it depends on torch and we don't want any pre-installed torch wheels inside CI docker builds Pull Request resolved: pytorch#187067 Approved by: https://github.com/pianpwk, https://github.com/atalman, https://github.com/fegin (cherry picked from commit ba71580) Co-authored-by: Nikita Shulga <nshulga@meta.com>
…d symbols in fake traces (pytorch#183837)" (pytorch#187348) Revert "[HOP][Dynamic Shapes] Ignore discarded unbacked symbols in fake traces (pytorch#183837)" This reverts commit 5ccc7ff. Reverted pytorch#183837 on behalf of https://github.com/wdvr due to failing some executorch / other tests on the HOP / control-flow / FlexAttention surface I believe ([comment](pytorch#183837 (comment))) (cherry picked from commit 3d10f15) Co-authored-by: PyTorch MergeBot <pytorchmergebot@users.noreply.github.com>
[CD] Bump 13.0 builds to 13.0.3 (pytorch#179758) CUDA 13.0.3 is released which includes the 1. patch release fix from cublas that fixes the below issue: Quote from [CUBLAS Patch Release notes](https://docs.nvidia.com/cuda/cublas-patch-release-notes/) Fixed an issue in cublasLtMatmul() that could lead to incorrect results when it ran concurrently with another kernel that used Tensor Memory. This issue affected only algorithms with CUBLASLT_ALGO_CONFIG_ID equal to 66 on GPUs with Compute Capability 10.x and 11.x, and had existed since cuBLAS 12.8. [5807900, 5943783] 2. nvjitlink is set to a lower bound, rather than a pin, for better compatibility for RAPIDS wheels nvcc/nvvm/crt compiler stack are pinned to the same CL for better compatibility. It will pull the latest nvjitlink available rather than the one that is pinned to the released CTK. Updating the CTK version to 13.0.3 in place of the drop in fix in pytorch#178333 Component | 13.0.2 | 13.0.3 -- | -- | -- CUDA cuBLAS | 13.1.0.3 | 13.1.1.3 CUDA nvsdm | 580.95.05 | 580.126.20 Pull Request resolved: pytorch#179758 Approved by: https://github.com/malfet, https://github.com/atalman (cherry picked from commit 99fd1c8) Co-authored-by: Ting Lu <tingl@nvidia.com>
…ytorch#187416) Skip TestMultiprocessingDeviceType on XPU due to lack of IPC support (pytorch#187314) # Motivation When pytorch#184737 generalize `test_multiprocess.py`, it helps enable `TestMultiprocessingDeviceType` test on XPU. However, XPU doesn't support this test suite because lack of IPC support currently. So we would like to skip this test case and restore XPU CI to green. Fixes pytorch#186585 Code originates from pytorch#186793 Co-authored-by: @xuhancn Pull Request resolved: pytorch#187314 Approved by: https://github.com/EikanWang, https://github.com/atalman ghstack dependencies: pytorch#181233, pytorch#187137, pytorch#187232, pytorch#187306 (cherry picked from commit 4f26a57) Co-authored-by: Yu, Guangye <guangye.yu@intel.com>
…rch#187417) [xpu][fix] Include kernel_compile_result.h in aoti xpu.h header (pytorch#187137) # Motivation pytorch#184735 introduces AOTI lazy autotuning with the dual-wrapper mechanism, which uncovered some new XPU test failures in CI. # Additonal Context Fix pytorch#187124 Fix pytorch#187123 Fix pytorch#187035 Fix pytorch#187035 Fix pytorch#187036 Fix pytorch#187125 Fix pytorch#187121 This needs to be cherry-picked to the release branch. Pull Request resolved: pytorch#187137 Approved by: https://github.com/EikanWang, https://github.com/atalman ghstack dependencies: pytorch#181233 (cherry picked from commit 6ec77b0) Co-authored-by: Yu, Guangye <guangye.yu@intel.com>
…o driver (pytorch#187422) Handle pyzes import failures gracefully on machines without level zero driver (pytorch#187232) # Motivation Previously, we didn't handle pyzes import failures gracefully on machines without level zero driver. Without this PR: <img width="510" height="436" alt="image" src="https://github.com/user-attachments/assets/5c6db7ff-ee8d-4ebe-9177-db2ff80916c1" /> With this PR: <img width="530" height="179" alt="image" src="https://github.com/user-attachments/assets/9239ac61-3722-42d7-8411-68f61abd2e0a" /> # Additional Context <img width="1004" height="36" alt="image" src="https://github.com/user-attachments/assets/0035d2c6-2e49-4570-97de-3a4b48ae0575" /> This needs to be cherry-picked to the release branch. Pull Request resolved: pytorch#187232 Approved by: https://github.com/EikanWang, https://github.com/atalman ghstack dependencies: pytorch#181233, pytorch#187137 (cherry picked from commit fd79a5f) Co-authored-by: Yu, Guangye <guangye.yu@intel.com>
Revert XPU device-wide synchronization (pytorch#187306) # Motivation This PR reverts pytorch#182630 to fix pytorch#187277 Root cause is `ext_oneapi_wait_and_throw` will introduce SYCL Graph to sync an invalid queue. # Additional Context This needs to be cherry-picked to the release branch. Why isn't it captured on CI? This issue is only found on BMG (Xe2), and the current CI is on Data Center GPU (Xe). Pull Request resolved: pytorch#187306 Approved by: https://github.com/EikanWang, https://github.com/atalman ghstack dependencies: pytorch#181233, pytorch#187137, pytorch#187232 (cherry picked from commit 421abac) Co-authored-by: Yu, Guangye <guangye.yu@intel.com>
…with attn_bias (pytorch#187684) [SDPA] Fix 32-bit offset overflow in mem-efficient attention forward with attn_bias (pytorch#187225) ## Summary `F.scaled_dot_product_attention` with the **EFFICIENT_ATTENTION** backend and an explicit `attn_mask` **silently returns garbage** for every query row past `2^32 / seq_len` once `num_queries * num_keys > 2^32` (i.e. S > 65536 for square self-attention). No error, no warning, no NaN — the corrupted values look plausible, which makes this extremely hard to attribute downstream (we found it as silently diverging RL training metrics). ## Root cause In `kernel_forward.h`, `query_start` is `uint32_t`: https://github.com/pytorch/pytorch/blob/545c55c1724bafed6772a0b85fecfd09f9aa0dbb/aten/src/ATen/native/transformers/cuda/mem_eff_attention/kernel_forward.h#L635 and the per-row offset into the bias tensor is computed as `query_start * p.bias_strideM` where `bias_strideM` is `int32_t`, so the multiply happens in 32-bit unsigned arithmetic and wraps modulo 2^32: https://github.com/pytorch/pytorch/blob/545c55c1724bafed6772a0b85fecfd09f9aa0dbb/aten/src/ATen/native/transformers/cuda/mem_eff_attention/kernel_forward.h#L811 Past `row = 2^32 / seq_len` the kernel reads the mask from wrapped addresses (typically an earlier row of the same tensor), producing wrong attention for those rows. Corruption onset at exactly `2^32 / S` (not `2^31 / S`) matches the unsigned arithmetic. The dropout RNG `skipahead` offset in the same kernel has the same 32-bit multiply (`(query_start + thread_i) * p.num_keys_absolute`). The backward kernel computes the equivalent offset with an `int64_t` `query_start` (`kernel_backward.h`), so with dropout + large seq_len the forward and backward dropout masks diverge past the same boundary, corrupting gradients. The batch/head-level strides (`bias_strideB`/`bias_strideH`) were already widened to `int64_t` previously; the per-row offset was missed. Note these kernels were vendored from xformers, which has since removed its in-tree CUTLASS FMHA sources, so the fix needs to land here. ## Fix Compute both offsets in 64-bit, matching `kernel_backward.h`. Two one-line casts; in-bounds behavior is bit-identical. ## Reproduction (any sm80+ GPU, bf16) ```python import torch import torch.nn.functional as F from torch.nn.attention import SDPBackend, sdpa_kernel S, HD = 73728, 64 # S^2 = 1.27 * 2^32 torch.manual_seed(0) q = torch.randn(1, 1, S, HD, device="cuda", dtype=torch.bfloat16) * 0.1 k = torch.randn(1, 1, S, HD, device="cuda", dtype=torch.bfloat16) * 0.1 v = torch.randn(1, 1, S, HD, device="cuda", dtype=torch.bfloat16) idx = torch.arange(S, device="cuda") causal = (idx[:, None] >= idx[None, :])[None, None] ref = F.scaled_dot_product_attention(q, k, v, is_causal=True) # ground truth with sdpa_kernel(SDPBackend.EFFICIENT_ATTENTION): out = F.scaled_dot_product_attention(q, k, v, attn_mask=causal) B = 2**32 // S # predicted corruption onset = row 58254 print((out - ref)[0, 0, :B].abs().max()) # ~6e-5 (bf16 noise) print((out - ref)[0, 0, B:].abs().max()) # ~0.39 (garbage) ``` Observed on `2.14.0.dev20260612+cu130` (H200, sm90) — corruption onset is exactly `2^32 // S` for every S tested (73728→58254, 81920→52428, 98304→43690, 90000→47721). The MATH backend with the same mask tensor is correct everywhere, confirming the mask contents are fine and the bug is in the kernel's indexing. `is_causal=True` (no mask tensor) is unaffected. ## Test plan - Added `test_mem_eff_attention_large_seq_len_attn_mask_index_overflow` (gated by `@largeTensorTest("12GB", "cuda")`): explicit additive causal mask vs `is_causal=True` on the same backend at seq_len=70000. Fails before this fix (max abs diff 0.54 past row 61356, exact 0 before it), passes after. - Verified the kernel change directly on H200: compiled `kernel_forward.h` (pristine vs patched, same CUTLASS pin) into a standalone extension driving `AttentionKernel<bf16, Sm80, true, 64, 64, 64>` with identical S=73728 inputs. Pristine reproduces the corruption bit-for-bit with the stock binary (max diff 0.39 past row 58254); patched returns bf16-noise-level diff (6.1e-5) everywhere, and is bit-identical to pristine for all in-bounds rows. AI assistance (Claude) was used to locate the overflow and prepare this PR; the change and verification were reviewed end-to-end by the submitter. Pull Request resolved: pytorch#187225 Approved by: https://github.com/Skylion007 (cherry picked from commit 77abe15) Co-authored-by: Bin Lei <leib2765@gmail.com> Co-authored-by: Claude Fable 5 <noreply@anthropic.com> Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
…ytorch#187666) Revert "Preserve FX graph cache guard provenance (pytorch#184193)" (pytorch#187581) This reverts commit 060670a. Pull Request resolved: pytorch#187581 Approved by: https://github.com/zou3519
…pytorch#187973) Fix Windows libtorch x86_64 and arm64 packages overwriting each other (pytorch#187837) Fixes pytorch#187812 ## Problem The Windows libtorch CD packages for x86_64 and arm64 are generated with the **same filename** and uploaded to the **same S3 location**, so the arm64 build clobbers the x86_64 one. Users downloading the Windows x64 libtorch release actually receive Aarch64 binaries (`c10.dll: PE32+ executable (DLL) (GUI) Aarch64`). ## Root cause `compute_zip_prefix()` in `.ci/libtorch/extract_libtorch_from_wheel.py` returned `libtorch-win-shared-with-deps` for every Windows build regardless of architecture (the docstring even named `libtorch-win-arm64-shared-with-deps`, but the code never produced it). Both x86_64 and arm64 are CPU builds, so the upload subfolder (`DESIRED_CUDA=cpu`) and the zip filename were identical, and the S3 object key is the zip filename. The arch-blind naming was introduced in pytorch#174753 (which added the wheel-extraction approach); the collision became live once the windows-arm64 wheel workflow started running the same extraction in pytorch#181586. ## Fix Thread architecture through the extraction so arm64 produces `libtorch-win-arm64-shared-with-deps-{version}.zip` while x86_64 keeps its existing `libtorch-win-shared-with-deps-{version}.zip` name (preserving the public download URL). `generate_libtorch_extraction_configs` also gives the arm64 job a distinct `build_name` so the GitHub artifact and job names no longer alias. ## Test Plan Verified prefix logic: ``` x86_64 -> libtorch-win-shared-with-deps arm64 -> libtorch-win-arm64-shared-with-deps ``` Regenerated the binary build workflows (`python .github/scripts/generate_ci_workflows.py`); the windows-arm64 wheel workflow now passes `--arch arm64` and uploads a distinct `libtorch-arm64-cpu-shared-with-deps-release` artifact, while the x86_64 workflow is unchanged apart from an explicit `--arch x86_64`. This PR was authored with the assistance of an AI coding assistant (Claude Code). Pull Request resolved: pytorch#187837 Approved by: https://github.com/Skylion007, https://github.com/huydhn, https://github.com/malfet (cherry picked from commit 599fb5c) Co-authored-by: atalman <atalman@meta.com>
…ch#187983) Fix bmm outer product Triton launch on non-current CUDA device (pytorch#187733) The Python native bmm outer-product override launches a Triton kernel for CUDA inputs shaped like `(B, M, 1) x (B, 1, N)`. Unlike the generated C++ ATen CUDA path, this Python dispatch path does not get an automatic CUDA device guard before launching the kernel. In vLLM multimodal tests, the model hooks can run the relevant rotary embedding buffers and inputs on `cuda:1` while the process current device is still `cuda:0`; Triton then launches on the wrong device/stream and rejects the `cuda:1` pointers with `ValueError: Pointer argument cannot be accessed from Triton (cpu tensor?)`. Guard the Triton call when the input device is not already current, while leaving the common already-current path direct to avoid unnecessary Python context manager overhead. Also require both bmm inputs to be on the same CUDA device before selecting the override, so mismatched CUDA inputs fall back to native bmm and report the normal same-device error instead of reaching the Triton kernel. I considered guarding unconditionally, but a small same-device benchmark showed that the Python context manager adds measurable overhead for small outer-product bmm calls. The conditional guard keeps the fix scoped to the non-current-device case that needs it. Fixes pytorch#187729 Generated by my agent Benchmark Results: - Command: `CUDA_VISIBLE_DEVICES=0 python - <<'PY' ...` benchmarking 7 trials of 1000 `torch.bmm` calls on `(32, 128, 1) x (32, 1, 512)` CUDA tensors with current device matching the inputs. - Before: median 24.210 us/call; raw `[24.34, 24.365, 24.195, 24.206, 24.21, 24.272, 24.142]`. - After: median 24.946 us/call; raw `[25.045, 24.909, 25.008, 25.042, 24.906, 24.946, 24.926]`. Test Plan: - `CUDA_VISIBLE_DEVICES=0,1 python - <<'PY' ...` minimal repro: before the fix failed with the Triton pointer `ValueError`; after the fix produced a `cuda:1` result and preserved current device `0`. - `CUDA_VISIBLE_DEVICES=0,1 python -m pytest test/test_bmm_outer_product.py -q -rs` passed: `11 passed, 10 subtests passed`. - `lintrunner torch/_native/ops/bmm_outer_product/triton_impl.py test/test_bmm_outer_product.py` passed. - `git diff --cached --check` passed. - `lintrunner -a` was run and failed on unrelated pre-existing clang-tidy findings in untouched C++ files. Pull Request resolved: pytorch#187733 Approved by: https://github.com/slayton58 (cherry picked from commit 5a5e50f) Co-authored-by: Jason Ansel <jansel@meta.com>
[xpu] Fix LSTM oneDNN Integration (pytorch#187334) 1. onednn LSTM on XPU does not support bf16 on bias and cell state 2. add deterministic attribute Pull Request resolved: pytorch#187334 Approved by: https://github.com/EikanWang, https://github.com/atalman (cherry picked from commit 691e8b6) Co-authored-by: Zhang, Jianyi <jianyi.zhang@intel.com>
* Revive CUDA 12.9 nightly binary builds (pytorch#186015) Restores the Linux-only (x86_64 + aarch64) CUDA 12.9 build matrix and `cuda12.9` docker images that were removed in pytorch#179155 and pytorch#179158. Generated workflows regenerated via `.github/regenerate.sh`. Windows continues to skip 12.9; `install_129` and the `build_cuda.sh` 12.9 arch list were already present on this branch. Fixes pytorch#185269. Authored with Claude. * Remove unused noqa: B950 directive in generate_binary_build_matrix.py --------- Co-authored-by: Nikita Shulga <2453524+malfet@users.noreply.github.com>
* [MPS] Refactor inlined Metal reduction logic into shared header (pytorch#187541) Pulls the open-coded identity / replace / combine / simd_reduce / threadgroup_reduce helpers used by the Metal min/max value-reduction kernels (and by the inductor MPS codegen's max/min and argmin/argmax paths) into shared `c10::metal::MaxOp<T>` / `MinOp<T>` structs in `c10/metal/reduction_utils.h`. The follow-up change migrating argmin/argmax will reuse those primitives as well. Fix latent bug in MPSInducotr when min/max would not identify -INFINITY, as identity used to be `-FLT_MIN` in inductor inlined reduction code, that allows one to remove xfails from bunch of dynamic shapes reduction tests Authored with Claude. Pull Request resolved: pytorch#187541 Approved by: https://github.com/Skylion007 * [MPS] Migrate argmin/argmax from MPSGraph to Metal kernels (pytorch#187304) Replaces the MPSGraph-based argmax/argmin implementation with three native Metal kernels mirroring the value_reduction layout introduced for amax/amin/all/any in pytorch#180752: a generic NormParams kernel for arbitrary reduction patterns, an inner-dim kernel (one simdgroup per row, simd_arg_reduce collapse) for contiguous reductions over the last dim, and an outer-dim kernel (TG_X x TG_Y tile, shared-mem pair tree reduce) for contiguous reductions over dim 0. The host-side dispatcher in ReduceOps.mm picks inner/outer when the input and output are contiguous and exactly one of those dims is reduced, and falls back to the generic kernel otherwise; full reduction (dim=None) is handled via a contiguous flatten so the returned linear index matches the standard as-if-contiguous convention. The MPSGraph path used to cast bfloat16 to float32 before the reduction, so bf16 is where the migration wins the most (e.g. 4096x4096 dim=0 argmax goes 1518us -> 294us = 5.17x on M4 Max); fp16/fp32 dim=0 hit 2.4-3.5x and dim=1 hit 1.1-1.3x. Correctness: the natural simd_argmax(val, idx) helper ties on lowest LANE, but when a single lane scans multiple positions its stored idx is not necessarily the lowest one carrying the winning value, so the kernels do a two-step simd_max + simd_min-on-eff_idx pattern instead (NaN lanes count as winners so first-NaN-in-source-order wins). The shared-memory tree reduction in the outer kernel uses the same strict-better-or-equal-with-lower-idx predicate. The NaN-propagating "should-replace" predicates argmax_replace / argmin_replace are factored into c10/metal/reduction_utils.h so they sit next to simd_argmax/simd_argmin, which already encode the same NaN-as-winner logic via simd_ballot. TODO: argmin/argmax and amin/amax now share the (general, inner, outer) kernel shape, the per-thread-scan + simd-collapse skeleton, and the address-math helpers. Unifying them under a single Reducer concept (per-thread accumulator + finalize hook, with NCHAINS as a property of the reducer) would let the three kernel grids be written once and instantiated for both ValueReducer<Op, Load, NCHAINS=8> and ArgReducer<Op, NCHAINS=1>. Worth doing in a follow-up. Benchmark (median of 500 iters on M4 Max, agent_space/bench_argminmax_pr.py): | op | shape | dtype | mode | baseline (us) | new (us) | speedup | |--------|-----------|----------|------|--------------:|---------:|--------:| | argmax | 4096x4096 | bfloat16 | dim0 | 1518 | 294 | 5.17x | | argmax | 4096x4096 | bfloat16 | dim1 | 991 | 315 | 3.15x | | argmax | 4096x4096 | float16 | dim0 | 1024 | 290 | 3.53x | | argmin | 4096x4096 | float16 | dim0 | 1014 | 326 | 3.11x | | argmax | 4096x4096 | float32 | dim0 | 1009 | 424 | 2.38x | | argmin | 4096x4096 | int64 | dim0 | 1075 | 740 | 1.45x | | argmax | 1024x1024 | bfloat16 | dim0 | 192 | 100 | 1.92x | | argmax | 1024x1024 | float32 | dim0 | 194 | 120 | 1.61x | | argmax | 4096x4096 | float32 | full | 5044 | 4926 | 1.02x | Authored with Claude. Fixes pytorch#130295 Pull Request resolved: pytorch#187304 Approved by: https://github.com/kurtamohler, https://github.com/seemethere, https://github.com/izaitsevfb ghstack dependencies: pytorch#187541
Remove setuptools upper bound (pytorch#187262) Upper bound was originally introduced by pytorch#174631, but `pkg_resources` is not used by `torch.utils.cpp_extensions` Test Plan: Install latest setuptools and all `cpp_extensions` test still work Fixes pytorch#187188 Pull Request resolved: pytorch#187262 Approved by: https://github.com/malfet, https://github.com/atalman (cherry picked from commit c776884) Co-authored-by: Yufeng He <40085740+he-yufeng@users.noreply.github.com> Co-authored-by: Nikita Shulga <2453524+malfet@users.noreply.github.com>
…ch#188192) Fix build_with_debinfo.py broken by CONFIGURE_DEPENDS globbing (pytorch#186780) ## Summary `tools/build_with_debinfo.py` recompiles named source files with `-g` so you can get debug info for a targeted file without a full (slow, ABI-incompatible) debug build. It is referenced in `CONTRIBUTING.md`, and it broke on current `main`: running it just prints `Nothing to do` and rebuilds nothing. ## Root cause The tool derived its compile/link commands from `ninja -j1 -v -n torch_python` (a dry run) and rewrote `-O2`/`-O3` to `-g`. The build now uses `file(GLOB ... CONFIGURE_DEPENDS)`, which wires a glob-verification step into `build.ninja`'s own regeneration (`CMakeFiles/VerifyGlobs.cmake` + `regenerate-during-build`). In dry-run (`-n`) mode ninja cannot run that check or reload the regenerated graph, so `ninja -n <target>` only ever reports the regeneration step and never the real compile/link commands. The tool parsed an empty plan and no-op'd. ## Fix Source the commands from places the glob-check does not gate: - the per-file compile command from `build/compile_commands.json` (rewrite `-O2`/`-O3` -> `-g`); - the `libtorch_python` link command from `ninja -t commands torch_python` (a graph walk, not a dry run; strip ninja's `: && ... && :` wrapper). Then symlink `build/lib` into `torch/lib` as before. The tool now rebuilds exactly the files you name plus the relink, rather than touching sources and relying on ninja's staleness detection. The old `>100 stale items` guard was a dry-run artifact and is removed; the tool now requires `compile_commands.json` and an already-built tree. ## Tests - **Unit tests** (`tools/test/test_build_with_debinfo.py`) for the pure plan-derivation helpers: the `-O` -> `-g` rewrite, `compile_commands.json` indexing, the command/arguments entry forms, and the `ninja -t commands` link extraction. - **Build-tree smoke check**: a new `--dry-run` mode plus a step in `.ci/pytorch/build.sh` that, after the Linux build, asserts the emitted plan contains a `-g` compile and the `libtorch_python` relink. This exercises the real `compile_commands.json` and `ninja -t commands` and fails loudly if a future build-system change breaks those data sources -- the class of bug here, which unit tests alone would not catch. `--dry-run` only reads the tree, so it does not dirty the checkout. ## Test plan Validated on a real editable CUDA build of `viable/strict`: ``` python tools/build_with_debinfo.py --verbose torch/csrc/Module.cpp ``` recompiles `Module.cpp.o` with `.debug_info`, relinks `libtorch_python.so` (which then carries `.debug_info`), symlinks it into `torch/lib`, and `import torch` still works. ``` python tools/build_with_debinfo.py --dry-run torch/csrc/Module.cpp ``` exits 0, prints the plan, and leaves the git tree clean; the build.sh `-g` and `libtorch_python` plan assertions both pass against that output. ``` python -m pytest tools/test/test_build_with_debinfo.py ``` -> 9 passed. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Pull Request resolved: pytorch#186780 Approved by: https://github.com/benjaminglass1, https://github.com/atalman (cherry picked from commit 8f9a6c8) Co-authored-by: Klaus Zimmermann <klaus.zimmermann@quansight.com> Co-authored-by: Benjamin Glass <3344239+benjaminglass1@users.noreply.github.com>
…dd fast path (pytorch#184824)" (pytorch#188196) Revert "[Reland] Port D104346887/PR 182675 for index_add fast path (pytorch#184824) (pytorch#184824)" This reverts commit 9e051b3. Reverted pytorch#184824 on behalf of https://github.com/meta-codesync due to Diff reverted internally ([comment](pytorch#184824 (comment))) (cherry picked from commit eaa0ca8) Co-authored-by: PyTorch MergeBot <pytorchmergebot@users.noreply.github.com>
…cross graph breaks (pytorch#184487)" (pytorch#188197) Revert "dynamo: round-trip torch.cuda.stream ctx mgr across graph breaks (pytorch#184487)" This reverts commit b0a67c7. Reverted pytorch#184487 on behalf of https://github.com/williamwen42 due to Breaks internal builds ([comment](pytorch#184487 (comment))) (cherry picked from commit 697514a) Co-authored-by: PyTorch MergeBot <pytorchmergebot@users.noreply.github.com>
…rch#184075)" (pytorch#188277) This reverts commit b35bc89 on the release/2.13 branch. It is the release-branch counterpart of the main-branch revert (pytorch#188219). PR pytorch#184075 reworked Inductor's temporary generalized scatter form to use private OpOverload targets (a torch.library FRAGMENT registering generalized_scatter / inplace_generalized_scatter_ with flattened, encoded view-op arguments) and added matching Piecewise support in the z3 validator. This revert restores the prior representation that passes view ops as a list of ViewOp dataclasses directly as call_function args. The reinplace.py hunks conflicted against the release branch; all were resolved to the pre-PR form with bare asserts (torch/_inductor/** is still S101-exempt on this branch, so no noqa is added), fully removing the encode/decode machinery, the torch.library registration, and the z3 validator additions. Test Plan: ``` lintrunner torch/_inductor/fx_passes/reinplace.py ``` This PR was authored with the assistance of an AI agent.
…188409) Bump DOCKER_IMAGE_PIN (and the generated linux manywheel binary build workflows) from f38ba0b to 78e737a, the latest manylinux2_28 / manylinuxaarch64 builder images built for v2.13.0-rc10. Verified the new images are published on Docker Hub (e.g. pytorch/manylinux2_28-builder:cuda12.6-78e737ad..., cpu-78e737ad...). Equivalent to regenerating the workflows after the pin bump (only the docker hash changes).
…188443) Add CUDA 12.9 to TORCH_CUDA_ARCH_LIST tables (fix cu129 build) CUDA 12.9 is in the release/2.13 build matrix (CUDA_ARCHES), but the arch-list tables introduced in the 2.13 refactor omit it, so manywheel-cuda-cu129-build fails at .ci/manywheel/build_env_setup.py with 'unknown cuda version 12.9'. In 2.12 the arch list was a bash case in build_cuda.sh that handled 12.9 as base + sm_12.0 (Blackwell), i.e. the 13.x set, not the legacy 12.6 set. Restore that by adding a 12.9 entry to both TORCH_CUDA_ARCH_LIST_TABLE (build) and PYTORCH_RELEASES_CODE_CC (runtime), kept in sync per validate_runtime_release_table_consistency(): x86_64: {75, 80, 86, 90, 100, 120} (== 13.0/13.2) aarch64: {80, 90, 100, 120} (13.x aarch64 minus sm_110, which 12.9 never added) validate_runtime_release_table_consistency() passes.
Co-authored-by: Abigail Fernandes <ferabiga@amazon.com>
* feat: add gradcheck support for different precision * docs: simplify gradcheck default parameters comment Address CR feedback: remove overly specific numerical analysis from the comment and instead clarify that these constants match the existing torch.autograd.gradcheck defaults, with a pointer to the source file. Keeps the rationale for why they are extracted as overridable constants. --------- Co-authored-by: Dixuan Wang <dixuan@amazon.com>
* adding test_join, serialization fixes for device agnostic Co-authored-by: Ryan King <kingrj@6amazon.com>
* feat: Make dynamo tests device-agnostic for PrivateUse1 backends Replace CUDA-specific code in 24 dynamo test files with device-agnostic equivalents, enabling PrivateUse1 backends to run these tests without monkey-patching. - Replace device=cuda with device_type, .cuda() with .to(device_type) - Replace torch.cuda.Stream/Event with torch.get_device_module(device_type) - Replace torch.cuda.synchronize/current_stream with torch.accelerator APIs - Replace @requires_cuda with @requires_accelerator where appropriate - Add @requires_cuda to tests that use CUDA-specific APIs in test body - Add device_type module-level constant using torch.accelerator - Add COMPILE_BACKEND/get_compile_backend() to common_utils.py - Add requires_accelerator_and_triton to triton_utils.py
Add privateuse1 to device type test bases in test_parametrization, test_transformers, and test_dataloader so that PrivateUse1 backends can run device-specific tests.
Co-authored-by: Ryan King <kingrj@6amazon.com>
* device agnostic changes for profiler tests * new changes for device agnostic profiler tests * fixing comments * refactoring * updating comments --------- Co-authored-by: Ryan King <kingrj@6amazon.com>
…_type_promotion, test_parity (#49)
Unconditionally yielding a 2j scalar fails for backends that don't support complex dtypes on non-complex dtype parameterizations. Gate the complex scalar on dtype.is_complex; matches the NaN-propagation pattern already used elsewhere in the same function.
Check torch.accelerator.get_device_capability().supported_dtypes and pre-classify declared-unsupported dtypes as unsupported without attempting sample_inputs / op execution. Avoids expensive compile attempts (e.g. complex on PrivateUse1 accelerators without complex support) while preserving the OpInfo-vs-device consistency check. CPU and CUDA return an empty set and retain existing behavior.
The threshold OpInfo uses a hardcoded sample_kwargs with 'value': -9, which overflows when applied to uint8 tensors. Exclude uint8 by switching from all_types_and to an explicit list of signed types. Co-authored-by: Claude <noreply@anthropic.com>
* fix: filter pytest handlers by module in _handler_watcher * fix: adjust _handler_watcher record duplication
Many test/dynamo tests hardcode CPU input tensors (no device= argument).
Upstream torch.compile is device-preserving, but accelerator backends that
execute the compiled graph on-device return device tensors, so autograd
rejects the device mismatch on backward:
RuntimeError: Function CompiledFunctionBackward returned an invalid
gradient at index 0 - expected device cpu but got neuron:0
Create inputs on the current accelerator via the module-level device_type
(torch.accelerator.current_accelerator, falling back to "cpu"), adding
device=device_type to input tensor factories and .to(device_type) to
nn.Module instances. Because device_type resolves to "cpu" when no
accelerator is present, these edits are a no-op on CPU and CUDA CI and
only take effect on accelerator backends. run_forward_backward in
test_utils gains an optional device="cpu" parameter so its device-sensitive
caller is unaffected while the target tests opt in.
Authored with Claude.
test_log_traced_frames and test_gan_repro_trying_to_backward_through_the_graph_a_second_time construct tensors on CPU (torch.ones) inside the compiled region, which then mix with on-device tensors and fail on accelerator backends with "input tensor is on cpu device, expected neuron". Create these tensors on device_type (torch.accelerator.current_accelerator, falling back to "cpu"), consistent with the existing device-generalization; a no-op on CPU/CUDA CI. Authored with Claude.
Follow-up to the earlier device-generalization pass. These test/dynamo tests
still hardcode CPU input tensors (no device= argument). torch.compile is
device-preserving, but accelerator backends that execute the compiled graph
on-device return device tensors, so autograd rejects the device mismatch on
backward, e.g.:
RuntimeError: Function CompiledFunctionBackward returned an invalid
gradient at index 0 - expected device cpu but got <accel>:0
or the compiled region raises a plain device mismatch when a CPU input meets an
on-device intermediate.
Create inputs on the current accelerator via the module-level device_type
(torch.accelerator.current_accelerator, falling back to "cpu"), adding
device=device_type to input tensor factories and .to(device_type) to nn.Module
instances in the affected tests. test_activation_checkpointing.py and
test_wrap_inductor_compiled_regions.py gain the module-level device_type
definition (the other files already have it); the latter also generalizes its
DTensor device mesh. Because device_type resolves to "cpu" when no accelerator
is present, these edits are a no-op on CPU and CUDA CI and only take effect on
accelerator backends.
Test Plan:
On CPU (no accelerator; device_type == "cpu", edits are a no-op):
```
python test/dynamo/test_autograd_function.py AutogradFunctionTests.test_apply_kwargs_old_style
python test/dynamo/test_hooks.py HooksTests.test_input_hooks_same
python test/dynamo/test_repros.py ReproTests.test_intermediate_leaf_requires_grad
python test/dynamo/test_fwd_loss_bwd.py TestForwardLossBackward.test_backward_dict_inputs
```
On an accelerator backend, the same nodeids (and their _nested_graph_breaks
variants) that previously failed with a device mismatch now pass.
Authored with an AI assistant (Claude).
Cherry-pick the module-level device_type definition from main (L52) onto release/pt_213. The pt_213 branch was cut before this landed on main, so test_misc.py references device=device_type in 22 places without defining it, causing 'NameError: name device_type is not defined' in 8 MiscTests (and 7 auto-generated mirrors in test_nested_graph_breaks_wrapped.py). Matches main byte-for-byte (torch.accelerator.current_accelerator() with no check_available arg, placed after the torch._dynamo.source import).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
16 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Issue #, if available:
Description of changes:
tolerance too tight for float32 all reduce
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.