RTX ASUS TUF 4070 Ti OC (AD104, 10de:2782) on ASRock X570 — measured working: FP16 ×1.72 / BF16 ×1.79

[kaitomugui]

RTX ASUS TUF 4070 Ti OC (10de:2782) — first full end-to-end success for this exact PCI ID

First complete transaction + readback + before/after performance numbers for
10de:2782 (RTX 4070 Ti, AD104).

Hardware / platform

• GPU: RTX ASUS TUF 4070 Ti OC (AD104), PCI 10de:2782, VBIOS 95.04.3C.80.55, Windows
  driver 581.57
• Board: ASRock X570 Creator, AMD platform
• Second GPU present but excluded by tx-select-bdf.txt: Tesla V100-SXM2-16GB
  at 0000:03:00.0 (pre-Turing, not a transaction target)
• Display: single monitor, DisplayPort, directly on the target card
  (VideoOutputTechnology = DISPLAYPORT_EXTERNAL, confirmed in Windows before
  the attempt). No black screen beyond the expected brief GOP-disconnect
  window.
• Tool base v2.1.9, asset family ad102, unlock mode
  (v67-ad102-four-plm.bin present, not chain-replay). All ten package files
  verified against SHA256SUMS.txt before staging.

⚠️ Not a stock v2.1.9 binary. EFI\BOOT\BOOTX64.EFI here is a locally
modified build, SHA-256 D56638AA49D1B13B253CDBDC310DAD9C9E0237004945CC83B6EB7D500F563F91.
It will not match SHA256SUMS.txt from any official release — that's
expected, not tampering. Four source changes vs. upstream main at the time
of this build, all on a two-GPU box (this 4070 Ti + the V100 above), which
is what motivated #4:

