VC4 and V3D OpenGL drivers for Raspberry Pi: an update

Here’s an update from Iago Toral of Igalia on development of the open source VC4 and V3D OpenGL drivers used by Raspberry Pi.

Some of you may already know that Eric Anholt, the original developer of the open source VC4 and V3D OpenGL drivers used by Raspberry Pi, is no longer actively developing these drivers and a team from Igalia has stepped in to continue his work. My name is Iago Toral (itoral), and together with my colleagues Alejandro Piñeiro (apinheiro) and José Casanova (chema), we have been hard at work learning about the V3D GPU hardware and Eric’s driver design over the past few months.

Learning a new GPU is a lot of work, but I think we have been making good progress and in this post we would like to share with the community some of our recent contributions to the driver and some of the plans we have for the future.

But before we go into the technical details of what we have been up to, I would like to give some context about the GPU hardware and current driver status for Raspberry Pi 4, which is where we have been focusing our efforts.

The GPU bundled with Raspberry Pi 4 is a VideoCore VI capable of OpenGL ES 3.2, a significant step above the VideoCore IV present in Raspberry Pi 3 which could only do OpenGL ES 2.0. Despite the fact that both GPU models belong in Broadcom’s VideoCore family, they have quite significant architectural differences, so we also have two separate OpenGL driver implementations. Unfortunately, as you may have guessed, this also means that driver work on one GPU won’t be directly useful for the other, and that any new feature development that we do for the Raspberry Pi 4 driver stack won’t naturally transport to Raspberry Pi 3.

The driver code for both GPU models is available in the Mesa upstream repository. The codename for the VideoCore IV driver is VC4, and the codename for the VideoCore VI driver is V3D. There are no downstream repositories – all development happens directly upstream, which has a number of benefits for end users:

  1. It is relatively easy for the more adventurous users to experiment with development builds of the driver.
  2. It is fairly simple to follow development activities by tracking merge requests with the V3D and VC4 labels.

At present, the V3D driver exposes OpenGL ES 3.0 and OpenGL 2.1. As I mentioned above, the VideoCore VI GPU can do OpenGL ES 3.2, but it can’t do OpenGL 3.0, so future feature work will focus on OpenGL ES.

Okay, so with that introduction out of the way, let’s now go into the nitty-gritty of what we have been working on as we ramped up over the last few months:

Disclaimer: I won’t detail here everything we have been doing because then this would become a long and boring changelog list; instead I will try to summarize the areas where we put more effort and the benefits that the work should bring. For those interested in the full list of changes, you can always go to the upstream Mesa repository and scan it for commits with Igalia authorship and the v3d tag.

First we have the shader compiler, where we implemented a bunch of optimizations that should be producing better (faster) code for many shader workloads. This involved work at the NIR level, the lower-level IR specific to V3D, and the assembly instruction scheduler. The shader-db graph below shows how the shader compiler has evolved over the last few months. It should be noted here that one of the benefits of working within the Mesa ecosystem is that we get a lot of shader optimization work done by other Mesa contributors, since some parts of the compiler stack are shared across multiple drivers.

Bar chart with y-axis range from -12.00% to +2.00%. It is annotated, "Lower is better except for Threads". There are four bars: Instructions (about -4.75%); Threads (about 0.25%); Uniforms (about -11.00%); and Splits (about 0.50%).

Evolution of the shader compiler (June vs present)

Another area where we have done significant work is transform feedback. Here, we fixed some relevant flushing bugs that could cause transform feedback results to not be visible to applications after rendering. We also optimized the transform feedback process to better use the hardware for in-pipeline synchronization of transform feedback workloads without having to always resort to external job flushing, which should be better for performance. Finally, we also provided a better implementation for transform feedback primitive count queries that makes better use of the GPU (the previous implementation handled all this on the CPU side), which is also correct at handling overflow of the transform feedback buffers (there was no overflow handling previously).

We also implemented support for OpenGL Logic Operations, an OpenGL 2.0 feature that was somehow missing in the V3D driver. This was responsible for this bug, since, as it turns out, the default LibreOffice theme in Raspbian was triggering a path in Glamor that relied on this feature to render the cursor. Although Raspbian has since been updated to use a different theme, we made sure to implement this feature and verify that the bug is now fixed for the original theme as well.

