SM103 / SM110 / SM120 / SM121

nvlink v13.0.88 registers four additional Blackwell-family architectures beyond the base SM100 datacenter target. All four share the "Blackwell" family name string at 0x1D40B6E, all use the 128-bit SASS instruction encoding defined by the SM100 ISA, and all reuse SM100 infrastructure for encoding, decoding, and descriptor initialization. The differences between them are confined to three areas: the architecture profile metadata (SM number, __CUDA_ARCH__ define, variant suffixes), the finalization compatibility remapping table, and the capability bitmask used to gate feature subsets during JIT re-finalization.

This page documents the profile registration, dispatch table sharing, finalization remapping, and capability bitmask system for sm_103, sm_110, sm_120, and sm_121 as observed in the binary.

Architecture Identity Matrix

Every architecture stores its ISA class as a (profile_sm_NNN)->isaClass string rather than a hardcoded human-readable name like "Hopper" or "Turing". This indirection means the ISA class is resolved at runtime through the profile object's field pointer rather than being a compile-time constant. The family name "Blackwell" is shared across all five 1xx architectures (a single rodata string with xrefs from all five registration blocks in sub_484F50).

Sub-variant Registration

Each of the four architectures registers three sub-variants (base, a, f) through the profile database initializer sub_484F50. The a suffix enables the full accelerated feature set; the f suffix marks the forward-compatible subset. For each base architecture, the database creates nine profile objects: three real (sm_NNN, sm_NNNa, sm_NNNf), three virtual (compute_NNN, compute_NNNa, compute_NNNf), and three LTO (lto_NNN, lto_NNNa, lto_NNNf).

Registration Order

The architectures are registered in sub_484F50 in the following order within the Blackwell block, determined by the address order of their string references:

1. sm_100 / sm_100a / sm_100f (xrefs at 0x485A..)
2. sm_110 / sm_110a / sm_110f (xrefs at 0x485E..)
3. sm_103 / sm_103a / sm_103f (xrefs at 0x4861..)
4. sm_120 / sm_120a / sm_120f (xrefs at 0x4865..)
5. sm_121 / sm_121a / sm_121f (xrefs at 0x4869..)

The ordering is notable: sm_103 is registered after sm_110, not after sm_100 as the numbering might suggest. This reflects the chronological order in which these targets were added to the compiler toolchain -- sm_110 (Jetson Thor) was defined before sm_103 (GB300 Blackwell Ultra), as confirmed by the xref address ordering in sub_484F50.

Rodata String Addresses

Dispatch Table Sharing

The SM dispatch table initializer sub_15C0CE0 registers seven callback function pointers per architecture into hash maps (qword_2A644B8 through qword_2A64488). The callbacks serve these roles:

Within each architecture family, all sub-variants share identical function pointers:

The encoding table accessor functions are small stubs (~100 bytes each) that return architecture-specific instruction encoding parameters. Each architecture gets its own encoding table accessor despite sharing the same underlying 128-bit instruction format. The differences between accessors encode per-architecture feature availability flags (e.g., which MMA variants are supported, which memory ordering modes exist).

Complete Encoding Table Map

Finalization Architecture Remapping

The finalization compatibility checker sub_4709E0 (2,609 bytes) and its companion sub_470DA0 (2,074 bytes) apply an internal architecture remapping table before performing compatibility comparisons. This remapping collapses certain architecture numbers into canonical equivalents:

The remapping uses a character-based encoding where each arch number maps to an ASCII character: 'd' (100), 'h' (104->120), 'g' (103), 'n' (110), 'y' (121). After remapping, the standard same-decade rule (arch / 10) determines family membership.

Remapping Semantics

The 104->120 remapping means that a cubin tagged with internal arch 104 is treated as sm_120-compatible for finalization purposes. Similarly, 130->107 places internal arch 130 into decade 10 (the sm_100 family), and 101->110 bridges internal arch 101 to the sm_110 family. These internal designations (101, 104, 130) never appear in user-facing --arch flags; they exist only within the finalization pipeline's compatibility-checking logic and represent early or experimental architecture IDs that were subsequently renumbered.

Special-Case Handling

sub_4709E0 contains explicit special-case logic for three architectures:

• sm_110: Direct match check outside the decade rule, because decade 11 contains only sm_110
• sm_121: Direct match check, because sm_121 shares decade 12 with sm_120 but has distinct finalization semantics
• sm_100: Family-head check for the entire 100-decade (sm_100, sm_103, sm_107)

The function returns a 5-way error code: 0 = compatible, 24 = null input, 25 = version too high (>0x101), 26 = incompatible architecture, 27-30 = type-specific incompatibility. The a1[3] byte selects among finalization class types 0-4 through the lookup table dword_1D40660[].

Capability Bitmasks

sub_470DA0 (can_finalize_with_capability_mask) extends the architecture check with a per-architecture capability bitmask. This function reads a mask pointer from a1+16, computes a target bitmask value based on the architecture number, and returns whether the required capabilities are satisfied.

Bitmask Assignment

The check evaluates (v12 & *v11) == v12 where v12 is the required bitmask for the target architecture and *v11 is the capability mask stored in the compilation unit. A compilation unit built with capability 1 (sm_100 only) cannot be re-finalized for sm_103 (requires bit 3) or sm_121 (requires bit 6). This mechanism controls which Blackwell sub-architectures a given compiled artifact is forward-compatible with.

