Date: 13 September 2026
Scope: Windows 10/11 64-bit international DCH WHQL Game Ready packages 610.88 (known good) and 616.92 (reported bad), inspected statically on macOS.
The evidence points to an R615 DisplayPort 2.x/UHBR display-stack regression, not a game profile, application, PNY board INF, or ordinary installer regression.
The highest-probability trigger is a new R615 policy which performs a display-head shutdown on more DP 2.x link-configuration transitions. In R610, shutdown was avoided whenever the candidate link's total data rate was at least the active rate. In R615, a DP 2.x connection avoids shutdown only when the whole target link configuration exactly matches the active configuration. NVIDIA added an internal compatibility switch named DP_LEGACY_HEAD_SHUTDOWN_POLICY for the old behaviour.
That change is a particularly close match for the affected ASUS ROG Swift OLED PG27UCWM: ASUS documents it as a full-bandwidth DisplayPort 2.1a UHBR20 (80 Gbit/s), 4K/240 Hz display. The unchanged HP display working by itself, while adding this particular DP 2.x sink reliably wedges the desktop, is strong connector-path evidence.
Two related R615 changes could contribute:
- Ordinary DP 2.x link training now has a 1,000 ms total fallback budget and can stop before another fallback attempt. A slow or marginal UHBR20 train can therefore finish without reaching a working lower link configuration.
- NVIDIA split much of the GSP payload into a separate
ucodes_ga10x.bin; NVIDIA's own extractor maps that payload to GB202, the RTX 5090 GPU family. The payload appeared by 616.56 and was revised again for 616.92.
Static inspection identifies the regression area and a strong lead, but cannot prove the final causal instruction without a kernel dump/ETL trace or a controlled A/B test on the affected hardware.
All installers came directly from us.download.nvidia.com.
| Version | NVIDIA package | Bytes | SHA-256 |
|---|---|---|---|
| 610.88 | official Windows package | 979,651,304 | 576a90c6f6eea47748db1defcbca1746c81fe4eb972f3132d30878778cee0b09 |
| 616.92 | official Windows package | 990,853,104 | 61f117423e8aeb5a966325030dfcd5379912990119a8e7f40d78dd6513b58b6a |
For first-bad bracketing, 616.56 and 616.64 were also downloaded and selectively inspected. Their package SHA-256 values are da50178def40a17c40d7b4622003b2073efd20c9422d0bb707bc7e59e8cc4868 and 36584e5df1dc048df5c677e9591295b96b870e7a6a0ad1461457b89de8bc1b37 respectively.
The files were unpacked as archives; no Windows driver was executed on macOS.
NVIDIA's 610.88 release notes and 616.92 release notes disclose these component changes:
| Component | 610.88 | 616.92 |
|---|---|---|
| HD Audio driver | 1.4.5.7 | 1.4.6.3 |
| PhysX | 9.23.1019 | 9.26.0703 |
| CUDA | 13.3 | 13.4 |
| DCH Control Panel | 8.1.969.0 | 8.1.969.0 |
616.92 publicly lists three general fixes: browser flicker, virtual-display creation, and a Remote Desktop black screen. It lists no gaming bug fixes and no DisplayPort, UHBR, link-training, head-shutdown, GSP, or firmware change. The 616.56 and 616.64 notes are similarly silent. In other words, the public Game Ready notes do not describe the material display-stack changes present in the binaries/source.
The matching NVIDIA release families are Windows 610.88/Linux 610.57.04 and Windows 616.92/Linux 615.71.09, as shown in NVIDIA's R610 and R615 release pages. The R615 Linux changelog adds RmDisableDisplayGlitchPerfLimit, a display-clock power-management control which may reduce multi-monitor idle power at the cost of momentary glitches. Its documented default is unchanged, so it does not by itself explain the failure; the observed 70 W is more plausibly a consequence of the display/GSP path remaining busy after the wedge.
| Measure | Result |
|---|---|
| Files in 610.88 archive | 1,157 |
| Files in 616.92 archive | 1,167 |
| Common paths | 1,092 |
| Common paths with changed content | 462 |
| Common paths unchanged | 630 |
Display.Driver common paths |
261 |
Changed Display.Driver common paths |
230 |
The many top-level additions/removals are primarily NVIDIA App JavaScript/localisation churn. The consequential display-driver changes are:
nvlddmkm.syschanged from 120,332,520 bytes (c28fd719733f0af2e56d48ef0ef1abe67e6fa71972d870c2f03d2d66fcc509f0) to 113,949,416 bytes (85753a7ddbc8d44c1ecc370bf62b5c68c05022a6d7192034186c0ba93c316ba2).ucodes_ga10x.binanducodes_tu10x.binwere added; the monolithic GSP binaries became much smaller.nvdiagclt32.dll,nvdiagclt64.dll, andlibnvdiagclt.so.1were added.nvd3d12sc.dllandnvd3d12scx.dllwere removed.
For GA10x-family packaging, 610.88 contains an 84,306,072-byte gsp_ga10x.bin. In 616.92 that is a 27,043,992-byte GSP plus a 58,215,936-byte ucode payload. The combined payload is 953,856 bytes larger, so this is a firmware repackaging/revision, not simple deletion. The R615 NVIDIA source explicitly associates the GA102 ucode bundle with AD102, GH100, GB100 and GB202.
The PNY RTX 5090 device (10DE:2B85) maps to the same nv_dispi.inf installation section in both packages, and that section is byte-for-byte identical. There is no new 5090/PNY install policy or visible default DisplayPort registry setting in the INF. This rules the device-specific INF out as the proximate cause.
NVIDIA's open kernel source changes by 1,943 additions and 402 deletions across 40 src/common/displayport files between tags 610.57.04 and 615.71.09: official comparison.
R610 used this effective rule during a mode/link transition:
avoid shutdown when candidate total data rate >= active total data rate
R615 keeps that rule for DP 1.x, but overrides DP 2.x with:
avoid shutdown only when target link configuration == active link configuration
The implementation is visible in NVIDIA's ConnectorImpl2x::avoidHeadShutdownForLinkConfig. The adjacent registry-key definition explicitly describes the old policy and says the exact-match policy is the default.
This code and its diagnostic strings are present in the Windows 616.56, 616.64, and 616.92 nvlddmkm.sys files but absent from 610.88. That confirms the public cross-platform source change is incorporated into the Windows binary under investigation.
Why it fits: the reported failure is triggered by attaching the only full-rate DP 2.x/UHBR sink; it occurs independently of physical GPU DP socket; and output freezes at compositor level rather than inside a named game. A bad shutdown/restart sequence around UHBR reconfiguration can strand scan-out, link training, or a display lock while the GPU remains above idle power.
R615 defines a 1,000 ms total training budget. Before another fallback it predicts the next attempt's duration and abandons fallback if the remaining budget is too small.
This is a good explanation for a black screen after a slow/marginal UHBR20 train. It is a weaker standalone explanation for a complete compositor wedge, but can interact with the new shutdown policy.
R615's LinkConfiguration::enableFEC forces Forward Error Correction on for every 128b/132b (UHBR) link even when its caller passes false. This changes validation/training semantics specifically for DP 2.x links.
The GSP/ucode split also affects GB202 and its payload changed again between 616.64 and 616.92. It is therefore a genuine candidate for “works on earlier branch, wedges on later branch”, but static package layout alone gives less causal specificity than the exact DP 2.x policy change.
R615 also adds dead-AUX detection, an abort after repeated payload-table AUX failures, EDID recovery, and MST robustness work. Their code/comments describe preventing seconds-long lock holds and OS deadlocks, so they are more likely attempted safeguards than the source of this direct-SST UHBR failure.
| Rank | Candidate | Confidence | Reason |
|---|---|---|---|
| 1 | New DP 2.x exact-match head-shutdown policy | High | Exact connector-class match, introduced in R615, present in Windows binaries, compatibility switch supplied by NVIDIA |
| 2 | 1 s DP 2.x training/fallback budget | Medium | Exact UHBR path match; naturally explains failure to recover a working link |
| 3 | GB202 GSP/ucode repackaging and 616.92 firmware revision | Medium-low | Applies to RTX 5090 and changed in the bad package, but diff does not identify the faulty routine |
| 4 | Forced FEC for 128b/132b links | Low-medium | UHBR-specific semantic change, but likely a specification correction |
| 5 | INF/application/game-profile changes | Very low | RTX 5090 install section is unchanged and the fault is connector-dependent/system-wide |
- Reproduce with 616.56, then 616.64, then 616.92. The core DP 2.x changes already exist in 616.56; if only 616.92 fails, the later firmware/binary revision moves above the branch-wide policy as the leading suspect.
- On 616.92, reduce the PG27UCWM link below UHBR20 (or use HDMI/DP 1.4 mode) if the monitor exposes a safe OSD option. If the system survives, that isolates the 128b/132b DP 2.x path.
- Ask NVIDIA engineering/support to A/B
DP_LEGACY_HEAD_SHUTDOWN_POLICY=1. The source proves the switch exists, but its Windows registry location is not publicly documented; it should not be guessed on a production system. - Capture a complete kernel dump or ETL/NVIDIA display log during the hang, including DPCD/link-training events, and provide both display EDIDs. NVIDIA's display-driver log collection guide is the appropriate starting point.
616.92 contains a substantial, undocumented DP 2.x transition/link-training rework inherited from the R615 branch. The best-supported diagnosis is that the new DP 2.x head-shutdown policy mishandles a transition involving the PG27UCWM's UHBR20 link, potentially compounded by the new bounded-fallback training behaviour. The RTX 5090 firmware repackaging is the main alternative if hardware testing shows 616.56/616.64 remain good and only 616.92 fails.