I am necromancing this thread and also asking the moderators to move it to the Early Intel Macs forum (as this covers multiple EIM models across the MBP and Mac mini.
My particular interest in this discussion related to VRAM allocation and running into what amounts to a buffer overrun when taxing the VRAM bounds.
This is an issue I’ve known about since at least 2012 (and across multiple Macs with the Intel Graphics HD 3000 iGPU), but until recently, I had no ideas or ways to test whether a relative alteration of VRAM allocation from RAM might reduce how often these buffering issues come up.
The symptoms are, in effect, the by-product of running multiple video-related tasks at once. Each time this breaking point occurs, the underlying system is unaffected (and indeed, if one is remotely ssh’d into the offending Mac, load averages are low, and echo response time is quick). What this looks like, however, is a delay of several tens of seconds — up to more than a minute — of screen “frozenness”. Then, for about a second or so, any inputs made by keyboard or trackpad will update/refresh, followed by another cycle of frozenness.
Ever since I first witnessed this back in 2012 (in an early 2011 i5 Mac with 8GB RAM on board), the setup is fairly similar: I’m watching an 1080p video in VLC or similar. Meanwhile, in the background there is a browser running, and possibly Photoshop as well. Atop all this, of course, is Mission Control (or its antecedent, Spaces). I have experienced these overruns spanning Snow Leopard to High Sierra, and it probably is just as much an issue with dosdude1/OCLP installs of subsequent macOS builds.
Although I’m no expert, what this resembles, whenever it happens, is a memory buffer overrun, correctable only by a clean reboot (as even a reset of WindowServer, i.e., by logging out and logging back in without restart, is ineffective). Indeed, the manual screencap of the above — using a physical camera — to show what the console echoes, after this threshold is reached, points to this being buffer overflow issue (and, frankly, probably related to the way Intel manages shared RAM for VRAM tasks).
Whenever this happens, iStat Menus reveals the VRAM allocation for the HD 3000 to meet or exceed, at average, a 25 per cent minimum paired with VRAM spikes which exceed 50 per cent of shared VRAM capacity (or, in exceptional cases, as low as several minutes at 37.5 per cent, or 3/8ths reported capacity). The highlighted time stamp from last day recorded when the most recent of these buffer overflow issues occurred (and is the incident captured above in the manual screen cap):
I generally take the specific values, as reported in iStat Menus, to be relative and not representative of actual VRAM values (in MB). But for each instance seen above over the last seven days, all of the above spikes produced the buffer overflow issue
eventually — sometimes immediate (as with Cmd-Tabbing between applications whilst video was running) and sometimes delayed (as with watching a movie in VLC whilst leaving the rest of the system alone, not switching apps, making no inputs, etc.).
I’ve come to conclude that once the VRAM demand exceeds 50 per cent, there is a 2:1 relationship of sorts. That is, spiking iGPU shared VRAM demand beyond a reported 50 per cent amounts to 100 per cent demand; anything beyond that can trip the GPU into the buffering issue necessitating a reboot.
So given the above, I see one potential, but substantive use-case for this hack — one I’m now going to test for the next little while and will update after that time.
I’ve been aware from the outset how such a change in VRAM would not (nor could not) have an impact on FPS performance, GL rendering, or other on-screen rendering performance — something which other folks were hoping to get out of such a hack.
Rather, the value in telling the system to allocate a higher shared VRAM share for the iGPU is to give the GPU enough memory headroom to not trigger a literal running out of memory with as high a frequency as it would with a lower VRAM cap.
To that end, I’ve moved the 512MB VRAM allocation on my late 2011 i7 13-inch MBP to, for now, 1GB:
I am setting it up in that manner because I also have the system RAM capped at its Sandy Bridge-limited 16GB.
I’ll post an update in a little while, once I‘ve had more time to test this hypothesis. Cheers.
D) but you could hook up an eGPU and an external display and say goodbye to the HD 3000.