Gpu on Christian Gmeiner

PanVK Extension Sprint: Mesa 26.1

Mon, 20 Apr 2026 00:00:00 +0000

Last week marks the Mesa 26.1 branch point, and I wanted to take a moment to look back at what happened on the PanVK front.

Spoiler: it was a busy one.

The landscape

PanVK - the Vulkan driver for Arm Mali GPUs (Valhall and newer) - is a collaborative effort. Collabora has been doing incredible work on the compiler backend and the foundational infrastructure. Arm themselves are actively contributing to the open source Mali GPU stack as well, reviewing patches and pushing driver quality forward. On the Igalia side, my focus this cycle was Vulkan extension coverage. The kind of work that doesn’t make for flashy demos but is absolutely critical for real-world application compatibility - especially for things like DXVK.

mesamatrix

Sun, 16 Jun 2019 15:40:01 +0000

You might be familiar with mesamatrix - a nice site to track the state of all GPU drivers provided by Mesa. Ohh.. did I say all? Let’s have a closer look:

This page is a graphical representation of the text file docs/features.txt from the Mesa repository.

So wouldn’t it be sick to get etnaviv mentioned in docs/features.txt and onto the matrix?

First mesamatrix needs to know/support etnaviv. This seems to be quite simple as there is already a pull request to add a bunch of embedded GPU drivers: Add VC4,VC5 and Vivante GPUs

etnaviv officially landed

Thu, 12 Jan 2017 19:48:36 +0000

After years of hard work the etnaviv team reached an other very important milestone. The gallium driver and the renderonly library got pushed into mesa’s git repository and will be released with mesa 17.0 - yeah!

This does not mean we are done with development at all. There are many interesting topics to work on and some of them like better support for newer IP cores or a reworked GLSL compiler should see the light of day during the next months.

etnaviv: kmscube

Fri, 25 Sep 2015 21:39:10 +0000

Last Friday I got kmscube successfully running with mesa and the new etnaviv DRM kernel driver. At this time I got it not really pixel perfect and I spend some nights to get it fixed. It turns out that I need a small mesa hack to get the rendering correct.

You may ask why did it so long to get it working? Let me explain it to you.

The Vivnate GPU is a so called render-only GPU which does not have any kind of scanout logic in it. It can only render to physical memory and this only in a tiled memory layout. So we need to use the resolve engine found on the GPU to de-tile the rendered image and blit it to the dumb buffer. Currently mesa has no software support for this kind of hardware, but I think that could change soon.

Vivante meets devicetree

Sat, 24 May 2014 23:41:14 +0000

It took me some time to rework the device tree bindings but it looks like it starts to work!

Gets loaded into :

