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. ...
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.
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.
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. ...