fix: fall back to PyTorch for ops TensorRT-RTX cannot serve on Turing (SM 7.5)

[tp5uiuc]

Description

TensorRT-RTX supports SM 7.5 and up, but its support matrix states that on Turing it "does not support FP32 GEMMs and 3D convolutions in this release", and Turing has no bfloat16 hardware. Torch-TensorRT had no notion of this and handed those ops to TensorRT-RTX anyway. Observed on a Turing GPU:

• FP32 GEMM, dynamic shapes — the engine builds, runs, and returns an all-zero tensor of the correct shape and dtype, with no exception and no NaN. This is the motivating case: it is silent, so the user gets plausible-looking output that is entirely wrong.
• FP32 GEMM, static shapes — createExecutionContext() returns null.
• 3D convolution — same null execution context.
• bfloat16 — segmentation fault.

How

• _utils.py: get_target_compute_capabilities() / trt_rtx_targets_turing(). Guards key off the capabilities being built for, not the build host — querying the local device would bake the build machine into an ahead-of-time artifact.
• aten_ops_converters.py: gemm_capability_validator on matmul/mm/bmm/dot/mv/addmm (fp32 operands only, so fp16 with use_fp32_acc is unaffected); 3D convolution rejected in convolution_capability_validator — forward only, since transposed 3D works on Turing.
• partitioning/: bfloat16 gated in both partitioners rather than per-converter, as the crash is not operator-specific. Mirrors the existing complex-dtype handling.
• _settings.py / _defaults.py / _compiler.py: new target_compute_capabilities option on all three compile entry points, added to _SETTINGS_TO_BE_ENGINE_INVARIANT so a cached engine built for different targets is never reused.
• _TRTInterpreter.py: the same list drives setComputeCapability(), so partitioning and engine targeting cannot drift apart.
• Tests: skip_if_trt_rtx_turing() in the conversion harness, applied to the affected matmul, cdist (p == 2), convolution (3D) and binary-op (bf16) tests.

Testing

On a Turing GPU all four cases now fall back to PyTorch and produce correct results (cosine 1.000000), while fp16 GEMM, transposed 3D convolution and 2D convolution still run on TensorRT. On an SM 8.9 GPU behaviour is unchanged by default, and compiling with target_compute_capabilities=[(7, 5)] reproduces Turing's partitioning — so this is testable without Turing hardware. Affected conversion suites: 121 passed, 57 skipped, 0 failed (previously 23 failures).

Notes for reviewers

• On Turing, fp32 GEMMs now run in PyTorch. Some fp32 GEMM shapes do execute correctly on Turing today, so this guard is deliberately broader than strictly necessary — the documented contract says unsupported, and the failure mode when it does bite is silent wrong answers. Happy to narrow it if you prefer.
• Guards read meta["val"], as other validators in this module do. Converter unit tests build graphs with empty node meta, so validators cannot fire there at all; those tests skip explicitly instead.
• Includes one unrelated one-line change: a pre-existing untyped return in _settings.py is bound to a typed local, because that file is now in the changed set and --strict mypy blocks the commit on it.
• No behaviour change on any architecture other than Turing.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)

Checklist:

• My code follows the style guidelines of this project (You can use the linters)
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas and hacks
• I have made corresponding changes to the documentation
• I have added tests to verify my fix or my feature
• New and existing unit tests pass locally with my changes
• I have added the relevant labels to my PR in so that relevant reviewers are notified