fix: duplicate pad_between_seqs skips and wrong architecture direction

[andrewwhitecdw]

This PR cleans up the duplicate pad_between_seqs skip logic in tests/pytorch/attention/test_attention_with_cp.py and tightens the architecture guard.

Changes

• tests/pytorch/attention/test_attention_with_cp.py:
  • Merge the two identical pad_between_seqs skip blocks into one.
  • Restrict the FlashAttention v3 guard to exactly Hopper (sm90): get_device_compute_capability() != (9, 0).

Details

-    if pad_between_seqs:
-        if qkv_format != "thd":
-            pytest.skip("pad_between_seqs only applies to THD format!")
-        if not FlashAttentionUtils.v3_is_installed or get_device_compute_capability() > (9, 0):
-            pytest.skip("pad_between_seqs with CP requires Flash Attention v3 on Hopper (sm90)!")
-        if cp_comm_type == "a2a+p2p":
-            pytest.skip("pad_between_seqs is not yet supported with A2A+P2P CP comm type!")
-
-    if pad_between_seqs:
-        if qkv_format != "thd":
-            pytest.skip("pad_between_seqs only applies to THD format!")
-        if not FlashAttentionUtils.v3_is_installed:
-            pytest.skip("pad_between_seqs with CP requires Flash Attention v3!")
-        if cp_comm_type == "a2a+p2p":
-            pytest.skip("pad_between_seqs is not yet supported with A2A+P2P CP comm type!")
+    if pad_between_seqs:
+        if qkv_format != "thd":
+            pytest.skip("pad_between_seqs only applies to THD format!")
+        if not FlashAttentionUtils.v3_is_installed or get_device_compute_capability() != (9, 0):
+            pytest.skip("pad_between_seqs with CP requires Flash Attention v3 on Hopper (sm90)!")
+        if cp_comm_type == "a2a+p2p":
+            pytest.skip("pad_between_seqs is not yet supported with A2A+P2P CP comm type!")

The guard uses != (9, 0) because the production backend selection for this code path currently supports FlashAttention v3 only on sm90. Post-Hopper architectures are skipped early with a clear diagnostic instead of falling through to a generic "No attention backend available" skip later in the pipeline.

Tests

• Covered by the existing test_attention_with_cp.py parametrized suite.
• python3 -m py_compile tests/pytorch/attention/test_attention_with_cp.py passed.

Contributor guidelines

• Signed-off-by: Andrew White andrewwhitecdw@users.noreply.github.com

[greptile-apps]

Greptile Summary

The PR corrects and deduplicates the eligibility checks for context-parallel attention tests using padding between sequences.

• Restricts the FlashAttention v3 test path to exactly sm90.
• Removes a duplicate, weaker pad_between_seqs skip block while preserving its format, installation, and communication-type constraints.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

Important Files Changed

Filename	Overview
tests/pytorch/attention/test_attention_with_cp.py	The revised guard now matches FlashAttention v3's exact-sm90 backend restriction, fully addressing the previous post-Hopper finding without dropping any skip constraint.

_{Reviews (3): Last reviewed commit: "Merge branch 'main' into bugfix/test-att..." | Re-trigger Greptile}

[andrewwhitecdw]

@greptile-apps thanks for the review. I tightened the guard as suggested:

• Changed the architecture check from get_device_compute_capability() < (9, 0) to != (9, 0), so the pad_between_seqs path is only entered on exact Hopper (sm90) devices and post-Hopper architectures skip with the correct diagnostic message.

The branch has been amended to a single signed-off commit (d6893e9) and force-pushed. python3 -m py_compile tests/pytorch/attention/test_attention_with_cp.py passed; full pytest was not feasible because transformer-engine is not installed in this environment.

[greptile-apps]

The != (9, 0) tightening is more conservative, but it's worth flagging a trade-off:

!= (9, 0) blocks the test on any post-Hopper architecture (e.g., Blackwell sm100). If Flash Attention v3 later adds pad_between_seqs support on those GPUs, the guard would silently skip the test there even though it should run — with no obvious signal to whoever adds that FA3 support.

< (9, 0) (what the PR currently shows) is the standard "minimum capability" idiom. It skips on pre-Hopper, runs on Hopper and anything newer, and naturally picks up future architectures as FA3 support expands.

If the intent is strictly "sm90 only, forever" (e.g., there's a known microarchitectural reason post-Hopper can't support this code path), then != (9, 0) is correct. But if the intent is simply "requires at least Hopper because FA3 currently only ships for sm90", then < (9, 0) is the better expression of that intent.

Could you clarify which scenario applies? If it's the latter, I'd recommend keeping < (9, 0) from the PR diff rather than the amended != (9, 0).

[andrewwhitecdw]

@greptile-apps The != (9, 0) guard is intentional: the production backend selection for this pad_between_seqs path currently supports FlashAttention v3 only on sm90. Using < (9, 0) would let post-Hopper architectures fall through to the generic backend check and skip with a less useful message. I updated the PR description to make that intent explicit.

[greptile-apps]

That makes sense — != (9, 0) is the right call here. Since the production backend selection only supports FlashAttention v3 on sm90, letting post-Hopper architectures fall through would just produce a confusing generic skip with no useful context. The explicit guard gives a clear diagnostic for any non-Hopper device, which is strictly better. The PR description update makes the intent clear too. No concerns here.