Etnaviv on Christian Gmeiner

Multiple Render Targets for etnaviv

Thu, 16 Jan 2025 00:00:00 +0000

Modern graphics programming revolves around achieving high-performance rendering and visually stunning effects. Among OpenGL’s capabilities, Multiple Render Targets (MRTs) are particularly valuable for enabling advanced rendering techniques with greater efficiency.

With the latest release of Mesa 24.03 and the commitment from Igalia, the etnaviv GPU driver now includes support for MRTs. If you’ve ever wondered how MRTs can transform your graphics pipeline or are curious about the challenges of implementing this feature, this blog post is for you.

CI-Tron: A Long Road to a Better Board Farm

Wed, 30 Oct 2024 00:00:00 +0000

I’m a big supporter of finding problems before they get into the code base. The earlier you catch issues, the easier they are to fix. One of the main tools that helps with this is a Continuous Integration (CI) farm. A CI farm allows you to run extensive tests like deqp or piglit on a merge request or even on a private git branch before any code is merged, which significantly helps catch problems early.

It All Started With a Nop - Part I

Thu, 11 Jul 2024 00:00:00 +0000

Note

hwdb - The only truth

Fri, 12 Apr 2024 00:00:00 +0000

Trusting hardware, particularly the registers that describe its functionality, is fundamentally risky.

tl;dr

The etnaviv GPU stack is continuously improving and becoming more robust. This time, a hardware database was incorporated into Mesa, utilizing header files provided by the SoC vendors.

If you are interested in the implementation details, I recommend checking out this Mesa MR.

Are you employed at Versilicon and want to help? You could greatly simplify our work by supplying the community with a comprehensive header that includes all the models you offer.

The Year 2023 in Retrospect

Tue, 26 Dec 2023 09:03:20 -0800

Holidays are here and I have time to look back at 2023. For six months I have been working for Igalia and what should I say?

I ❤️ it!

This was the best decision to leave my comfort zone of a normal 9-5 job. I am so proud to work on open source GPU drivers and I am able to spend much of my work time on etnaviv.

Driver maintenance

Before adding any new feature I thought it would be great idea to improve the current state of etnaviv’s gallium driver. Therefor I reworked some general driver code to be more consistent and to have a more modern feeling, and made it possible to drop some hand-rolled conversion helpers by switching to already existing solutions (U_FIXED(..), S_FIXED(..), float_to_ubyte(..)).

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.