data/relationship_edges.html

<style>

:root { color-scheme: light; }

.bi-wrap { font-family: Inter, ui-sans-serif, system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif; color: #1f2328 !important; }

.bi-wrap h1, .bi-wrap h2, .bi-wrap h3, .bi-wrap p, .bi-wrap strong, .bi-wrap td, .bi-wrap th, .bi-wrap div { color: #1f2328 !important; }

.bi-band { border: 1px solid #d8dee4; border-radius: 8px; background: #ffffff !important; padding: 16px; margin: 0 0 12px; }

.bi-title { display: flex; gap: 12px; align-items: flex-start; justify-content: space-between; margin-bottom: 12px; }

.bi-title h1, .bi-title h2 { margin: 0; line-height: 1.15; letter-spacing: 0; }

.bi-title h1 { font-size: 1.55rem; }

.bi-title h2 { font-size: 1.12rem; }

.bi-title p { margin: 4px 0 0; color: #57606a; max-width: 820px; }

.status-pill { border-radius: 999px; padding: 5px 9px; font-size: .78rem; font-weight: 700; background: #dafbe1; color: #116329 !important; white-space: nowrap; }

.metric-grid { display: grid; grid-template-columns: repeat(auto-fit, minmax(138px, 1fr)); gap: 8px; }

.metric { border: 1px solid #d0d7de; border-radius: 8px; padding: 10px; background: #f6f8fa !important; min-height: 86px; }

.metric-value { font-size: 1.45rem; font-weight: 800; line-height: 1.1; color: #0969da !important; }

.metric-label { margin-top: 4px; font-size: .84rem; font-weight: 700; }

.metric-note { margin-top: 2px; font-size: .76rem; color: #57606a !important; }

.callout-grid { display: grid; grid-template-columns: repeat(auto-fit, minmax(220px, 1fr)); gap: 8px; }

.callout { border-left: 4px solid #0969da; background: #f6f8fa !important; border-radius: 8px; padding: 10px 12px; }

.callout:nth-child(2) { border-left-color: #1a7f37; }

.callout:nth-child(3) { border-left-color: #bf8700; }

.callout:nth-child(4) { border-left-color: #cf222e; }

.callout strong { display: block; margin-bottom: 4px; }

.group-grid { display: grid; grid-template-columns: repeat(auto-fit, minmax(310px, 1fr)); gap: 10px; }

.group-card { border: 1px solid #d8dee4; border-radius: 8px; padding: 12px; background: #fff !important; }

.group-card h3 { margin: 0 0 7px; font-size: 1rem; line-height: 1.25; letter-spacing: 0; }

.meta-row { display: flex; flex-wrap: wrap; gap: 6px; margin: 6px 0; }

.chip-row { display: inline-flex; flex-wrap: wrap; gap: 5px; align-items: center; vertical-align: middle; }

.chip { display: inline-flex; align-items: center; border: 1px solid #d0d7de; border-radius: 999px; padding: 2px 7px; font-size: .78rem; background: #f6f8fa !important; color: #24292f !important; }

.chip.bucket { border-color: #9a6700; background: #fff8c5 !important; }

.chip.kind { border-color: #0969da; background: #ddf4ff !important; }

.workflow-grid { display: grid; grid-template-columns: repeat(auto-fit, minmax(260px, 1fr)); gap: 10px; }

.workflow-card { border: 1px solid #d8dee4; border-radius: 8px; padding: 12px; background: #fff !important; }

.workflow-card h3 { margin: 0 0 7px; font-size: 1rem; line-height: 1.25; letter-spacing: 0; }

.workflow-card .move-count { font-weight: 800; color: #0969da !important; }

.move-list { display: grid; gap: 10px; }

.move-row { border: 1px solid #d8dee4; border-radius: 8px; background: #fff !important; }

.move-row summary { list-style: none; cursor: pointer; padding: 12px; }

.move-row summary::-webkit-details-marker { display: none; }

.move-summary { display: grid; grid-template-columns: minmax(190px, 1fr) minmax(260px, 1.45fr) minmax(260px, 1.45fr) minmax(150px, .8fr) minmax(250px, 1.35fr) auto; gap: 16px; align-items: start; }

.move-title, .move-field { min-width: 0; }

.move-title h3 { margin: 0 0 4px; font-size: 1rem; line-height: 1.25; letter-spacing: 0; }

.move-field span { display: block; color: #57606a !important; font-size: .72rem; font-weight: 800; text-transform: uppercase; letter-spacing: 0; }

.move-field p { margin: 3px 0 0; font-size: .84rem; line-height: 1.35; overflow-wrap: anywhere; }

.move-field .chip, .move-title { overflow-wrap: anywhere; }

.view-bundles { align-self: center; justify-self: end; border: 1px solid #000000; border-radius: 999px; color: #000000 !important; background: #ffffff !important; padding: 4px 9px; font-size: .78rem; font-weight: 800; white-space: nowrap; }

.move-row[open] .view-bundles { background: #f6f8fa !important; }

.move-expanded { border-top: 1px solid #d8dee4; padding: 0 12px 12px; }

.bundle-row { border-top: 1px solid #eef1f4; padding: 12px 0; }

.bundle-row:first-child { border-top: none; }

.bundle-row h4 { margin: 0 0 6px; font-size: .94rem; line-height: 1.25; letter-spacing: 0; }

.bundle-scope { display: grid; grid-template-columns: repeat(auto-fit, minmax(220px, 1fr)); gap: 7px; margin-top: 8px; }

.evidence-list { margin: 8px 0 0 18px; padding: 0; color: #57606a !important; font-size: .82rem; line-height: 1.35; }

.evidence-list li { margin: 3px 0; }

.muted { color: #57606a !important; }

.evidence { font-size: .84rem; color: #57606a !important; }

.scroll-table { overflow-x: auto; border: 1px solid #d8dee4; border-radius: 8px; background: #fff !important; }

table.bi-table { width: 100%; border-collapse: collapse; font-size: .86rem; }

.bi-table th { text-align: left; background: #f6f8fa !important; color: #57606a !important; font-size: .78rem; border-bottom: 1px solid #d8dee4; padding: 8px; white-space: nowrap; }

.bi-table td { border-bottom: 1px solid #eef1f4; padding: 8px; vertical-align: top; min-width: 86px; }

.bi-table tr:last-child td { border-bottom: none; }

.wide { min-width: 280px; }

.tight { max-width: 180px; }

a { color: #0969da !important; text-decoration: none; }

a:hover { text-decoration: underline; }

.bi-wrap, .bi-wrap * { color: #000000 !important; }

@media (max-width: 720px) {

  .bi-title { display: block; }

  .status-pill { display: inline-block; margin-top: 8px; }

  .group-grid { grid-template-columns: 1fr; }

  .move-summary { grid-template-columns: 1fr; }

  .view-bundles { justify-self: start; }

}

</style>
<div class='bi-wrap'><section class='bi-band'><div class='bi-title'><div><h2>Relationship Edges</h2><p>Why items were connected. Excerpts are short and hashed; raw API payloads stay local.</p></div></div><div class='scroll-table'><table class='bi-table'><thead><tr><th>Kind</th><th>Source</th><th>Target</th><th>Confidence</th><th>Evidence</th><th>Evidence Hash</th></tr></thead><tbody><tr><td>references</td><td>issue #141287</td><td>issue #77764</td><td>medium</td><td><div class='wide'>lace to list and track work on adding support to new ops for the MPS backend. Most requested ops (extracted from comments to this issue and #77764) PyTorch MPS Ops Project : Project to track all the ops for MPS backend. There are a very large number of operators in pytorch and...</div></td><td>27287ca4e6e3b6b4ece6528bc77edeef25116a884123cb7ee2d31af4ad80d401</td></tr><tr><td>references</td><td>issue #189287</td><td>issue #188492</td><td>medium</td><td><div class='wide'>ibution needs confirmation (it is by failing-since alignment, not root-caused). Same #188251 bump has produced other confirmed regressions: #188492 (swin inductor accuracy) and #188841 (compile + float8 training numerics). Filed by pt2-oncall triage from HUD signal. cc @ptrblc...</div></td><td>9698400f2da6521759a9575e45c7f88418e35787b03ed55b7631eb8e3bc3e359</td></tr><tr><td>references</td><td>issue #189287</td><td>issue #188841</td><td>medium</td><td><div class='wide'>failing-since alignment, not root-caused). Same #188251 bump has produced other confirmed regressions: #188492 (swin inductor accuracy) and #188841 (compile + float8 training numerics). Filed by pt2-oncall triage from HUD signal. cc @ptrblck @msaroufim @eqy @tinglvv @nWEIdia @...</div></td><td>25eed4d5223772761e053cdbd2af3b7cce89b4147c534b321bd6700d9a93f1d2</td></tr><tr><td>references</td><td>issue #188756</td><td>issue #84520</td><td>medium</td><td><div class='wide'>09 notes flip is the only remaining MPSGraph user in Indexing.mm, but other files still lower gather/scatter-like ops to MPSGraph. Related: #84520 (MPS 32-bit limits umbrella — but here nothing asserts, it corrupts silently), #144824 (OOB indexing returns 0), #154235 (missing...</div></td><td>5ddb5dfa430472e79585e537d3eb57af3316c88b726367c07226c054df366a82</td></tr><tr><td>references</td><td>issue #188756</td><td>issue #144824</td><td>medium</td><td><div class='wide'>slicing — the device copy is intact; only the gather is broken. All indices involved are valid; this is not the OOB-index case of #154235 / #144824, though the failure surface is the same &quot;OOB reads return 0&quot; behavior. Root cause (as far as I can tell) In 2.12.0, index_select_...</div></td><td>f092cb9517d78cce4120db3a3afe47aaf2128377257db42ad51791c110aabff3</td></tr><tr><td>references</td><td>issue #189270</td><td>pr #187328</td><td>medium</td><td><div class='wide'>Summary kernel_information.json (#160540, extended in #183952) and the profiler-timeline provenance (#186230, #187328) map each generated kernel to a set of pre/post-grad node names, stack traces, and now extern I/O shapes. What is still missing is the phys</div></td><td>cf1d27af3d74794a50a5e5b334efdcaf82727003595ee820cb256914508b80a0</td></tr><tr><td>references</td><td>issue #129131</td><td>issue #97894</td><td>medium</td><td><div class='wide'>/_inductor/fx_passes/pad_mm.py#L636 https://github.com/pytorch/pytorch/blob/main/torch/_dynamo/convert_frame.py#L172 (Logic refers to issue #97894) Minified repro import torch @torch.compile def some_fn(x): return torch.pow(x, 0.1) / 2 with torch.device(&quot;cpu&quot;): x = torch.ones(...</div></td><td>0580bf147fcef88bd580d61c801894d53b3a463de97ba138037606fe24aed172</td></tr><tr><td>references</td><td>issue #187455</td><td>pr #182109</td><td>medium</td><td><div class='wide'>s; OpInfo / common_methods_invocations.py remains the broad semantic owner. Revisit LayerNorm backward after the active reduce/loss stacks. #182109 already has feedback asking for clearer rationale, benchmark script, and before/after results. If revived, split it into smaller...</div></td><td>9f2d6dee8fd1f5c80583f3267a977d73119c9166fd00f0623328c3eafee36435</td></tr><tr><td>references</td><td>issue #187455</td><td>pr #182731</td><td>medium</td><td><div class='wide'>tern used by the leaves. No user-visible behavior change; this is the cross-op infrastructure reviewers should see first. Scalar read leaf: #182731. Rebase on the UMA base helper. Scope: _local_scalar_dense / .item() / scalar truthiness direct CPU read. MPS-&gt;CPU copy leaf: #18...</div></td><td>931ba6c553643a760ccb443d494823a0c03e5d2d705a5ab71b93f5a266fa0aa4</td></tr><tr><td>references</td><td>issue #187455</td><td>pr #182736</td><td>medium</td><td><div class='wide'>leaf: #182731. Rebase on the UMA base helper. Scope: _local_scalar_dense / .item() / scalar truthiness direct CPU read. MPS-&gt;CPU copy leaf: #182736. Rebase on the UMA base helper. Scope: contiguous same-dtype copy_from_mps_ / .to(&quot;cpu&quot;) / .numpy() direct read. CPU-&gt;MPS copy le...</div></td><td>dd905b22f5c769d19280e2f72feb508eebe5b0c978eae6dcd77a6820a259b9d2</td></tr><tr><td>references</td><td>issue #187455</td><td>pr #182749</td><td>medium</td><td><div class='wide'>182736. Rebase on the UMA base helper. Scope: contiguous same-dtype copy_from_mps_ / .to(&quot;cpu&quot;) / .numpy() direct read. CPU-&gt;MPS copy leaf: #182749. Rebase on the UMA base helper. Scope: contiguous same-dtype CPU-&gt;MPS direct write, with non-blocking/non-contiguous/dtype-cast f...</div></td><td>39ad423213d6c30d7edcd3619f8789b5914d4a0303b1c24a70bc34c5c6107928</td></tr><tr><td>references</td><td>issue #187455</td><td>pr #182791</td><td>medium</td><td><div class='wide'>elper. Scope: contiguous same-dtype CPU-&gt;MPS direct write, with non-blocking/non-contiguous/dtype-cast fallbacks preserved. Fill/zero leaf: #182791. Rebase after the write-side copy leaf. Scope: dense zero_/fill_ via memset/std::fill_n, with negative-zero and unsupported dtype...</div></td><td>8ce2999c8c1c71211ab727a25ada447ebba73c20e3518765eae8f316d6715822</td></tr><tr><td>references</td><td>issue #187455</td><td>pr #183688</td><td>medium</td><td><div class='wide'>182791 draft/pending rework Rebase onto the UMA base/write-side direction; do not review as a standalone final PR. MPS capture/replay stack #183688 is much larger than a reviewable PyTorch PR and should be treated as a reference branch to split, not a final PR. Order: Capture...</div></td><td>9df4bd150ddf31bc316ce476fd7f829ad13277ecb7bace954fc85b13c855a01c</td></tr><tr><td>references</td><td>issue #187455</td><td>pr #187456</td><td>medium</td><td><div class='wide'>lit at the last-dim vs non-last-dim boundary and stacked as cumulative-leaf forks on main (external contributor, no ghstack): softmax core (#187456, 52a3223): native last-dim _softmax/_softmax_backward (single-row + 8-wide-half + looped online-softmax); non-last-dim and huge-r...</div></td><td>345ffb2dce60cb2b34d124fed94231118ec9415c1281c040878c8ed45ac7f037</td></tr><tr><td>references</td><td>issue #187455</td><td>pr #187457</td><td>medium</td><td><div class='wide'>-dim-only gate. Residual dim=0-backward tail is documented (MPSGraph&#x27;s fused reduce still wins there; escape hatch covers it). log_softmax (#187457, 3d6f962): native log_softmax stacked on the softmax kernels. cross_entropy (#187458, ee60969): fused 2D cross-entropy Metal kern...</div></td><td>4693297ad47a1ed0ffaf041a3a3b91720068b11cbbadf04b36ed80bb5e106daa</td></tr><tr><td>references</td><td>issue #187455</td><td>pr #187458</td><td>medium</td><td><div class='wide'>antiations each), not chained on each other. Independent loss-style work: #187559 (nll_loss, review comments addressed at fc26ad2e55e3) and #187458 (cross_entropy) do not fit the same elementwise fused-loss template. Softmax / log_softmax / cross_entropy: refreshed and opened...</div></td><td>2d0d3aa86c56419e390e88ebb84b2aef1fe2f403d789ea9a8a900d66e98ac76a</td></tr><tr><td>competes with</td><td>issue #187455</td><td>pr #187553</td><td>medium</td><td><div class='wide'>into the existing TestMetalLibrary.test_reduction_utils owner surface instead of adding a standalone regression. Land the loss-stack base: #187553 (mse_loss). Scope: shared fused-loss infrastructure (FusedLossParams, fused_loss_pass1, fused_loss_bwd, fused_loss_reduce, TensorI...</div></td><td>5ead698bdfb6499f55eff3d9865a7aca19a56d5d71a0e0c3761c5d982d27dc30</td></tr><tr><td>references</td><td>issue #187455</td><td>pr #187556</td><td>medium</td><td><div class='wide'>ases); OpInfo consistency (including the f16 grad test) remains the broad semantic owner. Stack: rebuild #187557 (binary_cross_entropy) and #187556 (smooth_l1_loss/huber_loss) as sibling leaves on the final #187553 (small op functor + instantiations each), not chained on each...</div></td><td>919f58fd26fa22c48388ef0ce0cc76ab80ab406ed90785dc78ba0b4a212ea983</td></tr><tr><td>references</td><td>issue #187455</td><td>pr #187557</td><td>medium</td><td><div class='wide'>d, mixed dtypes, out-variant edge cases); OpInfo consistency (including the f16 grad test) remains the broad semantic owner. Stack: rebuild #187557 (binary_cross_entropy) and #187556 (smooth_l1_loss/huber_loss) as sibling leaves on the final #187553 (small op functor + instant...</div></td><td>4b4c4b9ff1073e29e28405a99aff70564283a96f27ef4b0c1d4d4b4699486118</td></tr><tr><td>references</td><td>issue #187455</td><td>pr #187559</td><td>medium</td><td><div class='wide'>s) as sibling leaves on the final #187553 (small op functor + instantiations each), not chained on each other. Independent loss-style work: #187559 (nll_loss, review comments addressed at fc26ad2e55e3) and #187458 (cross_entropy) do not fit the same elementwise fused-loss temp...</div></td><td>c2e9079116af0b2664b8d9cf1704ea257b819b8f57dd55fd0c116be7e28a284d</td></tr><tr><td>references</td><td>issue #187455</td><td>pr #187787</td><td>medium</td><td><div class='wide'>guard; prod perf: outer/inner shape specializations, benchmark, perf table. Review var/std after the reduce base/prod direction is settled: #187787. Current state: rebuilt and pushed at cd01523561027; ready as the Welford follow-up, but should be read after #188156/#188333 bec...</div></td><td>952d13051c9d44a446a2be73e86248a8d47422d25eeff451dfe01383173f6430</td></tr><tr><td>references</td><td>issue #187455</td><td>pr #187976</td><td>medium</td><td><div class='wide'>anup: complex enablement, integer rejection, duplicate-dim behavior, and large-output errors if those remain separate review concerns. Keep #187976 independent. #187976 fixes an int64 amax/amin partial-simdgroup bug in the existing value-reduction helper path. It is a sibling...</div></td><td>a6a44834bd4df619c0ecf08fbcf7fc9d812c5e0bf2cd91c7401bf348805177df</td></tr><tr><td>references</td><td>issue #187455</td><td>pr #188156</td><td>medium</td><td><div class='wide'>A standalone test_mps.py case needs a clear reason why no existing surface owns the route. Order of operations Land the reduce-family base: #188156. Scope: collapse generic sum/mean/nansum/count_nonzero onto the shared value_reduction&lt;Op, Load, TA&gt; path already used by min/max...</div></td><td>6d4f2eed50ae483231d5f1291cd1d08b298ba1ff098a4eed5c37fae987ed7a54</td></tr><tr><td>supersedes</td><td>issue #187455</td><td>pr #188333</td><td>medium</td><td><div class='wide'>route for non-contiguous multi-dim sum-family reductions and load policies, not just a private helper. Land prod on top of the reduce base: #188333. Scope: migrate prod to value_reduction&lt;ProdOp&gt; and remove its shape-dependent MPSGraph route. This supersedes the closed standal...</div></td><td>64907f0296db66e3f73e9c6406bcd1aa15b12816066489d2f98f9630b55a7190</td></tr><tr><td>references</td><td>issue #187455</td><td>pr #189146</td><td>medium</td><td><div class='wide'>ned MPSGraph fallback, so it is correct standalone and strictly reduces the softmax graph-cache for the common last-dim case. softmax perf (#189146, 8fa0937): adds the huge-row two-pass and non-last-dim (coalesced/tiled/blocked) native kernels on top of core and removes the la...</div></td><td>ff04e385d39996a9012222e032a6741e7118b0823c5d3a9b59ce73aeaa1c8b26</td></tr><tr><td>references</td><td>issue #187175</td><td>issue #186241</td><td>medium</td><td><div class='wide'>to it unconditionally. There are several recently filed issues that highlight the TMA path for pointwise/reduction is not yet fully mature: #186241 #185513 #185222 #184714 #184563 Phase 2 — Once we are confident the TMA path is correct and mature: Enabling autotuning alone (wi...</div></td><td>447ca33d4dbd72febb21f81154fa1ee7db554dfabb534b423eff70ad1d01e8d1</td></tr><tr><td>references</td><td>issue #187810</td><td>issue #187811</td><td>medium</td><td><div class='wide'>Hi @chunhuanMeng , please help handle this issue and #187811</div></td><td>84c3b4bdab0afe48a014091b2f1016135305c1871a6dcf86c9eb8939aff8f862</td></tr><tr><td>references</td><td>issue #189138</td><td>issue #189135</td><td>medium</td><td><div class='wide'>is replaced by _exposes_streams(device), which checks whether iface.Stream is not DeviceInterface.Stream. Please refer to the dedicated RFC #189135 for detailed design elaboration. Dynamo Registry Splicing Dynamo answers two questions for every value/call during symbolic execu...</div></td><td>e8b0f2becfc15424643138f062faee984ee45d6b1e5b8479bfcd04876886be85</td></tr><tr><td>references</td><td>issue #189138</td><td>issue #189136</td><td>medium</td><td><div class='wide'>e-specialized tensor types — is handled by one optional slot dynamo_tensor_classes (default empty, safe). Please refer to the dedicated RFC #189136 for detailed design elaboration. Inductor Codegen Registration Interfaces Inductor&#x27;s codegen path has four things that lack regis...</div></td><td>175dc64f062f304b809a5c88277b99d8dcf7740ecb1dafd45a75009868f8126c</td></tr><tr><td>references</td><td>issue #189138</td><td>issue #189137</td><td>medium</td><td><div class='wide'>E_TO_ATEN fallback. No-c-shim backends will still fail AOTI at link time. This needs a separate proposal. Please refer to the dedicated RFC #189137 for detailed design elaboration. For a more comprehensive and detailed understanding of each component&#x27;s design, we highly encour...</div></td><td>75a60e2adbd3fd72c533e18e7d53249ad6bf4b74cb2ed1705175cb815516f709</td></tr><tr><td>references</td><td>issue #144965</td><td>issue #69078</td><td>medium</td><td><div class='wide'>der some specific conditions, raise a RuntimeError with message: &quot;Global alloc not supported yet.&quot;. I think this is linked to an old issue: #69078, however, I managed to consistently reproduce this error. The code that reproduces the bug is quite long and needs some explanatio...</div></td><td>af0a8b92d21995f8ec4b0b5a5d44613aaaaab920e32715959df72818a2c6066d</td></tr><tr><td>references</td><td>issue #188970</td><td>issue #180397</td><td>medium</td><td><div class='wide'>not collect Expected behavior Compile succeeds, or the unsupported/unsafe option is ignored with a warning — not a native SIGSEGV. Related #180397 proposes a capture/replay API for MPS and notes MPS currently has no CUDA-Graphs equivalent — possibly useful context, since trito...</div></td><td>8dc4c11946ae99660774b1637ca1d88153f73a9a68462b4a70a8207182287fd5</td></tr><tr><td>references</td><td>issue #187093</td><td>pr #189127</td><td>medium</td><td><div class='wide'>Opened a draft PR with the scoped post-grad rewrite: #189127 The patch extends the existing addmm bias-unfuse pattern to baddbmm: it only applies on GPU when the input is bias-like/broadcast and all b</div></td><td>56c41fc8de4001e0f38282047b6bfb8a47f1e098c860eb723fb2cd2a8c320d4c</td></tr><tr><td>references</td><td>issue #189121</td><td>pr #189124</td><td>medium</td><td><div class='wide'>Opened a draft PR with the focused cache-gate patch: #189124 The patch keeps the ordinary single-config fast path unchanged, but lets DSR-eligible single-config reductions create/load an autotune cach</div></td><td>d2b79c1ccd9aea3c11d6213c11b639a5cc50550df8650ad729bda49e2271fd54</td></tr><tr><td>references</td><td>issue #188602</td><td>pr #186245</td><td>medium</td><td><div class='wide'>used to optimize the binary. The current plan is that this needs the following high level steps: Integrate LLVM-BOLT into the build system #186245 Add a profile staleness metric script which guides profile updates Enable profile collection in PyTorch CI cc @malfet @ptrblck @ms...</div></td><td>eafa00736571e47a2117cc23a189b6b089ae0d1f7ef2932593feb7b174ca8374</td></tr><tr><td>references</td><td>issue #189078</td><td>pr #186245</td><td>medium</td><td><div class='wide'>add this so we can keep track of how various changes impact build times. The main motivation for this comes from the desire to ensure that #186245 does not introduce major build time overhead but metrics should be helpful in general. Alternatives No response Additional context...</div></td><td>15a0ad69b44471a4d861bf8220eee35293248bd9f1f3227256c083a28432d825</td></tr><tr><td>references</td><td>issue #189098</td><td>pr #189097</td><td>medium</td><td><div class='wide'>o Kineto could utilize the export_using_protocol method in order to access them in Pytorch. A draft PR of the changes has been opened here: #189097 Alternatives No response Additional context No response cc @robieta @chaekit @guotuofeng @guyang3532 @dzhulgakov @davidberard98 @...</div></td><td>02871cf4cce200404cad179b35736868e013efe2530612dc49c5e2b89b1af758</td></tr><tr><td>references</td><td>issue #189077</td><td>issue #188557</td><td>medium</td><td><div class='wide'>d-environment linux-jammy-cuda13.0-py3.12-gcc11-sm100, single unsharded (1, 1) job on one Blackwell GPU. This is the NVIDIA/b200 sibling of #188557 (which tracks the same failure mode on ROCm gfx950). Same root cause and fix levers; different infra/owners, so filing separately...</div></td><td>a245fc0a78e2348b1ce75282062a5e55c27c5db63737321c27f17e4ea8a3485b</td></tr><tr><td>references</td><td>issue #189075</td><td>issue #140556</td><td>medium</td><td><div class='wide'>never completes. Genuine per-test failures in the same job (e.g. the test_backward_prod_cuda_float32 mem-leak-check, tracked separately in #140556) are a distinct problem from this timeout. Fix levers (CI-side) Increase the shard count (currently 8) so each shard&#x27;s slice fits...</div></td><td>682fa9067cfe772f7378d44a92d3c58c9d10c338662ca6b4b9b83579609f2bde</td></tr><tr><td>references</td><td>issue #189065</td><td>issue #154297</td><td>medium</td><td><div class='wide'>0 runner pool: investigate GPU state on linux.dgx.b200.8 (leaked processes, compute mode, or reimage). Nothing to fix in test code. Related #154297 - Hangs and timeouts on dist.reduce_scatter on B200 GPU (user-reported; possibly shared underlying B200 cause). #162178 - [CUDA]...</div></td><td>e7c80387a19e22fcfe21acebc2f3514911d5bab4d80513a29d95491c258a1062</td></tr><tr><td>references</td><td>issue #189065</td><td>issue #162178</td><td>medium</td><td><div class='wide'>test code. Related #154297 - Hangs and timeouts on dist.reduce_scatter on B200 GPU (user-reported; possibly shared underlying B200 cause). #162178 - [CUDA] Umbrella Issues/Failures on B200 Runner (stale umbrella). cc @ezyang @gchanan @kadeng @msaroufim @awgu @wanchaol @fegin @...</div></td><td>b36586005896bfd37626f9eb243032b2e5752e9be2914e7be637b68a084a6805</td></tr><tr><td>references</td><td>issue #188733</td><td>issue #45111</td><td>medium</td><td><div class='wide'>al MLA / attention changes that alter KV-cache layout/strides and Sm90 backend selection for the MLA path -- most notably: vllm-project/vllm#45111 - &quot;Re-enable cross-layer KV cache layout for MLA via stride-aware kernels&quot; (changes MLA KV-cache strides/layout) -- primary suspec...</div></td><td>1d558cb9461e859db727514da4a760bfc7ca0df7fb0de4238ebc15a6b331d43a</td></tr><tr><td>references</td><td>issue #189034</td><td>issue #173059</td><td>medium</td><td><div class='wide'>iPy to a NumPy-2-compatible build (SciPy &gt;=1.13 supports NumPy 2). Whoever owns the H100 image / bumped numpy 2.2.6 should confirm. Related #173059 -- same class (NumPy binary/ABI incompatibility breaking test imports), different instance (pandas + test_dataloader/test_datapip...</div></td><td>4ff8aa912ca76a90e33f07b086d70223c3964f06cf9565c1b1a97a7b8e85df01</td></tr><tr><td>references</td><td>issue #188900</td><td>issue #158861</td><td>medium</td><td><div class='wide'>s-is, so only the slice at index 0 along the broadcast dimension gets values and the rest stay zero. This looks like the same root cause as #158861, where `@nikitaved` noted that explicit broadcasting via `sparse_broadcast_to` followed by coalesce is missing. Proposed fix: bef...</div></td><td>ea7c404fac461685b6138c3782e0a7aa2a90ce8b26aa1c804b94bd8e9cf24563</td></tr><tr><td>references</td><td>issue #188792</td><td>pr #188791</td><td>medium</td><td><div class='wide'>each worker do a serial 1-element torch.sqrt first; this drops the rate to 0 (5,200 first-calls), which is the basis of the fix proposed in #188791. mkl_vml_race_repro.py &quot;&quot;&quot;Minimal repro: MKL VML first-call dispatch race in torch.sqrt. Spawns waves of worker processes on an o...</div></td><td>7a83aacf57b04dde3d1b2448cf0f4270ff7c363003b1b84fc081ebdb5c886f78</td></tr><tr><td>references</td><td>issue #188564</td><td>issue #152595</td><td>medium</td><td><div class='wide'>Here the build is fine, the GPU is found, tests run and pass, and the job is killed purely by the 270-min wall-clock. (Other gfx1100 issues #152595 / #165141 / #169857 / #177834 are unrelated.) Suggested fix Unblock now (CI-side): increase shard count for this job (it&#x27;s num_sh...</div></td><td>7f98c780b875fbc5917ea441da987ef5c78b69b8ed2330a6f9d3b6d21d088cde</td></tr><tr><td>references</td><td>issue #188564</td><td>issue #165040</td><td>medium</td><td><div class='wide'>s confirmed for the current runs but not individually proven as the culprit for all 388 red runs. This is NOT covered by the existing issue #165040 &quot;DISABLED rocm / linux-jammy-rocm-py3_10-gfx1100 / test (default)&quot; (OPEN; module: rocm, module: ci) is adjacent but distinct: it&#x27;...</div></td><td>1727021f32469529a36c72b5fc4f013ba7de4ed2f4b810df8c96ebecb1fc8be8</td></tr><tr><td>references</td><td>issue #188564</td><td>issue #165141</td><td>medium</td><td><div class='wide'>uild is fine, the GPU is found, tests run and pass, and the job is killed purely by the 270-min wall-clock. (Other gfx1100 issues #152595 / #165141 / #169857 / #177834 are unrelated.) Suggested fix Unblock now (CI-side): increase shard count for this job (it&#x27;s num_shards=2 tod...</div></td><td>60d9d4eb9c8753752450ee1167bd539202a190c38396b057e8ef0c3262a396e7</td></tr><tr><td>references</td><td>issue #188564</td><td>issue #169857</td><td>medium</td><td><div class='wide'>ne, the GPU is found, tests run and pass, and the job is killed purely by the 270-min wall-clock. (Other gfx1100 issues #152595 / #165141 / #169857 / #177834 are unrelated.) Suggested fix Unblock now (CI-side): increase shard count for this job (it&#x27;s num_shards=2 today) so eac...</div></td><td>1f4d60a6b9f14e9096dc8a717bf935fce550e4de05919055bdbbf7467eb50770</td></tr><tr><td>references</td><td>issue #188564</td><td>issue #177834</td><td>medium</td><td><div class='wide'>U is found, tests run and pass, and the job is killed purely by the 270-min wall-clock. (Other gfx1100 issues #152595 / #165141 / #169857 / #177834 are unrelated.) Suggested fix Unblock now (CI-side): increase shard count for this job (it&#x27;s num_shards=2 today) so each Test ste...</div></td><td>75777d9e62901abcd78bcf4fcf56ad11f56310d0079b192934bc543a14640ce5</td></tr><tr><td>references</td><td>issue #188545</td><td>issue #187332</td><td>medium</td><td><div class='wide'>e returns [nan, nan, nan], but Inductor returns [nan, 0., nan]. This changes the isnan result for the +inf element. This appears related to #187332 , but it affects torch.special.bessel_y0. Repro import torch def test_bessel_y0_mismatch(): x = torch.tensor([float(&#x27;nan&#x27;), float...</div></td><td>6ccedbc5c7e5104c094940d20c35e1caf868f0491c04b80f0ac66cfa51bc06db</td></tr><tr><td>references</td><td>issue #188008</td><td>pr #187955</td><td>medium</td><td><div class='wide'>ing unwinding → std::terminate. This is a pre-existing latent bug (the per-segment unmap loop had the same defect); it is not introduced by #187955, but that PR&#x27;s unmapHandles rework touches the same code, so filing as follow-up. Mechanism map() / fromShared() set handles_[beg...</div></td><td>a0b4f7b49dff0e32705ba8c38ef4f342544be554b1648ec1a1fed54210ffcf10</td></tr><tr><td>references</td><td>issue #188008</td><td>pr #187955</td><td>medium</td><td><div class='wide'>Being fixed in #187955: mapAndSetAccess is now strongly exception-safe — on a partial map/setAccess failure it unmaps the mapped prefix and releases the range&#x27;s h</div></td><td>aaa82942a131c603561fa9378f65c45b3a3d5cc7cd2000202884d9ffee5f006f</td></tr><tr><td>references</td><td>issue #140718</td><td>issue #77764</td><td>medium</td><td><div class='wide'>y implemented for the MPS device. If you want this op to be added in priority during the prototype phase of this feature, please comment on #77764. As a temporary fix, you can set the environment variable PYTORCH_ENABLE_MPS_FALLBACK=1 to use the CPU as a fallback for this op....</div></td><td>913bb5cf94a50de8ea0c409f50d5e078de09feb8a75dfcd334449ef7e68ce925</td></tr><tr><td>references</td><td>issue #188953</td><td>issue #179891</td><td>medium</td><td><div class='wide'>xpu: GPU detected, data transfer works, but any non-trivial computation (matmul) fails with could not create an engine. Related to existing #179891 (get_device_properties segfault on BMG). Intel compute-runtime issue cross-reference: intel/compute-runtime#947 Environment Compo...</div></td><td>edf3792aa9ff53d09b457d938437da2f12830a88948c595bbf819c7e2ba2b893</td></tr><tr><td>references</td><td>issue #188718</td><td>pr #188719</td><td>medium</td><td><div class='wide'>Thanks @Sahil170595. The PR is #188719</div></td><td>d8de2cb15f5aab0c45ed4e1a918095e627d417e6a759e0bb722011f90c8d4967</td></tr><tr><td>references</td><td>issue #175891</td><td>issue #62530</td><td>medium</td><td><div class='wide'>itional nodes, switch can do the same in CUDA &gt;= 12.8. Alternatives No response Additional context This has previously been requested here: #62530 cc @mcarilli @ezyang @eellison @penguinwu @BoyuanFeng @chauhang @ydwu4 @bdhirsh @bobrenjc93 @aorenste</div></td><td>9a00af6f1c18741467c70dc5876e37327ef8e01a8789fa2f2fe567b1877b247f</td></tr><tr><td>references</td><td>issue #182277</td><td>issue #177827</td><td>medium</td><td><div class='wide'>aise a clean Python exception such as OverflowError, ValueError, or a normal CUDA OOM RuntimeError, not SystemError. This may be related to #177827, but it does not seem to be the same issue. #177827 is about negative allocation sizes, while this issue is triggered by a positi...</div></td><td>0c280b4f4ac95b5cd7b9eb9d77e20e1830114ba4cb6350cfd1897c45adbc30d9</td></tr><tr><td>references</td><td>issue #188812</td><td>pr #188801</td><td>medium</td><td><div class='wide'>MetalShaderLibrary&amp; MetalShaderLibrary::getBundledLibrary() { static BundledShaderLibrary* l = new BundledShaderLibrary(); return *l; } PR: #188801 (will be scoped down to just this leak). cc @malfet @aditvenk @kulinseth @DenisVieriu97 @jhavukainen @Isalia20 Versions PyTorch v...</div></td><td>c2134ecc4dba4b1da73c0d76b5a01693ba1c84a1c535b16b58927411e651d4df</td></tr><tr><td>references</td><td>issue #188319</td><td>pr #188951</td><td>medium</td><td><div class='wide'>Implemented the core pipeline changes in #188951, covers matrix generation, Makefile, Dockerfile, and workflow env vars. Would appreciate any feedback on the approach.</div></td><td>2efa83a6f79f702c8ae605facf76fdd636076faba758ac5e93db3089c80368d1</td></tr><tr><td>references</td><td>issue #177116</td><td>issue #117826</td><td>medium</td><td><div class='wide'>shaders, fixed for torch.mm/torch.bmm via tiling in PR #117549 but not all code paths), #122045 (F.linear wrong results for large inputs), #117826 (incorrect einsum gradient on MPS). Minimal reproduction The model is Embedding → 2 residual Linear blocks → output Linear, traine...</div></td><td>8ed85e7ca715f1fab7ccca1a190b0fd1593e47912a1109682dbc672e09b66fad</td></tr><tr><td>references</td><td>issue #184575</td><td>pr #188066</td><td>medium</td><td><div class='wide'>~1e12 in backward (not NaN). This is a silent gradient corruption — users see finite gradients when they should see NaN. Submitted test PR: #188066 Detected via NeuralDBG — causal diagnostic engine for PyTorch training.</div></td><td>9d5bc7624ee970ffb047679d26c36ed9cf9a8dab9b283dc84652743252a3ca4a</td></tr><tr><td>references</td><td>issue #188891</td><td>issue #187988</td><td>medium</td><td><div class='wide'>1-D weight correctly, which is why eager rank &gt;= 3 works. Context Found while adding 1-D-weight OpInfo samples to sample_inputs_linear for #187988 / PR #187989 (an unrelated MPS backward crash with 1-D weights): a sample with a scalar bias turns 14 functorch OpInfo tests red o...</div></td><td>5c0571484e233f01f4babb49eac24cc12f29f0aa634da0332f085e0c7df35515</td></tr><tr><td>references</td><td>issue #188891</td><td>pr #187989</td><td>medium</td><td><div class='wide'>orrectly, which is why eager rank &gt;= 3 works. Context Found while adding 1-D-weight OpInfo samples to sample_inputs_linear for #187988 / PR #187989 (an unrelated MPS backward crash with 1-D weights): a sample with a scalar bias turns 14 functorch OpInfo tests red on all backen...</div></td><td>c614743a0c8262a4303764eb0e730a4fdd43b87def99992865382c70940be5f6</td></tr><tr><td>references</td><td>issue #188670</td><td>pr #169694</td><td>medium</td><td><div class='wide'>nce / ROCm follow-up #182028 ROCm MI200 — flex vs SDPA assert_close tolerances #186889 XPU — relaxed assertEqual vs eager (atomic ordering) #169694 Transformer tests — golden precision / reference choice #183691 Test infra — tolerance overrides (helps symptoms; root cause is s...</div></td><td>198e53966f626e02bbdf17b398887cd138b4318c2c9a462aa2ae6ccc1ae15874</td></tr><tr><td>references</td><td>issue #188670</td><td>pr #183691</td><td>medium</td><td><div class='wide'>ose tolerances #186889 XPU — relaxed assertEqual vs eager (atomic ordering) #169694 Transformer tests — golden precision / reference choice #183691 Test infra — tolerance overrides (helps symptoms; root cause is still design in individual tests) 4. Conclusion &amp; proposed next s...</div></td><td>e77c5c394c4db350dad1287de44cbd34ca3016b7a29375880c9e86389e7b7a03</td></tr><tr><td>references</td><td>issue #188670</td><td>pr #184531</td><td>medium</td><td><div class='wide'>oesn&#x27;t solve the root of the issue. Tight same() / eager-fp16 equality is stricter than the bug needs and varies by hardware (e.g. #179958, #184531) — false failures even when the grid fix is sound. 3. Other examples (same pattern family) Link Note #183630 test_bmm_large_batch...</div></td><td>bd51bf5985bf862772fa908fe0af098cbe2480688a50b0a83f66cafb860b7ba2</td></tr><tr><td>references</td><td>issue #188670</td><td>pr #187050</td><td>medium</td><td><div class='wide'>Here is a PR that implements tests for bmm issue in a way that I think is better than current implementation: #187050 It shouldn&#x27;t be used to close the issue, just serve as an example of the direction that I propose to move towards to.</div></td><td>a6427297580fb8d1214da154523bc28d92d379f1130f2178df72aaef3e3c91e8</td></tr><tr><td>references</td><td>issue #188727</td><td>pr #188500</td><td>medium</td><td><div class='wide'>ike GraphPP and Eager Torchtitan PP. We are changing PP to no longer handle microbatch splitting and let the user supply microbatches here: #188500 Torchtitan will now produce microbatches right at source i.e. dataloader: pytorch/torchtitan#3856 So no changes are required from...</div></td><td>fa1d6ca45bc0918ba4f584c1be38f60155ad873dd4d1789d3473e40dc5f8e10a</td></tr><tr><td>references</td><td>issue #188772</td><td>pr #188698</td><td>medium</td><td><div class='wide'>tem.py (which is brittle) and implement their own workarounds for asynchronous saving over fsspec. Additional context This is drafted in PR #188698 and discussed offline with @LucasLLC and @meetv18. Opening this issue to take it further with the process cc @awgu @wanchaol @feg...</div></td><td>f672141928f220635f80b6689a8a4bf16d8e328f2cb1f56d4c4965a7c26729e1</td></tr><tr><td>references</td><td>issue #188711</td><td>issue #188675</td><td>medium</td><td><div class='wide'>fast_accum_True_scaling_block_sizes2_cuda One of ~14 failing test_main_loop_scaling parametrizations (w = BlockWise1x128 recipes). See also #188675, #188704. cc @ptrblck @msaroufim @eqy @tinglvv @nWEIdia</div></td><td>380e8b3b0e3d23c78bc388f0c39b430e7091ba46c1b318dee418bc47871250aa</td></tr><tr><td>references</td><td>issue #188711</td><td>issue #188704</td><td>medium</td><td><div class='wide'>m_True_scaling_block_sizes2_cuda One of ~14 failing test_main_loop_scaling parametrizations (w = BlockWise1x128 recipes). See also #188675, #188704. cc @ptrblck @msaroufim @eqy @tinglvv @nWEIdia</div></td><td>5d870351811498879b4882276cdb3b8ad227981535b4d9babb5dbe37ee5349d0</td></tr><tr><td>references</td><td>issue #188707</td><td>issue #188675</td><td>medium</td><td><div class='wide'>ast_accum_False_scaling_block_sizes1_cuda One of ~14 failing test_main_loop_scaling parametrizations (w = BlockWise1x128 recipes). See also #188675, #188704. cc @ptrblck @msaroufim @eqy @tinglvv @nWEIdia</div></td><td>086d0df5d173b95613cf8cc09a713ec31938bbe00b72919802796fb04158cce8</td></tr><tr><td>references</td><td>issue #188707</td><td>issue #188704</td><td>medium</td><td><div class='wide'>_False_scaling_block_sizes1_cuda One of ~14 failing test_main_loop_scaling parametrizations (w = BlockWise1x128 recipes). See also #188675, #188704. cc @ptrblck @msaroufim @eqy @tinglvv @nWEIdia</div></td><td>8aad4c9a3346ff569d46f2e73ceaea770185441378d8365818c617c77dc759ca</td></tr><tr><td>references</td><td>issue #188706</td><td>issue #188675</td><td>medium</td><td><div class='wide'>ast_accum_False_scaling_block_sizes0_cuda One of ~14 failing test_main_loop_scaling parametrizations (w = BlockWise1x128 recipes). See also #188675, #188704. cc @ptrblck @msaroufim @eqy @tinglvv @nWEIdia</div></td><td>800422d2dbb726ce7dc6d5d2b41483d112e6bfa3de8f3cbb186fd73a351fbc2f</td></tr><tr><td>references</td><td>issue #188706</td><td>issue #188704</td><td>medium</td><td><div class='wide'>_False_scaling_block_sizes0_cuda One of ~14 failing test_main_loop_scaling parametrizations (w = BlockWise1x128 recipes). See also #188675, #188704. cc @ptrblck @msaroufim @eqy @tinglvv @nWEIdia</div></td><td>e945e5c0dec8f603f8a1226536e8ebb9ceec1f90de8152f9072435d0f78e09f7</td></tr><tr><td>references</td><td>issue #102207</td><td>issue #108798</td><td>medium</td><td><div class='wide'>_.from needs to be renamed&quot; &#x27;test_advancedindex_mixed_cpu_devices&#x27; - &quot;FIXME&quot; &#x27;test_advancedindex_mixed_devices_error&#x27; - &quot;FIXME&quot; #108181 and #108798 &#x27;test_typed_storage_deprecation_warning&#x27; - &quot;FIXME&quot; &#x27;test_pin_memory&#x27; - &quot;pin_memory isn&#x27;t yet supported in TorchInductor&quot; &#x27;test_me...</div></td><td>9eac0f3787e9f7be4bae833fe135aa372e815033066e68e5669d452d2ff375ce</td></tr><tr><td>references</td><td>issue #188721</td><td>issue #188477</td><td>medium</td><td><div class='wide'>: module &#x27;cutlass.cute.arch&#x27; has no attribute &#x27;ProxyKind&#x27; (unpinned cutlass_api vs pinned nvidia-cutlass-dsl==4.5.2). Root cause tracked in #188477. Unstable until the cutlass_api / cutlass-dsl version skew is resolved. cc @malfet @pytorch/pytorch-dev-infra</div></td><td>10df704ed063fc92983779ef79ab6ae6c3f17cb633156e78fca63c99cc6dbec4</td></tr><tr><td>references</td><td>issue #188714</td><td>issue #188675</td><td>medium</td><td><div class='wide'>fast_accum_True_scaling_block_sizes1_cuda One of ~14 failing test_main_loop_scaling parametrizations (w = BlockWise1x128 recipes). See also #188675, #188704. cc @ptrblck @msaroufim @eqy @tinglvv @nWEIdia @mruberry @chauhang @penguinwu @voznesenskym @EikanWang @jgong5 @Guobing-...</div></td><td>c0ffd4ffb8e61edc1a7c08df3df4169354695b25febc034bde3c4b3e5565bf21</td></tr><tr><td>references</td><td>issue #188714</td><td>issue #188704</td><td>medium</td><td><div class='wide'>m_True_scaling_block_sizes1_cuda One of ~14 failing test_main_loop_scaling parametrizations (w = BlockWise1x128 recipes). See also #188675, #188704. cc @ptrblck @msaroufim @eqy @tinglvv @nWEIdia @mruberry @chauhang @penguinwu @voznesenskym @EikanWang @jgong5 @Guobing-Chen @Xia...</div></td><td>f6642f1800f107c17de69c746216551c020e432c2aafb41e60b78c092f123237</td></tr><tr><td>references</td><td>issue #188715</td><td>issue #188675</td><td>medium</td><td><div class='wide'>fast_accum_True_scaling_block_sizes2_cuda One of ~14 failing test_main_loop_scaling parametrizations (w = BlockWise1x128 recipes). See also #188675, #188704. cc @mruberry @chauhang @penguinwu @voznesenskym @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @we...</div></td><td>5a37ccad30a9eecfe83cb39ab9baab004caf4c3a94d0e77bb4de32f34f0a85b7</td></tr><tr><td>references</td><td>issue #188715</td><td>issue #188704</td><td>medium</td><td><div class='wide'>m_True_scaling_block_sizes2_cuda One of ~14 failing test_main_loop_scaling parametrizations (w = BlockWise1x128 recipes). See also #188675, #188704. cc @mruberry @chauhang @penguinwu @voznesenskym @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv...</div></td><td>eabbe0bea09182cafeb8da6c348ee12821462fde0eea5a628c7d38bee1b51061</td></tr><tr><td>references</td><td>issue #188712</td><td>issue #188675</td><td>medium</td><td><div class='wide'>ast_accum_False_scaling_block_sizes1_cuda One of ~14 failing test_main_loop_scaling parametrizations (w = BlockWise1x128 recipes). See also #188675, #188704. cc @ptrblck @msaroufim @eqy @tinglvv @nWEIdia @mruberry @chauhang @penguinwu @voznesenskym @EikanWang @jgong5 @Guobing-...</div></td><td>f290676f1ab2d12c4f511352083abff8c8d2dfde47772cd0e89040927553fa49</td></tr><tr><td>references</td><td>issue #188712</td><td>issue #188704</td><td>medium</td><td><div class='wide'>_False_scaling_block_sizes1_cuda One of ~14 failing test_main_loop_scaling parametrizations (w = BlockWise1x128 recipes). See also #188675, #188704. cc @ptrblck @msaroufim @eqy @tinglvv @nWEIdia @mruberry @chauhang @penguinwu @voznesenskym @EikanWang @jgong5 @Guobing-Chen @Xia...</div></td><td>4c5f171e6f5735599314786e8f0bbcedce80c4d199357c5c956644a673e21452</td></tr><tr><td>references</td><td>issue #188709</td><td>issue #188675</td><td>medium</td><td><div class='wide'>fast_accum_True_scaling_block_sizes0_cuda One of ~14 failing test_main_loop_scaling parametrizations (w = BlockWise1x128 recipes). See also #188675, #188704. cc @mruberry @chauhang @penguinwu @voznesenskym @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @we...</div></td><td>970a255e54311b85311aeac6f6fb42b2e9aea2c6e665b9f70ddeefe26ce11610</td></tr><tr><td>references</td><td>issue #188709</td><td>issue #188704</td><td>medium</td><td><div class='wide'>m_True_scaling_block_sizes0_cuda One of ~14 failing test_main_loop_scaling parametrizations (w = BlockWise1x128 recipes). See also #188675, #188704. cc @mruberry @chauhang @penguinwu @voznesenskym @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv...</div></td><td>7f22e90fe7a4f84c421309be4f27ee8ed5f0f2fdaddfe5504b01287f7d528fd6</td></tr><tr><td>references</td><td>issue #188713</td><td>issue #188675</td><td>medium</td><td><div class='wide'>ast_accum_False_scaling_block_sizes2_cuda One of ~14 failing test_main_loop_scaling parametrizations (w = BlockWise1x128 recipes). See also #188675, #188704. cc @ptrblck @msaroufim @eqy @tinglvv @nWEIdia @mruberry @jianyuh @nikitaved @walterddr @lezcano @chauhang @penguinwu @v...</div></td><td>506ac453723407ac03c04d17c5f9ed7f2effbe2e149b13e3d8cd1224c3b808c5</td></tr><tr><td>references</td><td>issue #188713</td><td>issue #188704</td><td>medium</td><td><div class='wide'>_False_scaling_block_sizes2_cuda One of ~14 failing test_main_loop_scaling parametrizations (w = BlockWise1x128 recipes). See also #188675, #188704. cc @ptrblck @msaroufim @eqy @tinglvv @nWEIdia @mruberry @jianyuh @nikitaved @walterddr @lezcano @chauhang @penguinwu @voznesensk...</div></td><td>faa883fd8e576c81e29b73be484507092dc97967ef43815ea59cb7f1df56deb7</td></tr><tr><td>references</td><td>issue #188717</td><td>issue #188675</td><td>medium</td><td><div class='wide'>ast_accum_False_scaling_block_sizes2_cuda One of ~14 failing test_main_loop_scaling parametrizations (w = BlockWise1x128 recipes). See also #188675, #188704. cc @mruberry @chauhang @penguinwu @voznesenskym @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @we...</div></td><td>9d6aa963f9e1b3659683551432bb0e30abe511d2cb5a6e2f058abbd3e5d11022</td></tr><tr><td>references</td><td>issue #188717</td><td>issue #188704</td><td>medium</td><td><div class='wide'>_False_scaling_block_sizes2_cuda One of ~14 failing test_main_loop_scaling parametrizations (w = BlockWise1x128 recipes). See also #188675, #188704. cc @mruberry @chauhang @penguinwu @voznesenskym @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv...</div></td><td>64eee4d83aca66f94e0f6b4b11c4304546de08d3f2a7916b64e4a00d94bb2bc6</td></tr><tr><td>references</td><td>issue #188708</td><td>issue #188675</td><td>medium</td><td><div class='wide'>ast_accum_False_scaling_block_sizes2_cuda One of ~14 failing test_main_loop_scaling parametrizations (w = BlockWise1x128 recipes). See also #188675, #188704. cc @mruberry @chauhang @penguinwu @voznesenskym @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @we...</div></td><td>1e7aa4b708515aed1abe502d66f11ba976d81326e4cff82fddbbe69d393fb8f0</td></tr><tr><td>references</td><td>issue #188708</td><td>issue #188704</td><td>medium</td><td><div class='wide'>_False_scaling_block_sizes2_cuda One of ~14 failing test_main_loop_scaling parametrizations (w = BlockWise1x128 recipes). See also #188675, #188704. cc @mruberry @chauhang @penguinwu @voznesenskym @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv...</div></td><td>a63ac04f3aa92924d143b5f3c76de537074f8941a76015bd963bb28801d1a9b8</td></tr><tr><td>references</td><td>issue #188716</td><td>issue #188675</td><td>medium</td><td><div class='wide'>ast_accum_False_scaling_block_sizes1_cuda One of ~14 failing test_main_loop_scaling parametrizations (w = BlockWise1x128 recipes). See also #188675, #188704. cc @mruberry @chauhang @penguinwu @voznesenskym @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @we...</div></td><td>0ea007c8d36e2ffeef844c1311a78327436c618f2324070d1743f416d8c89c4e</td></tr><tr><td>references</td><td>issue #188716</td><td>issue #188704</td><td>medium</td><td><div class='wide'>_False_scaling_block_sizes1_cuda One of ~14 failing test_main_loop_scaling parametrizations (w = BlockWise1x128 recipes). See also #188675, #188704. cc @mruberry @chauhang @penguinwu @voznesenskym @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv...</div></td><td>3533f21e3e7b72b453b8187347400979a070d26555cfd388a18ddb2c8e08d22a</td></tr><tr><td>references</td><td>issue #188710</td><td>issue #188675</td><td>medium</td><td><div class='wide'>fast_accum_True_scaling_block_sizes1_cuda One of ~14 failing test_main_loop_scaling parametrizations (w = BlockWise1x128 recipes). See also #188675, #188704. cc @mruberry @chauhang @penguinwu @voznesenskym @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @we...</div></td><td>4ae6d492ad2b3c3935086523dc68b6b689c360a25dac91b1ca3984b599f5c4d2</td></tr><tr><td>references</td><td>issue #188710</td><td>issue #188704</td><td>medium</td><td><div class='wide'>m_True_scaling_block_sizes1_cuda One of ~14 failing test_main_loop_scaling parametrizations (w = BlockWise1x128 recipes). See also #188675, #188704. cc @mruberry @chauhang @penguinwu @voznesenskym @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv...</div></td><td>fdc73e68154a961c66e385be08098f7660819a75001ad588ab6a8e9a4480183e</td></tr><tr><td>references</td><td>issue #188652</td><td>pr #188263</td><td>medium</td><td><div class='wide'>he system, it downloads its own python-six sources files from the web (pypi to be exact) This makes pytorch not buildable from sources only #188263 shows the changes needed for allowing air-gapped builds To reproduce the bug simply try to build pytorch on a machine without int...</div></td><td>c64925d08a1e2b495fad1e9153b7c9abe99e2fda39eaab3f5468c1ed5467b161</td></tr><tr><td>competes with</td><td>issue #188425</td><td>issue #188420</td><td>medium</td><td><div class='wide'>@Blooming-Tree I noticed that #188420, #188430, and #188432 appear to have the same methodology issue. They compare eager FP64 against compiled FP32 rather than eager FP32 again</div></td><td>6030c43457e684c489aa1189093263292c95b210873f3bdec9848039f82a9e41</td></tr><tr><td>competes with</td><td>issue #188425</td><td>issue #188430</td><td>medium</td><td><div class='wide'>@Blooming-Tree I noticed that #188420, #188430, and #188432 appear to have the same methodology issue. They compare eager FP64 against compiled FP32 rather than eager FP32 against compil</div></td><td>dfc3ea4565e9d75e9bd4e2d1a354936446792c6c243acbf699c6d0b7b85e6376</td></tr><tr><td>competes with</td><td>issue #188425</td><td>issue #188432</td><td>medium</td><td><div class='wide'>@Blooming-Tree I noticed that #188420, #188430, and #188432 appear to have the same methodology issue. They compare eager FP64 against compiled FP32 rather than eager FP32 against compiled FP32, so t</div></td><td>25952773a33260bddb92f3d86fd71d0c8614fcce65ca99bf69a67ad8950ae3e5</td></tr><tr><td>references</td><td>issue #132845</td><td>issue #15963</td><td>medium</td><td><div class='wide'>ue, please check the box on this page and assign the issue to yourself. Thanks! C10D NCCL #131203 #112815 #94003 #58856 GLOO #115740 #16295 #15963 Tcpstore #61671 #50701 MultiProcessing #65559 MultiThreadedTestCase #107425 #107424 #100459 #100448 RPC #125365 #74180 #70753 #705...</div></td><td>6c9111a02c5a0197606cd4c4228cdde6e8327e9346c654d4895eb3d1e5c8c6f5</td></tr><tr><td>references</td><td>issue #132845</td><td>issue #16295</td><td>medium</td><td><div class='wide'>an issue, please check the box on this page and assign the issue to yourself. Thanks! C10D NCCL #131203 #112815 #94003 #58856 GLOO #115740 #16295 #15963 Tcpstore #61671 #50701 MultiProcessing #65559 MultiThreadedTestCase #107425 #107424 #100459 #100448 RPC #125365 #74180 #7075...</div></td><td>3f5de47a55f7828e5b27e907165fc3be2fdd9844956ed32d2d4924eb21942134</td></tr><tr><td>references</td><td>issue #132845</td><td>issue #51062</td><td>medium</td><td><div class='wide'>1 #50701 MultiProcessing #65559 MultiThreadedTestCase #107425 #107424 #100459 #100448 RPC #125365 #74180 #70753 #70546 #69179 #69178 #64093 #51062 DeviceMesh and DTensor DeviceMesh #132833 #123906 #122525 #122664 #121951 #121776 #121372 #120706 #120692 #110026 #98875 #98059 #9...</div></td><td>ee4a99abde9564c99b6d193c26838b234f9ec91787e275ee2a2591f21c900c0e</td></tr><tr><td>references</td><td>issue #132845</td><td>issue #58856</td><td>medium</td><td><div class='wide'>u would like to take an issue, please check the box on this page and assign the issue to yourself. Thanks! C10D NCCL #131203 #112815 #94003 #58856 GLOO #115740 #16295 #15963 Tcpstore #61671 #50701 MultiProcessing #65559 MultiThreadedTestCase #107425 #107424 #100459 #100448 RPC...</div></td><td>2fcc1403a4a723e7d1a8c76cddfc97094f497485ee4cc71d2ba7a0b7ff58fc5c</td></tr><tr><td>references</td><td>issue #132845</td><td>issue #64093</td><td>medium</td><td><div class='wide'>e #61671 #50701 MultiProcessing #65559 MultiThreadedTestCase #107425 #107424 #100459 #100448 RPC #125365 #74180 #70753 #70546 #69179 #69178 #64093 #51062 DeviceMesh and DTensor DeviceMesh #132833 #123906 #122525 #122664 #121951 #121776 #121372 #120706 #120692 #110026 #98875 #9...</div></td><td>6de948c3fa1a17c69f726908fad72c292a277d6af77e747ec94e4c1149179992</td></tr><tr><td>references</td><td>issue #132845</td><td>issue #69178</td><td>medium</td><td><div class='wide'>Tcpstore #61671 #50701 MultiProcessing #65559 MultiThreadedTestCase #107425 #107424 #100459 #100448 RPC #125365 #74180 #70753 #70546 #69179 #69178 #64093 #51062 DeviceMesh and DTensor DeviceMesh #132833 #123906 #122525 #122664 #121951 #121776 #121372 #120706 #120692 #110026 #9...</div></td><td>ce44fb6f9ea09942a5f6cff4f68ee347d11719250e1d08e63c138b3c854a64a6</td></tr><tr><td>references</td><td>issue #132845</td><td>issue #69179</td><td>medium</td><td><div class='wide'>#15963 Tcpstore #61671 #50701 MultiProcessing #65559 MultiThreadedTestCase #107425 #107424 #100459 #100448 RPC #125365 #74180 #70753 #70546 #69179 #69178 #64093 #51062 DeviceMesh and DTensor DeviceMesh #132833 #123906 #122525 #122664 #121951 #121776 #121372 #120706 #120692 #11...</div></td><td>fcc954b1e21d7dfdc0b1f09f4a8123017402c67814372fb459ebc2b642715795</td></tr><tr><td>references</td><td>issue #132845</td><td>issue #94003</td><td>medium</td><td><div class='wide'>. If you would like to take an issue, please check the box on this page and assign the issue to yourself. Thanks! C10D NCCL #131203 #112815 #94003 #58856 GLOO #115740 #16295 #15963 Tcpstore #61671 #50701 MultiProcessing #65559 MultiThreadedTestCase #107425 #107424 #100459 #100...</div></td><td>04a20f55ce13ee93eb9c8f836de1361967940dc10cc7073e4b90f29a0233183a</td></tr><tr><td>references</td><td>issue #132845</td><td>issue #103625</td><td>medium</td><td><div class='wide'>14 #132447 #131446 #127373 #126868 #126852 #126493 #123294 DDP, FSDP, PiPPy FSDP1 #123726 #105024 FSDP2 #120961 DDP #106361 #104328 #104011 #103625 #77342 #77317 pipeline #121234 Other DCP #113937 #113936 Functional Collectives #107278 ShardedTensor #78068 cc @XilunWu @H-Huang...</div></td><td>7104f447a89af157a51d4b595d5cde1609425c7884a153dfe0b77f4d707f13a3</td></tr><tr><td>references</td><td>issue #132845</td><td>issue #104011</td><td>medium</td><td><div class='wide'>in #132114 #132447 #131446 #127373 #126868 #126852 #126493 #123294 DDP, FSDP, PiPPy FSDP1 #123726 #105024 FSDP2 #120961 DDP #106361 #104328 #104011 #103625 #77342 #77317 pipeline #121234 Other DCP #113937 #113936 Functional Collectives #107278 ShardedTensor #78068 cc @XilunWu...</div></td><td>6a719ae638ac282e95ba9b87e203085b4f5bc6c23cb2aeadeffcde444daac0de</td></tr><tr><td>references</td><td>issue #187473</td><td>issue #73764</td><td>medium</td><td><div class='wide'>ributed 500/shm_broadcast hang) and 4 (CPU-MM 3 timeout) are silent on build #72925 (2026-06-18) — both passed; never filed upstream. Build #73764 status (2026-06-23) Still reproducing (fixes in pytorch main, not yet in test-channel wheel): #187484 (Inductor FxGraphCache guard...</div></td><td>f2ab20b1cd7894d89eca1ab09af87d149a93a12aedd167abdac443781319eb50</td></tr><tr><td>references</td><td>issue #187473</td><td>pr #184193</td><td>medium</td><td><div class='wide'>eam. #187484 — [Inductor] w8a8 block-fp8 BackendCompilerFailed: inductor (DeepGEMM H100, FusedMoE H100/B200, Kernels MoE Test 1–4) · Cause: #184193 · Fix: revert #187666 (release/2.13, bisected — all 75 failures pass reverted) #187735 — [CPU multimodal] qwen2_vl multi-image to...</div></td><td>f90706cfb2736e37955d14ed1b6cce7c4c26e149d7614ae98ce25afef6ad29e3</td></tr><tr><td>references</td><td>issue #158968</td><td>issue #158371</td><td>medium</td><td><div class='wide'>ture, motivation and pitch These enhancements are to have a better UX when using foreach_map, suggested in a few places, but most recently, #158371 (comment) These enhancements should allow easier compiler-first custom optimizer implementations. Alternatives No response Additi...</div></td><td>a06136a5d639c01df4166d0ecc0fe59446cd3972cf8b65cf24fae0d7baf8aa69</td></tr><tr><td>references</td><td>issue #77764</td><td>issue #141287</td><td>medium</td><td><div class='wide'>lace to list and track work on adding support to new ops for the MPS backend. Most requested ops (extracted from comments to this issue and #141287) PyTorch MPS Ops Project : Project to track all the ops for MPS backend. There are a very large number of operators in pytorch an...</div></td><td>43524886f1e21123a7453a8d5ab0713bb84880c7928fbbaa614e5646b57bf808</td></tr><tr><td>references</td><td>issue #139792</td><td>issue #101699</td><td>medium</td><td><div class='wide'>speeding up pickling itself, it would be great to have core support for arrays of strings represented as tensors (and simple data frames): #101699 If there is a million-sized list of python strings, pickle probably would be slower compared to a single tensor of concatenated ut...</div></td><td>00c944a126a20273d4aac658a2c66174e32c8e948480ea861b96d06cad8000e8</td></tr><tr><td>references</td><td>issue #188113</td><td>pr #188114</td><td>medium</td><td><div class='wide'>ses manual attention. It works on both AOTriton v0.11.2 and CK: a, w = attn(x, x, x, need_weights=True) # OK on both backends Updated PR at #188114 with all four files.</div></td><td>91dd135026cbb2814acedea56df2a1908c59fe3c7d459e78130daf7898a0c19e</td></tr><tr><td>references</td><td>issue #184229</td><td>issue #175467</td><td>medium</td><td><div class='wide'>uted.device_mesh import init_device_mesh from torch.distributed.tensor.parallel import ColwiseParallel, parallelize_module # Workaround for #175467 (DTensorSpec not registered as pytree constant). torch.utils._pytree.register_constant( torch.distributed.tensor._dtensor_spec.DT...</div></td><td>5551942bc14ca08353529e9362d5cbd688dbe26d12bff87952fa9e12d33b43f3</td></tr><tr><td>references</td><td>issue #184229</td><td>pr #184508</td><td>medium</td><td><div class='wide'>There is an AI generated fix here: #184508 Which is waiting for review.</div></td><td>92976a5224c4d6aa9a3b36bac0bede9cf2ba2600b8f0bf6608f71e57d8370b41</td></tr><tr><td>references</td><td>issue #187953</td><td>issue #135859</td><td>medium</td><td><div class='wide'>recompile under torch.compile on every new input shape, while the functional variants specialize only once. Reported originally as part of #135859 for linalg.norm and cholesky; the max / min / topk cases (structured ops) are fixed in #187952, but the composite ops need a diffe...</div></td><td>ecfef6ec584732aa9ed14763fda420b2313435bb050dd5ee5a3a838487499aeb</td></tr><tr><td>references</td><td>issue #187953</td><td>pr #187952</td><td>medium</td><td><div class='wide'>ze only once. Reported originally as part of #135859 for linalg.norm and cholesky; the max / min / topk cases (structured ops) are fixed in #187952, but the composite ops need a different fix. Minimal repro: import torch torch._logging.set_logs(recompiles=True) def f(x): out =...</div></td><td>03517d2896bd196f1b2189c6ae7890ac461dccc3b686339326c7962bc719747c</td></tr></tbody></table></div></section></div>