Building the Moblin Media Player Gui with the Intel Compiler

Introduction

The media player project is know as Hornsey and depends on clutter, clutter-gst, bickley, nbtk, bognor-regis, libunique, libstartup-notification and gtk+-2.0.

For the build enironment I am using the Moblin2 development image installed on a dualcore laptop. 

In this paper, I am only building the top level of the player, and not the underlying library dependencies.

Setting up the build environment 

Download and install the moblin dev image from here

http://moblin.org/documentation/moblin-sdk/download-development-images6

Create a USB or CD and install. Instructions here:

http://moblin.org/documentation/test-drive-moblin/using-moblin-live-image

Building the media player gui

Downloading the sources

Boot up Mobln2

In directory of your choice get the Hornsey code

    git clone git://git.moblin.org/hornsey

Directory structure should look similar to this:

    <dev dir>/hornsey

Go into the hornsey directory and change the branch to match  the moblin dev image
e.g.  

         cd hornsey
         git checkout –b origin/moblin-2.0

 FYI you can get a list of branches by doing
      
        git  branch –a
 

Building the sources

Choosing which compiler

Building with GCC

For our installation, we'll use the environment variable  $PREFIX custom directory so as not to override any existing installation

     export PREFIX=~/dv/hornsey/gcc
    ./autogen.sh --prefix=$PREFIX

Building with ICC

To build the library with the Intel compiler use the following commands

    export CC=icc
    export CXX=icc
    export CFLAGS="-02 -g"
 

   export PREFIX=~/dv/hornsey/icc
  ./autogen.sh --prefix=$PREFIX

Continuing the build

