[Bug] 2.7.1: Displays panel and "Show all resolutions" take minutes on 3440x1440@144 DP (2.6.6 was fine)

Aperta
  • Qualcosa non va?
#503 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
42/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
macos, rust
Ambito
backend

Direzione di ricerca

Start by tracing how the driver handles display mode enumeration and the work triggered when System Settings opens the Displays panel; the report says CoreGraphics enumeration itself is fast. Check the WindowServer cache exclusion and the refused zero-copy paths described in the issue. The issue gives no source files or tests; done means identifying and fixing the cause of the panel delay and confirming the panel and resolution list appear promptly.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Send logs report ID

NM-

Where does it go wrong?

On the desktop (flicker, lag, displays, sleep)

What happens

Regression: 2.6.6 was fine, 2.7.1 is slow. System Settings -> Displays spins on "Collecting display information" for a long time, and "Show all resolutions" then takes minutes to appear. The rest of the system stays responsive - only that one panel stalls. No deadlock, no kernel panic, no crash.

Hardware:

  • NVIDIA GeForce RTX 2060 (TU106), 6 GB
  • macOS 26.7.2 (build 25G332), SMBIOS MacPro7,1
  • Display: 3440x1440 @ 144 Hz over DisplayPort
  • Driver 2.7.1 - NVRM / NVAccel / NVRMFB / NVRMAGDC all loaded
  • boot-args: keepsyms=1 nvfb=1 nvaccel=1 gfxrst=4 amfi_get_out_of_my_way=0x1 amfi=0x80 revpatch=sbvmm,cpuname nvfbheads=4 -nvkmsnosmooth ipc_control_port_options=0 nvrmsettle=10000
What I checked

1. The shared shader caches are empty. Both directories carry the ownership and mode install.sh sets, yet hold no entries after four hours of use:

drwxr-xr-x  _windowserver  wheel  /Library/GPUBundles/nvmtl/aircache   0 entries
drwxr-xr-x  _windowserver  wheel  /Library/GPUBundles/nvmtl/spvcache   0 entries

nvmtl-allow.txt is the one from the package, unchanged - * then !WindowServer. So WindowServer is excluded from the shared cache it is meant to fill. The comment in install.sh says that without these caches, WindowServer "re-translates them from scratch at every start".

2. WindowServer's zero-copy paths are all refused - 18 lines in 37 seconds:

vk: vkAllocateMemory refused the imported host pointer 0x1824d0000 (26628096 bytes, memory type 2)
vk: host-pointer import refused - ptr 0x189260bc0 / size 27054080 are not both a multiple of 4096; that buffer is COPIED
buffer texture: refused on alignment - bind at 530992 (buffer 530688 + 304) vs alignment 32
newTiledTextureWithDescriptor: linear view refused -> copied texture (20x20 bpr 224; said once)
reflection: SimpleTextureFragment has no AIR - cannot be reflected

The refused offsets (304, 1872, 1968) and the 20x20 textures are the small masks and icons the settings UI draws, so every one of them falls back to a copy.

3. The panel extension blocks for about 6 seconds between its XPC connection and didBeginHosting, with no log output at all in between (measured from the unified log).

Extra data

CGDisplayCopyAllDisplayModes reports 85 modes for this display: 144 Hz is replicated on every resolution (including 640x480) and there is no HiDPI entry. Enumeration itself is fast - a standalone CoreGraphics tool gets the whole list in under a second - so the stall is not in producing the mode list, it is in what happens after.

Did you change anything yourself?

I moved NullMoth's NMXAudio out of /Library/Extensions so SimpleHDA could take over audio, and rebuilt the auxiliary kernel collection from /Library/Extensions following docs/MULTI-GPU.md. The four display kexts load from permanent paths and the GPU works normally.

Lingua principale
Rust
Stelle
2.5k
Fork
233
Merge medio
3g 14h
PR unite (30g)
14

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di nullmoth/nvidia-macos-driver

Tutte le issue di nullmoth/nvidia-macos-driver

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.