[1]原始磁盘映像（RDM）会将整个 SAN LUN 暴露在虚拟机面前，而不是让 VMware ESX 管理程序创建 VMFS （VMware 公司的 SAN 文件系统）卷。这样（通常）会改进性能并允许使用 SAN 专用工具，从而使得虚拟机能够与 SAN 直接交互。

Intel感知计算（1）- 简介

Intel感知计算通过设备感知和理解用户行为来进行人机交互，它是更加自然的、身临其境的、直觉交互方式。现在Intel感知计算SDK Beta版本已经能够使用，网友可以访问http://software.intel.com/en-us/vcsource/tools/perceptual-computing-sdk来下载安装文件，如图1所示：

图1

先在图1右侧下来框中选择Perceptual Computing，然后在点击Download按钮。

Intel感知计算支持多种使用模式，比如说：

l  语言认知

         图2

l  人脸识别

                      图3

l  近距离跟踪，比如说手指近距离跟踪等

                     图4

l  2D/3D对象跟踪

                    图5  

英语好的网友，不妨看一下David Perlmutter是如何来看Intel感觉计算的J

视频：http://v.youku.com/v_show/id_XNDgxNTQ0NjQw.html

Introduction

The Intel® System Studio contains build of GDB, the GNU* Project Debugger that has been tested against the cross-build requirements of developing and debugging applications targeting Embedded Devices and Intelligent Systems. In addition the GDB provided by Intel offers additional features to identify and fix data races during debug. On the Intel® Atom™ processor it also gives access to application level Last-Branch-Record (LBR) instruction trace. A very powerful tool to supplement callstack backtrace and unwind the instruction flow leading up to an error condition, even under most challenging circumstances.

In this article we will focus on the use of GDB for embedded use cases and the strength of the unique Intel® System Studio feature set of GDB.

Table of Contents

• Using GDB to debug application on embedded devices
• Using GDB to debug applications running inside a virtual machine
• Debugging Data Race Conditions
• Branch Instruction Tracing
• Integrate GDB into Eclipse* CDT
• Summary

Using GDB to debug application on embedded devices