1. a mandatory pre-transaction identity gate (PCI/BD
2. a STOP-on-hard-failure policy (no auto emergency_flr, no trying the
   next card, no auto chain-load on a genuine transaction failure — was:
   all three happened automatically);
3. BridgeMaster (bridge bus-master guard) now releases explicitly only on
   the clean success tail, instead of an implicit Drop that could clear it
   mid-failure while the booter might still be doing DMA;
4. the read-only M1 SAMPLE phase now honors tx-select-bdf.txt too.
   Upstream's SAMPLE phase always ran against gpus.first() — whichever
   NVIDIA card the firmware happened to enumerate first, regardless of the
   selector file. On a single-GPU box that's harmless; on this two-GPU box
   it meant the read-only cold-state sweep could silently run against the
   V100 instead of the 4070 Ti depending on enumeration order, while the TX
   phase correctly honored the selector. Generalized select_tx_targets
   into a select_targets used by both phases, so SAMPLE and TX always
   agree on the same pinned card.

All seven asset .bin files + their SHA256SUMS.txt entries are
untouched/stock (only BOOTX64.EFI differs). Happy to post the diff against
upstream main if useful, or open it as a separate PR for review.

Judgement lines (this boot, full log available on request)

SELECTOR RESULT: SS0=0x88888888 SS1=0x8
POST-FLR: verified (selectors survive AON)
HANDOFF-OUT: ss0=0x88888888 ss1=0x8 readout1=0x00000000 feat_plm=0xffffffff
wpr2_hi=0x0 pmcsr=0x0008 dstate=D0
| ss0_unlock=true ss1_unlock=true plm_open=true
TX: multi-GPU pass complete (1 target(s) processed)
CHAIN: ... StartImage the preloaded '\EFI\Microsoft\Boot\bootmgfw.efi'

Clean chain-load, Windows up normally, nvidia-smi saw both GPUs immediately,
same driver (581.57 — this is firmware, not a driver swap).

Performance (cuBLAS dense GEMM via PyTorch, 8192³, same card, before/after)

precision	locked	unlocked	ratio
FP32 (SIMT, control)	27.52 TF	27.89 TF	1.01× (unchanged, as expected)
FP16	80.35 TF	137.97 TF	1.72×
BF16	80.44 TF	144.13 TF	1.79×
PCIe H2D / D2H / VRAM D2D	23.3 / 18.3 / 378 GB/s	23.3 / 17.3 / 379 GB/s	unchanged

Post-unlock nvidia-smi: driver unchanged, D0, 45 °C, clocks normal — nothing
abnormal.

| this card, 4070 Ti, AD104 2782 | ×1.72 | ×1.79 |
| 4070, AD103 2709 (#8) | ×2.03 | ~2.0× |
| 4070 Ti SUPER, AD103 2705 (#36) | ×2.02 | — |

Lines up closely with the other AD104/AD106 cards (×1.4–1.8), noticeably below
the AD103 cards in this table (~×2.0) — consistent with the clamp being set
per-SKU rather than purely per-die.

Summary for the matrix

10de:2782 works end to end: identity-gated, marker + PLM + selector-survives-FLR
all confirmed by readback, clean handoff. Please upgrade it from "pending
retest" to "measured working".

Happy to attach the full loader.log and the raw benchmark output as follow-up
comments if useful.

硬件与平台

• 显卡：RTX ASUS TUF 4070 Ti OC（AD104），PCI 10de:2782，VBIOS 95.04.3C.80.55，Windows
  驱动 581.57
• 主板：ASRock X570 Creator，AMD 平台
• 第二张卡存在但被 tx-select-bdf.txt 排除：Tesla V100-SXM2-16GB，
  0000:03:00.0（Pre-Turing，非事务目标）
• 显示器：单屏，DisplayPort，直连目标卡（Windows 侧确认
  VideoOutputTechnology = DISPLAYPORT_EXTERNAL）。除预期的 GOP 断连短暂黑屏
  外，没有黑屏。
• 工具版本 v2.1.9，资产家族 ad102，解锁模式（v67-ad102-four-plm.bin
  在场，非 replay）。十个包文件在上机前全部与 SHA256SUMS.txt 校验通过。

⚠️ 不是官方 v2.1.9 发布版二进制。 这里的 EFI\BOOT\BOOTX64.EFI 是本地修改版，
SHA-256 为 D56638AA49D1B13B253CDBDC310DAD9C9E0237004945CC83B6EB7D500F563F91，
不会与任何官方 release 的 SHA256SUMS.txt 匹配—
V100）上做的，第 4 条正是因此而来：

1. 强制的事务前身份门（PCI/BDF + 固定 1 MiB PROM 窗口 SHA-256，类型层面强制——
   run_transaction 不传入已验证的 VerifiedIdentity 编译都过不了）；
2. 硬失败即 STOP 的策略（不再自动跑 emergency_flr、不再尝试下一张卡、
   不再自动链式启动——这三件事以前都是自动发生的）；
3. BridgeMaster（桥接总线主控守卫）现在只在成功的干净收尾路径显式释放，
   而不是靠一个隐式 Drop，后者可能在失败中途、booter 仍在做 DMA 时就把它清掉；
4. 只读的 M1 SAMPLE 阶段现在也遵守 tx-select-bdf.txt。 上游的 SAMPLE
   阶段一直是对 gpus.first() 跑——固件枚举到的第一张 NVIDIA 卡，不管选择器文件
   写的是什么。单卡机器上这无所谓；但在这台双卡机器上，这意味着只读冷态扫描
   可能悄悄跑到 V100 身上而不是 4070 Ti，取决于枚举顺序，而 TX 阶段却正确地
   遵守了选择器。把 select_tx_targets 泛化成两个阶段共用的 select_targets，
   让 SAMPLE 和 TX 永远认定同一张钉住的卡。

七个资产 .bin 文件及其在 SHA256SUMS.txt 里的条目都未改动（只有
BOOTX64.EFI 不同）。如果有用，可以贴出对比上游 main 的 diff，或者单独开
一个 PR 供 review。
POST-BOOT: FEAT_PLM=0xffffffff
SELECTOR RESULT: SS0=0x88888888 SS1=0x8
POST-FLR: verified (selectors survive AON)
HANDOFF-OUT: ss0=0x88888888 ss1=0x8 readout1=0x00000000 feat_plm=0xffffffff
wpr2_hi=0x0 pmcsr=0x0008 dstate=D0
| ss0_unlock=true ss1_unlock=true plm_open=true
TX: multi-GPU pass complete (1 target(s) processed)
CHAIN: ... StartImage the preloaded '\EFI\Microsoft\Boot\bootmgfw.efi'

链式启动干净，Windows 正常起来，nvidia-smi 立刻看到两张卡，驱动不变
（581.57——这是固件层面，不是换驱动）。

算力实测（cuBLAS dense GEMM，PyTorch，8192³，同卡解锁前后）

精度	未解锁	解锁后	倍率
FP32（SIMT，对照组）	27.52 TF	27.89 TF	1.01×（符合预期，未变）
FP16	80.35 TF	137.97 TF	1.72×
BF16	80.44 TF	144.13 TF	1.79×
PCIe H2D / D2H / VRAM D2D	23.3 / 18.3 / 378 GB/s	23.3 / 17.3 / 379 GB/s	未变

解锁后 nvidia-smi：驱动不变，D0，45°C，频率正常——没有异常。

与矩阵里其它 AD10x 数据点的对照

	FP16	BF16
4070 SUPER，AD104 2783（#3）	×1.42	×1.51
4060 Ti 8GB，AD106 2803（PR #87）	×1.70	×1.70
本卡，4070 Ti，AD104 2782	×1.72	×1.79
4070，AD103 2709（#8）	×2.03	~2.0×
4070 Ti SUPER，AD103 2705（#36）	×2.02	—

与其它 AD104/AD106 卡（×1.4–1.8）高度吻合，明显低于表中的 AD103 卡
（约×2.0）——与"钳制是按 SKU 设的，不只是按 die"的推测一致。

给矩阵的结论

10de:2782 全链可用：身份门通过、marker+PLM+选择器穿 FLR 全部读回确认、
交棒干净。请把它从"定级待复测"升级为"实测可用"。

如果有用，可以在跟帖里附完整 loader.log 和原始基准输出。

[physicsdolphin]

@JerryHelper Thank you for this exceptional report — and for offering the diff. As promised, we ran the code review against current main today (verified at 7b28403). Verdicts, with line references:

1. SAMPLE phase ignores tx-select-bdf.txt — confirmed, real bug. loader/src/main.rs:144-149 runs the read-only M1 sweep against gpus.first() unconditionally, while the TX phase goes through pci::select_tx_targets(gpus) (main.rs:236). On a multi-GPU box the read-only cold-state sweep can therefore pin a different card than the transaction. We're adopting this as a defect — your select_targets generalization is the right shape.

2. BridgeMaster guard released on implicit Drop — confirmed as a real tightening of the ae7b128 shape. Current main binds _bridge_master at function scope (loader/src/tx.rs:1099-1104) after the #98 regression round (4b7e955 moved it into the else block; ae7b128 restored function scope). But function scope still means release at return, including failure returns — and a failure return can coincide with SEC2 still having DMA in flight. Explicit release on the clean success tail closes that window. We'd like this in the PR for line-by-line review.

3. STOP-on-hard-failure — factually accurate, but this one is policy, not a defect. Your description of current behavior is correct: auto emergency_flr on failure (main.rs:441), the target loop continues to the next card (fail-don't-block is the deliberate multi-GPU default), and CHAIN proceeds regardless. The current tradeoff buys half-transaction recovery and a guaranteed boot over observability; your STOP variant trades back. We'd rather take this up as an opt-in design discussion inside the PR than flip the default silently.

4. Typed identity gate (VerifiedIdentity) — confirmed absent in main, and welcome. Nothing equivalent exists today; a compile-time-enforced identity with a fixed 1 MiB PROM-window SHA-256 is exactly the type-level realization of our per-card identity rule. Happy to see it in the PR.

So: please do open the PR. Suggested shape: your (4) SAMPLE fix and (3) guard release as the fix core; (1) identity gate and (2) STOP policy as opt-in switches behind markers/config, so the reviewed defaults stay the field-proven ones. We'll audit it with the same discipline as the #41–#60 batch.

Two notes for the record: your build SHA (d56638aa…) is cited in the compatibility matrix 2782 row with the modified-binary caveat — an official-binary rerun (or a merged PR followed by a rerun) upgrades the tier; and #105 (PNY/H670, replay-mode black screen) stays a separate triage — same ID, different mode, no contradiction with your result.