[100milliongold]

Description

-a 107-real is accepted and reaches CMakeCache.txt intact, but no SM107 code is ever
produced. setup_cuda_architectures() normalizes requested architectures against

set(ARCHITECTURES_COMPATIBILITY_BASE 80 86 90 100 120)
set(ARCHITECTURES_NO_COMPATIBILITY 87 101)

An architecture in neither list is folded to the largest base sharing its major version.
107 is in neither, and 107 / 10 == 100 / 10, so it silently becomes 100. No warning is
emitted.

9f92665 ("[None][infra] Recognize SM107 (Rubin) in build config and arch detection")
added 107 to the default architecture list and to ARCHITECTURES_WITH_KERNELS, but not
to this one, so the normalization step still removes it.

-  set(ARCHITECTURES_COMPATIBILITY_BASE 80 86 90 100 120)
+  set(ARCHITECTURES_COMPATIBILITY_BASE 80 86 90 100 107 120)

Background and the fuller trace are in #19067.

Test Coverage

Configured with -DCMAKE_CUDA_ARCHITECTURES="90-real;100-real;103-real;107-real",
counting gencode flags across every generated flags.make:

	before	after
compute_90a	147	147
compute_100f	145	145
compute_103a	2	2
compute_107f	0	133

Nothing else changes, so architectures that already worked are unaffected.

A full --cpp_only build then completes and the resulting shared library really does
carry SM107 code. Same tree, same flags, only this one line differing:

	before	after
libtensorrt_llm.so size	1,929,033,784	1,968,622,760
sm_90a ELFs	720	720
sm_100 ELFs	110	110
sm_89 / sm_86 / sm_80 / sm_120a / sm_100a	36 each	36 each
sm_107 ELFs	0	72

(cuobjdump --list-elf, counted on the linked library.) Every previously present
architecture is unchanged; the 40 MB difference is the SM107 code.

For a single target compiled by hand with the flags CMake generated for it
(tensorrt_llm/common/cudaFp8Utils.cu):

--generate-code=arch=compute_90a,code=[sm_90a]
--generate-code=arch=compute_100f,code=[sm_100f]
--generate-code=arch=compute_107f,code=[sm_107f]

rc=0
cuobjdump --list-elf:  sm_90a  sm_100  sm_107

Environment: nvcc 13.4 V13.4.59, gcc 13.3.0, Ubuntu 24.04, no GPU used (compile only).

A question rather than an assumption

I cannot tell whether the fold is currently deliberate. generate_kernels.py contains no
occurrence of 107 and routes it into the SM100 family through range(100, 110), and
the Rubin kernels that do ship are precompiled sm107a cubins rather than sources. If
the intent is "build SM100 code and run it on Rubin until Rubin sources land", then this
PR is premature and the real issue is only that -a 107-real silently does nothing.

Please close this if that is the case. I opened it because the one-liner is small enough
to judge quickly, not because I am confident it is wanted.

PR Checklist

• PR title follows the format
• Commit is signed off (DCO)
• An issue was filed first ([Bug]: -a 107-real is silently folded to 100, no SM107 code is generated #19067)

Dev Engineer Review

Adds architecture 107 to ARCHITECTURES_COMPATIBILITY_BASE. This preserves -a 107-real and enables SM107 code generation instead of normalizing to SM100. The change is limited to one CMake list and does not affect existing architectures.

QA Engineer Review

No test changes.

Per-File QA Perspective

• cpp/cmake/modules/cuda_configuration.cmake: Verify SM107 output for -a 107-real and unchanged output for existing architectures. Reported validation showed 133 compute_107f flags, 72 linked-library SM107 ELF entries, and a successful CUDA 13.4 compile-only build.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Enterprise

Run ID: 3e01d0f0-e579-4fe9-ac10-2abf53c5434c

📥 Commits

Reviewing files that changed from the base of the PR and between 31b47b6 and 7dbeb18.

📒 Files selected for processing (1)

• cpp/cmake/modules/cuda_configuration.cmake

Included review availability: Your plan provides up to 12 included reviews per hour; 11 remain after this review.

---

Walkthrough

The CUDA configuration now includes architecture 107 in the compatibility base list used during architecture normalization.

Changes

CUDA architecture compatibility

Layer / File(s)	Summary
Add SM 107 compatibility target cpp/cmake/modules/cuda_configuration.cmake	The compatibility base architecture list now includes 107. This allows architecture normalization to use SM 107 directly.

Priority: ⬇️ Low

Estimated code review effort: 1 (Trivial) | ~3 minutes

Change: Bug fix

Suggested reviewers: atrifex

Merge Risk: ⚪ Minimal · up to 7dbeb

SM107 normalization now produces SM107 code as intended, while existing architectures remain unchanged.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description check	✅ Passed	The description clearly explains the normalization issue, the one-line fix, test coverage, build results, and checklist items. It includes the required Description, Test Coverage, and PR Checklist sec…
Title check	✅ Passed	The title follows the required ticket/type format and clearly states that architecture 107 is added so -a 107-real emits SM107 code.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0…
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

_{Comment @coderabbitai help to get the list of available commands.}

[zhangcl]

Adding 107 here means all kernels will be build for this arch, when enabled. That leads to longer build time and binary size. And not all kernels can benefit from targeting 107a. That's why 107 is not put here. Please refer to this comment in the original PR for more details.

To target 107a only for specific kernel, please refer to this comment.

[100milliongold]

Thanks for the detailed explanation, @zhangcl, and for linking the original discussion in #17336. You are right, and I am withdrawing this PR.

My premise was wrong, and I want to record exactly how I got it wrong so the next person does not repeat it.

What I measured, and why it was misleading

I concluded "no SM107 code is generated" from cuobjdump --list-elf reporting zero sm_107 entries. That tool does not distinguish family-specific cubins from arch-generic ones:

$ nvcc -gencode arch=compute_100,code=sm_100   -cubin k.cu -o plain.cubin
$ nvcc -gencode arch=compute_100f,code=sm_100f -cubin k.cu -o fam.cubin
$ cuobjdump --list-elf plain.cubin | grep -o 'sm_[0-9]*[af]*'   # sm_100
$ cuobjdump --list-elf fam.cubin   | grep -o 'sm_[0-9]*[af]*'   # sm_100   <- same

Both cubins are the same size, have identical ELF headers, identical .nv.compat sections, and nvdisasm prints .target sm_100 for both. Only arch-specific targets show a suffix (sm_100a, sm_107a). So --list-elf cannot answer the question I was asking it.

The build log answers it directly, and it was there the whole time:

ptxas info : Compiling entry function '..._Z...get_mla_metadata_kernel...' for 'sm_100f'

cuda_configuration.cmake already appends the family suffix after normalization:

list(APPEND CMAKE_CUDA_ARCHITECTURES_NORMALIZED "${CUDA_ARCH}f-real")

So -a 107-real normalizes to 100 and emits 100f, which is exactly the intended behavior described in #17336, not a missing entry.

Conclusion

Folding 107 into the 100 compatibility base is deliberate, and adding 107 to ARCHITECTURES_COMPATIBILITY_BASE would build every kernel for an architecture that 100f already covers, at the cost of build time and binary size. Closing.

I am opening a separate, narrower PR for one place where the family suffix is dropped for 10x architectures other than x00, which I believe is an unintended gap rather than policy. I will link it here.

[100milliongold]

Follow-up as mentioned above: #19095 — DeepEP drops the family/arch suffix for 10x architectures other than x00, so 103 and 107 reach it as bare targets while 100, 110 and 120 do not. Scoped to that one condition, no change to the compatibility base list.