Raspberry Pi online course

Configure the Raspberry Pi CPU and GPU Memory Split

Learn how Raspberry Pi shared RAM is divided between the CPU and GPU, how to change the allocation with raspi-config, and how to choose a setting for servers, desktops, and graphics workloads.

Raspberry Pi computers use system RAM as a shared resource. Depending on the model, operating system, firmware, and graphics stack, part of that RAM can be reserved for the GPU while the rest remains available to Linux, the CPU, and applications. This division is called the memory split.

This lesson explains what the setting does, how to change it with raspi-config, and how to choose an appropriate allocation without unnecessarily reducing memory available to your applications.

What the Raspberry Pi memory split means

RAM is the system memory used by the operating system and running programs. On a Raspberry Pi, the CPU and GPU can share the same physical RAM pool rather than having completely separate memory installed for each processor.

The CPU, or Central Processing Unit, executes general-purpose work such as operating system processes, calculations, services, scripts, and desktop applications. The GPU, or Graphics Processing Unit, handles display output, graphics rendering, and supported video or hardware-accelerated workloads.

The memory split establishes a boundary within the existing RAM:

  • Increasing the GPU allocation reserves more RAM for graphics-related work.
  • Decreasing the GPU allocation leaves more RAM available to Linux and CPU-side applications.
  • Changing the split does not add RAM or make the processor faster.

CPU memory and GPU memory trade-offs

Every megabyte reserved for the GPU is unavailable to the operating system and CPU applications. On a device with limited RAM, this trade-off can be noticeable. A large GPU reservation may leave too little memory for databases, containers, web services, or multiple desktop applications.

Conversely, reserving too little GPU memory can cause display, video, camera-preview, game, or graphical-application problems when those workloads require more graphics resources. The best setting depends on what the Pi is doing.

Default allocation and platform differences

Many older Raspberry Pi configurations commonly reserved 64 MB for the GPU by default. This is not a universal rule for every Raspberry Pi. Actual defaults, selectable values, and the practical effect of the setting can vary according to:

  • The Raspberry Pi model and its available RAM.
  • The installed Raspberry Pi OS release.
  • Firmware and boot configuration.
  • The display stack and graphics drivers.
  • Whether the workload uses legacy or modern graphics behavior.

Inspect the value offered by your installed raspi-config and consult documentation for your exact model and operating system. Newer models and modern graphics drivers may manage graphics memory differently, making a manual legacy split less important for some workloads.

Change the memory split with raspi-config

raspi-config is Raspberry Pi's text-based system configuration utility. Where the installed system supports the setting, use it rather than manually editing boot files.

  1. Open a terminal or connect to the Pi remotely.
  2. Run:
sudo raspi-config
  1. Open Advanced Options.
  2. Choose Memory Split if that option is offered.
  3. Enter or select the amount of RAM to reserve for the GPU.
  4. Finish the utility and accept the reboot request when prompted.

A reboot is normally required because the allocation is applied during startup. If the utility saves the setting but does not restart the device, run:

sudo reboot

raspi-config changes the relevant supported boot configuration. It does not change the amount of physical RAM installed in the Raspberry Pi.

Choosing an appropriate allocation

Start with the system default or a balanced setting for ordinary desktop use. Do not increase GPU memory solely to make general CPU-bound tasks feel faster; doing so can reduce the RAM available to those tasks.

Headless server
Graphics requirement: None or very limited.
Relative GPU allocation direction: Lower, using the smallest supported value that meets actual platform requirements.
CPU-memory trade-off: More RAM is available for services, databases, containers, and file sharing.
Notes: A later need for a local desktop, video playback, camera preview, or display application may require a larger allocation.

Command-line development
Graphics requirement: Low when no local desktop is used.
Relative GPU allocation direction: Lower or default, depending on the model and OS.
CPU-memory trade-off: More memory remains available for compilers, shells, editors, and development services.
Notes: Remote administration does not necessarily require a large GPU reservation.

