Environment
- macOS: Monterey 12.7.2
- OpenCore: (0.9.6 (REL-096-2023-11-06))
- Lilu: 1.7.2
- WhateverGreen: 1.7.0
- SMBIOS: MacPro7,1
- CPU: AMD Ryzen 9 5950X (16C/32T)
- GPU: AMD Radeon RX 6800 XT (Navi 21, 16 GB VRAM)
- Boot args:
npci=0x2000 agdpmod=pikera brcmfx-country=#a watchdog=0
- Display: 120 Hz, connected via DisplayPort
- displaysleep: 15 minutes
Description
The total VRAM address pool (calculated as inUseVidMemoryBytes + vramFreeBytes from ioreg PerformanceStatistics) continuously shrinks over time after a fresh boot. This is not an increase in VRAM usage — the entire addressable pool decreases, indicating that allocated VRAM blocks are never returned to the driver's free pool.
After approximately 70 minutes of idle/light desktop use, the total pool shrinks from ~16.2 GB to ~7.5 GB (a loss of ~8.7 GB). The system then exhibits severe UI lag: typing delay, Dock animations freeze, System Preferences bounces for a long time before opening, and menu clicks respond slowly.
When the display enters sleep and subsequently wakes, the VRAM pool is fully reset to ~16.3 GB, and performance temporarily returns to normal. However, the shrinkage immediately resumes after wake.
Quantitative Data
VRAM pool total over time (sampled every ~21 seconds via ioreg -l | grep PerformanceStatistics):
| Time (CST) |
VRAM Used (MB) |
VRAM Free (MB) |
Pool Total (MB) |
Notes |
| 21:15 (boot) |
306.8 |
15,915.2 |
16,222 ✅ |
Fresh boot |
| 21:25 |
734.7 |
14,712.2 |
15,447 |
Slight decrease |
| 21:30 |
948.4 |
13,239.5 |
14,188 |
-2 GB |
| 21:40 |
688.8 |
12,662.2 |
13,351 |
-3 GB |
| 21:47 |
816.0 |
10,091.5 |
10,908 |
-5.3 GB |
| 21:55 |
1,191.6 |
7,936.4 |
9,128 |
-7 GB |
| 22:00 |
1,433.1 |
6,262.9 |
7,696 |
-8.5 GB |
| 22:07 |
1,544.0 |
5,608.0 |
7,152 |
-9 GB, UI lag begins |
| 22:12 |
372.9 |
6,977.4 |
7,350 |
Stable at ~7.5 GB |
| 22:27 (lag) |
390.9 |
7,132.1 |
7,523 |
Severe lag, typing delay |
| 22:28 (wake) |
217.2 |
16,120.2 |
16,337 ✅ |
Display woke, pool reset |
| 22:29 |
297.2 |
15,999.1 |
16,296 |
Normal again |
| 22:33 |
500.8 |
13,081.1 |
13,582 |
Shrinkage resumes |
The full CSV log with 230+ data points is available upon request.
System Log Evidence
At 22:23:14, the display entered sleep:
kernel: PMRD: Removed IODisplayWrangler from idle sleep preventers list
At 22:27:44, the display woke:
WindowServer: (CoreDisplay) Received display did wake notification for display 0x2b28660c kernel: (IOAcceleratorFamily2) IOAccelDisplayPipe::display_change_handler event = <2>
At 22:28:14 (50 seconds after wake), the VRAM pool total jumped from 7,523 MB back to 16,337 MB, confirming the GPU driver reinitialized the VRAM pool during the display wake sequence.
Steps to Reproduce
- Fresh boot macOS Monterey 12.7.2 with RX 6800 XT
- Use the desktop normally (browser, Finder, text editor)
- Monitor
inUseVidMemoryBytes + vramFreeBytes from ioreg -l | grep PerformanceStatistics every 20 seconds
- After 60-90 minutes, total pool drops to ~50% of initial value
- UI becomes severely laggy (typing delay, Dock freeze, slow app launch)
- Let display sleep and wake → pool resets to full 16 GB, performance restored
Expected Behavior
The total VRAM pool (inUseVidMemoryBytes + vramFreeBytes) should remain approximately constant (~16 GB for RX 6800 XT) regardless of uptime. VRAM allocations and deallocations should not cause the overall pool to shrink.
Actual Behavior
The VRAM pool total decreases monotonically over time at a rate of approximately 120-130 MB/minute, eventually stabilizing at ~7-8 GB (roughly half the physical VRAM). Only a display sleep/wake cycle resets the pool.
Additional Notes
- All GPU hardware metrics (
Core Clock, Memory Clock, GPU Activity, Temperature, Power, Fan Speed) report 0 in PerformanceStatistics, which may indicate incomplete driver integration for Navi 21 on this macOS version.
recoveryCount in PerformanceStatistics remains at 0, suggesting no GPU TDR/reset events were triggered by the driver itself.- The system load average during the lag period was ~2.5 on a 32-thread CPU, ruling out CPU-bound starvation.
- A concurrent Dock tile plugin crash loop (from a third-party app) was also present but was confirmed as a secondary factor, not the root cause.
Environment
npci=0x2000 agdpmod=pikera brcmfx-country=#a watchdog=0Description
The total VRAM address pool (calculated as
inUseVidMemoryBytes + vramFreeBytesfromioreg PerformanceStatistics) continuously shrinks over time after a fresh boot. This is not an increase in VRAM usage — the entire addressable pool decreases, indicating that allocated VRAM blocks are never returned to the driver's free pool.After approximately 70 minutes of idle/light desktop use, the total pool shrinks from ~16.2 GB to ~7.5 GB (a loss of ~8.7 GB). The system then exhibits severe UI lag: typing delay, Dock animations freeze, System Preferences bounces for a long time before opening, and menu clicks respond slowly.
When the display enters sleep and subsequently wakes, the VRAM pool is fully reset to ~16.3 GB, and performance temporarily returns to normal. However, the shrinkage immediately resumes after wake.
Quantitative Data
VRAM pool total over time (sampled every ~21 seconds via
ioreg -l | grep PerformanceStatistics):The full CSV log with 230+ data points is available upon request.
System Log Evidence
At 22:23:14, the display entered sleep:
kernel: PMRD: Removed IODisplayWrangler from idle sleep preventers list
At 22:27:44, the display woke:
WindowServer: (CoreDisplay) Received display did wake notification for display 0x2b28660c kernel: (IOAcceleratorFamily2) IOAccelDisplayPipe::display_change_handler event = <2>
At 22:28:14 (50 seconds after wake), the VRAM pool total jumped from 7,523 MB back to 16,337 MB, confirming the GPU driver reinitialized the VRAM pool during the display wake sequence.
Steps to Reproduce
inUseVidMemoryBytes + vramFreeBytesfromioreg -l | grep PerformanceStatisticsevery 20 secondsExpected Behavior
The total VRAM pool (
inUseVidMemoryBytes + vramFreeBytes) should remain approximately constant (~16 GB for RX 6800 XT) regardless of uptime. VRAM allocations and deallocations should not cause the overall pool to shrink.Actual Behavior
The VRAM pool total decreases monotonically over time at a rate of approximately 120-130 MB/minute, eventually stabilizing at ~7-8 GB (roughly half the physical VRAM). Only a display sleep/wake cycle resets the pool.
Additional Notes
Core Clock,Memory Clock,GPU Activity,Temperature,Power,Fan Speed) report0inPerformanceStatistics, which may indicate incomplete driver integration for Navi 21 on this macOS version.recoveryCountinPerformanceStatisticsremains at0, suggesting no GPU TDR/reset events were triggered by the driver itself.