The Raspberry Pi 4’s GPU is a 500MHz Broadcom VideoCore VI — a tile-based renderer delivering roughly 32 GFLOPS that handles 4K60 HEVC video playback, PS1, most N64 and Dreamcast titles, and a large slice of the PSP library, but tops out well short of GameCube and PS2 emulation. Knowing where that ceiling sits, and how the memory split and a modest overclock shift it, is what separates a smooth RetroPie build from a stuttering one.
As an Amazon Associate we earn from qualifying purchases at no extra cost to you.
VideoCore VI: the numbers that matter
The VideoCore VI lives inside the BCM2711 SoC and shares everything — memory, bandwidth, thermal budget — with the quad-core Cortex-A72 CPU. Key specs:
| Spec | Value |
|---|---|
| Architecture | VideoCore VI (V3D), tile-based |
| Stock clock | 500 MHz (3D core) |
| FP32 throughput | ~32 GFLOPS at 500 MHz |
| APIs | OpenGL ES 3.1/3.2, desktop OpenGL 3.1, Vulkan 1.2 via Mesa’s V3DV driver |
| Video decode | H.265/HEVC 4Kp60, H.264 1080p60 |
| Video encode | H.264 1080p30 |
| Display out | 2× micro-HDMI: single 4Kp60 or dual 4Kp30 |
| Memory | Shared LPDDR4-3200, ~12.8 GB/s total |
For context, ~32 GFLOPS is roughly a quarter of a PlayStation Vita’s GPU and a tiny fraction of any desktop card — but it’s paired with excellent open-source Mesa drivers, which is why the Pi 4 punches above its raw numbers in emulators and why Kodi plays 4K HEVC flawlessly via the dedicated decode block rather than the 3D core.
The real limit: 12.8 GB/s shared bandwidth
The spec sheet won’t tell you this, but memory bandwidth — not compute — is what caps most real workloads. The LPDDR4-3200 chip runs on a 32-bit bus: 3,200 MT/s × 4 bytes = 12.8 GB/s total, shared between the CPU, GPU, and display engine.
Two worked examples show how fast that disappears:
- 4K60 desktop: refreshing a 3840×2160 RGBA framebuffer costs 3840×2160×4×60 ≈ 2 GB/s — about 16% of all bandwidth just to keep the screen lit, before a single game frame is drawn. That’s why 4K video playback (hardware decode block) works great while native 4K 3D rendering is out of the question.
- 1080p60 3D frame: 1920×1080×60 ≈ 124 Mpix/s. With typical ~3× overdraw and ~8 bytes of traffic per pixel (color, depth, tile buffers), you’re looking at roughly 3 GB/s — feasible for OpenGL ES 2-era games like Quake III, tight for anything with modern shaders.
Practical takeaway: render emulators at the console’s native resolution and let the GPU upscale to your display. It’s nearly free bandwidth-wise and looks cleaner than forcing 1080p internal rendering.
What it can actually emulate and render
CPU power is the bottleneck for most emulators (the dynarec cores burn A72 cycles), but the GPU ceiling matters wherever internal resolution or shaders scale up. Expect roughly this:
| System | Typical emulator | Realistic result on Pi 4 |
|---|---|---|
| SNES / Genesis / GBA | RetroArch cores | Full speed, run-ahead latency reduction viable |
| PlayStation | PCSX-ReARMed, DuckStation | Full speed at native res; 2× internal res mostly holds |
| Nintendo 64 | mupen64plus | Most titles full speed at native res; heavy games (Conker, GoldenEye) need lower res or frameskip |
| Dreamcast | Flycast | Full speed in most games at native res |
| Saturn | YabaSanshiro / Beetle Saturn | Mixed — many 2D titles fine, 3D games dip |
| PSP | PPSSPP | Most games full speed at 1×–2× res; God of War and GTA need frameskip |
| GameCube / Wii | Dolphin | Not viable — single-digit to low-teens fps |
| PS2 / 3DS | — | Beyond the hardware entirely |
| MAME arcade | FinalBurn Neo / MAME | 2D classics through late-’90s fine; 3D boards struggle |
For native gaming, think the OpenGL ES catalog rather than PC ports: Quake III Arena and OpenArena run at 1080p60, SuperTuxKart is playable at 720p low settings, and DOSBox/ScummVM libraries run trivially. A 64-bit OS image (Batocera, Recalbox, or 64-bit Raspberry Pi OS) helps — several dynarecs perform noticeably better on ARM64.
Memory split: gpu_mem settings that actually help
This is where most guides are outdated. With the default full-KMS graphics stack (vc4-kms-v3d), the driver allocates GPU buffers dynamically from a shared CMA pool — so cranking gpu_mem up does not give games more memory. It only reserves firmware-side RAM, and setting it too high starves the CPU and can even break booting on 1GB models.
Edit /boot/firmware/config.txt on current Raspberry Pi OS (Bookworm and later) or /boot/config.txt on older images:
| Use case | gpu_mem | Why |
|---|---|---|
| RetroPie / dedicated emulator build | 128 | Emulators allocate via CMA; 128 covers the firmware frame buffer |
| Desktop + Kodi at 1080p | 256 | Headroom for HEVC decode buffers and compositing |
| 4K display output / LibreELEC | 256–320 | 4K framebuffers are ~32 MB each; dual buffering plus decode needs room |
| Camera encode or legacy fkms stack | up to 512 | Hardware codec paths use firmware memory directly |
If a game is slow, gpu_mem is almost never the fix — the fix is lowering render resolution or closing the desktop compositor.
Safe GPU overclock headroom
Thermals come first: the Pi 4 throttles at 85°C, and a bare board under combined CPU+GPU load can get there even at stock clocks. Any overclock below assumes at least a decent heatsink with airflow, and ideally active cooling — a fan-equipped case or a tower-style cooler (the official Pi 4 Case Fan or an ICE Tower-class cooler typically holds load temps in the 55–65°C range).
- Step 1 — the free step (600 MHz): add
over_voltage=2andgpu_freq=600to config.txt. Nearly every board is stable here, and FP32 scales linearly with clock: 64 FLOPs/cycle × 600 MHz ≈ 38 GFLOPS (+20%). - Step 2 — active cooling territory (700–750 MHz):
over_voltage=4(up to 6) withgpu_freq=750≈ 48 GFLOPS. Most chips hit their ceiling in this band; a few go to ~800. Watchvcgencmd get_throttled— a returned value like 0x50000 means it’s throttling. - The smarter option: overclock only the domain that matters.
v3d_freq=700raises the 3D core alone while leaving the HEVC/H.264 blocks at stock clocks — less heat for the same gaming gain. Usehevc_freqseparately if you’re tuning a media build.
Two honest caveats: keep over_voltage at 6 or below (higher values require force_turbo=1, which sets the permanent warranty flag), and for emulation specifically, arm_freq=2000 usually buys more frames than any GPU clock — N64 and PSP are CPU-bound long before the VideoCore becomes the limit.
FAQ
Does raising gpu_mem increase FPS?
No. Under the KMS driver, graphics memory comes from the dynamic CMA pool. Past ~256 MB, extra gpu_mem just removes RAM the CPU could use.
Can the Pi 4 GPU do 4K gaming?
4K video playback, yes — the HEVC decode block handles it independently of the 3D core. 4K 3D rendering, no: the bandwidth math above shows scanout alone eats a sixth of total memory bandwidth.
Is the Pi 5’s GPU a big upgrade?
Yes — the VideoCore VII at 800 MHz delivers roughly 2–2.5× the throughput, which moves light GameCube titles from “no” to “borderline.” If emulation beyond Dreamcast/PSP is the goal, that’s the better board.