Standard desktop
Graphics requirement: Display output, web browsing, office work, and light programming.
Relative GPU allocation direction: Keep the default or balanced value initially.
CPU-memory trade-off: Avoid sacrificing application memory unless a specific graphics problem is demonstrated.
Notes: Ordinary desktop responsiveness may be limited by CPU capacity, storage, drivers, or thermal throttling rather than GPU memory.

Graphical kiosk or display application
Graphics requirement: Persistent display rendering or a graphical application.
Relative GPU allocation direction: Higher only when testing shows the current reservation is insufficient and the platform supports the change.
CPU-memory trade-off: Less RAM remains for the operating system and application logic.
Notes: Test the exact display resolution and application behavior after rebooting.

Graphics-intensive or video-oriented application
Graphics requirement: Games, video-related workloads, accelerated rendering, or other graphics-heavy tasks.
Relative GPU allocation direction: Higher when the application explicitly reports insufficient graphics memory or documentation requires it.
CPU-memory trade-off: A larger GPU reservation can increase memory pressure on CPU-side software.
Notes: More GPU memory does not fix CPU limits, unsupported acceleration, slow storage, driver problems, or thermal throttling.

Headless and server use

Headless means operating the Raspberry Pi without a local graphical display environment or monitor-driven workload. Examples include a file server, automation controller, web service, database, container host, or command-line-only device.

For a genuinely headless system, reducing the GPU reservation can make more RAM available to server processes. This is most useful on low-memory models where several services compete for a small amount of RAM.

Before reducing the value, consider whether the Pi still needs local display output, video playback, camera preview, or another graphics feature. If the device later becomes a desktop or display controller, restore an appropriate allocation through raspi-config and reboot.

Safe adjustment workflow

  1. Record the current setting. Note the value shown by raspi-config before changing anything.
  2. Identify the workload. Decide whether the priority is server memory, ordinary desktop use, or graphics and video.
  3. Check the platform. Confirm the model, installed Raspberry Pi OS release, available RAM, and whether the Memory Split menu exists.
  4. Change one setting at a time. Avoid changing memory allocation together with unrelated boot, driver, or overclocking settings.
  5. Reboot. The boot-time allocation normally becomes active only after restarting.
  6. Test the target workload. Run the service, desktop application, game, display, or video project that motivated the change.
  7. Revert if necessary. Return to raspi-config, select the previous or default value, reboot, and test again if stability, display behavior, compatibility, or performance worsens.

After rebooting, free -h provides a general view of the memory Linux can use:

free -h

Interpret this as a system-memory check rather than a complete GPU diagnostic. The exact meaning of visible memory depends on the model, firmware, and graphics stack.

Checks to make before changing Memory Split

Raspberry Pi model
Why it matters: RAM size, firmware behavior, and supported options differ between models.
Action: Identify the exact board model before choosing a value.

Installed Raspberry Pi OS release
Why it matters: Menu availability and graphics-memory behavior can change between releases.
Action: Check the installed system and use documentation appropriate to it.

Whether the Memory Split menu is present
Why it matters: Its absence may indicate that the legacy setting is not supported or is not useful on the platform.
Action: Use supported current configuration options instead of forcing a legacy setting.

Current allocation
Why it matters: You need a known working value for comparison and rollback.
Action: Record the value shown in raspi-config.

Need for local display or graphics
Why it matters: A headless server and a display-driven kiosk have different requirements.
Action: List the graphics, video, camera, and display features the device actually uses.

Available system RAM
Why it matters: The trade-off is more severe on low-memory models.
Action: Check memory capacity and current pressure with free -h or other monitoring tools.

Ability to reboot and test
Why it matters: The setting is applied during boot, and behavior must be checked afterward.
Action: Make the change during a maintenance period or ensure remote access and recovery are available.

Legacy boot configuration concept

The traditional configuration concept is often represented as:

