With Qualcomm hardware, Rob finds no conflict of interest. He began this driver less than two months ago with using a DragonBoard as his base development platform, which is the mobile development board with a Snapdragon S3 APQ8060. In terms of how he went about the Snapdragon graphics, reverse engineering is similar to what is being done within the Lima project. He developed an LD_PRELOAD shim for intercepting system calls, analyzed the existing open-source kernel code for understanding its API, and then worked out other tools for analyzing other bits of the Qualcomm graphics processor. Here is a bit from a blog post he is currently working on that describes his reverse-engineering effort.
The libwrap code I wrote logs information about the blits (cmdstream, and various parameters like gpu addresses, surface dimensions, blit coords) to a simple .rd log file (which amounts to a sequence of type/length/value fields). These .rd files get processed with a utility I wrote called "redump", to generate a reports [example] showing side-by-side comparisons of the cmdstream, with similarities and parts of dwords that appeared to match surface and blit parameters highlighted. It is not a perfect disassembly of the command stream, but it certainly helps to spot patterns.
Once I had a reasonable collection of tests for the types of blit operations which are important for an x11 EXA driver, I started varying parameters to figure out the limits, ie. what is the largest blit x, y, width, height, max surface width, height, stride, etc, to establish how many bits are used to encode different fields in the command stream. In some cases, I noticed there were multiple encoding options so parameters could be packed if fewer dwords if less bits where needed to encode the parameters. (For the current EXA driver I'm pretty much using the worst case encoding options so far, to keep things simple.)
With these tests, and the corresponding redump reports, I started work on implementing the EXA accel fxns for the xf86-video-freedreno driver. The work on the EXA driver really only started about 1.5 weekends ago (and most of the time at the beginning was just getting a skeletal driver setup, which is based on a stripped down and simplified xf86-video-msm).
Rob started out with 2D acceleration support as a starting point. In addition, this support is important since Qualcomm does not even provide a DDX (X.Org) driver for the Snapdragon platform (as most Qualcomm devices are just running Android anyhow with Qualcomm not supporting any other software platform). In addition, the 2D upbringing should help the open-source 3D effort, "from what I've been able to figure out from the GPL kernel driver, a lot of the infrastructure like pixel and [command stream] buffer allocation, and [command stream] submission, appear to be similar for 2d and 3d, so I think a lot of the work done so far for 2d accel will be useful when it comes to working on the 3d part as well."
As far as where his open-source 2D acceleration support is at now for the Snapdragon, he has basic solid/copy/composite operations working on his reverse-engineered driver. Though right now there are some fundamental performance issues as there is not yet support for submitting multiple blits simultaneously, but that's being worked on.
Rob is calling this new open-source driver the "Freedreno" project. Adreno is the marketing name for the graphics core found on the Snapdragon SoC, which is what Qualcomm renamed the graphics products to following their acquisition of the ATI Imageon product line. The Adreno series is the actual target of this Freedreno driver effort.
For those not familiar with the current capabilities of the Snapdragon graphics, the Adrendo 220 found in the Qualcomm MSM8660/MSM8260 is clocked at 266MHz but can be overclocked up to 400MHz and supports OpenGL ES 2.0, OpenGL ES 1.1, OpenVG 1.1, EGL 1.3. The Adreno 225 meanwhile is inside the MSM8960 and tacks on some Direct3D 9 support and other features, although not too relevant in the Linux world.
In terms of how Freedreno will play with Qualcomm's current kernel graphics driver, Rob says, "Quick note on the kernel: the existing driver from qualcomm is what I'd call a semi-DRM driver. It is using GEM buffers, so it gives us what we would need eventually for DRI2 and 3d. But not mode setting (which is handled via fbdev driver, also opened by xserver), and not a batchbuffer sort of interface for cmd submission.. cmd submission is handled via separate kgsl-2d/3d devices which are not aware of GEM buffer handles, so mapping buffers to the GPU cannot be handled as part of the cmd submission. So far I'm leaving the kernel driver mostly as-is (sans maybe some minor backwards compatible enhancements), because it is essential to be able to run test code based on the existing binary blob libraries back to back with work-in-progress xorg/mesa drivers. One approach to cleaning up the kernel part might be to provide an emulation layer to emulate the old interfaces, although for now there are enough other things to do that I haven't given this much thought yet. Of course, volunteers are always welcome."
This will certainly be an interesting project and will hopefully succeed quite well, let us just hope that Texas Instruments or Linaro does not try to halt Rob's development work on this open-source code, even though it is being done exclusively on his own time. The xf86-video-freedreno driver and other Freedreno code are being housed on Gitorious.org.
Discuss this article in our forums, IRC channel, or email the author. You can also follow our content via RSS and on social networks like Facebook, Identi.ca, and Twitter (@Phoronix and @MichaelLarabel). Subscribe to Phoronix Premium to view our content without advertisements, view entire articles on a single page, and experience other benefits.