VMware ESXi and vSphere Cluster Management

Configure the Raspberry Pi CPU/GPU Memory Split

Learn how Raspberry Pi shared RAM is divided between the CPU and GPU, when to change GPU memory, and how to configure Memory Split with raspi-config.

Raspberry Pi systems that support a configurable memory split divide shared system memory between the CPU and GPU. Changing this setting can be useful when configuring a desktop, media center, game system, camera project, or headless server.

This is a workload setting, not a general performance boost. The best value depends on how the Raspberry Pi is being used.

How Raspberry Pi Shared Memory Works

RAM, or Random Access Memory, is temporary working memory used while programs and services run. On applicable Raspberry Pi systems, some RAM is shared between two processors rather than being permanently separated into unrelated physical pools.

  • CPU: The Central Processing Unit handles general-purpose computation, the operating system, applications, and server processes.
  • GPU: The Graphics Processing Unit handles display output, graphics rendering, video-related workloads, and some multimedia functions.

The memory split is the configured division of shared RAM that reserves a specified amount for GPU use. If more RAM is reserved for the GPU, less remains available to CPU-side applications and services. If less is reserved for the GPU, more remains available to the CPU side.

What the Memory Split Setting Controls

The Memory Split setting controls how many MB, or megabytes, of system RAM are reserved for GPU-related work. On relevant configurations, a moderate default such as 64 MB is common, but the default values and available choices can vary by Raspberry Pi model, Raspberry Pi OS release, firmware, and graphics stack.

A larger reservation may help a graphics or multimedia workload that is constrained by the available GPU memory. However, it also reduces the RAM available to the operating system, applications, file caches, and background services.

Likewise, a smaller reservation can benefit a server by leaving more RAM for CPU-side work. It may be unsuitable if the device later needs a graphical desktop, display output, camera processing, video, or another graphics-dependent function.

When to Increase GPU Memory

Consider increasing the GPU allocation when the Raspberry Pi is used for:

  • A graphics-intensive desktop or high-resolution display.
  • Video playback or other media applications.
  • Games or 3D graphics.
  • Graphics rendering or display-driven applications.
  • A workload that reports or clearly demonstrates insufficient graphics-related memory.

More GPU-reserved memory can prevent a graphics or multimedia workload from being constrained by an allocation that is too small. It does not automatically increase frame rate, decode speed, or overall graphical performance.

The trade-off is important: every additional MB reserved for the GPU is unavailable to CPU-side programs. On a device with limited total RAM, an oversized GPU reservation can cause applications to have less memory, increase swapping, or leave less room for services.

When to Decrease GPU Memory

A lower GPU allocation is commonly appropriate for a headless Raspberry Pi. Headless means the device operates without a local graphical desktop, monitor-based interface, or display-focused workload.

Examples include:

  • File-sharing servers.
  • Web or application services.
  • Home automation systems.
  • Command-line-only installations.
  • Remote administration systems without a local GUI.

Reducing the GPU reservation makes more shared RAM available for server processes, applications, caches, and other CPU-side workloads. This can be particularly useful on a low-RAM model running several lightweight services.

Choosing an Appropriate Value

There is no universal best memory split. Choose based on the workload rather than trying to maximize one processor's allocation.

Workload: Headless server
Need for graphical output: None or minimal
Suggested direction: Decrease the GPU reservation where supported
Primary trade-off: A very small allocation may require changing the setting if a display or graphics workload is added

Workload: General desktop
Need for graphical output: Regular desktop, web, office, terminal, and occasional video use
Suggested direction: Keep a balanced or default-style setting unless a specific issue is observed
Primary trade-off: More GPU memory reduces RAM available to desktop applications

Workload: Video or media use
Need for graphical output: Moderate to high
Suggested direction: Increase gradually only if testing indicates the current allocation is inadequate
Primary trade-off: Extra GPU memory can reduce RAM available to media software and the operating system

Workload: Gaming or graphics-intensive use
Need for graphical output: High
Suggested direction: Test a larger allocation incrementally
Primary trade-off: Graphics memory can compete with CPU-side game processes and background services

Workload: Low-memory device
Need for graphical output: Depends on the installation
Suggested direction: Favor a smaller reservation when no GUI or display workload is required
Primary trade-off: A large GPU reservation has a proportionally greater effect on available system RAM

For ordinary desktop use, retaining a balanced or default-style allocation is usually the sensible starting point. For graphics-heavy use, make one change at a time and test the actual application. Devices with less total RAM are more sensitive to an oversized reservation.

