Codethink is hoping that ARM will become directly involved with this open-source project itself. Below is the rationale for this work that I received in a currently-private document.
While everything is pretty much done on the x86 front, and each remaining vendor has its own stance on how to support open source software, nothing has happening on the ARM front with respect to graphics drivers. This is now going to change.
From a technical point of view, ARM's Mali GPU is the perfect candidate for a reverse engineering project. The hardware is well structured and beautifully simple. The driver stack is equally structured and highly logical. The kernel interface is kept simple and sane. Compared to some of its competitors, the Mali is a thing of beauty. It gives this driver developer the same buzz that the original ATI R500 display engine did when implementing the radeonHD driver.
ARM has done a lot for and with open source software before, and will undoubtedly have a big stake in open source software in the future. There is a distinct possibility that ARM will not only applaud a free software driver project for their Mali, but they might also actively contribute to it.
Malis are becoming more and more widespread. While the mali-200 is readily and cheaply available in the telechips SoC (available in many shady chinese tablets), the mali400 can be bought in the Samsung exynos (in, amongst others, their top of the range Galaxy s2 smartphone), and a slew of cheap chinese tablets (AMLogic, Allwinner, Realtek, ...). There are even some low cost development boards available today with the ST/E based Snowball, and the Samsung based Origen. The next generation Mali will undoubtedly be even more popular.
The future community can get themselves a brand new mali-200 based tablet for as little 80EUR, and a much improved next generation chinese tablet with mali-400 for 150EUR. Never was a major graphics driver project this cheap and portable at the same time.
Most of the Malis are today shipped in Android based devices. Even though Android is not a classical linux operating system with a full GNU stack, it does suffer from the same issues with relation to binary graphics drivers. A major stumbling block for providing updates to Android devices are the lack of open source drivers. An updated kernel and updated toolchain are just as big an issue for drivers for Android as for another linux based operating system. Community generated android distributions, like cyanogenMod, are now too becoming aware of this problem.
Additionally, that document does shed some light on the design details. In terms of the Mesa usage, "It is highly likely that [the driver project] will end up using the Mesa infrastructure, but this is not fixed at this point, maybe somewhere in february, things will be much clearer. [This project] will currently not change the kernel side, as that would only break compatibility with the existing binary driver and will only hamper reverse engineering efforts. Whether [the driver] will end up using DRM infrastructure, and which of the various memory managers it will support, is all pretty academic at this point." Hopefully more kernel-level improvements will come later.
The most complex part of the Mali reverse-engineering was breaking down the shader compiler. Like the Nouveau driver and most other GPU reverse-engineering, this was done via capturing, replaying, and analyzing the command stream that's submitted to the graphics processor when using the binary driver. Basically it's submitting simple commands to the GPU and then analyzing what happens, after that happens enough times, you can begin to understand the hardware. That is a "clean-room" approach, but it also appears that some decompilation of the binary driver itself was also done. "But since there are few restrictions for the infrastructure, some manual decompilation has taken place to help document the usage of mali registers and the command stream. Special care is taken that no methods or algorithms of the original driver are used."