When autogen has completed you should get a message similar to the display below 

      config.status: config.h is unchanged
      config.status: executing depfiles commands
      config.status: executing default-1 commands
      config.status: executing po/stamp-it commands
      Now type `make' to compile hornsey

Now build the source by calling make

       
        make clean

        make

The progress of the make will be reported, the last few lines looking similar to this:

          CC    hrn-controls.o
          CC    nbtk-im-label.o
          CC    hornsey
        Making all in data
        Making all in po

Installing the media player

To install the new new media player call:

      make install

Checking the contents of the install dir :

ls -R  $PREFIX

    /home/sblairch/dv/hornsey/gcc:
                bin  share

    /home/sblairch/dv/hornsey/gcc/bin:
                hornsey

    /home/sblairch/dv/hornsey/gcc/share:
                applications  dbus-1  hornsey  icons  locale

Running the Media Player

The media player can be invoked by simple calling the executable  <install dir>/bin/hornsey

Introduction
Intel offers a wide range of software development tools designed for enabling the software developer to get great performance and end-user experience out of their application. At the same time it ensures with its wide range of development tools that performance bottlenecks can be identified quickly and coding errors and runtime issues can be pinpointed and fixed quickly. The purpose is to enable on-time delivery of mature and fast applications that showcase the user-friendliness, performance and feature richness of your applications.
Specifically for development projects targeting Moblin compliant applications and devices taking advantage of the Intel(R) Atom(TM) processor a set of software development tool suites is being offered. It bundles key development components addressing all phases of development from design, testing, bug fix cycle to performance tuning.
The following paragraphs will provide an insight into the Intel(R) Application Software Development Tool Suite for Intel(R) Atom(TM) processor and the Intel(R) Embedded Software Development Tool Suite for Intel(R) Atom(TM) processor. They will highlight the tools components included and their effective use.

Tools Overview
The Intel(R) Atom(TM) processor is specifically targeted at low-power IA-32 based designs for a wide range of small form factor devices. These include netbooks, settop boxes, consumer electronics, in-vehicle infotainment and other designs focusing on internet content consumption, telephony and mobile location based services. The one thing most of these designs have in common is that their form factor makes it inconvenient to develop software natively on these platforms. The Intel(R) Software Development Tool Suites for Intel(R) Atom(TM) processor take this into account and offer solutions that address cross development requirements for designs running Moblin compliant Linux* OS and other Linux* based operating systems.
The Intel(R) Application Software Development Tool Suite consists of 4 development tools components.

Intel(R) C++ Compiler
The Intel(R) C++ Compiler for Linux* has been optimized to harness key properties or the Intel(R) Atom(TM) processors architecture and get optimal performance out of it. The option switch –xSSE3_ATOM will cause the Intel(R) C++ Compiler to model the instruction pipeline of this in-order processor feeding instructions to it in an order that minimizes dependency stalls and resource stalls. Additionally it takes advantage of a complex set of heuristics to decide which type of assembly instructions to generate to speed up memory access, improve branch prediction and take account of the Intel(R) Atom(TM) processor’s floating point properties. Finally it also aggressively takes advantage of the SSE3 instruction set for vectorization and sped-up execution of thus parallelized loops.

Intel(R) Integrated Performance Primitives
The Intel(R) IPP offer a rich set of library functions and codecs to be used to speed up development of highly optimized routines for the handling of multimedia formats and data of any kind. They have been low-level hand optimized to provide their known performance strength and ease of use for Intel(R) Atom(TM) processor based platforms.

Intel(R) VTune(TM) Performance Analyzer
Finding the bottlenecks in your application, identifying where most time is spent during application and using event-based sampling to find hardware resource constraints that limit the performance potential of your application. This is the domain of the Intel(R) VTune(TM) Performance Analyzer. A VTune(TM) Performance Analyzer Sampling Collector (SEP) is included that allows for low overhead command line based performance data collection on the Intel(R) Atom(TM) processor based target device without any instrumentation of the code base to be analyzed.

Intel(R) Application Debugger
A rich and user friendly Eclipse* RCP based graphical user interface combined with OS signal awareness and thread awareness enable the developer to use this TCP/IP cross-debug solution to more easily find coding issues that affect application runtime behavior and correct them.

Intel(R) JTAG Debugger
In addition to these components the Intel(R) Embedded Software Development Tool Suite for Intel(R) Atom(TM) processor provides a JTAG debug solution that utilizing the same Eclipse* RCP based graphical user interface to give you access to the descriptor tables, page tables and all chipset registers with the detail that only it’s bitfield editor can provide. This debugger allows for high level language source level debugger of bootcode, OS kernel and device drivers.

Benefits for your development projects
The benefits of using these comprehensive tool suites are many and impact every phase of the software development process.

Improved performance in your critical applications and codecs due to the use of the Intel(R) C++ Compiler’s optimizations for the Intel(R) Atom(TM) processor or the Intel(R) IPP.

Performance tuning and avoidance of inefficient code in your application with the help of the Intel(R) VTune(TM) Performancer Analyzer, leading to a smoother and more responsive end-user experience

Faster coding issue detection and correction and thus improved maturity as well as faster time-to-market, faster development cycles for your project.

How to start with application development for Moblin on Intel® Atom™ processor
The Intel(R) Application Software Development Tool Suite supports a wide variety of Intel(R) Atom(TM) processor based devices. This means that there is not one single use case or usage model that will fit the needs of every developer. Development for Intel(R) Atom(TM) processor based devices tends to have one aspect in common however. In most cases you will want to take advantage of the performance and the high screen resolution of your regular development environment and deploy your build to the real hardware for validation and analysis only. In short, most commonly the usage model will be one of cross development.
The Intel(R) Application Software Development Tool Suite for Intel(R) Atom(TM) processor addresses this in multiple ways.

The Intel(R) C++ Compiler and the Intel(R) Integrated Performance Primitives will by default be installed on the development host system. To provide a protected build environment without host system library pollution it is however also supported to install these components into the Moblin* Image Creator 2 jailroot system or to install them into a Moblin* 2 developer image running inside a KVM* virtual machine or even on a real target. For the installation into Moblin* Image Creator 2 or into a KVM* image it is recommended to do this following the yum rpm repository based installation process outlined in the Moblin* Integration Guide Moblin_Integration.htm.

Moblin* Image Creator 2 kickstart scripts can be found at
http://software.intel.com/en-us/articles/moblin-integration-software-development-tool-suite-atom/
A template rpm repository definition file for the direct KVM* image installation of compiler and Intel(R) IPP can be found at http://software.intel.com/en-us/articles/installing-compiler-into-kvm-atom/.

The Intel(R) Application Debugger will with the standard installation package be installed on your development host. Via TCP/IP you can connect to and debug a process either running on actual Intel(R) Atom(TM) processor based target hardware or a KVM* virtual machine or some other virtualization method that assures you that the application to be debugged runs in a software environment identical to the later application deployment. Please also have a look at the Getting Started Guide Getting_Started.html that is part of the tool suite distribution for further details on the Intel(R) Application Debugger usage.

The Intel(R) VTune(TM) Performance Analyzer analyzes event based and time based sampling data on the development host. The data has been gathered on an Intel(R) Atom(TM) processor based target platform with low overhead giving you accurate sampling data. The analysis can be done within the standard KDE* or Gnome* based standard Linux* GUI you are used to for your development efforts.

How to develop, and optimize applications for Windows* running on Intel® Atom™ processors
When developing for a Microsoft Windows* XP or Windows* 7 based netbook whose platform is based on the Intel® Atom™ processor, the software development methodology is basically identical to what you are familiar with for writing an application that targets regular notebook PCs.

The whole range of Intel’s software development products are at your disposal.
o Intel® Parallel Studio
A plug-in into Microsoft* Visual Studio* to analyze, and develop multithreaded applications for netbooks, and other Windows/Intel Atom processor based systems
o Intel® C++ Compiler for Windows*
A build solutionto generate highly optimized application code
o Intel® Integrated Performance Primitives Library for Windows*
A highly optimized multimedia library – already including multi-threading / autoscaling
o Intel® Threading Building Blocks
A template library to implement multithreading through C++ templates

For more information on these tools please check on our website for more details on download, evaluation, usage and purchase: http://www.intel.com/software/products.

Additional details on Intel® Atom™ specific development under Windows can be found at

o Developing for Intel® Atom™ Processor running Linux* and Microsoft Windows* XP
http://software.intel.com/en-us/articles/development-atom-linux-and-windows/
o Optimized for the Intel® Atom™ Processor with Intel's Compiler
http://software.intel.com/en-us/articles/atom-optimized-compiler
o Using VTune™ Peformance Analyzer for Intel® Atom™ Processor on Windows* XP
http://software.intel.com/en-us/articles/using-vtune-atom-windows

Usage Details & Examples
The Intel Software network offers a wide range of further reading and whitepapers detailing the different use cases for the Intel(R) Software Development Tool Suites for Intel(R) Atom(TM) processor and it’s components.

Application Debugging in Cross-Debug Environment
http://software.intel.com/en-us/articles/cross-application-debugging/
Using the VTune(TM) Performance Analyzer Sampling Collector for Mobile Internet Devices
http://software.intel.com/en-us/articles/sampling-collector-mid/
Optimized for the Intel(R) Atom(TM) Processor with Intel's Compiler
http://software.intel.com/en-us/articles/atom-optimized-compiler/
Integrating Intel(R) Software Development Tool Suite Components with Moblin* Image Creator
http://software.intel.com/en-us/articles/moblin-integration-software-development-tool-suite-atom/
Installing the Intel(R) C++ Compiler and Intel(R) Integrated Performance Primitives into KVM* for Intel(R) Atom(TM) Processor targeted development
http://software.intel.com/en-us/articles/installing-compiler-into-kvm-atom/
Compile moblin2 kernel sources with Intel Compiler
http://software.intel.com/en-us/articles/compiler-moblin2-kernel-sources-with-intel-compiler/
Device Driver Debugging on Intel(R) Atom(TM) processor based devices http://software.intel.com/sites/products/documentation/hpc/atom/application/device_driver_debugging.pdf
Building Clutter* GUI libraries using the Intel(R) C++ Compiler
http://software.intel.com/en-us/articles/building-the-moblin-clutter-library-with-the-intel-compiler/
Building FFMEG using the Intel(R) C++ Compiler
http://software.intel.com/en-us/articles/how-to-build-ffmpeg-to-run-under-moblin-2/

References
Product Page: http://www.intel.com/software/products/atomtools
Documentation: http://software.intel.com/en-us/articles/intel-application-tool-suite-documentation/
http://software.intel.com/en-us/articles/intel-embedded-tool-suite-documentation/
Knowledge Base: http://software.intel.com/en-us/articles/software-development-toolsuite-atom-kb/all/1/
Forum: http://software.intel.com/en-us/forums/software-development-toolsuite-atom/

Conclusions
The Intel(R) Software Development Tool Suites for Intel(R) Atom(TM) processor provide a comprehensive development tools solution for Moblin compliant and Intel(R) Atom(TM) processor based platforms that is versatile and highly configurable in its usage model, tightly integrates with the Moblin SDK and brings the power of Intel’s software development tools solutions to the new class of devices and applications targeted by the Intel(R) Atom(TM) processor.

The application ‘ffmpeg’ consist of three executables and 5 libraries. All the sources can be downloaded using the following svn command:

Ø      svn checkout svn://svn.ffmpeg.org/ffmpeg/trunk ffmpeg

 Required patch

One version which I tried ( download: svn checkout svn://svn.ffmpeg.org/ffmpeg/trunk ffmpeg –r 17944)

has a known problem with the sources. If you try to build the code, then you will get a compile time error:

 libswscale/swscale.c:488: error: ‘PIX_FMT_YUV420PLE’ undeclared

The solution is solved by copying the contents of the libswscale directory from .   http://www.ffmpeg.org/releases/ffmpeg-0.5.tar.bz2    (see http://www.ffmpeg.org/download.html)

Please Note, only the libswscale directory should be copied over the top of the existing files.

Build Instructions

Following instructions will help you build ffmpeg under a Linux system assuming that the tar ball from the download is copied to <install_directory>:

 Ø      cd  <install_directory>

 Ø      cd tar xvfz  ffmpeg.tar.gz   #Extract the tar ball to your local directory. You will find a directory tree under the name ffmpeg installed. All the required sources are installed within this tree provided that you are not enabling any additional third party libraries.

 Ø      cd ffmpeg

 Ø      ./configure –help <cr> # to show all the options available to rebuild ffmpeg. For a reference build with gcc there is no need to provide any parameters to configure. However if you would like to enable any third party libraries like ‘libfaad’, ‘libx264’ etc. then you need to add --enable-libfaad --enable-libx264 etc. as parameters to configure. If this is required make sure that you have these sources available on your development environment and that the third party libraries are rebuilt with the selected compiler / compiler options.

 Ø      ./configure <parameters as below>

 Ø      make <cr> #recommended sequence is ‘make clean’ followed by ‘make’. The rebuild will take several minutes (depending on your development environment). Two versions of each executable are produced: ex. ‘ffmpeg’ and ‘ffmpeg_g’. The ‘*_g’ contains the executable with debug information while the ‘*’ is the stripped version. In addition ‘ffplay, ffplay_g, ffserver and ffserver_g’ are produced as executables and libavutil, libavcodec, libavformat, libavdevice and libswscale are rebuilt.

 Icc build:

Depending on what version of icc you are using different configure parameters may be necessary.

 Using icc v10.1.xxx:

 Ø      ./configure cc=icc --extra-cflags=”-xL –O3” --extra-libs=-lsvml <cr> # Without linking in the extra library (libsvml.so) you get several references unresolved.

 Using icc v11.0.xxx:

 Ø      ./configure cc=icc –extra-cflags=”-xSSE3_ATOM –O3” –extra-libs=-lsvml <cr> #  The option –xSSE3_ATOM do require that you run the code on a processor which does support the ‘movbe’ instruction. If you would like to test the code on a processor not supporting the ‘movbe’ instruction you can add the option ‘-minstruction=nomovbe’ in the extra-cflag part of the command line above.
Ø      Make sure that the LD (linker) options do not contain ‘–march=generic’ in the config.mak file. This option causes an error from the compiler.

Using icc v11.1.xxx:

Ø      To avoid a run time erratum following source change is needed:   Open file ./libavcodec/x86/dsputil_mmx.c and on line #2944 insert // before || __ICC > 1100. The line is highlighted below.

Ø      After the change it will look like: #if ARCH_X86_64 || ! ( __ICC) // || __ICC > 1100

Ø      ./configure cc=icc –extra-cflags=”-xSSE3_ATOM –O3” <cr> # This simple configure does work but you get better performance if you also add the ‘--extra-lib=-lsvml’. Additional compiler switches can be used to improve the performance – for example ‘-no-prec-div’, ‘-vec-‘. As the no-prec-div has an effect on the fp calculations please refer to the compiler documentation before it is used. In addition the ‘-xSSE3_ATOM’ switch are no longer requiring a processor with ‘movbe’ support.

 Cross compilation.

It is standard practice to build the library and executables on a development machine and then copy the resultant files to the MOBLIN target.  You can use the option --enable–cross-compile in this case.

Once you have completed the configure stage you can just run the ‘make clean’ followed by ‘make’. You could expect additional warnings produced.

Building ffmpeg with third party libraries:

The application can support 21 different external 3^rd party libraries. Each of those are selected in the configure process by adding the option ‘--enable-<library-name>’.

Below is an example of using some of the different external libraries available:

 Ø      ./configure <other options as above> --enable-libfaac --enable-libfaad --enable-libmp3lame --enable-libtheora --enable-libx264 --enable-libxvid 

The invocation above assumes that you will be using 6 external 3^rd party libraries:

 - libfaac       # for example you can download ‘faac-1.28.tar.gz’ or later version from the web.

 - libfaad       # for example you can download ‘faad2-2.7.tar.gz’ or later version from the web.

 - libmp3lame # for example you can download ‘lame-398-2.tar.gz’ or later version from the web.

 - libtheora    # for example you can download ‘libtheora-1.0.tar.tar’ or later version from the web. Please note that you can not use ICC v 10.1 to rebuild this library due to a compiler issue. This has been fixed with 11.1 version of the compiler.

 - libx264      # for example you can download ‘x264-snapshot-20090117-2245.tar.bz2’ or later version from the web.

 - libxvid      # for example you can download ‘xvidcore-1.2.1.tar.gz’ or later version from the web.

Introduction

Build environment

The build instructions below are based on the assumption that the build environment is a Fedora10 installation. 

A copy of the installation disks can be found here. http://fedoraproject.org/get-fedora

It is important that the GCC tools are installed when the Fedora installation is installed.

Cross-development

The clutter libraries  and test environment  are first built on a Fedora installation, and then the resultant executables and libraries can then be copied over to a MOBLIN2 platform.

Virtualisation

The steps below can be undertaken on a virtual machine, the only restriction being that not all virtual machines support video acceleration  

The tests

There are a number of tests that can be used to benchmark the clutter library. The benchmark performance is measured by how many Frames Per Second (FPS) are achieved.

Building the Clutter Libraries

Downloading the sources

The sources for the clutter library can be obtained by using the following command.

In a development directory of your choosing download the sources

   git clone git://git.clutter-project.org/clutter

   git clone git://git.clutter-project.org/clutter-box2d

Progress for each download should be reported similar the following:

$ git clone git://git.clutter-project.org/clutter

Initialized empty Git repository in /home/intel/dv/clutter/clutter/.git/
remote: Counting objects: 25225, done.
remote: Compressing objects: 100% (10261/10261), done.
remote: Total 25225 (delta 20575), reused 18319 (delta 14944)
Receiving objects: 100% (25225/25225), 6.99 MiB | 104 KiB/s, done.
Resolving deltas: 100% (20575/20575), done.

Building the Sources

Directory structure should look similar to this:

             <dev-dir>/clutter/
            <dev-dir>/clutter-box2d

In each of these sub directories build the libraries as follows:

Choosing which compiler

Building with GCC

For our installation, we'll use the environment variable  $PREFIX custom directory so as not to override any existing installation

     export PREFIX=/opt/custom/gcc
    ./autogen.sh --prefix=$PREFIX

Building with ICC

To build the library with the Intel compiler use the following commands

    export CC=icc
    export CXX=icc

   export PREFIX=/opt/custom/icc
  ./autogen.sh --prefix=$PREFIX

Continuing the build

When autogen has completed you should get a message similar to the display below 

  
                                  Clutter    0.9.7
                         ====================
                                  prefix:   /opt/custom/gcc
                                Flavour:   glx/gl
                                 XInput:   no
                          GL headers:   GL/gl.h
                    Image backend:   gdk-pixbuf
                       Target library:   libclutter-glx-0.9.la
               Clutter debug level:   yes
                 COGL debug level:   minimum
                      Compiler flags:   -Wall -Wshadow -Wcast-align -Wno-uninitialized -Wno-strict-aliasing -Wempty-body -Wformat-security -Winit-self
        Build API documentation:   no
  Build manual documentation:   no
         Build introspection data:   auto

Now build the source by calling make

The progress of the make will be reported, the last few lines looking similar to this:

   Making all in tools
     CC    disable-npots.o
     LINK  libdisable-npots-static.la
     LINK  libdisable-npots.la
   Making all in po

Installing the new library

To install the new library call:

make install

Note, depending on the permissions of the installation directory (set with the $PREFIX variable in the previous steps) you may need to do this as root.

Building the tests

The test directory has a number of tests. The README describes the tests as follows 

"The conform/ tests should be non-interactive unit-tests that verify a single feature is behaving as documented. See conform/ADDING_NEW_TESTS for more details.

 The micro-bench/ tests should be focused performance test, ideally testing a single metric. Please never forget that these tests are synthetic and if you are using them then you understand what metric is being tested. They probably don't reflect any real world application loads and the intention is that you use these tests once you have already determined the crux of your problem and need focused feedback that your changes are indeed improving matters. There is no exit status requirements for these tests, but they should give clear feedback as to their performance. If the frame rate is the feedback metric, then the test should forcibly enable FPS debugging.

 The interactive/ tests are any tests who's  status can not be determined without a user looking at some visual output, or providing some manual input etc. This covers most of the original Clutter tests. Ideally some of these tests will be migrated into the conformance/ directory so they can be used in automated nightly tests."

To build the tests, from the top level of the test directory do: 

    make

The build will report:

    Making all in data
    Making all in conform
    Making all in interactive
    Making all in micro-bench
    Making all in tools

Running the tests

Having built the tests, each test can be run from the command line.

Automatic running of  tests.

Many of the tests do not run to completion, but keep running,  The script in the appendix below gives an example of how the tests can be automatically called and killed after a predefined time.

Appendix 1 -  Script to drive test cases

#!/usr/bin/perl
# list of tests TODO: EDIT THESE TO YOUR REQUIREMENTS
@Tests=("test-actors", "test-behave", "test-clip","test-cogl-offscreen","test-cogl-primitives","test-cogl-tex-convert","test-cogl-tex-foreign","test-cogl-tex-getset","test-cogl-tex-polygontest","test-cogl-tex-tile","test-depth","test-layout","test-multistage","test-pixmap","test-project","test-random-text","test-rotate","test-scale","test-script","test-sharder","test-text","test-texture-quality","test-textures","test-threads","test-unproject","test-viewport");

#@Tests=("test-actors", "test-behave");
@Results=();

# for each test run it for 10 seconds
my $Timeout = 10;
## chdir interactive;
my $bStarted = 0;

foreach my $Test (@Tests)
{
    # print "executing $Test\n ";
    eval {
        local $SIG{ALRM} = sub { die "alarm\n" }; # NB: \n required
        alarm $Timeout;
        # system("./$Test --clutter-show-fps > res.$Test.txt");

        # mark end of prev test
        push @Results, "END" if $bStarted;
        push @Results, "TEST:$Test\n-----------------------\n";
        $bStarted = 1;
        open (RUN,"./$Test --clutter-show-fps &|");
        while(<RUN>)
        {
            push @Results, $_;
        }
        alarm 0;
    };
    if ($@)
    {
        die unless $@ eq "alarm\n"; # propagate unexpected errors
        # timed out
        system("killall -9 lt-test-interactive");
     }
}
# mark the end of the last test
push @Results, "END" if $bStarted;

# process the results
my $NumTests = 0;
my $Total = 0;
my $Max = 0;
my $Min = 9999;
my $TestName="";

print "\nName Min Max NumTests Average\n";
foreach my $Line (@Results)
{
    if($Line=~/^TEST:(.*)/)
    {
        # print "IN TEST $Line";
        $TestName= $1;
        chomp $TestName;
        $NumTests = 0;
        $Total = 0;
        $Max = 0;
        $Min = 9999;
    }

    if($Line=~/END/)
    {
        # print "IN END :$Line";
        $Average = 0;
        $Average = $Total/$NumTests if $NumTests > 0;
        print "$TestName $Min $Max $NumTests $Average\n";
    }

    if($Line=~/\*\*\* FPS: (.*) \*\*\*/)
    {
        # print "IN FPS: $Line";
        $NumTests++;
        $Total = $Total + $1;
        $Max = $1 if $1 > $Max;
        $Min = $1 if $1 < $Min;
    }
}

print "exiting ..\n";
 

 Appendix 2 - Essential notes on installing Fedora  

When installing Fedora you must install the Software Development tools.

Whether you intend to do most of your development on a live Moblin* image running inside a KVM* virtual machine ore whether you intend to do your development in a protected jailroot/chroot environment, there are tools components that should be installed on your development host system and should be independent of your Moblin* based Intel(R) Atom(TM) Processor target.

It is recommended to register for the Intel(R) Application Software Development Tool Suite for Intel(R) Atom(TM) Processor or the Intel(R) Embedded Software Development Tool Suite for Intel(R) Atom(TM) Processor at http://software.intel.com/en-us/intel-compilers/ and download it at https://registrationcenter.intel.com. It is also recommended to install at least the Intel(R) VTune(TM) Performance Analyzer and the Intel(R) Debugger following the steps outlined in the product installation guide Install_All.htm. This will take care of installing the host components to take advantage of the Intel(R) Application Software Development Tool Suite's performance analysis, tuning and debug capabilities.

To install the Intel(R) C++ Compiler and the Intel(R) Integrated Performance Primitives into the Moblin* Image Creator jailroot environment and prepare the Moblin* Image Creator produced target image to also include the Intel(R) Application Debugger debug agent (Idbserver) and the Intel(R) VTune(TM) Analyzer Sampling Collector (SEP) please follow the steps below:

1. Go to http://www.moblin.org and download Moblin* Image Creator 2. Detailed Moblin* Image Creator documentation can be found at http://moblin.org/documentation/moblin-image-creator-2/using-moblin-image-creator and the Moblin* Image Creator itself can be downloaded at  http://git.moblin.org/cgit.cgi/moblin-image-creator-2 .
2. Follow the instructions you find at moblin.org for installing the Moblin* Image Creator.
3. Go to http://software.intel.com/en-us/articles/moblin-integration-software-development-tool-suite-atom/ and download the two scripts netbook-core-developer_JAILROOT.ks and netbook-core-developer_TARGET.ks .
4. To create a KVM* image or a Live-CD of the target Moblin* system, please use netbook-core-developer_TARGET.ks:
    

   > moblin-image-creator -c <path_to_ks>/netbook-core-developer_TARGET.ks -f raw --cache=/tmp/mycache

   The image created will contain The Intel(R) Application Debugger Idbserver and the Intel(R) VTune(TM) Analyzer Sampling Collector for target system located as a tarball in the /tmp directory. TheParameter '-f raw' of the moblin-image-creator command instructs the Moblin* Image Creator to create an image which can be loaded into a KVM* virtual machine. For more information on Moblin* Image Creator usage please consult moblin.org.

5. To create an image with the Intel(R) C++ Compiler & the Intel(R) Integrated Performanced Primitives that you can then use to do builds in a protected jailroot/chroot environment before creating the target image please use netbook-core-developer_JAILROOT.ks:
    

   > moblin-image-creator -c <path_to_ks>/netbook-core-developer_JAILROOT.ks -f loop --cache=/tmp/mycache

   The image will contain the Intel(R) C++ Compiler and the Intel(R) IPP at /opt/intel/Compiler. The command parameter '-f loop' of moblin-image-creator tells it to create a loop image. You can mount this image and then chroot into it for your protected builds using the following commands:
     

   > mount -o loop moblin-netbook-core-developer_JAIROOT.img /mnt/loop
    > chroot /mnt/loop su

6. To additionally install the Intel(R) VTune(TM) Analyzer Sampling Collector (SEP) you would download it directly from http://downloads.moblinzone.com/development-tool-suite-2/rpm/vtune91_target.tar.gz and unpack it and install it in the Moblin* environment. Please be advised that using SEP is only supported on real Intel(R) Atom(TM) Processor based hardware and not on OS images running under KVM*. 

    

Advanced

If you would like to modify the kickstart script templates provided with the Moblin* Image Creator yourself, below is a short outline of the changes we apply to the template scripts provided with the Moblin* Image Creator to enable our integration. The example kickstart scripts for the Moblin* Image Creator can be found in the /usr/share/mic2 after you installed it.

To enable integration of the Intel(R) Software Development Tool Suite you would do the following:

1. add a repository entry for the Intel(R) Software Development Tool Suite  to the header of ks file:  
      

   > repo --name=intel-tools --baseurl=http://downloads.moblinzone.com/development-tool-suite-2

2. add packages which you want to install into Moblin image in %packages section of the ks file.
   There are 4 groups of Intel packages which you may want to install:
   

     @Compiler
     @IPP
     @Application Debugger
     @Server agent for Application Debugger

Each of these groups contains a set of rpm files related to the corresponding products.
  

@Compiler contains the Intel(R) C++ Compiler for applications runninng on IA-32
  @IPP containsthe Intel(R) IPP for Intel(R) Atom(TM) Processor
  @Application Debuggers contains the Intel(R) Application Debugger 2.0 for Intel(R) Atom(TM) Processor
  @Server agent for Application Debugger conntains the Intel(R) Debugger Remote Server (idbserver) 

    
Each group of packages contains the information about its dependencies which will be automatically resolved during the installation.

Host Install 

It is recommended to register for the Intel(R) Application Software Development Tool Suite for Intel(R) Atom(TM) Processor or the Intel(R) Embedded Software Development Tool Suite for Intel(R) Atom(TM) Processor at http://software.intel.com/en-us/intel-compilers/ and download it at https://registrationcenter.intel.com. It is also recommended to install at least the Intel(R) VTune(TM) Performance Analyzer and the Intel(R) Debugger following the steps outlined in the product installation guide Install_All.htm. This will take care of installing the host components to take advantage of the Intel(R) Debugger and Intel(R) VTune(RM) Perfromance Analyzers debuging and performance optimization tuning capabilities.

If you wanted to you could however also do the host component install using the kickstart script approach of Moblin Image Creator 2. This is however not the recommended approach.
To the any kickstart script of your choice you would add  the '%post --nochroot' section shown below for copying of the Intel(R) VTune(TM) Performance Analyzer and the Application Debugger to the host machine and VTune sampling collector for embedded systems (SEP-embedded) to the target image.

%post --nochroot

# Copying vtune_for_targets to the target image (set your proxy here if needed)
echo "Downloading required additional packages..."
export http_proxy=http://proxy.jf.intel.com:911
test -s /tmp/vtune91_target.tar.gz || wget http://downloads.moblinzone.com/development-tool-suite-2/rpm/vtune91_target.tar.gz -O /tmp/vtune91_target.tar.gz
cp /tmp/vtune91_target.tar.gz $INSTALL_ROOT/tmp/vtune91_target.tar.gz

# copying VTune for host to the user's host machine
test -d /tmp/intel-tools || mkdir -p /tmp/intel-tools
test -s /tmp/intel-tools/l_vt_pu_9.1.021.tar.gz || wget http://downloads.moblinzone.com/development-tool-suite-2/l_vt_pu_9.1.021.tar.gz -O /tmp/intel-tools/l_vt_pu_9.1.021.tar.gz

# copying Application Debugger to the user's host machine
test -d /tmp/intel-tools/idb || mkdir -p /tmp/intel-tools/idb
wget http://downloads.moblinzone.com/development-tool-suite-2/rpm/intel-mid_idb20006-2.0.006-001.i486.rpm -O /tmp/intel-tools/idb/intel-mid_idb20006-2.0.006-001.i486.rpm
wget http://downloads.moblinzone.com/development-tool-suite-2/rpm/intel-mid_idb-kernel20006-2.0.006-001.i486.rpm -O /tmp/intel-tools/idb/intel-mid_idb-kernel20006-2.0.006-001.i486.rpm
wget http://downloads.moblinzone.com/development-tool-suite-2/rpm/intel-mid_idb-eclipse20006-2.0.006-001.i486.rpm -O /tmp/intel-tools/idb/intel-mid_idb-eclipse20006-2.0.006-001.i486.rpm

# Installing App Debugger (if needed, please remove the comments)
# TODO: write some lines, so that add installation for non-rpm systems (like Ubuntu 8.10)
#echo "Installing an Application Debugger..."
#type -P rpm &>/dev/null
#if [ $? -eq 0 ]; then
# rpm -U --force --nodeps /tmp/intel-tools/idb/intel-mid_idb20006-2.0.006-001.i486.rpm
# rpm -U --force --nodeps /tmp/intel-tools/idb/intel-mid_idb-kernel20006-2.0.006-001.i486.rpm
# rpm -U --force --nodeps /tmp/intel-tools/idb/intel-mid_idb-eclipse20006-2.0.006-001.i486.rpm
#fi

%end

Design Choices

Many of the functional parts of this application are foundational to everyday applications, requiring features such as user authentication, configuration storage and retrieval, network communications, and user interaction. It’s important to modularize the design as much as possible to both break the overall project down into manageable pieces and to make it easier to reuse the code.

The application checks each time it runs to see whether any user credential information has been entered. If not, it presents a typical user name/password login dialog box and stores the information in an encrypted local configuration file. A preferences dialog box makes it possible to change the user name and password after initial setup along with other program options.

For the initial release of this program, I assume that there is an active network connection. This is a bit of a stretch for the Compal JAX10* MID I tested on: It did not have an active 3G radio, so there was no “always-on” Internet connection. I was able to simulate having a consistent connection by using Wi-Fi, instead. Later versions might check for connectivity and, if currently disconnected, queue up the message to send the next time a connection to the Internet is available.

Another design consideration for the mobile form factor is deciding what happens when a button is pressed. With this particular application, there is a consequence for choosing single-key action; every time the user presses one of the action buttons, a message is sent to Twitter. If you assume the user won’t inadvertently press a button or do something like put the device in a back pocket with the application running, it shouldn’t be a problem. Alternatives might include adding a confirmation dialog box to each action (“Really send message?”), adding a button or a timer to lock the screen, or exiting the program by default after the message is sent.

Building a UI for the Small Screen

One of nice things about Python* is the abundance of libraries to do just about anything you need to do. The Compal* MID used for this project has a number of useful libraries installed as a part of the base operating system, and I chose to take advantage of them. The GTK+* user interface (UI) library contains a wealth of resources for building everything from a simple dialog box to a complex data-entry form. PyGTK is a wrapper around the GTK+ library and provides access to virtually every routine through standard Python objects.
Building a login dialog using PyGTK consists of creating a simple window with individual text boxes for username and password. You can find a good example and explanation of these techniques on the PyGTK tutorial page. In the following code snippet the pass_input.set_visibility(False) line causes the password to be blanked by a dot symbol:

def login(self):
        dialog = gtk.Dialog('Login', 
                            self.window,
                            flags=gtk.DIALOG_MODAL | gtk.DIALOG_DESTROY_WITH_PARENT,
                            buttons=(gtk.STOCK_CANCEL, gtk.RESPONSE_REJECT,
                                     gtk.STOCK_OK, gtk.RESPONSE_ACCEPT))
        dialog.set_default_response(gtk.RESPONSE_ACCEPT)
        
        userbox = gtk.HBox(False)
        
        user_label = gtk.Label('Username:')
        userbox.pack_start(user_label)
        
        user_input = gtk.Entry()
        user_input.set_activates_default(True)
        userbox.pack_start(user_input)
        
        dialog.vbox.pack_start(userbox)
    
        passbox = gtk.HBox(False)
        
        pass_label = gtk.Label('Password:')
        passbox.pack_start(pass_label)

        pass_input = gtk.Entry()
        pass_input.set_activates_default(True)
        pass_input.set_visibility(False)
        passbox.pack_start(pass_input)
	  dialog.vbox.pack_start(passbox)

A second option with GTK+ is to create a table that fills the screen with a matrix of buttons that essentially takes up all the screen real estate. Although doing so might not be as visually appealing, it does accomplish the task of building a finger-friendly interface in which you can easily “click” the right button. It also provides a few more options for adding descriptive text to the button for the Twitter application. In Python, the matrix would look something like this:

def create_table(self):
        self.table = gtk.Table(3,4,True) # Create a 3 row by 4 column table
        button1 = gtk.Button("Button 1") # Create a button named button1
        self.table.attach(button1,0,1,0,1) # put button 1 in location 0,1
        button2 = gtk.Button("Button 2")
        self.table.attach(button2,1,2,0,1)	
        button3 = gtk.Button("Button 3")
        self.table.attach(button3,1,2,0,1)
.
.
.	
        button12 = gtk.Button("Button 12")
        self.table.attach(button12,1,2,0,1)

The lines with a single period are meant to indicate that the sequence repeats down to the final definition of button12.

Coding Practices

Python is a language that allows you to write code by the brute-force method, as in the lines above, or in a more elegant way using concepts like iteration. If you were to define all 12 buttons in a linear fashion, you would need 26 lines of code. Using the Python for construct, you can accomplish the same task in a mere seven lines of code. That equates to less than one-third of the code for this simple example, but the difference would be substantial for a larger table. Here’s the code in a more “Pythonic” way:

    def create_table(self):
        self.table = gtk.Table(3,4,True)
        for row in range(3):
            for col in range(4):
            	name = 'Twitter %i' % (row*4 + col + 1)
            	button = gtk.Button(name)
            	self.table.attach(button, col, col+1, row, row+1)

Keeping your code manageable is important when scripts start to get large. Python functions are a good way to break down your code into small, manageable pieces. It’s also important to point out that everything in Python is an object. You can see this to some extent in the create_table function through the use of the self construct. The function create_table creates a gtk.Table and returns it as an object—hence, the use of self to refer to the object being created. There is an abundance of resources on the Web if you’re not familiar with object-oriented programming concepts.

Taking advantage of all the built-in language features and functions is another way to keep your source code manageable. Python has a module for reading and writing configuration files named ConfigParser. This module provides all the tools you need to save and read program configuration information. It supports different sections and creates a file of name–value pairs within each section. There are even individual methods to retrieve specific types, such as getboolean, getint, and getfloat.

If you can’t find what you need in the Python standard library, chances are that someone else has already written what you need. A quick Google* search typically returns multiple choices for a specific tool. Python-Twitter is a good example of a helper library to accomplish the heavy lifting of sending messages to the Twitter service. It’s hosted on Google Code* and even comes with several sample applications.

You can test code on the Compal MID in several ways. File transfer over a USB port is drop-dead simple and works well.  Optionally, you could attach a USB keyboard to the Compal MID and use the VI editor directly on the device for your editing and the Python interpreter for testing. This method works okay for small proof-of-concept efforts but gets out of control for anything but small, simple programs. Another, similar approach is to use Virtual Network Computing* (VNC) to remotely view the screen on the device through your workstation.

Another way is to use the emulator approach.  The Moblin* project has a tool called the Moblin Image Creator* (MIC) for building platform-specific images. With MIC you can also use the Xephyr* emulator tool to launch an independent session for testing purposes. This method has the advantage of a rapid build / test cycle to help work the bugs out of your code in short order.

A final way might be to test the initial version of the software on your Linux* desktop.  The advantage is that you don’t need MIC.  The disadvantages are that you may need additional hardware for your desktop (GPS, for example) and that you can’t test MID specific functionality (such as screen characteristics).

Lessons Learned

Don’t get bogged down in the details too early in the process. It’s important to completely flesh out your requirements in the beginning, then make some design decisions based on a clear picture of what you’re trying to accomplish. Get comfortable with your development tools—especially the debugging portion—as you’ll probably use them more than you think.

The easier it is for you to test and debug your code, the quicker you’ll get it running.

Have a convenient way to transfer files to your device that doesn’t require a lot of motion. This could be as simple as keeping an easily accessible USB cable plugged into your workstation. When you get down to squashing bugs, it helps to make the process as smooth and painless as possible, especially if you’re editing all the code on a workstation and have to move it over to the device for testing.

Summary

Building a solid application for the MID platform requires the same set of disciplined steps you would use in any software project. Be sure you don’t skip steps like these:

• Take your time on the design process, and consider alternatives.
• Think through the UI design from a user’s perspective before you start coding.
• Write your code with testing in mind.
• Have a clear set of requirements that you can test.
• Use tools such as source code control, and check in your code frequently.

About Author

Paul Ferrill has been writing in the computer trade press for more than 20 years. He got his start writing networking reviews for PC Magazine on products like LANtastic and early versions of Novell Netware. Paul holds both BSEE and MSEE degrees and has written software for more computer platforms and architectures than he can remember.

[root@CompalMID~]#

To start the SSH daemon you must type:

[root@CompalMID~]# /etc/init.d/sshd start

You should see:

Starting sshd:  								[OK]

• Choose a good IDE that you're comfortable with.
• Use a popular Linux distribution like Ubuntu for the operating system of your development computer.
• Don't skimp on your development hardware, and do get a machine with a recent processor and ample memory.
• Use good software development practices, like gathering requirements and using a source code control tool.

Workloads

• Idle behaviour in typical system idle states
• Video playback using Moblin Media Player & Helix framework
• Multi-threaded Video decode, audio transcode and Flash workloads used for HT impact analysis
• Browsing using Moblin Browser

• HT on/off
• C6 on/off

• Home Screen - HTML
• Home Screen - HTML - Screen off
• Home Screen - Clutter (OpenGL)
• Home Screen - Flash (UI created in Flash, embedded in HTML)
• XTerm
• Moblin Browser with default home page loaded

Appendix A - Atom™ processor specifications

Appendix B - HW setup and NetDAQ power measurement setup

Acronyms

Power Efficiency – Analysis and SW Development Recommendations for Intel® Atom™ processor based MID platforms [PDF | 2MB ]

Background

The objective of this paper is to investigate Intel® Atom™ processor based MID (Mobile Internet Device) platform power (including chipset components) characteristics for typical workloads, such as media playback, browsing, idle, etc. The results are aimed at providing recommendations for SW developers on how to best optimize applications for power efficiency.
The platform power characteristics were captured using two methods:

• Instrumented Crown Beach/Menlow Software Development Platform (SDP) (including Intel® Atom™ processor and chipset) enabling discrete component power measurements using Fluke NetDAQ* equipment
• Linux* tool, PowerTOP*, to extract information on processor C-state (sleep) residency, P-state (execution) residency and wakeup characteristics.

The Intel® Atom™ processor provides low power features such as:

• New core x86 micro-architecture
  • In-order execution
  • Multithreading support. Hyper Threading Technology (HT) aka. Simultaneous Multi-Threading (SMT). Not available for all Atom SKUs.
  • Enhanced macro-op execution
• 45nm technology
• Enhanced Intel® SpeedStep® Technology
• Up to SSSE3 instruction set support
• Deep Power-Down Technology - C6 processor sleep state
• Dynamic cache sizing
• Enhanced dynamic clock gating
• Enhanced L2 data pre-fetcher

The chipset provides features such as:

• Graphics HW acceleration (including video acceleration used by media player)
• Intel® Display Power Saving Technology
• Intel® Rapid Memory Power Management

The OS/SW stack used for this investigation is Moblin* Linux with the Helix* media framework using HW accelerated video codecs. Other OS or SW stacks such as RedFlag*, MIDinux*, or Microsoft Windows* Vista are out of scope for this investigation.

The "Recommendations" chapter summarizes the findings from the analysis and provides guidelines on how to develop power efficient SW on the MID platform. The following chapters are divided into "Technical Background", which describes some key technical concepts, "Measurement procedure", which outlines the methods used to capture the data presented in this paper and "Workloads", which breaks down results for each of the workloads analyzed.

To read the rest of the article, please download the PDF below.

Recommendations

1. Be aware that one power inefficient application in Idle is enough to cripple battery life for the whole system.
2. Develop context aware applications that adapt to system state changes Refer to http://software.intel.com/en-us/articles/energy-efficient-software-developing-power-aware-apps for articles on developing for context awareness.
   • Power state change (system sleep/wake transitions): The application shall handle system power state change gracefully and not incur unnecessary delays. The application shall not prevent system from changing power state unless absolutely necessary.
   • Battery state change: Adapt behavior due to switch from AC to/from battery power. Some features, such as automatic updates, could potentially be deactivated to save power when powered by battery.
   • Network state change: Adapt application behavior to network connect/disconnect events. Some features could potentially be deactivated, saving power when not connected to network (flight mode).
3. Develop "Data Efficient" applications that minimize data movement to/from external storage or RAM. Also investigate if data movement can be grouped or batched to decrease frequency of drive spin up/down.
4. Utilize extended SIMD instruction sets such as SSE3, improving performance and indirectly reducing application energy usage.
5. Utilize tools to achieve power optimizations or identify power optimization opportunities
   • Utilize the Intel® Compiler for MID to compile the code into a binary specifically adapted to the Intel® Atom™ micro-architecture. This has the potential to greatly improve performance and in some cases also energy efficiency
   • Utilize PowerTOP to find components waking up the system excessively
   • Utilize Application Energy Toolkit to graph/analyze energy consumption

1. Make sure the system is configured to power the screen off if there is no user input for a suitable time interval. This reduces the average power in the chipset and allows additional power savings from LCD power down.
   
   Refer to chapter "5.1.2: Processor & Chipset power usage in Idle mode" for details.
2. Using on-demand governor to regulate P-state, depending on workload, improves system power efficiency.

1. Optimize to meet performance goals
2. Establish baseline before power optimizations
   • Gather data using PowerTOP in single threaded mode (Powertop currently not as accurate in HT mode)
     1. Wakeups/s
     2. Cx state residency
     3. Px state residency
   • If possible utilize external power meter to measure average power during application idle compared to system idle and during key workload execution
3. Investigate behavior during application idle compared to system idle. Explore difference in wakeups/s, Cx/Px states. Optimally an application in idle should have none or minimal impact on total system idle power
4. Use Intel® VTune™ for MID to identify functions that show high C0 residency running key application workloads. Utilize processor "unhalted ref clock" counter to assess C0 residency. Note that "Unhalted core clock" is unreliable due to frequency change (if Intel® SpeedStep® Technology is enabled) and that "Time stamp counter" is unreliable at and below C4 due to disabled PLL. "unhalted ref clock" / wall clock time can be used to compute true C0 residency.
5. Re-architect/re-code
   • Look for activities that force processor into C0 state (interrupts)
   • Coalesce or remove unnecessary activities to reduce wakeups
   • Look into data efficiency bottlenecks (disk, memory, network)
   • Note that optimizing for speed may increase C0% which might be OK since overall energy reduces due to performance speed up

For further details on the above and related topics please find detailed articles at Intel Software Network (ISN): Energy Efficient Software http://software.intel.com/en-us/articles/energy-efficient-software/.

Technical Background

This chapter explains some of the technologies in focus for this paper.

Measurement Procedure

Note that this paper does not analyze all component parts of a typical MID form factor device. MID devices will feature a range of wireless communication components such as WiFi, WiMax, WWAN or BT all increasing the average platform power footprint. Extended analysis of form factor devices might include networked workloads such as audio/video streaming, Chat or Email, VOIP, P2P solutions, connected browsing and gaming.