NVIDIA on macOS: what moved, 2026-10-22 evening to 2026-10-23

thanhnndev's ASUS GA403WM (Ryzen AI 9 HX 370, Radeon 890M panel, RTX 5060 Laptop on HDMI) is working on the mirror image of our X6: NVIDIA composites, the iGPU panel scans out (our NvGfx #16). The AGDC and IOPresentment layer in between is the same for both, which is where their last two days overlap with our I-107.

• NMXAGDC (503ad770, branch ci/nmxaccel, kexts/NMXAGDC): an AppleGraphicsDeviceControl service for the 890M framebuffer, derived from NullMoth's NVRMAGDC like our XeGfxAGDC. It starts itself at load, polls for the NMXGPUFB service, answers vendor info, the 0x980 slot table (from IOFBDependentIndex), and 0x921 and 0x711 type 0x10 through the K5 helper. Same selectors as ours, built a day apart from the same IOPresentment reverse engineering (their Step64, our N-249).
• Step65 result (b7fd593a): AGDC up, IOPresentment opened the AMD pipe for the first time, then WindowServer sent 0x2001, 0x925 and 28 times 0x711, all refused, no transaction ever, and the machine froze 3 s later with no panic. Our N-258 ws.txt shows the identical post-open sequence (0x2001 x3, 0x925 x2, 0x711 x28, iop_ok 0); our 425 frames came through the legacy surface-swap copy, not IOPresentment. Their freeze is not our I-108 (ours was a CoreAnimation push_surface abort after fence timeouts, cured in N-258 with NVMTL_WS_WAIT_COMPLETION=1). High.
• The piece we lack: e196ab19 (branch codex/nmx-agdc-clientset-trace) acknowledges 0x2001, the 4-byte "client set" WindowServer sends right before Unable to get AGDC information. On their earlier Tahoe hybrid runs (890M-TRACE Step55/56) CoreDisplay only started submitting display-pipe transactions after 0x2001 was accepted. It is a 19-line change in nvrm-agdc.cpp, the file XeGfxAGDC is built from, plus entry counters at initFramebufferResource, validateTransaction, isTransactionComplete and performTransaction in nvrm-accel.cpp. Untested on their own NMX stack (Step67 never reached the pipe: amdgpu PSP LOAD_IP_FW failed). Medium that it starts transactions on ours.
• Keep refusing the rest: their Step07 measured that answering the non-0x10 0x711 types with success and count 0 breaks pipe open, and Step22 decodes the 28 queries (14 plane-capability types, two passes: CSC, gamma, scaler, rotation, HDR, 3D LUT, cursor and so on). Claiming them moves colour stages into the pipe, which a copy path would then have to apply.
• Plugin vendor claim (e95984f0): in WindowServer the plugin now defers a non-NVIDIA accelerator claim when an NVAccel exists. Cause (Step62): Tahoe's CoreDisplay asserts "Failed to create MetalDevice (null)" only for a display that has a display pipe. Our fork still has first-wins g_vendor (plugin/nvmtl_vk.c:86, NvGfx #18 blocker 4). Their rule, prefer NVIDIA, is right for #16 and wrong for X6; the general rule is that the accelerator owning the main display's framebuffer claims WindowServer. High.
• A lead to check (Step64, Low): UseIOPresentment() is true only while every GPU vendor in the framebuffer list has its useIOP_on{IG,NVIDIA,AMD,APV} default set. Our display is vendor IG. If Tahoe's IG default is off, no AGDC change will produce transactions and the swap copy is the ceiling.
• What we have that they lack: XGDR (libdrm relaying ioctls through the accelerator user client when /dev/dri is refused, our I-106 fix), which their Step61/63 name as the blocker for the other direction, and the NVMTL_WS_WAIT_COMPLETION finding.

Licences: the kext files are PolyForm Noncommercial (reusable in the NvGfx fork with credit, ideas only for XeGfx); the ga403wm step logs and scripts are Clear BSD.

