vcio2 - Kernel driver to access Raspberry Pi VideoCore IV GPU without
When using Raspberry Pi's GPU from user space (e.g. gpu_fft)
with the built vcio driver in the RPi kernel you need to have root
privileges for every application.
The goal of the vcio2 driver is to come around this restriction.
Furthermore vcio2 keeps track of the resources and performs a clean-up if
the application is interrupted.
▼ Features, ▼
Limitations & problems ▼
Installation instructions, ▼ Using
the driver, ▶ Sample code,
▶ Programming guide, ▶ API reference, ▼
Download & history
Download DKMS kernel module, an example and
- First public release.
- No root privilege required to use the GPU.
- Automatic cleanup of resources like GPU memory on application
termination, e.g. crash or SIGBREAK.
- Share the GPU by multiple applications.
- Enable and disable the GPU automatically.
- Some protection against invalid memory access.
- Install dkms package if not yet done. (apt-get install
- Install Linux kernel headers. (normally apt-get install
The kernel headers must exactly match your running kernel. Check the
output of uname -r to examine what kernel you use.
The Raspbian repositories do not support kernel headers! But
have a look here.
- In fact I only tested with kernel 3.16.0-4-rpi so far but it
is likely to work with other kernels too.
Build and install the driver
- Unpack the package above to some folder.
- Open a shell.
- Go to the folder where the files are extracted. (not to sub folder src)
- sudo make install
Normally this should build the kernel module using DKMS, install it for
the currently running kernel, setup the driver for autostart and load the
driver. So you are ready to use immediately.
If it does not work, have a look at the error messages on the screen as
well as /var/dkms/vcio2/0.1/build/make.log and /val/log/syslog.
Remove the driver
- Open a shell.
- Go to the folder where the files are extracted. (Not to sub folder src)
- sudo make remove
This will unload the kernel module and uninstall it.
Using the driver
As soon as the driver is loaded successfully, two new devices appear in
the /dev directory.
- This is a device compatible to the one used by hello_fft.
You can use a symbolic link to this device for the char_dev
required by hello_fft instead of creating a character device
with mknod. This enables you to run hello_fft from a
remote file system.
Using this device does not offer the features of vcio2.
- This is the new device which offers new features.
Using this device requires changes to the source code of the
application. See the API reference and
especially the migration guide.
You might want to grant access to this device to some group to prevent
the need of root privileges to use the GPU. I.e. chmod 660 and
chgrp. You might also set up a udev rule to set this
permissions automatically. (Who knows how to do this?)
Note that access to this device is still a major security hole,
suitable to gain root privileges. This is due to the fact that the GPU
bypasses the MMU. The risk is comparable to a kernel debug permission.
See vcio2 programming guide for further
Patching the kernel
Since the driver is compatible to bcm2708_vcio, it could be
used as replacement as part of the kernel. However, this would require you
to compile your own kernel on each update. You do not want to compile this
on the Raspberry, because it takes a whole day. Using a cross compiler
will result in reasonable times.
In fact this was my first approach. But for now a DKMS driver is easier
to use. If someone thinks that it should be part of the RPi kernel and
knows how to contribute, let me know.
Limitations and known problems
- Power management events (e.g. ARM clock changes) are blocked during
execution of GPU code.
This is an restriction of the RPi firmware. It simply uses the same
mailbox channel for system health and GPU execution.
- No two applications can run GPU code concurrently even if they do not
use all QPUs.
This is due to some global GPU resources like semaphores that cannot be
- Support for qpu_enable to explicitly control the QPU power.
- Power off the QPU after execution timeouts for better error recovery.
- Implement some higher level functions that do memory allocations,
locking and mapping in one step.
- Provide functions to access the performance counters.
Comments, ideas, bugs, improvements to raspi at maazl dot de.