SW that matters

During the past few weeks/months we have been seeing a lot of news about the future HW of different vendors. Qualcomm has been pushing out news about their 1.5GHz dual-core Snapdragon (ARM cortex-A8 based, Qualcomm modified), Samsung about their Orion a 1GHz dual-core ARM Cortex A9 and Marvell its tri-core Armada 628 (once again ARM based, ARM v7 cores) which can have the main two cores running up to 1.5GHz and the third at 624 MHz. Quite impressive, right?

Lets first think about the figures that the different vendors are providing. What do we do with all of that power? at least form my point of a view this is an excellent questions.
Take for ex the first generation iPhone - ARM11 downclocked to run at 412Mhz, PowerVR MBX light (optimized for low power consumption instead of speed), 128MB of RAM. Still with these figures in the paper even the first iPhones can still beat many of the devices in the markets today. And bare in mind that iPhone 2G was announced already at at the beginning of 2007.
Why is that? Well the SW and especially the framework has been build in a respect of the underlaying HW. And because of the fact that Apple was ready to make compromises with the device - no multitasking which makes things a lot simpler (limited support existing nowadays), simple set of features which really work, extremely simple and limited set of widgets without theming or the 480x320 pixel resolution combined with a color depth of 18 bits (helping a lot with memory bandwidth usage [1]) - focusing on simplicity and usability.

And its not only about the framework from the SW side that matters - badly implemented drivers, SW which is not making the use of the architecture and features a chip offers (separate cores for video, image processing, blitting, etc.). This will effect to the overall performance.


The other thing with these nice MHz figures is the battery consumption. My self I would at least like to get my hands on one touch screen based device which would really last longer than my working day. Of course this is also how the power management of the device is done, which comes once again to well designed and implemented SW...

Instead of getting the MHz's up, how about as an ultimate goal to get the CPU to run as slow as possible and really shifting the operations to GPU. The GPU's can in many cases achieve far better efficiency than the CPU. This would of course still require something from the SW - framework build in such away that it can really utilize the GPU and not just making it to do some fancy effects when switching between applications.


[1] 320x480pixels, 18 bits for a pixel and rendering that 60 times per sec vs. that a frame would hold 800 x 480 pixels (as the Nexus has).

Difficulty of developing Open Source Linux drivers for GPU

During the last few days there as been an active discussion ongoing at dri-devel list about Open Source Graphics drivers. The discussion was initiated by Qualcomm's RFC message - [RFC] Qualcomm 2D/3D graphics driver.

Qualcomm's Linux team has been working on Open Sourced Kernel drivers for their chipset. What they have done so far is that they have build DRM driver with a limited set of supported functionality to enable DRI2. Their own userland parts of the drivers do still utilize the KGSL (Kernel Graphics Support Layer) interface to allocate memory making DRM just as an API to be more closer with the mainstream Linux Graphics stack. Qualcomm does still have some plans in the future to move to an standard design - possibly TTM.


The dri-devel list the opinions about drivers with an userland binary blobs was made quite clear - if you aren't going to open the whole drivers don't try to push them to mainline. Basically the door was slammed from the Qualcomm efforts for pushing the drivers in.

In between the lines I think there were some excellent point made in this discussion.
The bottom line is that the community cannot work with the drivers if there exists and dependency to closed sourced userland - this is definitely clear. With this kind of an setup it is just impossible to work with the drivers. On the otherhand if the community is going to bombard down all the drivers with the closed userland parts (even without making sure what are the attemts to open source them) how are we ever going to see open sourced mobile GPU drivers? From my point of view the community also has the means to guide this work to right direction - giving comments to the request. It really seems that the Qualcomm guys do have the enthusiasm to develop the open source drivers. How about making sure that these guys are taking the correct steps also with the userland and making sure that the Kernel bits are as they should?