Computers do things with data, and data needs to be stored somewhere. When your browser downloads a web page from its server, the source code for that page has to be stored while the browser’s rendering engine turns it into the image to be displayed inside its window. WindowServer then has to composite that window with all the others on your Mac’s display, and hand the composite over to the display controller to send to the display.
Throughout those processes, data has to be processed from and to memory. The CPU cores have relatively small local caches for their immediate needs, and both their code and data have to be fetched from larger and slower main memory. Some of the data, such as the page source code, may be cached to disk storage, which is even more capacious but slower, and ultimately it will all have to pass through memory.
Until comparatively recently, several parts of a Mac had their own local memory. Main memory (RAM) was the preserve of the cores in the CPU, while GPUs came on a graphics card with their own dedicated high-speed memory, VRAM. Some models, particularly those at the lower end and laptops, allocated some of the main memory for graphics use instead. Other hardware systems also had their own memory, used for buffering and temporary storage.
This has some obvious advantages. It’s eminently upgradeable by the user; when you can afford a better graphics card, you can replace the existing one with a faster GPU and more graphics memory. You can also buy a basic version of that model with little main memory, and upgrade that when you can afford it. This has allowed graphics cards to have less, faster and more expensive memory which is only accessible to the GPU.
There are also problems with that architecture. GPUs are now being used for a lot more than just driving the display, most recently for many of the calculations used in AI. So long as CPUs and GPUs continue to use their own local memory, simply moving data between RAM and VRAM has become an unwanted overhead. If you’d like to read a more technical account of some of the issues that have brought unified memory to Nvidia GPUs, you’ll enjoy Michael Wolfe’s article on the subject.
At the same time, chip design has changed, with far tighter integration of what were separate chips into a System on a Chip (SoC), a field in which Apple is one of the leaders, largely as a result of its hardware development for iPhones and iPads. SoCs can run faster, use less power, and stay cooler, and when built in quantity are significantly cheaper, all advantages that Apple has used in its products, now including its full range of Macs.
In this new model, CPU cores, GPUs and other hardware such as the Neural Engine all access the same memory. When data being processed by the CPU needs to be manipulated by the GPU, it stays where it is. That unified memory can be as fast to access as dedicated GPU memory, and completely flexible. When you want to connect a high-resolution display, that’s not limited by the memory tied to the GPU, but by total memory available, and the display controller.
To achieve this, Apple integrates the unified memory in the chip carrier itself. That provides the shortest and fastest path between those systems within the SoC and the memory they share. It unfortunately also means that memory can’t be upgraded without replacing the whole chip. As that’s soldered onto the logic board, that in turn requires logic board replacement, and much of the cost of a new computer.
Early Apple silicon chips for Macs were severely limited in the memory that could be integrated into the chip carrier. The first MacBook Air and Pro M1 offered a choice of 8 or 16 GB, but even the base MacBook Air and Pro M5 now range from 16 to 32 GB, with more than double the memory bandwidth of the base M1. At the top end, the most available in the M1 Ultra was 128 GB, which has risen to 512 GB in the M3 Ultra, to support its use with Large Language Models.
Memory, its size and use have changed greatly since the days of Mac OS 8.6 running on a PowerMac G3 with just 384 MB of memory.