AD103 / RTX 4080 (10de:2704) on AM5 X670E - measured working: 2.05x GEMM after unlock, plus BRIDGE-BME hit

[Jz-2317]

AD103 desktop (10de:2704) EFI chainload — working data point / 第二个 EFI 实测点

Title (if posted as discussion): AD103 desktop (2704) permanent EFI chainload — all seven green

Hardware / platform

• GPU: RTX 4080 (AD103), PCI 10de:2704, VBIOS 95.03.33.00.29, Windows driver 616.56
• Board: MSI MAG X670E TOMAHAWK WIFI (MS-7E12), BIOS 1.G2 (2024-11-28), UEFI, Secure Boot = Off, CSM off, dGPU direct output
• nv-uefi-unlocker v0.2.0, assets regenerated locally with make-usbroot.ps1 -Family ad102 (all SHA-256 verified)
• Deployment mode: installed on the ESP, permanent boot chain — bcdedit {bootmgr} device partition=T: / path \EFI\Boot\NVUNLOCK.EFI / timeout 0, then chainload to \EFI\Microsoft\Boot\bootmgfw.efi. Every boot re-runs the transaction (no flash, nothing persisted).

Judgement lines (this boot, full log attached)

BOOTER forensic: ... MAILBOX0=0x67b00001
POST-BOOT: FEAT_PLM=0xffffffff
POST-BOOT: WPRCFG=0xfffff0ff FBPA=0xffffff0f WPR=0xffffffff
SELECTOR RESULT: SS0=0x88888888 SS1=0x8
POST-FLR: verified (selectors survive AON)
TX: execution verified
HANDOFF-OUT: ... ss0_unlock=true ss1_unlock=true plm_open=true
CHAIN: loader found ... \EFI\Microsoft\Boot\bootmgfw.efi

Note: tu10x: plm=0xbadf5040 ss0=0xbadf5040 ss1=0xbadf5040 | tu10x_unlock=false in HANDOFF-OUT is expected on AD103 — that family does not read the TU10x registers, the three booleans are what matter.

Bridge BME fix confirmed on AM5 desktop

BRIDGE-BME: Some((0,0,1,1)) command 0x0003 -> 0x0007 — PR #5's automatic Bus-Master enable works on X670E too, restored afterwards, transaction unaffected. Same class as H310/B760/B850 in the README, adding an AM5/X670E data point.

Performance (4096-cubed cuBLAS soak, Windows, same card, before/after)

mode	unlocked-off	unlocked	ratio
FP16 / FP32 accumulate	85.9 TF	176.0 TF	2.05x
BF16 / FP32 accumulate	85.3 TF	174.0 TF	2.04x
FP8 e4m3	167.9 TF	303.9 TF	1.81x
FP16 / FP16 accumulate	170.0 TF	172.0 TF	1.01x (already full speed)

Power/thermals after unlock: FP16 soak avg 251 W / max 264 W; FP8 avg 294.8 W / max 304 W; 60-65 C, smclk 2805 MHz throughout, no downclock. Power limit untouched (default 340 W).

Summary for the matrix

AD103 desktop, second EFI-path machine (issue #8 was 4070 / 2709). Please upgrade 10de:2704 from "upstream silicon verified" to "measured working".

Full \loader.log of this boot is attached below.

Full \loader.log posted as follow-up comments (13.7k + 19.3k chars): part 1 / part 2.

[physicsdolphin]

Recorded and thank you for a thorough report - 2704 sits at ✅ first-hand verified in the compatibility matrix with Discussion #72 linked as the source, and your X670E data point is in the BRIDGE-BME root-cause document's affected-board list (which now reads "H310/B760/B850/X670E - four generations of desktop sockets all affected", making the "firmware policy, not vendor" argument even harder to argue with).

Two things worth closing the loop on:

1. Your parenthetical about the tu10x: cluster reading 0xbadf5040 on AD103 was ahead of us - the same untagged-booleans problem later bit issue [Bug] RTX 2080 Ti 22GB（1e04）：HANDOFF-OUT 状态判读与交接问题 #102 (a Turing card chased as an EFI-side failure), and HANDOFF-OUT is now family-tagged on main (tu10x: / ga/ada: prefixes).
2. The ESP-resident bcdedit chain you built is your own deployment choice and clearly works - noted as a field data point for that shape, though the project itself keeps shipping the USB-stick flow.

The permanent-boot re-run model you documented (every boot replays the transaction) is exactly the intended volatility semantics, and the PR #5 bridge Bus-Master fix confirming on AM5/X670E is now in the root-cause doc. Thanks for the complete logs.