• HiDPI at high refresh (#360, #354, #359). Collecting every switchMode line in those threads (GA106 on two machines, AD104, TU116) next to ours (GB206), one rule sorts every reported pass from every refusal: the desktop's own pixel rate, width x height x refresh. Every pass is at or below about 1.16 Gpx/s (3360x2100 at 165 Hz), every refusal at or above about 1.37 Gpx/s (3840x2160 at 165 Hz). The downscale ratio alone, the pixel clock alone and ratio x pclk do not sort them. The refusal comes from NVKMS's applyModeSetConfig test, not from NVRMFB's own checks. Our GB206 has committed 3360x2100 at 165 Hz on fork builds 2.4.1 and 2.4.3; 3840x2400 and 4096x2560 validate and are listed but have not been switched yet, so we have no GB206 point above the band. Medium.
• Override format by macOS version (#354): 12-byte scale-resolutions entries list on 26.7.1 (us, jixx-choi on a Blade 18); on 15.8.1 bywanfeng found only the 16-byte form works. High for both, one machine each.
• Scaled modes at high refresh on desktops (#359): setDetailedTimings keeps the first 64 of the modes macOS offers; with 536 offers the 180 Hz scaled modes start at entry 307 and are all dropped. Not our case (our panel offers 52). High.
• Blocky backdrop blur (#363): RTX 3080, macOS 15.8.1, stock 2.5.3. The same class as our Dock blocks (a small blurred backdrop enlarged 32x), now seen on Ampere and Sequoia, so it is not fork-, Blackwell- or Tahoe-specific. Whether current builds still show it on our machine is not measured. Medium.
• Chrome 155 Skia Graphite flicker (#367): a fourth card (RTX 4080 Laptop) where disabling Graphite fixes it, after #302, #333 and our Discord test on PR #348. Medium.
• Display audio pins (PR #366): matches each external display to its HDA pin by ELD. On an internal panel it only adds a gated no-op on display wake and hotplug; nothing we rely on changes. High on the diff, not booted by anyone yet.
• WindowServer after wake (#353): a SIGSEGV 5 s after wake where -[NVMTLCommandQueue commandBuffer] returned nil (backend down) and SkyLight recursed until the stack guard. Why the backend was down is not in the report. Low.

Game-5040 (HP OMEN 16, RTX 5070 Laptop, NullMoth 2.5.2, nvrmacpibl=1) found that brightness is not kept across boots and jumps to maximum a few hundred ms after a display wake. Their MIT watchdog in tools/brightness holds it down; the likely mechanism is AppleBacklightDisplay's full-power request applied literally, which open PR #312 addresses with a saved target. Observation High, mechanism Medium.

• mickys/nvidia-macos-driver stages nine plugin changes on 2.5.3 as PR branches: one VRAM import per IOSurface shared between wrappers, capture ordering, reader skip and smaller NVRMFB desktops as real modes. Measured on an RTX 4090 in KVM. Medium.
• NVIDIA released 595.112.07 (R595 production branch) and 595.44.16 (Vulkan developer beta). Neither changes anything for GB206; 2.5.x builds on R615 (615.78.08). The 615.71.10 datacenter build fixes a Blackwell memory-system hang; whether 615.78.08 already has it is unchecked.

• WindowServer compiles shaders on its compositor thread (#370, RTX 2070 Super, Sequoia 15.8.1). In 317 of 353 samples the coreanimation.pipelines thread is in create_fragment_shader, through nvmtl_translate_with_fc_cached and metal2vulkan, and the cache writes (writeToFile, fsync) happen on that same thread. Scanout is fine (30,397 of 30,399 flips hit). It was worse on some boots and better after logging out. That fits our slow drags in the first three minutes after login (NvGfx #11) and the shader re-hashing in #6: the spindump we still owe on #11 should look for this stack. High on their data, Medium that it is our cause.
• A buffer overrun in NVMTL (#374): llama.cpp faults in -[NVMTLCommandBuffer(EventSubmission) nvmtlAdvancePart] inside a memmove, always at an address ending in 0x5a0, after the Metal 4 tensor library fails to translate. Not one of our problems yet. Medium.
• WindowServer dies after wake (#353): SkyLight's RenderEncoder and SetScissor recurse about 100 frames deep with NVMTLCommandQueue commandBuffer on top. Our reading, not the reporter's: the queue hands back nil after wake and SkyLight retries forever. Low.
• mickys 2.5.3-mickys.8 (release, afa361d): NVAccel's page-off now waits for the GPU without holding the accelerator lock. It only fires when a CPU lock meets a pending GPU write (screen capture), and the measured gain is small, so it is a weak match for our drag stalls. Two of the fork's upstream candidates fit better: descriptor masks (2.2 million descriptor writes a second down to 35 thousand) and the async CPU-surface upload (WindowServer system CPU 28 % to 7 % at 4K). PolyForm Noncommercial, like upstream. Low to Medium.
• Display pipe armed too late (11f899e, d31e5dc). On an AMD 890M the NMX pipe arm gave up after 30 s while WindowServer opened the framebuffer at about 45 s, leaving a CPU readback of every frame. A longer retry still armed 2 ms late, so the next change publishes the scanout before open(). For our Intel panel work (NvGfx #12) the check is whether any arm or retry window ends before WindowServer opens the framebuffer. High on the diagnosis, the second fix untested.
• kmutil recipe confirmed (ccce493): the aux collection rebuild worked all along; their own check failed because sudo mktemp -d makes a 0700 root directory the user cannot list. Our install script runs kmutil as root and is not affected. High.
• Netflix error M7702-1003 on #333 is Netflix pointing at Chrome's Widevine module, not at the graphics driver (Netflix help). Prime and Disney+ play on the same setup. Medium.
• New project: MegaMind2566/Lenovo-IdeaPad-S540-15IWL-GTX-OSX86, a GTX 1650 Max-Q port paused before RM and GSP init, with a written port assessment.