VideoCore IV Processor Manual (Raspberry Pi GPU)
6 points · Open discussionhermanhermitage
videocoreiv
Python2012–2021
hermanhermitage / videocoreiv
videocoreiv
Tools and information for the Broadcom VideoCore IV (RaspberryPi)
18Distinct people
24Mentions
0Explicit recommenders
864GitHub stars
What to know before exploring
What it is
Tools and information for the Broadcom VideoCore IV (RaspberryPi)
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year24 dated mentions
Observed mentions: 2012-09-25 11:10:44 UTC to 2021-12-06 00:22:10 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2012 | 2012-01-01 00:00:00 UTC | 2013-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2013 | 2013-01-01 00:00:00 UTC | 2014-01-01 00:00:00 UTC | 3 | 1 | 2 |
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 6 | 0 | 6 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 6 | 0 | 6 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 2 | 1 | 1 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
Disclaimer:
This is a independent documentation project based on a combination of static analysis
and trial and error on real hardware. This work is 100% independent from and not
sanctioned by or connected with Broadcom or its agents.
No Broadcom documents or materials were used beyond those publically available
(see Referenced Materials).
This work was undertaken and the information provided for non commercial use on the
expectation that hobbyists of all ages will find the details useful for understanding
and working with their Raspberry Pi hardware.
The hope is that Broadcom will be flattered by the interest in the device and
understand the benefits of opening up understanding to a larger audience of
potential customers and developers.
Broadcom should be commended with making their SoC available for a project as
exciting as the Raspberry Pi.
The intent is that no copyrighted materials are contained in this repository.
Introduction
Purpose of this repo: Documentation and samples on the VideoCore IV instruction set as used in the BCM SoC used in the Raspberry Pi. As of early 2016, Broadcom has yet to release public information on the VPU, so it is hoped you find this repo useful.
The BCM2835 SoC (System on a Chip) in the original RaspberryPi has the following significant computation units:
(ARM) ARM1176JZF-S 700 MHz processor which acts as the "main" processor and typically runs Linux.
(VPU) Dualcore Videocore IV CPU @250MHz with SIMD Parallel Pixel Units (PPU) which runs scalar (integer and float) and vector (integer only) programs. Runs ThreadX OS, and generally coordinates all functional blocks such as video codecs, power management, video out.
(ISP) Image Sensor Pipeline (ISP) providing lens shading, statistics and distortion correction.
(QPU) QPU units which provide 24 GFLOPS compute performance for coordinate, vertex and pixel shaders. Whilst originally not documented, Broadcom released documentation and source code for the QPU in 2014.
Newer Raspberry Pi mix things up with faster and more modern ARM cores, but the VPU information here is still relevant.
For more information on the Raspberry Pi, see the foundation's site at http://raspberrypi.org,
or the embedded linux wiki at http://elinux.org/R-Pi_Hub.
Active discussions take place on IRC (freenode) on #raspberrypi-internals, #raspberrypi-osdev, #raspberrypi-dev,
and #raspberrypi.
There is a raspberrypi-internals mailing list, you can subscribe at mailing list page at
freelists.org.
We are in a very early stage of understanding of the device. At this stage we only have Serial IO and GPIO for
flashing things like the status led. You will need to attach a terminal to the Mini UART on the GPIO connector.
For more details see "Getting started" below.
It is now possibly to use VideoCore Kernels from Userland / Linux,
see https://github.com/hermanhermitage/videocoreiv/wiki/VideoCore-IV-Kernels-under-Linux. Our understanding of the
Videocore Processor is nearing completion, and it is an excellent target for integer SIMD and DSP kernels. Essentially,
it can be used for 16 way SIMD processing of 8, 16 and 32 bit integer values.
Videocore IV Community and Resources:
I recommend starting with Julian's GNU toolchain, at https://github.com/itszor/vc4-toolchain
[2016-06-15] SDRAM and ARM initialization reference code for the VPU is now available at https://github.com/christinaa/rpi-open-firmware
[2016-05-03] Kristina Brooks has got David Given's LLVM fork to work on rPi at https://github.com/christinaa/LLVM-VideoCore4
[2016-04-23] Julian Brown has pulled together bits and pieces of previous GNU toolchain work and fixed them up so they work together at https://github.com/itszor/vc4-toolchain
[2015-11-08] (QPU). Koichi NAKAMURA has developed a Python library for GPGPU on Raspberry Pi at https://github.com/nineties/py-videocore.
[2016-04-21] (QPU). mn416 has developed QPULib, a programming language and compiler for the Raspberry Pi's Quad Processing Units at https://github.com/mn416/QPULib
[2015-01-02] (QPU). A new QPU macro assembler from Marcel Müller. This builds on Pete and Eman’s earlier QPU assemblers to include support for macros and functions, at http://maazl.de/project/vc4asm/doc/index.html and https://github.com/maazl/vc4asm/
[2014-10-28] (VPU). RPi foundation discusses how Argon Design use the VPU to accerate stereo depth perception at https://www.raspberrypi.org/blog/real-time-depth-perception-with-the-compute-module/ a comment about using MMAL is at https://www.raspberrypi.org/blog/real-time-depth-perception-with-the-compute-module/#comment-1078440
[2014-06-10] (QPU). Louis Howe gives a talk on 'Hacking the Raspberry Pi's VideoCore IV GPU' at https://www.youtube.com/watch?v=eZd0IYJ7J40
[2014-06-09] (QPU). Pete Warden wrote a series of posts covering Deep Learning, Optimizing for QPU, and Image Recognition at https://petewarden.com/2014/06/09/deep-learning-on-the-raspberry-pi/, https://petewarden.com/2014/08/07/how-to-optimize-raspberry-pi-code-using-its-gpu/ and https://petewarden.com/2015/05/10/image-recognition-on-the-raspberry-pi-2/. He updated Eric's QPU assembler at https://github.com/jetpacapp/qpu-asm, and added QPU support to his DeepBeliefSDK at https://github.com/jetpacapp/DeepBeliefSDK/, and a QPU implementation of GEMM matrix-multiply at https://github.com/jetpacapp/pi-gemm
[2014-05-03] (QPU). Eric Lorimer wrote a set of posts on Hacking The GPU For Fun And Profit (including SHA hashing) at https://rpiplayground.wordpress.com/2014/05/03/hacking-the-gpu-for-fun-and-profit-pt-1/, and wrote his own QPU assembler at https://github.com/elorimer/rpi-playground
[2014-02-28] (QPU). Broadcom announced the release of full documentation for the VideoCore IV graphics core, and a complete source release of the graphics stack at https://www.raspberrypi.org/blog/a-birthday-present-from-broadcom/. Note this does NOT include VPU documentation, except in so much that the source drop includes sa
Read the full README on GitHubWhat Hacker News says
24 sourcesInteresting, the VC firmware is ThreadX based, indeed[1]! The number of platforms this runs on is absolutely mind-blowing (from an engineering perspective).
[1] https://github.com/hermanhermitage/videocoreiv
In Taking a Stand in the War on General-Purpose Computinghttps://github.com/hermanhermitage/videocoreiv/wiki/VideoCor...
Documented as much as Lion's documentation on Unix. Gotta dance around NDAs an all, but they had to deal with that in the 80s as well.
In What is the “two-drive trick” that can read Amiga disks on a PC?Typically it's a dedicated hardware block on the die of a larger chip, like AMD's UVD [1] and VCE [2] inside their GPU/APUs, or Nvidia's PureVideo [3] and NVENC [4]. Sometimes the line is even blurrier, like the Broadcom SOC in the Raspberry Pi, where various more general-purpose processors can work together to decode [5].
Then you have APIs that try to disassemble all the typical stages of video codec processing that applications can call and GPU drivers can implement, which serve as a bridge between hardware-assisted decode and application code. These are APIs like DXVA or one of the several in use with Linux [6].
[1] https://en.wikipedia.org/wiki/Unified_Video_Decoder [2] https://en.wikipedia.org/wiki/Video_Coding_Engine [3] https://en.wikipedia.org/wiki/Nvidia_PureVideo [4] https://en.wikipedia.org/wiki/Nvidia_NVENC [5] https://github
Read the rest
Indeed, several good examples of these DSPs are the Qualcomm Hexagon and the VideoCore IV, the latter of which has a 64x64 register bank, and is largely reverse engineered so you can actually figure out how it works [1]. They are really good for highly serial per-block operations, such as video encoding and decoding. They would also work OK for stuff like large convolutions, which is what I kind of imagine the IPUs are for, but not really significantly better than a GPU (the low serial latency is wasted).
I did find the original source to the Ars article [2] and it says that each IPU core has 512 ALUs. This seems more like a extremely wide GPU than the VPU. It also seems to be programmable in Halide [3], which presents a more "SIMT"-like interface, just like a GPU shader. It probably lacks the super fast bilinear texture mapping units tha
Read the rest
t a GPU has, but otherwise seems very similar. It'd be interesting to know if the texture/pixel cache is handled automatically, or manually with a large register file like the VPU.
The article also features this quote, which also seems to back Google being unsatisfied with only high level access to the GPU:
>A key ingredient to the IPU’s efficiency is the tight coupling of hardware and software—our software controls many more details of the hardware than in a typical processor.
It would be really awesome if they opened this chip up to third party developers. Unfortunately the press release only mentions availability in the Camera API so far, relegating it to the same opaque blob status as all the other dedicated image processors :(
[1] https://github.com/hermanhermitage/videocoreiv/wiki/VideoCor...
[2] https://blog.google/products/pixel/pixel-visual-core-image-p...
[3] http://halide-lang.org/
The "24 GFLOPS" in RP come from the GPU (Videocore IV, 32-bit precision) [1].
The PS3 does more than 230 GFLOPS, just with the Cell processor (1 dual threaded CPU and 7 vector units -CPUs with wide SIMD, working in 256KB local scratchpad RAM-) [2]. In addition to that, the PS3 GPU does 400 GFLOPS [3]. So the PS3 is "600 GFLOPS" (32-bit precision).
[1] https://github.com/hermanhermitage/videocoreiv/wiki/VideoCor...
[2] https://en.wikipedia.org/wiki/PlayStation_3_technical_specif...
[3] https://en.wikipedia.org/wiki/RSX_'Reality_Synthesizer'#cite...
In Blobless Linux on Raspberry PiThat's not quite right. The Pi has a completely separate GPU unit. The VC4 is different, and is a pretty normal processor, although it's got a pile of DSP addons.
The instruction set's here:
https://github.com/hermanhermitage/videocoreiv/wiki/VideoCor...
...but to summarise:
- 32 registers which can hold either integers or 32-bit floats;
- ARM-like 32-bit 3op instructions, with a limited set of 16-bit 2op instructions;
- integrated 32-bit floating point instructions, using the same registers as everything else;
- some 48 bit instruction forms (allowing a full 32-bit payload! No ghastly ARM constant pools or PowerPC-style split payloads!);
- two cores, with integrated interrupt handler;
- integrated DSP with 80-bit vector instructions working on a 64x64x8bit vector working area, which TBH looks like it was stolen from another processor com
Read the rest
pletely and which I frankly don't understand;
- ARM-style conditional execution (for some instructions);
- ARM-style multiregister loads and saves (and pushes and pops);
- DSP-style saturated arithmetic and fixed-point support;
- no ALU-setting-condition-flags instructions, or add-with-carry or subtract-with-carry operations, which makes 64-bit arithmetic really painful (if you need cmp to set the condition flags, what's the carry flag even for?)
It's actually a really nice thing to write assembly for. It's orthogonal enough to be understandable, while quirky enough to allow some really satisfying optimisations. e.g. there's the addcmpb instruction, which while add a value to a register, compare with another register, and branch based on a condition code, all in a single 32-bit operation --- it's basically a loop in a box.
It's also the only time I've ever seen 6-bit floating point constants...
Better documentation: https://github.com/hermanhermitage/videocoreiv
It's a vector processor and a GPU. The vector processor is intended for video decoding and therefore has a very big SIMD capability. It has some nice gimmicks like the 'square' register file: you can access rows or columns for SIMD operations. The VPU is I believe what boots first and normally runs an RTOS called "ThreadX".
The GPU is OpenGL-capable.
In Minimal Raspberry Pi VPU firmwareThe VC4 was intended for use in set-top-boxes or TVs, where the ARM would run a regular lightweight OS to drive the UI menus and the VC4 would do the video decoding, and compose the UI onto the video. It's not an accident, but it is a second-class citizen.
It was also clearly intended for possible use in mobile phones, as some of the patent diagrams have "baseband" on them: https://github.com/hermanhermitage/videocoreiv/wiki/VideoCor...
In Minimal Raspberry Pi VPU firmwareThere is some information here:
https://github.com/hermanhermitage/videocoreiv/wiki/VideoCor...
In particular we are talking about "Scalar/Vector (VPU)" "Dual Core VideoCore IV® Multimedia Co-Processor" (Figure 3B). As far as I understand, that's the thing that boots the device and usually runs ThreadX OS in the closed-source bootloader. The VPU is a dual core processor with scalar and integer vector instructions.
The VPU is more-or-less independent of the GPU, although I'm not sure whether the VPU gets involved with some GPU scheduling tasks.
The GPU has four "QPU" QuadProcessor pipelines, which from memory can do floating-point vector processing.
In Minimal Raspberry Pi VPU firmware> There is also the fact that in modern CPU-side development you will find it almost always is a bad idea to try to drop to assembly micro-optimization. Your compiler is going to almost always do a better job optimizing the general case into an optimal set you won't be able to easily implement in raw ASM, especially when you start using vectorization instructions.
I agree. In fact, the fact that it's not even a good idea in most situations to write in assembly on x86 CPUs proves the point even more. GPUs are less willing to spend die space on things like sophisticated branch prediction, complex superscalar architectures, register renaming, and so forth. This effectively means that GPUs punish naive codegen (which is the kind of codegen that humans without in-depth knowledge of the architecture tend to produce with their brains) significan
Read the rest
tly worse than x86 CPUs do. For an extreme example, look at the vector part of the low-power VideoCore IV architecture [1]: compared to a compiler, I don't trust myself for a second to program this optimally.
[1]: https://github.com/hermanhermitage/videocoreiv/wiki/VideoCor...
This isn't the same, the document in question relates to the QPU ISA. The VPU ISA hasn't been officially documented but there were many projects that involved reverse engineering it. The VC4 ISA is documented here:
https://github.com/hermanhermitage/videocoreiv
The VPU is basically a general purpose RISC processor with some fancy vector instructions on top. In fact, most of the firmware that runs on it is written in C.
In LLVM Backend for the VideoCore4, Raspberry Pi 2 VPUYou can try without a blob: https://github.com/hermanhermitage/videocoreiv
(booting directly from Broadcom VideoCore IV)
In Raspberry Pi Zero: the $5 computerBtw., VPU had been reverse-engineered to a degree, should be sort of possible to roll out your own bootstrap now: https://github.com/hermanhermitage/videocoreiv
In The Interim Operating SystemI realise now I forgot to reference my source; I didn't do any of the reverse engineering myself:
https://github.com/hermanhermitage/videocoreiv
I believe it was figured out from a combination of analysis of the blob, examining the patents (which contain quite a lot of information), trial-and-error, and careful examination of the fragments of VC4 source released by Broadcom (their big source release a year or so back contained quite a lot). I know that at least one person wrote a program which would run arbitrary instructions on the Pi and analyse the state of the registers afterwards, which is a neat trick.
The VC4 is a really nice processor, BTW. Dual core, lots of registers, efficient instruction packing, 64x64x8bit vector unit, integrated single-precision FPU using the integer registers (no double-precision, alas), 1kB on-chip lookup
Read the rest
table... but, bizarrely, no adc or sbc instructions, so 64-bit arithmetic is hard. Very weird.
Showing the 15 most recent of 24 sources. Enable JavaScript to search and browse every indexed mention.