Note that sm_120 does not appear in the bitmask table. Its finalization compatibility is handled entirely through the architecture remapping (104->120) and the same-decade rule (decade 12 includes both sm_120 and sm_121).

Capability Data in Profile Structs

Each profile struct stores three 128-bit capability vectors at offsets +80, +96, and +112 (loaded from xmmword_1D40F10--xmmword_1D40F70 via SSE instructions during sub_484F50 initialization). These vectors encode generation-specific feature bitmasks used by the finalization pipeline. The can_finalize_with_capability_mask function dereferences through the profile's capability pointer at a1+16 to reach these vectors.

Same-Decade Compatibility Groups

The same-decade rule (arch_number / 10, integer division) produces three distinct Blackwell compatibility groups:

Despite sharing the "Blackwell" family name string and the same ISA encoding infrastructure, code compiled for sm_100 cannot run on sm_120 -- the decade boundary is a hard compatibility wall. The family name is informational only; actual compatibility is governed by the decade rule and the finalization remapping table.

SM101/SM110 Cross-Mapping Bridge

The compatibility checker sub_4878A0 contains a special bidirectional bridge between SM101 and SM110. When either the source or target architecture is 101 or 110, the normal same-decade comparison is bypassed. SM101 is an internal designation that maps to the sm_110 family (confirmed by the 101->110 remapping in sub_4709E0). This bridge allows artifacts tagged with the internal arch 101 to finalize for sm_110 and vice versa.

Instruction Encoding Sharing

All five Blackwell-family architectures (sm_100 through sm_121) share the same 128-bit SASS instruction encoding infrastructure documented on the SM100 Blackwell page. The 4,236 template-instantiated encoder/decoder/descriptor functions at 0x620000--0xF15A50 are common to all 1xx targets. The per-architecture encoding table accessors (slot 3 in the dispatch table) return architecture-specific parameters that modify which instruction families are available, but the encoding format itself is identical.

Shared Components

Per-Architecture Differences

The encoding table accessor functions (slot 3) return different parameter sets that control feature gating at the instruction level. While the exact parameter layouts have not been fully decoded, the pattern is consistent: each accessor populates a small structure (8-32 bytes, exact size not determined) that tells the encoder/decoder which instruction families and sub-opcodes are valid for the target architecture.

This means sm_103 (GB300) may support additional MMA instruction variants compared to sm_100, and sm_120 (consumer) may lack certain datacenter-specific instructions present in sm_100. The instruction format is the same; only the set of valid opcodes within that format varies.

Compiler Backend Sharing

The SM-specific compiler backend functions (instruction selector, peephole optimizer, legalization passes) are selected through the dispatch table rather than duplicated per architecture. The backend at 0x1782540--0x17B9300 is shared across all 1xx targets, with per-architecture behavior controlled through the dispatch table callbacks and the encoding table parameters.

Key shared backend functions:

SM-Specific Codegen Options

The per-SM codegen option handler sub_15C2E90 processes SM-specific compilation flags via string comparison dispatch. These options are common to all Blackwell targets:

Key Functions

Observations

1. No separate ISA definition -- sm_103, sm_110, sm_120, and sm_121 do not define their own instruction encoding/decoding tables. They reuse the SM100 infrastructure entirely. The per-architecture differentiation happens through small encoding-table accessor stubs and capability bitmask checks, not through separate code.

2. Heterogeneous numbering -- The five Blackwell architectures span three decades (10, 11, 12), creating three distinct compatibility groups despite sharing a single ISA. The three decades correspond to substantially different silicon configurations (datacenter, automotive/embedded, consumer) even though the instruction set is common.

3. Internal designations -- The remapping table reveals three internal architecture numbers (101, 104, 130) that do not correspond to any user-visible sm_ target. These are development or pre-release designations that were renumbered before public release.

4. Asymmetric bitmasks -- The capability bitmask values are non-sequential (1, 2, 8, 64) with gaps at 4, 16, and 32. This leaves room for future architectures to be inserted at those positions without renumbering existing masks.

5. Registration order anomaly -- sm_103 is registered after sm_110 in the database initializer, suggesting sm_110 (Jetson Thor) was added to the compiler toolchain before sm_103 (Blackwell Ultra GB300) despite sm_103 having a lower SM number.

6. sm_120 bitmask absence -- sm_120 has no entry in the capability bitmask table at sub_470DA0. Its finalization compatibility is handled solely through the remapping rule (104->120) and the same-decade rule. This may indicate that sm_120 was designed from the start to be the "base" consumer architecture within decade 12, with sm_121 being the enhanced derivative.

Confidence Assessment

For general Blackwell architecture details, see the ptxas wiki: Blackwell. For SM120 consumer target specifics, see cicc wiki: SM120.

Cross-References

nvlink Internal

• SM100 Blackwell -- base Blackwell ISA and encoding shared by all four architectures
• Architecture Profiles -- profile registration for sm_103/110/120/121
• Compatibility -- finalization compatibility and same-decade rules
• Architecture Dispatch -- per-architecture vtable entries (all four share SM100 codegen)
• Mercury Overview -- Mercury encoding default for all Blackwell-family targets

Sibling Wikis

• ptxas: Blackwell -- standalone ptxas SM100+ target support (includes SM103/110/120/121)
• cicc: SM100 Blackwell -- cicc compiler Blackwell target
• cicc: SM120 -- cicc compiler SM120 consumer target