Fixing Piglit and CTS test failures has been another focus of our work in these initial months, trying to get us closer to driver conformance. You can check the graph below showcasing Piglit test results to have a quick view at how things have evolved over the last few months. This work includes a relevant bug fix for a rather annoying bug in the way the kernel driver was handling L2 cache invalidation that could lead to GPU hangs. If you have observed any messages from the kernel warning about write violations (maybe accompanied by GPU hangs), those should now be fixed in the kernel driver. This fix goes along with a user-space fix to go that should be merged soon in the upstream V3D driver.

A bar chart with y-axis ranging from 0 to 16000. There are three groups of bars: "June (master)"; "Present (master)"; Present (GLES 3.1)". Each group has three bars: Pass; Fail; Skip. Passes are higher in the "Present (master)" and "Present (GLES 3.1)" groups of bars than in the "June (master)" group, and skips and fails are lower.

Evolution of Piglit test results (June vs present)

A a curiosity, here is a picture of our own little continuous integration system that we use to run regression tests both regularly and before submitting code for review.

Ten Raspberry Pis with small black fans, most of them in colourful Pimoroni Pibow open cases, in a nest of cables and labels

Our continuous integration system

The other big piece of work we have been tackling, and that we are very excited about, is OpenGL ES 3.1, which will bring Compute Shaders to Raspberry Pi 4! Credit for this goes to Eric Anholt, who did all the implementation work before leaving – he just never got to the point where it was ready to be merged, so we have picked up Eric’s original work, rebased it, and worked on bug fixes to have a fully conformant implementation. We are currently hard at work squashing the last few bugs exposed by the Khronos Conformance Test Suite and we hope to be ready to merge this functionality in the next major Mesa release, so look forward to it!

Compute Shaders is a really cool feature but it won’t be the last. I’d like to end this post with a small note on another important large feature that is currently in early stages of development: Geometry Shaders, which will bring the V3D driver one step closer to exposing a full programmable 3D pipeline – so look forward to that as well!


manuti avatar

Awesome!!! Increíble trabajo el vuestro.

Kenneth Howe avatar

Thank you for your hard work and dedication.
Awesome job that you are doing!

I like that I am finally able to use on the Raspberry Pi 4 and I am looking forward to future improvements.

Andrey Yaromenok avatar

Great news!

>>the VideoCore VI GPU can do OpenGL ES 3.2, but it can’t do OpenGL 3.0,
Can you give a bit more details on this issue?

horace avatar

yes, i would also find that interesting. what is missing for opengl 3.0?

Charlie Birks avatar

Looking at Mesa’s code and what the driver currently supports, it seems that RGTC and conditional rendering are the missing bits…

Alejandro Piñeiro avatar

>>>the VideoCore VI GPU can do OpenGL ES 3.2, but it can’t do OpenGL 3.0,
> Can you give a bit more details on this issue?

It is an issue with HW limits. Videocore VI hw only supports up to 4 multiple render targets.

For OpenGL ES that is enough, as the minimum value for GL_MAX_DRAW_BUFFERS is 4 (see table 6.27 on OpenGL ES 3.0 spec).

But for OpenGL 3.0 that is not enough, as the minimum value for GL_MAX_DRAW_BUFFERS is 8 (see table 6.51 on OpenGL 3.0 spec).

john jones avatar

will the V3D support the following extensions ?
(a lot of code use them as a pack so would help a LOT ;-)

* KHR_debug
* KHR_texture_compression_astc_ldr
* KHR_blend_equation_advanced
* OES_sample_shading
* OES_sample_variables
* OES_shader_image_atomic
* OES_shader_multisample_interpolation
* OES_texture_stencil8
* OES_texture_storage_multisample_2d_array
* EXT_copy_image
* EXT_draw_buffers_indexed
* EXT_geometry_shader
* EXT_gpu_shader5
* EXT_primitive_bounding_box
* EXT_shader_io_blocks
* EXT_tessellation_shader
* EXT_texture_border_clamp
* EXT_texture_buffer
* EXT_texture_cube_map_array
* EXT_texture_sRGB_decode

Chris H avatar

Would it not be possible to somehow emulate additional render targets?

laurent avatar

Nice work guys, keep going on ;)
One question though: the V3D/VC4 will also helps to move the maximum of the blob features on the open source driver, in order to use the mainline Linux kernel (such as DSI screen, CSI camera and so on), or is it just Mesa related?

Iago Toral avatar

We are only working on the Mesa side of things.

Andrew Oakley avatar

I really want our CI system at work, to be a bunch of brightly-coloured Pibows in a pristine white cupboard. “And this, Ms. Impressive-Visitor, is where we keep the rainbows that drive our build process…”