[ 3.358155] vivante: module is from the staging directory, the quality is unknown, you have been warned. [ 3.373087] imx-sgtl5000 sound.15: sgtl5000 2028000.ssi mapping ok [ 3.379150] [drm] add child gpu2d [ 3.379154] [drm] add child gpu3d [ 3.380395] vivante-gpu 134000.gpu2d: pre gpu[idx]: 0x00000000 [ 3.380401] vivante-gpu 134000.gpu2d: adding core @idx 1 [ 3.380408] vivante-gpu 134000.gpu2d: post gpu[idx]: 0xecb56c10 [ 3.380460] vivante gpu-subsystem.11: bound 134000.gpu2d (ops gpu_ops [vivante]) [ 3.380467] vivante-gpu 130000.gpu3d: pre gpu[idx]: 0x00000000 [ 3.380473] vivante-gpu 130000.gpu3d: adding core @idx 0 [ 3.380479] vivante-gpu 130000.gpu3d: post gpu[idx]: 0xecb57210 [ 3.380502] vivante gpu-subsystem.11: bound 130000.gpu3d (ops gpu_ops [vivante]) [ 3.380533] IO:R f0200018 14010000 [ 3.380537] IO:R f0200020 00002000 [ 3.380540] IO:R f0200024 00005108 [ 3.380546] vivante gpu-subsystem.11: model: 2000 [ 3.380551] vivante gpu-subsystem.11: revision: 5108 [ 3.380554] IO:R f020001c e0296cad [ 3.380558] IO:R f0200034 c9799eff [ 3.380561] IO:R f0200074 2efbf2d9 [ 3.380564] IO:R f0200084 00000000 [ 3.380567] IO:R f0200088 00000000 [ 3.380572] vivante gpu-subsystem.11: minor_features: c9799eff [ 3.380578] vivante gpu-subsystem.11: minor_features1: 2efbf2d9 [ 3.380583] vivante gpu-subsystem.11: minor_features2: 0 [ 3.380588] vivante gpu-subsystem.11: minor_features3: 0 [ 3.380592] IO:R f0200000 00070100 [ 3.408629] IO:R f0200004 7fffffff [ 3.408632] IO:R f0200000 00070100 [ 3.412940] vivante gpu-subsystem.11: 130000.gpu3d: using IOMMU [ 3.413080] IO:R f01f8018 14010000 [ 3.413083] IO:R f01f8020 00000320 [ 3.413087] IO:R f01f8024 00005007 [ 3.413093] vivante gpu-subsystem.11: model: 320 [ 3.413098] vivante gpu-subsystem.11: revision: 5007 [ 3.413101] IO:R f01f801c e02c7eca [ 3.413105] IO:R f01f8034 c1399eff [ 3.413108] IO:R f01f8074 020fb2db [ 3.413111] IO:R f01f8084 00000000 [ 3.413114] IO:R f01f8088 00000000 [ 3.413120] vivante gpu-subsystem.11: minor_features: c1399eff [ 3.413126] vivante gpu-subsystem.11: minor_features1: 20fb2db [ 3.413131] vivante gpu-subsystem.11: minor_features2: 0 [ 3.413136] vivante gpu-subsystem.11: minor_features3: 0 [ 3.413139] IO:R f01f8000 00070100 [ 3.438615] IO:R f01f8004 7fffffff [ 3.438619] IO:R f01f8000 00070100 [ 3.442583] vivante gpu-subsystem.11: 134000.gpu2d: using IOMMU [ 3.442681] [drm] Initialized vivante 1.0.0 20130625 on minor 1

Vivante MMU v1

Sat, 03 May 2014 20:25:35 +0000

I did spend quite some time the last days to figure out how the MMU v1 could work and what all the code in the v4 Kernel sources does. It took quite some time and a little hint from Russel to finally understand it. So lets start with the technical details.

The MMU uses a page table with a maximum size of 256KB. Where each Page Table Entry (PTE) is 4 byte long. The used page size is 4K and can not be changed via some registers etc. Lets have a look at the bit layout of a PTE.

The next steps for etnaviv

Sat, 22 Feb 2014 17:54:17 +0000

I did spend some time to find the cause for the rendering issues during running some egls2 demos. The fix is a simple one-liner and I would say that GC8xx and GC2000 are ‘equal’ now. That means general work on etnaviv can start now. Currently I am looking in different problem zones and where to start.

Update mesa fork
Start working on an improved compiler
Start working on an kernel interface

I think that Rob will start soon on the kernel interface and the mesa update should be doable during some hours. So I think the next big and important step is to improve the compiler. What should I say… I have basic compiler understanding, did wrote a compiler and VM during my study… thats it. I have never written a single line of glsl and I do not completely understand the Vivante GPU. So a perfect starting point for doing some hacking 🙂 The success rate will be quite low and I hope to not lose my motivation too soon.

Mesa meets GC2000

Sat, 15 Feb 2014 20:18:25 +0000

Here is the first result of running mesatest_gles on mesa&etna:

Following tests are showing good visual results compared to swrast:

Hello_Triangle/CH02_HelloTriangle
Simple_VertexShader/CH08_SimpleVertexShader
CubeVBO/cube_vbo
ParticleSystem/CH13_ParticleSystem
Viewports/viewports

All other are visual corrupted or segfault. So there is still some work done to get all demos up and running.

GC2000 support for etnaviv

Sun, 09 Feb 2014 17:22:56 +0000

Today I hit an important milestone for etnaviv – an open source user-space driver for the Vivante GCxxx series of embedded GPUs. I finally got GC2000 support to a level that it seems to work. It took me some months to get there. At the beginning it sounds easy to rebuild a ‘driver’ if you get readable command buffer dumps. I did start with working on a simple replay program to render a cube in the same was as the binary blob does it. But what should I say… it is quite boring to do everything by hand and not taking advantage of libetnaviv and the ‘driver’ at all. So I decided to go the hard way and try to fix/add all missing bits until it renders something. The good thing is that I have now some knowledge about the structure of libetnaviv, the dirver and mesa in general. It helps a lot if you know why stuff is done that way.