gpu_mem=<megabytes>

This setting refers to reserving a specified number of megabytes for the GPU in boot configuration. Use raspi-config where it is available. Do not assume that manually adding this setting is supported, necessary, or equally meaningful on every current Raspberry Pi model and operating system.

Troubleshooting memory split changes

Server runs out of memory
Possible relationship: Too much RAM may be reserved for the GPU on a low-memory device.
Recommended check: Restore the previous or a lower supported allocation, reboot, and monitor service memory use.

A graphical application reports graphics-memory limitations
Possible relationship: The GPU reservation may be too small for the application's display, rendering, or video workload.
Recommended check: Confirm the application's requirements, increase the allocation only if supported, reboot, and retest.

Increasing GPU memory does not make the application faster
Possible relationship: The previous allocation may already have been sufficient, or the bottleneck may be elsewhere.
Recommended check: Check CPU usage, temperature and throttling, storage speed, display resolution, driver status, hardware acceleration, and application limitations.

Memory Split is unavailable
Possible relationship: The model, firmware, OS version, or graphics stack may not expose the legacy option.
Recommended check: Confirm the model and OS, update system configuration packages when appropriate, and follow supported platform-specific guidance.

Display behavior changes after reducing GPU memory
Possible relationship: The new reservation may be too small for the active display or graphics workload.
Recommended check: Restore the default or a larger supported allocation, reboot, and test with the connected display and target application.

The user expects more total RAM
Possible relationship: The memory split has been misunderstood as a hardware upgrade.
Recommended check: Explain that the setting redistributes existing RAM; it does not add physical memory.

When memory split is not the real performance problem

A larger GPU reservation cannot solve every graphics problem. Poor performance may instead result from insufficient CPU capacity, thermal throttling, incorrect or limited drivers, slow storage, high display resolution, missing hardware acceleration, or an application that does not use the GPU.

If increasing the allocation produces no measurable improvement, return to the previous setting and investigate those causes. Likewise, if a server becomes unstable after increasing GPU memory, prioritize the server's CPU-side RAM unless the graphics workload is essential.

Practical examples

Headless home server

A Pi used for file sharing, web services, automation, containers, or command-line administration normally benefits from prioritizing CPU-side memory. Use the smallest supported GPU allocation that meets the device's actual display or firmware requirements, reboot, and verify the services.

General-purpose desktop

For web browsing, office work, light programming, and an attached display, retain the default or balanced allocation initially. Raise it only when a specific application demonstrates a graphics-memory requirement.

Graphics or video project

A display-driven kiosk, game, graphical application, or video workload may justify a higher allocation. Increase it only when the hardware and OS support the setting and testing shows that the existing reservation is insufficient. Remember that the CPU and operating system will then have less RAM.

Low-memory Raspberry Pi

When multiple services compete for limited RAM, prioritize the device's primary purpose. A large GPU reservation can create avoidable memory pressure if the Pi has no meaningful graphics workload.

Returning from server to desktop use

If a previously headless Pi is connected to a display, revisit the memory split. Restore an appropriate graphics allocation if the desktop, video playback, camera preview, or display application reports problems.

Key points

  • Raspberry Pi CPU and GPU workloads can use a shared physical RAM pool.
  • The memory split reserves part of that pool for the GPU and leaves the remainder for Linux and CPU applications.
  • Increasing GPU memory reduces CPU-side RAM; decreasing it does the opposite.
  • Many older configurations commonly used 64 MB as a default, but current behavior varies by platform.
  • Use sudo raspi-config, then Advanced Options and Memory Split, when the menu is supported.
  • Reboot after changing the setting.
  • Use lower allocations for genuinely headless workloads and higher allocations only for demonstrated graphics needs.
  • Do not force legacy boot settings on systems that do not expose or require them.

For related administration skills, see Using raspi-config, using the Raspberry Pi terminal, Raspberry Pi boot options, and monitoring running processes.