TheBuzzSaw avatar

Any chance of Vulkan support on the VCVI?

Alejandro Piñeiro avatar

For now we are focusing on progressing the GLES driver only. The hardware is capable of doing Vulkan though so of course we would like to work on that as well in the future.

Ismael Salas López avatar

What do I need to know to work with you, you’re my idols. I would like to know more that about the work you do and, if is possible, collaborate with you.
It’s a very interesting topic to me about how do you develop the graphics driver for the Raspberry Pi

Bastien avatar

What about Full KMS ?

Iago Toral avatar

We are only working on progressing GLES driver, but I believe there is a different team working on this.

Mr Casa avatar

just wondering if this any of this work on rpi4 vc6 will help with hw encoding performance?

Iago Tora avatar

I guess you are talking about hardware accelerated video encoding. I don’t think our work will help with that.

James Hughes avatar

Codec performance is looked at by a different team, but on the whole it’s already running fairly close to maximum (1080p50 or so). There is no HW support for H265 encoding, only decoding.

Charlie Birks avatar

Where should I report bugs? My code seems to trigger a few…

Chema Casanova avatar

Here you have the instructions about how to submit bugs to Mesa3d

You can post issues at

Iago Toral avatar

Make sure to tag them with the V3D label.

Alejandro Piñeiro avatar

> Where should I report bugs? My code seems to trigger a few…

For bugs on the mesa driver, you can report them here:

using the label v3d.

Charlie Birks avatar

Okay, definitely know where to go now :). Looks like I’m down to one bug with git master, will report when I’m back on my Pi.

Axel Richter avatar

Wow, thats awesome. Now Minetest runs great on this little unit (Pi 4). With OpenGL 2.1. i’ll see future. You Guys are great. The Pi is going better and better. Vlc run also fast for Internetradio. This is the nicest and stablest mini desktop. I like the noiseless and compact version of linux pc. See future of your work.

Greetings Axel Richter

Marek avatar

Thanks guys !
Keep the great job on!
Having proper drivers is a “must have” for me.
Rpi had sluggish performance for too long..

Mikael Bonnier avatar

Is it possible to run FreeCAD and Blender in Raspbian Buster on Raspberry Pi 4 Model B with 4 GB RAM?

Vaticinator avatar

Blender 2.79 works.

Nick avatar

FreeCAD requires OpenGL 2.0 or later, so it’s technically possible to run it on the Raspberry Pi. But Blender requires OpenGL 3.3, so it can’t work on any existing Pi.

But it’s more complicated with Blender, considering it also needs SSE2, which is x86-specific, and 1GB video RAM as a minimum requirement, which is clearly out of the scope of the Raspberry Pi.

horace3d avatar

blender 2.79 works fine and is in the raspbian repository. it’s still a very nice and useful 3d-animation software.

blender 2.80 won’t work anymore unfortunately. even if the raspberry pi 4 supported opengl 3.3 it probably would be too slow for some of the new realtime rendering features…

Andreas Bergmeier avatar

So reading this I assume, that Igalia got access to some Hardware Docs for VC6.
Is there any chance the community is getting access?

James Hughes avatar

Unlikely at this stage.

horace avatar

unfortunately freecad 0.18 from the raspbian repository crashes if you start a new project.

but actually the raspberry pi should be able to run it. seems to be some bug that maybe should be reported?

Thomas avatar

Great work guys, finally a good driver for me.

Ayman avatar

I tried to build the V3D Driver for two days. it did not work. Can someone put some simple instruction to how to build the driver, and how to use the outcome of the compiled files? Thanks.

klaus avatar

i write down how compile thes mesa driver on the raspberry pi 4 on 64 bit system. It is in german, sorry, but the code is english and have you questions, don’t hesitate to ask me. look at

MG avatar

will we get EXT_buffer_storage in the for GLES?

Salvador avatar

How about S3TC texture compression support for OpenGL? At least a software implementation in driver. A lot of games that can run on the PI need this.

Salvador Cipolla avatar

What about S3TC support? there is a chance for at least a software implementation in driver? there is several games that can run on the PI but need this.

Super_Pizza avatar

Good Work! I’m just waiting for V3D to have great performances as advertised.
And keep up the work with openGL ES(Vulkan would be cool too)
The Pi4 has still bad performances, and I would REALLY like Smooth performance like it was with the Pi3.
It has been too long…

Comments are closed