Effects of Changing GPU Memory Allocation

Change: Increase GPU allocation
Potential benefit: More reserved memory for graphics, display, and multimedia work
Potential drawback: Less RAM for applications, services, and caches
Best suited to: Graphics-intensive desktops, high-resolution displays, video, gaming, or rendering when testing shows a need

Change: Decrease GPU allocation
Potential benefit: More RAM for server processes, applications, and CPU-side workloads
Potential drawback: Display, desktop, camera, video, or graphics workloads may become unstable or constrained
Best suited to: Headless, command-line-only, or server installations

Change: Leave the setting unchanged
Potential benefit: Preserves a balanced allocation without introducing a new trade-off
Potential drawback: It may not address a confirmed graphics-memory or system-memory constraint
Best suited to: General desktop use without a specific memory problem

Change the Setting with raspi-config

raspi-config is the Raspberry Pi OS configuration utility. Open it from a terminal with administrative privileges:

sudo raspi-config
  1. Open Advanced Options.
  2. Select Memory Split, or an equivalent setting named GPU Memory or similar.
  3. Enter or select the desired GPU memory allocation in MB.
  4. Finish the configuration and accept the restart prompt if one appears.

If the utility does not restart the system automatically, reboot manually:

sudo reboot

A reboot is a restart of the Raspberry Pi. It is required because the changed low-level memory allocation must be applied during startup.

Verify the Change and Roll It Back

After the reboot, test the workload that motivated the change. Check both sides of the trade-off: graphics behavior and the amount of RAM available to applications and services.

  • For a desktop or media system, open the affected applications and test display output, video playback, or graphics performance.
  • For a server, check whether services have sufficient memory and whether the system remains responsive under normal load.
  • After every change, reboot and test again before making another adjustment.

To change the value again, return to sudo raspi-config, open the relevant Advanced Options menu, choose Memory Split or its equivalent, select a different value, and reboot.

If desktop applications fail, display output becomes unstable, performance worsens, or available system RAM becomes too limited, restoring the previous setting is an appropriate first recovery step.

Troubleshooting

Desktop or graphics applications become unstable

The GPU reservation may be too small for the active graphical workload. Use raspi-config to restore the previous value or choose a larger allocation, then reboot and test again.

Server applications have less RAM than expected

Too much shared RAM may be reserved for the GPU even though the system has little or no graphics work. On a headless installation, reduce the GPU allocation through the Memory Split setting and reboot.

Increasing GPU memory does not improve performance

The bottleneck may be elsewhere, such as application requirements, display settings, driver behavior, storage speed, CPU load, or the capabilities of the Raspberry Pi model. Return to a balanced setting if necessary and investigate the actual workload rather than continuing to increase GPU memory.

The Memory Split menu is missing

The Raspberry Pi model, OS release, firmware, or graphics stack may expose memory allocation differently. Review the available raspi-config menus and the documentation for the specific hardware and OS version before applying manual configuration changes.

The new value appears not to be active

The system may not have been restarted after saving the setting. Run sudo reboot, then retest the intended workload.

Scope and Limitations

Memory allocation is only one factor in Raspberry Pi graphics and multimedia performance. Results also depend on the hardware generation, total RAM, display configuration, drivers, application demands, CPU-side memory pressure, and the graphics stack.

Additional GPU memory does not always improve graphical performance. If the application is limited by CPU processing, storage, network throughput, drivers, display resolution, or hardware capability, changing the split may have little or no effect.

Some newer Raspberry Pi graphics stacks, firmware versions, and hardware configurations may manage graphics memory differently. They may offer different options or make the traditional Memory Split setting less significant. Treat the setting as an available workload-specific tuning option, not a required step for every Raspberry Pi installation.

Practical Recommendations

  • Headless home server: Decrease the GPU reservation where supported so file sharing, web services, automation, and command-line administration can use more RAM.
  • General desktop: Keep the balanced or default-style value for browsing, office work, terminal use, and occasional video unless a specific constraint is observed.
  • Media or graphics-focused system: Increase the allocation gradually only when video playback, games, display-driven applications, or rendering indicate that more GPU memory may help.
  • Low-RAM server: Favor a smaller GPU reservation when no GUI or display workload is needed because each reserved MB has a larger proportional impact.

Use the Raspberry Pi memory split guide as a reference when deciding whether the CPU or GPU side of the system needs more of the shared RAM.