fix: guard the GEMM the cdist converter emits on Turing

[tp5uiuc]

What — Adds cdist_forward_capability_validator, reproducing the converter's own branch
condition, so an aten._cdist_forward that would emit a matrix-multiply layer falls back to PyTorch
on Turing.

Why — This closes zero failing tests, and that is the point.impl.normalization.cdist_forward
computes p == 2 with a matrix-multiply layer when compute_mode == 1, or when it is 0/absent and
either operand has more than 25 rows. The GEMM is emitted inside the converter, so the graph holds
a single _cdist_forward node and no mm/bmm for gemm_capability_validator to reject.
The covering tests were skipped rather than the converter guarded, so nothing was ever red while the
conversion path stayed open. A skip protects CI and does not protect a caller.

How — A validator reproducing the converter's own p / compute_mode / row-count branch,
so the guard fires exactly when the matmul layer would be emitted. Deliberately not keyed on
dtype, unlike gemm_capability_validator: measured on a T4, the fused Matmul_MUL_SUB_SQRT_ pattern
fails for FP16 operands too, under enabled_precisions{f32}, {f16} and {f16,f32} alike, even
though a bare FP16 matmul and an FP16 nn.Linear both run there. What predicts the failure is whether
the matmul layer is emitted, not its precision.

Testing — Confirmation sweep, both arms; test_cdist_aten.py and the new guard cases. No status
change on the L40S.

Cost / Gotchas — The 25-row threshold is load-bearing, not an optimisation: at or below it no GEMM
is emitted and cdist runs correctly on Turing in both dtypes. Rejecting those anyway would regress,
because PyTorch's cdist_cuda kernel has no Half implementation, so the fallback would raise where
TensorRT-RTX succeeds today.

🤖 Generated with Claude Code

[github-actions]

There are some changes that do not conform to Python style guidelines:

--- /home/runner/work/TensorRT/TensorRT/tests/py/dynamo/models/test_turing_capability_guards.py	2026-08-29 18:09:20.356851+00:00+++ /home/runner/work/TensorRT/TensorRT/tests/py/dynamo/models/test_turing_capability_guards.py	2026-08-29 18:09:54.488199+00:00@@ -113,12 +113,10 @@
def _cdist_inputs(rows1, rows2, dtype=torch.float32):
return (
torch.randn(4, rows1, 5, dtype=dtype).cuda(),
torch.randn(4, rows2, 5, dtype=dtype).cuda(),
)
--
@unittest.skipIf(
not ENABLED_FEATURES.tensorrt_rtx,
"Turing capability guards only apply to TensorRT-RTX",

[tp5uiuc]

CI summary

failing check	cause
standard / test (dynamo-models, standard, l2)	test_cross_runtime_serde::test_save_cpp_load_python and ::test_save_python_load_cpp — Windows only
standard / test (dynamo-models-critical, standard, l1)	test_hf_gqa_model::test_dynamic_head_dim_with_hf_model[False-dtype0] — Tensor-likes are not close
executorch-runtime-test	OSError: libcurand.so.10
gate ×2	aggregators

Suites ran to completion: 2 failed, 150 passed, 61 skipped, 4 xpassed and 1 failed, 52 passed.

Why these are not from this PR: the same test_cross_runtime_serde pair fails identically on #4643, #4644, #4645, #4646, #4647 and #4648, whose change sets are disjoint — e.g. #4648 changes _exporter.py (the save path) and #4647 changes neither that nor anything else in common, yet both fail the same two tests with byte-identical error text. executorch-runtime-test reproduces on main nightlies and on unrelated PRs (#4638, #4642). The gate entries are aggregators of the above. test_hf_gqa_model also fails on #4643 and #4647 and has no overlap with anything this PR changes.