Please refer to GDB: The GNU* Project Debugger (http://www.gnu.org/software/gdb/) for details.
For cross-development GDB comes with a remote debug agent called gdbserver. This debug agent can be installed on the debug target to launch a debuggee and attach to it remotely from the development host.
This can be useful in situations where the program needs to be run on a target host that is different from the host used for development, particularly when the target has a limited amount of resources (either CPU and/or memory).
To do so, start your program using gdbserver on the target machine. gdbserver then automatically suspends the execution of your program at its entry point, waiting for a debugger to connect to it. The following commands start an application and tells gdbserver to wait for a connection with the debugger on localhost port 2000. 

      $ gdbserver localhost:2000 program
     Process program created; pid = 5685
     Listening on port 2000

Once gdbserver has started listening, we can tell the debugger to establish a connection with this gdbserver, and then start the same debugging session as if the program was being debugged on the same host, directly under the control of GDB.

      $ gdb program
     (gdb) target remote targethost:4444
     Remote debugging using targethost:4444
     0x00007f29936d0af0 in ?? () from /lib64/ld-linux-x86-64.so.
     (gdb) b foo.adb:3
     Breakpoint 1 at 0x401f0c: file foo.adb, line 3.
     (gdb) continue
     Continuing.
    
     Breakpoint 1, foo () at foo.adb:4
     4       end foo;

It is also possible to use gdbserver to attach to an already running program, in which case the execution of that program is simply suspended until the connection between the debugger and gdbserver is established. The syntax would be

$ gdbserver localhost:2000 --attach 5685

to tell gdbserver to wait for GDB to attempt a debug connection to the running process with process ID 5685

Using GDB to debug applications running inside a virtual machine

Using GDB for remotely debugging an application running inside a virtual machine follows the same principle as remote debug using the gdbserver debug agent.

The only additional step is to ensure TCP/IP communication forwarding from inside the virtual machine and making the ip address of the virtual machine along with the port used for debug communication visible to the network as a whole.

Details on how to do this setup can be found on Wikibooks* (http://en.wikibooks.org/wiki/QEMU/Networking)

The basic steps are as follows

1. Install QEMU, the KQEMU accelerator and bridge-utils

$ su -
$ yum install qemu bridge-utils

2. Creating the image for the guest OS

For best performance, you should install your guest OS to an image file. To create one, type:

$ qemu-img create filename size[ M | G ]

where filename is going to be the name of your image, and size is the size of your image with the suffix 'M' (MB) or 'G' (GB) right after the number, no spaces.

$ qemu-img create Linux.img 10G

3. Configuring network for your guest OS

Put the following contents into /etc/qemu-ifup:

#!/bin/sh
#
# script to bring up the device in QEMU in bridged mode
#
# This script bridges eth0 and tap0. First take eth0 down, then bring it up with IP 0.0.0.0
#
/sbin/ifdown eth0
/sbin/ifconfig eth0 0.0.0.0 up
#
# Bring up tap0 with IP 0.0.0.0, create bridge br0 and add interfaces eth0 and tap0
#
/sbin/ifconfig tap0 0.0.0.0 promisc up
/usr/sbin/brctl addbr br0
/usr/sbin/brctl addif br0 eth0
/usr/sbin/brctl addif br0 tap0
#
# As we have only a single bridge and loops are not possible, turn spanning tree protocol off
#
/usr/sbin/brctl stp br0 off
#
# Bring up the bridge with IP 192.168.1.2 and add the default route
#
/sbin/ifconfig br0 192.168.1.2 up
/sbin/route add default gw 192.168.1.1
#stop firewalls
/sbin/service firestarter stop
/sbin/service iptables stop

Please change the IP's to show your setup.

Now, put this into /etc/qemu-ifdown:

#!/bin/sh
#
# Script to bring down and delete bridge br0 when QEMU exits
#
# Bring down eth0 and br0
#
/sbin/ifdown eth0
/sbin/ifdown br0
/sbin/ifconfig br0 down
#
# Delete the bridge
#
/usr/sbin/brctl delbr br0
#
# bring up eth0 in "normal" mode
#
/sbin/ifup eth0
#start firewalls again
/sbin/service firestarter start
/sbin/service iptables start

 
Make the scripts executable so QEMU can use them:

$ su -
$ chmod +x /etc/qemu-if*
$ exit

4. Installing the guest OS

Type the following to start the installation:

$ su
$ /sbin/modprobe tun
$ qemu -boot d -hda image.img -localtime -net nic -net tap -m 192 -usb -soundhw sb16 -cdrom /dev/hdc;/etc/qemu-ifdown

Where image.img was the name you gave to your image earlier. I'm also assuming /dev/cdrom is your CD drive - if it's not, then please change it to the correct device. After the install is complete, proceed to step 5.

5. Making the run script & running at will

The last step is to create the QEMU start script and from there on you can run your guest OS. Create this file - called qemustart - in the same directory as your image:

#!/bin/sh
su -c "/sbin/modprobe tun;qemu -boot c -hda image.img -localtime -net nic -net tap -m 192 -usb -soundhw sb16;/etc/qemu-ifdown"

Where image.img was the name given to the image earlier.
Last step - make the startup script executable:

$ chmod +x /path/to/qemustart
 

Debugging Data Race Conditions

A data race occurs when multiple threads access overlapping memory without synchronization. Although data races may be harmless or even part of the design in some cases, a data
race typically indicates a bug. GDB may be used as a front-end for the parallel debug extension (PDBX) data race detector that is part of the Intel compiler. The PDBX data race detector consists of compiler instrumentation and run-time support library. Both are provided by the Intel compiler. The PDBX run-time library provides a debugger interface for communicating detected data races as well as for configuring the analysis. The PDBX data race detector is enabled with the ‘-debug parallel’ compiler option.This option is available with the Intel® C++ Compiler starting from version 12.1 supporting GNU*/Linux* on IA-32 and Intel® 64 architectures.The data race detector can handle pthread and Intel OpenMP synchronization primitives. When debugging remotely, make sure that gdb finds the correct version of libpdbx that is used on the target. When using OpenMP, the following variables must be defined in the debuggee’s environment:

INTEL LIBITTNOTIFY32=""
INTEL LIBITTNOTIFY64=""
INTEL ITTNOTIFY GROUPS=sync

1. Enable, Disable, and Reset

The PDBX data race detector logs all memory accesses and synchronization for all threads. It checks for data races on each memory access. As can be expected, this is very expensive,
both in terms of performance and memory consumption. To mitigate this, you can fine-tune the data race analysis. While you can’t control logging of synchronization events, you can control logging of memory accesses. Memory accesses are logged so long as the data race detector is enabled, and because the data race detector always logs synchronization, it may be disabled and
re-enabled at any time. Of course, the detector is only able to detect data races on known memory accesses. In addition to selective enabling, you can get the data race detector to discard the
memory logs it has collected. This may be useful when debugging data races in separate parts of the program under memory constraints.

The following commands enable, disable, and reset the data race analysis:

pdbx

Prints the data race detector status. It shows whether the data race detector is enabled, whether the run-time library was loaded, and the version being used.

pdbx enable

Enables memory access logging and data race detection. The data race detector logs memory accesses and reports detected data races to gdb.

pdbx disable

Disables memory access logging and data race detection. The data race detector stops logging memory accesses. Data races that are about to be reported are discarded.

pdbx reset

Discards memory access logs. Data races are only detected for new memory accesses. This reduces the memory consumption of the data race detector and may also improve performance.

2. Filters

You can configure the data race detector to ignore parts of the application that may be useful under a variety of different use cases, such as to:

• Ignore false positives
The data race detector may incorrectly report correctly synchronized accesses as data races. This is typically caused by a synchronization construct that is not known to the data race detector. It may also be caused by partially instrumented applications.

• Ignore intended or harmless data races
In some cases, data races may be harmless or even intended. Examples are data races where all threads are guaranteed to write either the same or an equivalent value. Accepting such a harmless data race is typically cheaper than synchronizing the threads.

• Ignore currently irrelevant data races
The data race detector may correctly report data races that are not related to the bug currently under observation. Such distracting data races may be ignored until a later time.

• Improve data race analysis performance
Ignoring parts of your program may have a significant impact on the analysis performance overhead. It is typically cheaper to repeatedly analyze a small portion of your program than it is to analyze the whole program.

• Improve data race analysis memory consumption
Ignoring parts of your program may have a significant impact on the analysis memory consumption. This allows data race detection to be used in scenarios where a whole program analysis would not be feasible.

gdb uses filters expressed in source language terms to describe parts of the program that should be ignored/focused upon. Filters can be defined using the following commands:

pdbx filter code addr
pdbx filter code start - end

This filter specifies either a single code address or a range of code addresses from start (inclusive) to end (exclusive).

pdbx filter data addr
pdbx filter data start - end

This filter specifies either a single data address or a range of data addresses from start (inclusive) to end (exclusive).

pdbx filter line expr

This filter specifies the code generated for a single source line. The expr argument must be of a form accepted by info line and is interpreted in the current context.

pdbx filter variable expr

This filter specifies the data object corresponding to the source expression expr evaluated in the current context.

pdbx filter reads

This filter specifies all read accesses in the program. It is important to note that filters on stack objects are not automatically removed or disabled when the object is destroyed.

3. Filter Sets

Filters are organized in sets. A filter set defines the semantics of the filters it contains and can be set to either the ‘suppress’ or ‘focus’ type. The following commands alter the type of the current filter set:

pdbx fset suppress

Set the type of the current filter set to suppress. The filters in this filter set specify the parts of the program that should be ignored by the data race detector. Memory accesses made from or to filtered areas are not logged and do not participate in the data race analysis.

pdbx fset focus

Set the type of the current filter set to focus. The filters in this filter set specify the parts of the program that should be analyzed for data races. Memory accesses that are not made from or to filtered areas are not logged and do not participate in the data race analysis. Beware that an empty focus filter set ignores the entire program. When debugging data races, it may be useful to define different filter sets and switch between them during the course of the debug session. gdb provides the following commands manage filter sets:

pdbx fset new name

Create a new filter set with the given name. The name must start with a letter. If a filter set with that name already exists, it results in an error and no filter set is created. The current filter set is not changed in that case. The filter set is initially empty and of type suppress. The new filter set will automatically be selected. Use filter commands or pdbx fset import to populate the filter set.

pdbx fset delete name

Delete a filter set with the given name. If no filter set with that name exists, it results in an error. The current filter set can not be deleted.

pdbx fset select name

Select the filter set with the given name. If no filter set with that name exists, it results in an error. The current filter set is not changed in that case.

pdbx fset list

List all filter sets. For each filter set, the type, name, and the number of filters it contains is printed. When new filters are created, they are automatically added to the current filter set. In
addition to this, gdb provides the following commands to deal with filters within filter sets. Each of these commands accepts an optional filter set name and an optional range argument. If both arguments are present, the name precedes the range and they are separated by a colon :. The range argument may be a single integer or two integers separated by a dash -. Examples are:

pdbx fset cmd

Target all filters in the current filter set.

pdbx fset cmd num

Target filter num in the current filter set.

pdbx fset cmd start - end

Target filters start (inclusive) through end (inclusive) in the current filter set.

pdbx fset cmd name

Target all filters in filter set name.

pdbx fset cmd name: num

Target filter num in filter set name.

pdbx fset cmd name: start - end

Target filters start (inclusive) through end (inclusive) in filter set name. If a name argument is given but no filter set with that name exists, the command terminates with an error message. If a range argument is given and some of the filter numbers are out of bounds, the command gives an error message and operates on the filter numbers that are inside the bounds of the filter set.

The following commands are provided to manage filters within filter sets:

pdbx fset show

List filters in a filter set.

By default, filters are printed as specified by the pdbx filter command. With the /r modifier, the addresses that are used for that filter are printed, instead.

pdbx fset remove

Remove filters from a filter set.

pdbx fset enable

Enable filters in a filter set.

Filters that have already been enabled are not modified. Filters that have been disabled are enabled and evaluated in the current context. If evaluation fails, the respective filter is marked pending and will not contribute to the data race detector configuration.

pdbx fset disable

Disable filters in a filter set. Disabled filters do not contribute to the data race detector configuration.

pdbx fset evaluate

Evaluate filters in a filter set.

Filters are evaluated in the current context. If evaluation fails, the respective filter is marked pending and does not contribute to the data race detector configuration.

pdbx fset import

Import filters into the current filter set. Imported filters are added to the end of the current filter set. They keep their state and are not re-evaluated. The same filter may be imported multiple times. Filters can not be imported from the current filter set.

4. Race Detection History

GDB keeps a history of data races reported by the PDBX data race detector. This list may be used for setting filters on a subsequent run. Except for pdbx history, all history commands accept an optional range argument. The range argument may be a single integer or two integers separated by a dash -. The range argument specifies the reports that the command operates upon. The pdbx history command does not take any arguments. The following commands operate on the data race history:

pdbx history

Prints a brief summary of the data race history showing the number of reported data races, the number of threads involved, and the number of read, write, and update accesses in that order.

pdbx history remove

Removes data race reports from the history.

pdbx history list

Prints a brief summary of data race reports in the history in the form of a list. The list includes the number of different threads involved in the data race, as well as the number of read, write and update accesses, one report per line.

pdbx history show

Print a detailed description of data race reports in the history. The detailed description prints each memory access involved in the data race, one access per line. By default, gdb tries to map data addresses back to variables and code addresses back to source lines. With the /r modifier, raw addresses are printed, instead.

Branch Instruction Tracing

Intel® Architecture on the Intel® Atom™ processor offers a feature called Branch Trace Store (BTS) that stores a log of branches into an OS-provided ring buffer. The
GNU/Linux operating system supports this feature since version 2.6.32 as part of the perf_event interface.

The gdb extension for branch tracing is based on the hardware BTS feature making it very useful to debug problems that do not immediately result in a crash. It is particularly useful for bugs that make other debugger features fail, for example, a corrupted stack that breaks unwinding. You can use the gdb branch tracing commands to record program control flow and view the recorded branch trace as a

• list of blocks of sequential execution (list view)
• disassembly of one of the listed blocks

Branch tracing is less powerful when compared to reverse debugging,  but it is considerably faster. In addition, the list view provides a quick overview of where you are, and is therefore comparable with the backtrace command.

1. Branch Tracing Commands

Enable and Disable Branch Tracing

To enable/disable branch tracing use the btrace enable/disable commands.

btrace enable/disable

This command starts/stops recording branch trace information for program threads. It is available in three flavors.

btrace enable/disable all

Starts/stops recording the branch trace for all threads.

btrace enable/disable auto

Automatically enables/disables recording branch trace for all new threads. Branch tracing induces significantly less overhead than full recording, yet the overhead is noticeable for longer-running applications. Unless you feel that the overhead is disturbing, you could simply turn on automatic enabling and forget about the feature until you need it.

btrace enable/disable [<begin>[-<end>]]

Starts/stops recording branch trace for a specified range of threads. If no argument is provided, the command applies to the selected thread.

2. List Traced Blocks

To list the traced blocks use the btrace list command.

btrace list [<begin>[-<end>]]
btrace list /a
btrace list /f
btrace list /l
btrace list /t

This command prints the blocks that have been traced, one line per block. It accepts an optional range argument, specifying the range of blocks to be listed. If no argument is given, all blocks are listed. The output can be configured using the modifiers, /a, /f, /l, where the default is /fl. The command prints:

<nn> the block number
/a the begin and end code address of that block
/f the function containing the block
/l the source lines contained in the block

Blocks are ordered from newest to oldest: block 1 always contains the current location.

(gdb) btrace list 24-34
24 in stdio_file_flush () at ../../../git/gdb/ui-file.c:525-529
25 in ui_file_data () at ../../../git/gdb/ui-file.c:175-180
26 in stdio_file_flush () at ../../../git/gdb/ui-file.c:522-523
27 in gdb_flush () at ../../../git/gdb/ui-file.c:185
28 in gdb_wait_for_event () at ../../../git/gdb/event-loop.c:840-847
29 in gdb_do_one_event () at ../../../git/gdb/event-loop.c:461
30 in gdb_do_one_event () at ../../../git/gdb/event-loop.c:453
31 in process_event () at ../../../git/gdb/event-loop.c:407
32 in process_event () at ../../../git/gdb/event-loop.c:361-367
33 in process_event () at ../../../git/gdb/event-loop.c:1041-1043
34 in process_event () at ../../../git/gdb/event-loop.c:1041-1045

3. Print Branch Trace Disassembly

To print branch trace disassembly use the btrace command.

btrace [+, -, <begin>[-<end>]]
btrace /m
btrace /r

Prints branch trace disassembly, block by block. The btrace command accepts an optional range argument specifying the range of blocks to be printed. If more than one block is specified, the blocks are printed in reverse order to preserve the original control flow. Repeated commands iterate over all blocks similar to the gdb list command. The btrace command supports the /m and /r modifiers accepted by the gdb disassemble command. The /m modifier is used to interleave source information.

(gdb) btrace /m 25
../../../git/gdb/ui-file.c:175{
0x0000000000635410 <ui_file_data+0>: sub $0x8,%rsp
Chapter 15: Branch Tracing 171
../../../git/gdb/ui-file.c:176 if (file->magic != &ui_file_magic)
0x0000000000635414 <ui_file_data+4>: cmpq $0xb33b94,(%rdi)
0x000000000063541b <ui_file_data+11>: jne 0x635426 <ui_file_data+22>
../../../git/gdb/ui-file.c:177 internal_error (__FILE__, __LINE__,
0x000000000063541d <ui_file_data+13>: mov 0x50(%rdi),%rax
../../../git/gdb/ui-file.c:178 _("ui_file_data: bad magic number"));
../../../git/gdb/ui-file.c:179 return file->to_data;
../../../git/gdb/ui-file.c:180}
0x0000000000635421 <ui_file_data+17>: add $0x8,%rsp
0x0000000000635425 <ui_file_data+21>: retq

Note that using the mixed source and disassembly modifier does not work very well for inlined functions, a problem that the btrace command shares with the gdb disassemble command.

Example:

Program crashed and back trace is not much help: 
 

(gdb) run  
Starting program: ../gdb/trace/examples/function_pointer/stack64    Program received signal SIGSEGV, Segmentation fault. 0x000000000000002a in ?? ()
(gdb) bt
#0  0x000000000000002a in ?? ()
#1  0x0000000000000017 in ?? ()
#2  0x000000000040050e in fun_B (arg=0x4005be) at src/stack.c:32
#3  0x0000000000000000 in ?? ()

Look at the branch trace.
List of blocks starts from the most recent block (ending at the current pc) and continues towards older blocks such that control flows from block n+1 to block n.

(gdb) btrace list 1-7
in ?? ()
in fun_B () at src/stack.c:36-37
in fun_B () at src/stack.c:32-34
in main () at src/stack.c:57
in fun_A () at src/stack.c:22-25
in fun_A () at src/stack.c:18-20
in main () at src/stack.c:51-56

from main(), we called first fun_A() and then fun_B(). The call to fun_A() returned, and we crashed somewhere in fun_B().

Look at the disassembly of the last 3 blocks in original control flow (i.e. reverse trace) order, starting from the call to fun_B() from main().

/m interleaves source info

(gdb) btrace /m 1-3
src/stack.c:32  static long fun_B(void* arg) {  
 0x000000000040050e <fun_B+1>:        mov    %rsp,%rbp   
 0x0000000000400511 <fun_B+4>:        mov    %rdi,-0x18(%rbp)  
src/stack.c:33      struct B_arg* myarg = arg;   
 0x0000000000400515 <fun_B+8>:        mov    -0x18(%rbp),%rax  
 0x0000000000400519 <fun_B+12>:       mov    %rax,-0x8(%rbp)  
src/stack.c:34      if (!myarg) return -1;   
 0x000000000040051d <fun_B+16>:       cmpq   $0x0,-0x8(%rbp)  
 0x0000000000400522 <fun_B+21>:       jne    0x40052d <fun_B+32>  
src/stack.c:36      return myarg->arg1 + myarg->arg2;  
 0x000000000040052d <fun_B+32>:       mov    -0x8(%rbp),%rax  
 0x0000000000400531 <fun_B+36>:       mov    (%rax),%rdx  
 0x0000000000400534 <fun_B+39>:       mov    -0x8(%rbp),%rax  
 0x0000000000400538 <fun_B+43>:       mov    0x8(%rax),%rax  
 0x000000000040053c <fun_B+47>:       lea    (%rdx,%rax,1),%rax  
src/stack.c:37  }  
 0x0000000000400540 <fun_B+51>:       leaveq   
 0x0000000000400541 <fun_B+52>:       retq 
0x000000000000002a:  Cannot access memory at address 0x2a

fun_B() is executed and returns to an invalid address suggesting a corrupted stack. fun_B() leaves but that there was no corresponding push on entry to fun_B()
=> the function pointer comp that was called in main() had been corrupted.

Integrate GDB into Eclipse* CDT

To use the provided GNU* Project Debugger GDB instead of the default GDB debugger provided with the default GNU* tools installation of your distribution, please source the following debugger environment setup script:

<install-dir>/system_studio_2013.0.xxx/debugger/gdb/bin/debuggervars.sh

Remote debugging with GDB using the Eclipse* IDE requires installation of the C/C++ Development Toolkit (CDT)  (http://www.eclipse.org/downloads/packages/eclipse-ide-cc-linux-developers-includes-incubating-components/indigosr2) as well as Remote System Explorer (RSE) plugins (http://download.eclipse.org/tm/downloads/). In addition RSE has to be configured from within Eclipse* to establish connection with the target hardware.

1. Copy the gdbserver provided by the product installation

<install-dir>/system_studio_2013.0.xxx/debugger/gdb/<arch>/<python>/bin/

to the target system and add it to the execution PATH environment variable on the target.

2. Configure Eclipse* to point to the correct GDB installation:

a. Inside the Eclipse* IDE click on Window>Preferences from the pulldown menu.

b. Once the preferences dialogue appears select C++>Debug>GDB from the treeview on the left.

c. The GDB executable can be chosen by editing the “GDB debugger” text box. Point to

<install-dir>/system_studio_2013.0.xxx/debugger/gdb/<arch>/<python>/bin/,

where <arch> is ia32 or intel64 and <python> is py24, py26, or py27, depending on architecture and Python* installation

Summary

Intel provides extra capabilities to GDB, the GNU* Project Debugger, targeted at strengthening it's ability to find and resolve vexing runtime issues of code running on Intel® architecture based devices fast. The application specific branch trace supplements callstack backtrace and reverse execution by providing a fast and reliable method of unwinding past execution flow and pinning down root causes for segmentation faults and issues corrupting the callstack. PDBX based data race detection provides the ability to pin down root causes for concurrency introduced runtime bugs in your code as part of your default GDB based debug methodology. Every effort is made to ensure that this GDB integrated with the Intel® System Studio supports embedded cross-debug requirements for target OS's like Yocto Project* and Wind River* Linux* whether they are running on a remote small form-factor target device or inside a virtual machine.

This is the second blog I have written in which TouchDesigner is mentioned, but this time I have an informative interview with Jarrett Smith, system architect of TouchDesigner and Ben Voigt, product manager of TouchDesigner included. TouchDesigner is a very exciting and unique program. I have a hard time concisely explaining what TouchDesigner is as it has so many uses and  applications. It has a node based interface and is also open to programming. Python will be added to it as a language that can be used.  I will call it a platform from which you can according to the website create, interactive art production, architectural and environmental projections, pre-visualization, live character puppeteering, prototype environments, projection mapping, real time special effects, and VJ and in-studio performances.

My uses of it mostly falls within the VJ performance category.  I also create and render out images from it much as you would from any 3d program such as Autodesk Maya. I find it easier to do certain types of complex modeling in Maya so I import the model and material into TouchDesigner.  I should be able to import animation as well but have not yet succeeded in that. Of course as in most VJ programs I can import in movies and images and do compositing and other operations on them real time.  

I am excited about using TouchDesigner in the next immersive environment dome show I create. The mapping capabilities of TouchDesigner will enable me to map the dome and any stage sets I am using. Ideally I will be able to perform live visuals, video playback  and do real time animation which can also be controlled by channels in my audio. TouchDesigner has a module which will enable me to hook up to Kinect hardware so I can have performers interacting with the visuals and music. I wish I had done this for the "Blue Apple" dance performance in the dome I created the visuals for several months ago. There is also a Photoshop module in TouchDesigner I would like to try out. Audience members will also be able to interact with the visuals using controls on the the iPad, iTouch or iPhone using the TouchDesigner OSCemote app.  My hope is that in the future more built out modules for the most commonly used functions will be included in the TouchDesigner interface.  Doing this can will only increase the number of people who use the platform.

 Questions (answered by Jarrett Smith and Ben Voigt)

 What was the initial inspiration that led to the development of TouchDesigner?

 Our passion for music electronic music and performing live visuals alongside musicians and DJs was the inspiration. At the time, there we not many tools and we were hacking Houdini to become as realtime as we could make it. We saw the need for more specialized tools for live performance and decided to develop new tools to focus on realtime animation.

Was it a labor of love?

 Yes, the love for music, visuals, and technology.

Do you feel TouchDesigner occupies a unique spot in the market place?

 Yes, there are not many software packages that target live visual performances and the custom installation market the way TouchDesigner does. When you consider the level of customization TouchDesigner allows and the unique visual interface that constantly communicates with the user, that group is even smaller.

What were the initial goals for the development of TouchDesigner and have they changed?

 As technology has changed over the last 10 years, so too have TouchDesigner's goals. The initial goal of making visuals performed to music is now just one part of the bigger picture. Video playback has become a much more important cornerstone of TouchDesigner technology over the past 6 years. As well, the more recent rise of projection mapping and full show control/management have defined our development over the past few years.

What do you feel is important in interface design and what inspired the design of the TouchDesigner interface?

 When redesigning TouchDesigner's UI for 077, form really followed function. As a procedural node-based program, we realized the most time consuming thing when working was trying to identify where in the project something was taking place. How could you easily trace back where a certain effect or modification was introduced? By introducing an interactive viewer to each and every node, the user can now visually see where things change, follow their data flowing through the operators more easily. This was a breakthrough when compared to the previous workflow of loading each node into a single viewer or scouring through parameters to decipher where something was changed.

How has user input influenced you in the continuing development of the interface and engine?

 Our users have helped guide what features we have built into TouchDesigner, either through specific requests and unique project requirements or by popular demand. For example, Kinect functionality was something our users really wanted to experiment with, so we built it in. 

What do the majority of TouchDesigner users use TouchDesigner for?

 The uses are so varied and diverse that question is hard to answer. If we had to generalize, any form of visualization that lets you interact with it! More specifically, we've seen a large increase in people using it for high performance, large scale multi-display installations and live shows.

What has surprised you about how people are using TouchDesigner?

It always a nice surprise when we find out about a new studio or individual (who we've never heard of) doing amazingly creative work somewhere around the world. The TouchDesigner Vimeo group is a constant source of inspiration for us.
We'll never forget then time when TouchDesigner was hooked up to large trees to monitor the trees response to music stimulation!

Do you do personal projects using TouchDesigner? If so please describe..

 Yes, most of the employees at Derivative have also use TouchDesigner for personal projects. A variety of projects have been done from custom VJ video mixers, to art gallery exhibits, to large size prints, to oscilloscope rendering for a music video.

Any plans for the future of TouchDesigner you care to disclose?

 TouchDesigner 088, the next version of TouchDesigner, is currently in beta and should be released early next year (2013). TouchDesigner 088 includes the addition of Python as the default scripting language along with a number of other new features. More information on the beta can be found here: http://www.derivative.ca/Events/2012/088BetaRelease/

There is a fundamental problem when creating new hardware: you need software using it before anyone is willing to buy it. The problem with getting software written for new hardware, is that no one wants to put in the time to build applications using hardware that no one has bought yet. This chicken and egg problem has killed lots of cool hardware, from anyone who hasn't had the skills to develop their own killer apps, or the clout to convince the world that every one will buy their hardware. My first week of work on the challenge has been dedicated to trying to solve this problem.

The plan is to write a platform layer like GLUT and SDL, but with a twist. Instead of giving the application access to inputs like mouse and keyboard, I describe generic inputs like pointers, axis and events. That way an application that supports a pointer, works just as well if the input comes from a mouse, a touch screen, a Waccom, WiiMote or any other hardware that you can use to point with. Obviously they have differences you can query; A mouse may have multiple buttons, while a touch screen only has one "button". (You cant "right click" on a touch screen, well yet. If you build that hardware my API will support it).

Most platform libraries come as a DLL, and if we make this a open source DLL anyone could add what ever hardware support they wanted to it and any application using the DLL would be exposed to the new hardware. Great! Except if we wrote a DLL that supported every known hardware, it would obviously become huge and create a dependency hell, and what if someone created a version of the DLL that supported my sound system and someone else wrote a different version of the DLL that supported my pedals, how would I be able to play my racing game and hear the engine scream when I pushed the pedal?

So I decided we need a different approach, Lets make the library lean and mean instead, but lets give it a plugin interface so that you can write modules for it that add new functionality. Each module is independent and can add as much or as little functionality as you want. The library itself is only a few files large so you can even just drop them in to your project and make a self contained executable that has no dependencies to any DLL. Nice and tidy!

This week I set out to write this library dubbed "Betray" and I knew I was in for a bit of a Indirection hell but problems didn't arise where I thought they would.

The first objective was to do a bit of house keeping and create a utility library to handle some platform specific things, that aren't related to windows, drawing or inputs. In about a day I wrote the sub library "imagine" to handle the following:

-Directory management (Listing volumes and directories, had to do some
work to unify unix and windows here)
-My Application settings API (previously found in "Seduce")
-Dynamic loading of Libraries and sharing of function pointers.
(Needed for the plugin system)
-Threads and Mutexes. (Previously in my old platform layer)
-Execution. (Previously in my old platform layer)

Then I went on to implementing the basic out of the box functionality of the betray library: (Much of this was code taken form older projects)

-Opening a window with OpenGL/OpenGL ES Context (With FSAA)
-Mouse / keyboard
-Reading Cut/paste
-Opening file requesters.
-Directory search
-Execute
-Quad buffer stereoscopic. (It should work but i don't have a display
to test it on :-()
-Threads
-Multi-touch (will still run on pre 7 Windows)
-Fullscreen
-Timers
-Mouse warp

See the API HERE

This was quick and easy and I followed it by building a brand new plug-in API. It too went fairly pain less, although the constant passing around of function pointers got mind numbing after a while. Once done the new plug-in API supported:

Allocation and setting of:
-Multiple Pointers
-1-3D Axis
-Buttons with labels and key-codes.
-The ability to hook in to the main loop.
-The ability to listen to events from windows event pump
-A sound API (Few features are still missing)
-A settings API, so that plugins can communicate their settings to a
application.
-View Vantage
-View direction

See the API HERE

I started out writing some test plugins for some hardware I found in my apartment like a Microsoft 360 controller. It worked brilliantly once I figured out what the DLL needed was really called (Not what MSDN says). Then I went on to write a plugin for TrackIR and that went reasonably well too.

Then I had this idea that turned in to a Rabbit hole: What if the Betray API could trick the application in to drawing in to a texture instead of the the screen? Then (potentialy) a plugin could manipulate the screen output before its drawn to screen. You could do things like Color correction plugins (You could play Diablo as gloomy as you want!), plugins that could save out massive screen shots, and if you let the plugins draw more then once you could even support anaglyph 3D, and mult-iscreen CAVE environments!

This was just too cool to not do, so I wrote all the code I though I needed to do this. Then I ran the code... Well it did nothing I thought it would. The problem is that the application has a bunch of OpenGL state and as soon as the plugin tries to access any OpenGL functionality it will need to set its own state, and thats a problem because it, A doesn't know what state OpenGL is in, and B upsets the applications state. I briefly considered trying to read out the current state so that plugins could put it back once it was done with it, but that would be a huge amount of work and wont be forward compatible as newer versions of OpenGL adds more state. The solution will have to be to use 2 OpenGL contexts and its starting to get complex so I will need to do way more work on this.

Finally I came to the big price: The depth seeing camera intel sent me! I'm not at all convinced that depth seeing cameras are very good as interfaces but there is one particular feature Ive been looking for and that is the ability to get the vantage point of the user to the screen. A depth seeing camera should be able to very accurately compute the users head position in front of the computer.

Initially I had some problems just from the fact that the API is C++, and I am a pure C programmer but my good friend Pontus Nyman was nice enough to lend a hand and write a C wrapper for the functionality I needed. So one night we sat down to tie together his nice wrapper with my nice plugin API. Intel has provided us with the Perceptual computing API that contains face tracking so this should be easy, but when we started looking at the data coming out of it, it wasn't very good. It was jerky, imprecise and often didn't pickup a faces more then a few times a second. All the output turned out to be 2D and it leads me to believe it isn't using the depth camera to help it do better facial recognition (the depth camera output was less noisy then the color cameras). You do get access to the depth buffer, but its warped and you need to do a look-up in to a uv table to map it over to the color image, the problem is that you cant do it the other way around so its hard to look up the depth in the depth buffer of the facial detection running on the color buffer. We did some hacks to get something out of it, and for a brief moment here and there it was working, but not at all reliable enough.

I will give it a few more days, but right now its not looking very good. In theory I could write my own face detection code using the depth buffer alone that could be much better but that is a much larger project then i planed, for only a tangentially important feature. I want to begin work on my interface stuff this week, maybe its something I can look in to after GDC. This Week I intend to tie up all lose ends in the Betray platform, release it and move on to the new interface toolkit!

Edit: Intel confirms that the algorithm is not using the depth map for face recognition, but they also suspect I have faulty camera (I sent them images), so they are sending me a new one. The cameras are Pre-Production so this kind of thing is expected. Very nice to get such fast feedback!

This week Ive been thinking a lot about how to design a UI toolkit, and this is about to get very techy, because I would like to talk about API design.

I prefer C to C++ and I'm not particularly fond of Object orientation (Although i use it on occasion). UIs is an area that are often thought of as a place where Object Oriented design realy shines, but I think that is because of how we think UIs should be designed. Lets have a look at how one would typically create a button in a UI system:

void my_button_callback(void *user)
{
    printf("Button was clickedn");
}

{
    UIContainer *c;
    c = create_ui_container();
    add_ui_button(c, x, y, "Click me!", my_button_callback, NULL);
    
    while(TRUE) /* our main loop */
    {
        manage_ui_container(c);
    }
}

void my_button_callback(void *user)
{
    printf("Button was clickedn");
}

{
    UIContainer *c;
    UIElement *e;
    c = create_ui_container();
    e = add_ui_button(c, x, y, "Click me!", my_button_callback, NULL);
    
    while(TRUE) /* our main loop */
    {
        move_ui_element(e, sin(current_time), cos(current_time));
        manage_ui_container(c);
    }
}

void my_button_callback(void *user)
{
    printf("Button was clickedn");
}

{
    UIContainer *c;
    UIElement *e;
    c = create_ui_from_file("my_ui_design.dat");
    e = query_for_element("button");
    if(e != NULL)
        attach_callback_to_element(e, my_button_callback, NULL);

    while(TRUE) /* our main loop */
    {
        if(e != NULL)
            move_ui_element(e, sin(current_time), cos(current_time));
        manage_ui_container(c);
    }
}

    while(TRUE) /* our main loop */
    {
        if(my_button(x, y, "Click me!"))
            printf("Button was clickedn");
    }

void my_main_loop(BInputState *input, void *user_pointer)
{
    if(my_button(input, x, y, "Click me!"))
        printf("Button was clickedn");

}

void my_main_loop(BInputState *input, void *user_pointer)
{
    static float value = 0;
    static void *slider_handle = NULL;
    
    if(slider_handle == NULL)
        slider_handle = create_slider_handle();

    my_slider(input, slider_handle, &value, x, y, "slider!");
}

void my_main_loop(BInputState *input, void *user_pointer)
{
    static float value = 0;
    my_slider(input, &value, &value, x, y, "slider!");
}

void my_main_loop(BInputState *input, void *user_pointer)
{
    float *value;
    static char *ids = NULL;
    uint i;

    value = user_pointer; /* lets assume user_pointer keeps changing for sake of argument. */
    
    if(ids == NULL)
        ids = malloc(2600);
    for(i = 0; i < 2600; i++)
        my_slider(input, &ids[i], &value[i], x, y + i, "slider!");
}

void my_main_loop(BInputState *input, void *user_pointer)
{
    draw_my_desktop(input, &ids[0], "picture_of_a_cat.jpg");
    if(draw_icon_on_desktop(input, &ids[1], x, y, "software.exe"))
        execute_software("software.exe");
    draw_window(input, &ids[2], x2, y2, "files");
    draw_content_in_window(input, &ids[3]);
}

void my_main_loop(BInputState *input, void *user_pointer)
{
    if(draw_content_in_window(input, &ids[0]))
        return;

    if(draw_window(input, &ids[1], x2, y2, "files"))
        return;

    if(draw_icon_on_desktop(input, &ids[2], x, y, "software"))
    {
        execute_software("software");
        return;
    }
    draw_my_desktop(input, &ids[3], "pictiure_of_a_cat.jpg");
}

void my_main_loop(BInputState *input, void *user_pointer)
{
    if(input->mode == BAM_DRAW)    
    {
        r_matrix_push(NULL); /* similar to glPushMatrix */
        r_matrix_rotate(NULL, time, 0, 1, 0); /* similar to glRotate */
    }

    if(my_button(input, x, y, "Click me!"))
        printf("Button was clickedn");

    if(input->mode == BAM_DRAW)
        r_matrix_pop(NULL); /*  similar to glPopMatrix */
}

Continued enhancements to Intel platforms and KVM-based Red Hat Enterprise Virtualization make platform refresh an attractive proposition. Independent testing commissioned by Intel and Red Hat demonstrates that open virtualization on refreshed servers, servers 2 years old or more, enables workloads to be supported on fewer hosts, reducing equipment and facilities requirements, as well as lowering operational expenses such as power, cooling, and support.

Server Refresh with Intel® Xeon® processor E5-2690 and Red Hat Enterprise Virtualization:

A Simple Path to Dramatic Performance and Cost Improvements Continued enhancements to Intel platforms and KVM-based Red Hat Enterprise Virtualization make platform refresh an attractive proposition, but when to make the move? Intel and Red Hat commissioned Principled Technologies, a technology assessment and testing firm, to quantify some of the potential benefits. A middleware application was moved, without changes, from a bare-metal server based on the Intel® Xeon® processor 5500 series to a virtual machine (VM) under Red Hat Enterprise Virtualization 3.1 on the Intel® Xeon® processor E5-2690. The VM delivered 90.3 percent greater application performance than the previous-generation bare-metal server. Even more dramatic results were generated by running a second, identical (but isolated) VM on the newer host: 143.8 percent greater application performance compared to the bare-metal server. Each VM had 16 virtual cores and 24 GB of virtual RAM, matching the 16 logical cores and 24 GB RAM on the bare-metal server. Both the VMs and the bare-metal server ran Red Hat Enterprise Linux* 5.8.2. This result demonstrates that open virtualization on refreshed servers, servers 2 years old or more, enables workloads to be supported on fewer hosts, reducing equipment and facilities requirements, as well as lowering operational expenses such as power, cooling, and support.

Server Refresh: Migrating Server Workloads to Red Hat Enterprise Virtualization on Intel® Xeon® Processor 2600-based Servers

Principled Technologies, a technology assessment and testing firm, virtualized a middleware application running on Red Hat Enterprise Linux hosted on a previous-generation bare-metal server onto a Red Hat Enterprise Virtualization VM on a two-socket server powered by Intel® Xeon® processors E5-2690. The migration caused minimal disruption and the single VM increased performance over the previous-generation server by 90.3 percent, with headroom to host additional applications. When a second VM was added to take advantage of the headroom, each VM still outperformed the previous-generation server, indicating that moving previous-generation servers to VMs backed by Intel® Xeon® processors E5-2690 can significantly improve overall Java performance while providing the benefits of both virtualization and new server technologies.

By John Tyrrell

Download Article

 Loclville Case Study.pdf [807.07 KB]

Introduction

Loclville is a free Windows* 8 app that provides an easy-to-use virtual community notice board. Developed by amateur app developer Zubair Lawrence, a Sr. Production Services Technician at Sony Pictures Imageworks, the app began life as a web site and was subsequently redesigned for the Intel-sponsored App Innovation Contest hosted by CodeProject in fall 2012.

Visually inspired by classic cork pin boards, Loclville lets anyone post notices without the need to register, with users moderating the posts through a voting system. Central to the app’s functionality is the ability to set the geographical size of the community users want to interact with. The accessible design lets even the most reticent computer users easily engage with their local community online.

 Loclville running on Microsoft Surface*.

The Loclville app is now available on the Intel AppUp® center and the Windows* Store, optimized for Ultrabook™ devices running Windows 8, and is also available for the Google Android* and BlackBerry* mobile devices.

During development of Loclville, Lawrence collaborated with the originator of the idea for the concept and execution of the app, and with a graphic designer for the visual assets. Lawrence experienced numerous development challenges, many of which he encountered for the first time, from how to accurately manage the geo-localization inherent to the app’s core functionality, to programming for a touch UI on Ultrabook and handheld devices.

Approach

Lawrence approached the development of the app in two separate parts: the app side, which is the program that users download and interact with, and the server side. Each part had its own distinct development process.

JavaScript* and HTML5

Lawrence initially decided to use JavaScript as the main programming language for the app as one of the core technologies (the other being CSS3) for interactivity and animation in the HTML5 development environment. Based on this decision, he was ultimately able to reuse significantly more of the code and functionality from the web site than he originally thought possible, in addition to being able to keep the server-side calls.

Though Lawrence had reservations about using JavaScript and HTML5 after hearing other developers’ concerns about speed, he found that JavaScript was able to deliver fast performance depending on how the code was written. Lawrence’s early decision to use JavaScript as the main language for the app was ultimately justified, and he described it as one of the best choices he made.

AJAX

During the coding of the original web site, Lawrence relied heavily on AJAX, the collection of client-side web technologies—including JavaScript and XML—that facilitates asynchronous web applications. For app creation, AJAX delivered a number of efficiencies, including the ability to reuse the web site code, particularly on the server side.

The app was designed with API calls for the different features; for example, receiving posts or retrieving them from the drag-and-drop pocket feature. With one call, the app serves up all the posts for the area specified. The AJAX JavaScript-coded procedures from the site were reused for the app, which meant the app could more easily be completed within the project deadline.

Server

Lawrence first considered building the app using PHP on a Linux* server. However, concerns about scalability led him to experiment with, and eventually choose, the Azure* platform from Microsoft. Azure provides a virtual machine for each server, hence delivering a much more scalable server configuration with as many virtual servers as needed spread out globally through the platform’s distributed cloud solution. Windows Azure Mobile Services was employed for the push notifications, with all the images stored on the Windows Azure Content Delivery Network (CDN).

HTML5 Encapsulator

To create the desktop app, Lawrence Initially experimented with AppJS, the Intel AppUp encapsulator, and TideSDK, finding the latter a bit too complex and offering features he didn’t need. After these initial road tests, Lawrence decided to use the Intel AppUp encapsulator to build the HTML5 app, finding it to be an invaluable tool to quickly bring the app to the desktop.

Once the basic app was up and running, Lawrence discovered that he required greater location support. To achieve this, Lawrence switched to the AppJS solution, which offered the HTML5 geo-location features and the Mac* and Linux support he needed.

Store and Desktop

Lawrence also made an early decision to develop simultaneously for the Windows Store and for the desktop in order to maximize the audience potential. Because of its association with Intel, Lawrence thinks the Intel AppUp center gives consumers a higher degree of confidence in the apps, with the extra testing helping to ensure the safety and security of content. In addition, the fact that the Intel AppUp center is not restricted to only the Windows 8 platform helped the app reach a much larger audience than it would otherwise.

Development Challenges

Location

One of the most significant development challenges Lawrence faced was ensuring the integrity of the individual user location data, which is critical to the proper functioning of the app. Drawbacks with the Global Positioning System (GPS) data alone include uncertainty over the age of the data—there is always a possibility that the user is many miles from the location where the last reading was taken—and whether the GPS was actually correctly locked on when the data was read.

Loclville screen layout on mobile.

During the early stages of development, Lawrence noticed inaccuracies in the location data, with data that were either imprecise or showed multiple locations. To remedy this, Lawrence implemented a hybrid process with which the app collects both GPS data from the devices itself and IP address data. These readings automatically update throughout the user session to ensure that positioning information is as accurate as possible and to guarantee the useful functioning of the app’s key distance radius features.

When serving up posts based on a user’s specific location, the server first receives a request for a post, and then compares the latitude and longitude coordinates of the requester with the latitude and longitude of the posts in the database. The posts within the defined radius are returned (Figure 1).

Figure 1.Sample code used by the Loclville app that establishes the distance between sets of latitude and longitude coordinates.

Touch and UI

Because Lawrence had no prior experience implementing a touch UI, understanding the different requirements related to menus, screen size, button size, and positioning on-screen was challenging. Lawrence used a responsive design approach, designing in such a way that the app or web site provided an optimized viewing experience across a wide range of different devices and screen sizes. Using this approach, Lawrence was able to ensure that the app serves up the appropriate UI for the device it’s running on, delivering a high level of legibility and straightforward navigation, with a minimum amount of resizing, panning, and scrolling required from the user.

Loclville running responsively on a variety of different screen configurations.

To determine how the UI should respond, the app queries the pixel size of the screen and the device itself, then uses those conditions to decide how to draw the UI and adapt to any changes. If the user rotates the screen of the device—for a tablet or smartphone, for example—or if the web browser window is resized, the app responds and adjusts the UI accordingly.

The original Loclville web site featured bold and simple buttons and menus that helped facilitate a relatively straightforward transition to smaller screens and touch controls. Tweaks were made to the drop-down menus and some of the links in order to optimize them for touch. These modifications included making buttons more finger-friendly by ensuring enough separation between them to help prevent accidental presses.

Adapting to smaller screens also involved repositioning some of the menus to make better use of the limited space available. The Distance, Categories, and Post buttons were moved to a footer menu, and posts were changed to be shown in a list view, making it possible to show more in a smaller space. Because of the overall simplicity of the layout, Lawrence decided against implementing any specific changes related to flipping between portrait and landscape views on a phone or tablet. The overall result of the optimizations is an app that is well adapted to multiple devices and screen sizes.

jQuery

Another challenge that Lawrence faced was that he needed to make jQuery work in a Windows 8 JavaScript app. Unlike the desktop version of the app, the Windows Store app had to meet code compliance requirements, which meant porting the jQuery library to allow it to work with the Windows Store version.

Figure 2 below shows the code implemented in the app for porting jQuery to work in the Windows 8 JavaScript app.

Figure 2.Sample code from the Loclville app for porting jQuery.

Testing

Beta testing the app was an informal process, conducted primarily by collaborators, their friends, and by the users themselves. After each set of changes, Lawrence released a new version of the code, and then proactively gathered feedback from users regarding its functionality, usability, and bugs. Lawrence said the testing was the most difficult part of the development process, noting that users often behaved unpredictably when using the app, making the testing both very important and challenging.

An example of unexpected behavior occurred when users were asked to input their address, a vital piece of data for the proper functioning of the app. Lawrence repeatedly saw an error stating that the app was unable to find the address. He eventually realized that the input question was ambiguous, causing users to enter their e-mail address, which naturally would not permit the app to pinpoint their physical location. The implementation of automatic geo-localization of the users using GPS and IP address data provided the solution.

Lawrence used a touch screen Ultrabook device for testing to ensure the integrity and proper functioning of the touch interface alongside the traditional mouse and keyboard controls.

Feedback from reviews has also proved useful on at least one occasion for identifying and fixing a bug, although Lawrence has been frustrated by the one-way nature of the communication with reviewers. The lack of ability to reply means there is no way to respond directly to let a reviewer know that a bug he or she discovered has since been fixed.

Metrics

To gather Loclville user behavior metrics, Lawrence implemented the open-source analytics tool Piwik*, which gathers data including the app version (for example, browser, Android, iOS*, or Windows 8), the user’s city, whether the user clicks a post, the link clicked to leave the site, and the session length. Lawrence also gathers his own data from the app, including number of posts, user location, and growth and usage patterns.

Lawrence analyzes the data to determine where users are coming from and then offers direct support to those within that locality by creating specific posts, with the goal of helping users grow the community.

Next Steps

Some of the features that Lawrence is considering implementing in the future include:

• Localization. Making the site available in languages other than English, although which languages and when this feature will be available have yet to be defined.
• Monetization. The ability to pay to post commercial offers and information. This feature will be based on the same rules of user voting, thus encouraging only content with real value to users.

                                                                                       Promotional offers in the Loclville mobile app.

• Family filter. Placing more power in the hands of the individual user, as opposed to the community, regarding what content a user sees; for example, providing the ability to filter profanity. This feature would also potentially include the ability to prevent unregistered users from posting pictures. One related challenge is finding a way to filter in multiple languages, a problem that Lawrence is still working to solve.
• Social media integration. On-screen buttons that allow users to directly share Loclville content through a chosen social network such as Facebook*.
• Near Field Communication (NFC). Functionality to allow users to share posts by touching two devices together using NFC technology.

The next major planned update for Loclville is version 3.0, which is currently scheduled for release in September 2013.

Conclusion

Outside of the core coding process, Lawrence cited the following points as important to consider when creating apps:

• Touch is important, but developers shouldn’t ignore the mouse and keyboard. Apps need to be user friendly for both types of user interface.
• Awareness of screen sizes and orientation is crucial. Apps are now expected to run on more devices than ever, from the 10-inch screen of a Microsoft Surface* and 13- or 14-inch Ultrabook device screens to even a 30-inch desktop screen. With tablets and Ultrabook convertibles, developers also need to be aware of the different design demands of landscape and portrait layouts, and develop accordingly.
• Take the time and effort to submit apps to both the Windows Store and the Intel AppUp center because the potential audience is huge.

Despite the concerns he heard regarding the use of HTML5 and JavaScript as an app development platform, Lawrence firmly believes that the combination of HTML5 and AJAX technologies was the right choice, and he plans to continue using a similar workflow for subsequent apps.

About the developer

A 2009 Masters graduate of the Savannah College of Art and Design in Georgia, Zubair Lawrence started programming as part of his Visual Effects degree course and rapidly developed both a strong affection and a clear affinity for it. He has since developed his coding knowledge and abilities beyond the Python* programming that was part of his course, becoming a competent self-taught application programmer.

In June 2011, Lawrence joined the CodeProject independent developer community (http://www.codeproject.com) using the moniker Helix Ten and continued to code avidly in his spare time even after joining California-based Sony Pictures Imageworks* in January 2012. In December 2012, Lawrence successfully entered the Loclville app into the Intel-sponsored App Innovation contest hosted on the CodeProject web site. Lawrence complements his professional work at Sony Pictures Imageworks with coding in his spare time, including ongoing support and updates to the Loclville app and web site.

Helpful resources

One of the most valuable resources for Lawrence during the development of the Loclville app was the development community on CodeProject, the site that hosted the Windows* 8 & Ultrabook™ App Innovation Contest. During development of the app, Lawrence interacted frequently with the community members, and he still visits the site frequently. The Intel HTML5 Encapsulator was invaluable in allowing Lawrence to bring the app to the desktop quickly, with a great deal of documentation and videos available to support the development process. Lawrence cited the documentation available on the Intel AppUp center as a vital resource during the app submission process, describing it as being very clear and thorough.

Portions of this document are used with permission and copyright 2012 by CodeProject. Intel does not make any representations or warranties whatsoever regarding quality, reliability, functionality, or compatibility of third-party vendors and their devices. For optimization information, see software.Intel.com/en-us/articles/optimization-notice/. All products, dates, and plans are based on current expectations and subject to change without notice. Intel, the Intel logo, Intel AppUp, Intel Atom, the Intel Inside logo, and Ultrabook, are trademarks of Intel Corporation in the U.S. and/or other countries.  *Other names and brands may be claimed as the property of others. Copyright © 2013. Intel Corporation. All rights reserved

In my previous blog, I discussed “Ways to Speeding up Your Cloud Environment…”, I will continue with this thread by introducing the topic of Software Defined Networks (SDN).  The industry has been depending on proprietary networking equipment and appliances, essentially creating an environment requiring vertical integrated software running on dedicated hardware. Due to millions of new connected devices and increasing traffic in the cloud computing environment, the network congestion challenges the vertical networking business model.  As a result, the cloud computing community is looking into a network virtualization solution. 

This blog focuses on speeding up your data packet networking by using the Intel® Data Plane Development Kit (Intel® DPDK) on Intel® Architecture.  With an Intel® Xeon® processor E5-2600 series (or later), an integrated DDR3 memory controller, an integrated PCI Express controller, and Intel DPDK, you can potentially see the increase for small network packet throughput in your cloud computing environment.  Before going into the Intel DPDK, I want to provide some insight for those unfamiliar with the terminology related to the SDN.

Common Terminology for SDN (from Wiki)  

• SDN is a form of network virtualization where the control plane is separate from the data plane, and is implemented in a software application. SDN architecture allows network administrators to have programmable control of network traffic without the need to access to the network's hardware devices.
• Control plane is the part of the router architecture concerned with the information in a routing table that defines what to do with incoming packets. 
• The data plane defines the part of the router architecture that decides what to do with packets arriving on an inbound interface.  
• Network virtualization is the process of combining hardware, software network resources, and network functionality into a single software-based administrative entity. 
• A virtual network is a link that does not consist of a physical (wired or wireless) connection between two computing devices.  Network virtualization involves platform virtualization, often combined with resource virtualization.
• Platform virtualization hides the physical characteristics of a computing platform from users, instead showing another abstract computing platform.
• Hypervisor is the software that controls virtualization.

Intel’s 4:1 Workload Consolidation Strategy

Intel’s strategy is to consolidate the workloads (application, control plane, packet and signal processing) into a more scalable and simplified solution on Intel® Xeon® processor platforms.  This software-based approach depicted in Figure 1 shows the Intel’s 4:1 workload consolidation strategy.  Figure 2 and Figure 3 show the performance increases from various generations of Intel architecture processor-based platforms.

Figure 1. Intel's 4:1 Workload Consolidation Strategy

Note: Performance tests and ratings below are HW/SW configuration dependent and measured using specific computer systems and/or components as measured by those tests. Any difference in the configuration will reflect in the test results.

Figure 2. Breakthrough data performance with Intel® development kit (Intel® dpdk) L3 packet forwarding

Note: The measurement is in Million packets per second (Mpps) and each packet is 64 byte. The data performance (L3 packet forwarding) indicated that you can experience higher throughput by applying the Intel DPDK to your Linux environment.

Figure 3. IPv4 Layer 3 Forwarding performance for various generations of Intel Architecure Processor-based platforms

Figures 2 and 3 show the small packet performance achievable using the Intel Architecture with the Intel DPDK.    The hardware elements that contribute to the performance increase are the integrated memory controller, the integrated PCI Express* controller, and the increase number processor cores per chip in the latest Intel processor.   

The System Configurations Used for collecting the data used in Figure 2 and Figure 3 were:

• Dual Intel® Xeon® processors E5540 (2.53 GHz, 4 core) processed 42 Mpps.
• Dual Intel® Xeon® processors E5645 (2.40 GHz, 6 core) processed 55 Mpps.
• A single Intel® Xeon® processors E5-2600 (2.0 GHz, 8 core) processed 80 Mpps (with Intel® Hyper-Threading Technology (Intel® HT Technology) disabled).
• A dual Intel® Xeon® processors E5-2600 (2.0 GHz, 8 core) processed 160 Mpps (with Intel® HT Technology disabled) and 4x 10GbE dual port PCI Express* Gen2 NICs on each processor.

Intel DPDK Overview

The Intel DPDK is based on simple embedded system concepts and allows users to build efficient small packet (64byte) high performance applications.  It consists of a growing number of libraries (Figure 4) designed for high speed data packet networking, and offers a simple software programming model that scales from Intel® Atom™ processors to the latest Intel® Xeon® processors. The source code is available for developers to use and/or modify in a production network element.

• The Environment Abstraction Layer (EAL) provides access to low-level resources (hardware, memory space, logical cores, etc.) through a generic interface that hides the environment specifics from the applications and libraries.
• The Memory Pool Manager allocates NUMA-aware pools of objects in memory.  The pools are created in huge-page memory space to increase performance by reducing translation look aside buffer (TLB) misses, and a ring is used to store free objects.  It also provides an alignment helper to ensure objects are distributed evenly across all DRAM channels, thus balancing memory bandwidth utilization across the channels.
• The Buffer Manager reduces the amount of time the system spends allocating and de-allocating buffers.  The Intel DPDK pre-allocates fixed size buffers, which are stored in memory pools for fast, efficient cache-aligned memory allocation and de-allocation from NUMA-aware memory pools.  Each core has a dedicated buffer cache to the memory pools, which is replenished as required.  This provides a fast and efficient method for quick access and release of buffers without locks.
• The Queue Manager implements safe lockless queues instead of using spinlocks that allow different software components to process packets, while avoiding unnecessary wait times.
• The Ring Manager provides a lockless implementation for single or multi producer/consumer en-queue/de-queue operations, supporting bulk operations to reduce overhead for efficient passing of events, data and packet buffers.
• Flow Classification provides a proficient mechanism for generating a hash (based on tuple information) used to combine packets into flows, which enables faster processing greater throughput.
• Poll Mode Drivers for 1 GbE and 10 GbE Ethernet controllers greatly speed up the packet pipeline by receiving and transmitting packets without the use of asynchronous, interrupt-based signaling mechanisms, which have a lot of overhead.

Figure 4. Major Intel DPDK Components

The Intel DPDK library is currently provided cost-free to OEMs under a BSD licensing model. A public version of the software will be available to download in early 2013.  For more information, see www.intel.com/go/dpdk. 

Once you download the Intel DPDK, here is the suggested reading order to use the kit:

• Release Notes: Provides release-specific information, including supported features, limitations, fixed issues, known issues, and so on. It also provides frequently asked questions in FAQ format.
• Getting Started Guide: Describes how to install and configure the Intel DPDK; designed to get users up and running quickly with the software.
• Programmer's Guide: Describes:

— The software architecture and how to use it (through examples), specifically in a Linux* application (linuxapp) environment.
— The content of the Intel DPDK, the build system (including the commands that can be used in the root Intel® DPDK Makefile to build the development kit and an application) and guidelines for porting an application.
— Optimizations used in the software and those that should be considered for new development.

• API Reference: Provides detailed information about Intel DPDK functions, data structures and other programming constructs.
• Sample Application User Guides: A set of guides, each describing a sample application that showcases specific functionality, together with instructions on how to compile, run and use the sample application.

Conclusion

The growing demand for more connected devices and data accesses over the network has pushed the vertical network model to the limit.  To save cost and reduce power consumption of the network infrastructure, you may consider decreasing the number of physical assets by consolidating their functions using network virtualization on a common platform.  By using the Intel DPDK library on a common platform, you can:

• experience faster network packet processing,
• potentially reduce cost by simplifying the hardware to industry standard server architectures,
• conserve energy by using power-optimized Intel platforms,
• and increase efficiency by maximizing the utilization of your existing environment.

 References:

Packet Processing on Intel® Architecture:

• http://www.intel.com/go/dpdk
• Intel® Xeon® Processor E5-2600 Series-based Platforms for Intelligent Systems: http://www.intel.com/content/dam/www/public/us/en/documents/platform-briefs/xeon-e5-platforms-for-intelligent-systems-brief.pdf
• Consolidating Communications and Networking Workloads onto one Architecture: http://www.intel.com/content/dam/doc/white-paper/consolidating-networking-workload-onto-ai.pdf
• Workload Consolidation with Even Greater Packet Throughput : http://www.intel.com/content/www/us/en/communications/global-communications-network.html?cid=sem120p17670
• Platform Consolidation Increases Agility and Lower Cost for Server Providers and TEMs: http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/communications-platform-consolidation-paper.pdf
• Software Defined Network (SDN):  http://en.wikipedia.org/wiki/Software-defined_networking

回到英特尔学术社区首页>>

Intel oVirt Worksop | May 2013 | Shanghai, China 

Ovirt strives to become the first and best truly open and comprehensive data center virtualization management suite. As the oVirt community is rapidly evolving and growing, one of the ways we look to connect is through oVirt Workshops around the globe. The May 2013 oVirt workshop successfully held at Intel's Shanghai Campus. This workshop was designed to encourage collaboration in our community, as well as help answer questions about the project from both a developer and user's perspective. Slides and videos are shared in the following event agenda.

Workshop Agenda：

My HAXM (process emulator-x86.exe) always crashed after run Maps.apk in AVD from Google APIs (x86 System Image) version 19 revision 4, Google ADT version 22.6.2, HAXM version 1.0.7 on Windows 8.1 Enterprise x64

Hi.

I'm using Beacon Mountain for Windows on Windows 7 SP 1. I installed the Android USB driver for Windows version 1.1.5 which comes with it.  When I connect the cable Windows sees the connection and tries to install driver software but does not install the "Android" device and so I cannot push my app to the device to test it.  (Eclipse does not see the device.)

I have tried removing the device driver, reinstalling it, rebooting in between, just about every combination of hoops that one normally jumps through with this, and nothing is working.

For the work I'm doing I have to run on the Atom device I have; the emulator environment won't do.

Suggestions, pointers, directions, etc. will be most welcome.

Thanks,

Aharon Robbins

I have just started learning more about Intel XDK. I am loving it and Connie Brodie's lesson was brilliant. Unfortunately she is missing just one video on how to release that app on google play, how does one create an icon that’s linked to the whole app. So that when users download and install the app they get the icon automatically?

Thanks Connie your tutorials are the best and very good. Keep it up.

This post just to notify a small problem with 4.4.2 (api19) x86 image and the HOST GPU setting.

The problem affects the whole emulator and not only apps. Basically when displaying something animated (or even when user swipes the home screen), suddenly the animation stops and the display seems stuck at frame when animation stopped. Animation does not continue any more and when it stops in the middle of a swipe animation, also swipe gesture does not work any more. You have to press menu button to unlock display (probably because display of something else is requested to the system). Also in-app small animation are affected, for example indeterminate progress bar in action bar makes a few round and stops.

If I disable HOST GPU, everything works fine. But it is strange because I have no problem at all with 4.2 (api17) image and HOST GPU enabled.

My machine is Win7 64bit with core i7 cpu, 6GB ram, integrated graphics. Tried with both HAXM 1.0.6 and 1.0.8.

In can make screenshots of the stuck display if someway useful.