Quantcast
Channel: Intel Developer Zone Articles
Viewing all 3384 articles
Browse latest View live

Inference of Caffe* and TensorFlow* Trained Models with Intel’s Deep Learning Deployment Toolkit

$
0
0

Install Deployment Toolkit

First, download Deployment Toolkit.

Then, install the Deployment Toolkit.

The application by default is installed in /opt/intel/deeplearning_XXX/(for root user) or in ~/intel/deeplearning_XXX/(for non-root user). Further in the tutorial we will refer to it as IE_INSTALL.

E.g. ~/intel/deeplearning_deploymenttoolkit_2017.1.0.4463/.

Read introduction to the tool.

Configure Model Optimizer (MO) for Caffe

Configure the Model Optimizer (MO) for Caffe.

Comments for MO configuration steps:

  1. ModelOptimizer folder is
     IE_INSTALL/deployment_tools/model_optimizer
  2. When copying files to Caffe, you can use the following commands, assuming you are in
     IE_INSTALL/deployment_tools/model_optimizer
    Example command could be:
    cp -R adapters/include/caffe/* CAFFE_HOME/include/caffe/
    cp -R adapters/src/caffe/* CAFFE_HOME/src/caffe
  3. To make sure that rebuild of Caffe catched new adapters, in console output you will see something like:
    CXX src/caffe/LayerDescriptor.cpp
    CXX src/caffe/CaffeCustomLayer.cpp
    CXX src/caffe/CaffeAPI.cpp
    CXX src/caffe/NetworkDescriptor.cpp
  4. If you get a problem with hdf5 library on (at least on Ubuntu 16.04), use the following fix. By default the built library is in
    CAFFE_HOME/build/lib

You need to set a variable FRAMEWORK_HOME pointing to it.

E.g. write in ~/.bashrc:

export FRAMEWORK_HOME="CAFFE_HOME/build/lib"
export LD_LIBRARY_PATH="CAFFE_HOME/build/lib:$LD_LIBRARY_PATH"
export LD_LIBRARY_PATH="IE_INSTALL/deployment_tools/model_optimizer/bin:$LD_LIBRARY_PATH"

After you have configured MO on the machine, you need to convert existing Caffe model to the IR.

Configure Model Optimizer (MO) for TensorFlow (TF)

Configure the Model Optimizer (MO) for Tensorflow.

Comments for MO configuration steps:

Install TensorFlow from sources. Further in this tutorial we will refer to the name of framework asTF.

Follow this link for full instruction.

Further in this tutorial, we will refer the directory, containing TF sources (be default it istensorflow) as TF_HOME.

Comments for TensorFlow installation steps:

  1. After cloning and going into the tensorflow(by default) directory, checkout tor1.2 branch:
    git checkout r1.2
  2. If you have built TF with python 3.5, it might be useful to run pip installation of TF wheel with specifying that it is the pip of python version 3+.

    E.g.
    sudo pip3 install /tmp/tensorflow_pkg/tensorflow-1.2.1-cp35-cp35m-linux_x86_64.whl
  3. If you decide to check TF installation leave tensorflow directory. Unless, you will most likely get error while importing TF from python console.

Build Graph Transform Tool, here are instructions.

Comments for Graph Transform Tool installation steps:

bazel build tensorflow/tools/graph_transforms:transform_graph

After that you need to go the ModelOptimizerForTensorFlow in MO folder. E.g.

cd IE_INSTALL/deployment_tools/model_optimizer/ModelOptimizerForTensorFlow

Run the configuration script with necessary parameters. For instance, it should look like:

python configure.py --framework_path TF_HOME

Note: Make sure that there are two dashes before the argument. Sometimes the page is rendered with single dash and you will get an error in terminal.

Install modeloptimizer package:

sudo python3 setup.py install

After you have configured MO on the machine, you need to convert existing Tensorflow model to the IR.

Convert Caffe model to IR

In this tutorial we will take already trained model. In particular, AlexNet from the Caffe ModelZoo.

We will refer to the directory with Caffe model as MODEL_DIR. It should contain a .prototxt (deploy-ready topology structure) and .caffemodel (trained weights) files.

To run MO, use tutorial.

Comments for MO running steps:

  1. To just generate IR, you need to execute it only with options: precision, weights, deploy proto file and that it will be the input for IE (-i).
    ./ModelOptimizer -p FP32
    -w MODEL_DIR/bvlc_alexnet.caffemodel
    -d MODEL_DIR/deploy.prototxt -i -b 1

It should output something like "Writing binary data to: Artifacts/AlexNet/AlexNet.bin".

Meaning that AlexNet IR was generated and both (.xml - topology description and .bin - weights of the model) are placed in Artifacts.

After you have generated IR, let's run it via the appropriate sample. In this case, as AlexNet is a classification model, you need to refer to instructions for building IE samples and running the classification sample.

Convert TensorFlow model to IR

In this tutorial we will take already trained model. In particular, Inception V1 Model from TF ModelZoo.

We will refer to the directory with TF model as MODEL_DIR. It should contain a .pb - a binary protobuf file with deploy-ready topology structure and trained weights.

How to get model from the Model Zoo and convert it to IR

If you have already a model in a .pb format, skip this section and go directly to IR generation.

Originally, you get model checkpoint from the given link. Unzip it to the folder. We will refer to it as CKPT_DIR.

To get the desired .pb file, which is required to generate valid IR, you need to make the .pb file first.

To do that, go to the specific folder:

cd IE_INSTALL/deployment_tools/model_optimizer/ModelOptimizerForTensorFlow/modeloptimizer/frameworks/tensorflow

After that you need to run freeze_checkpoint.py:

python3 freeze_checkpoint.py --checkpoint CKPT_DIR/inception_v1.ckpt --output_pb / MODEL_DIR/inception.pb --output InceptionV1/Logits/Predictions/Reshape_1 --net inception_v1

If there is no error in terminal, you will find the .pb file in a MODEL_DIR.

Now move back to the root folder:

cd IE_INSTALL/deployment_tools/model_optimizer/ModelOptimizerForTensorFlow

To run MO, use tutorial.

Comments for MO running steps:

  1. When specifying a path to the protobuf file, use absolute paths only. Relative ones like ~/models/inception woould not work for you.

  2. To just generate IR, you need first to know the input and the outpuit layers names of the model you are going to convert. If you don't know that, you can use summarize_graph util from the TF, otherwise skip this step. To use it:

    2.1 Go to TF directory. E.g.:
    cd TF_HOME

    2.2 Build it and run, using the instruction.

    In the output, you will get something like:
    Found 1 possible inputs: (name=Placeholder, type=float(1), shape=[1,224,224,3])
    No variables spotted.
    Found 1 possible outputs: (name=InceptionV1/Logits/Predictions/Reshape_1, op=Reshape)
    Found 6633279 (6.63M) const parameters, 0 (0) variable parameters, and 0 control_edges
    Op types used: 298 Const, 231 Identity, 114 Add, 114 Mul, 58 Conv2D, 57 Relu, 57 Rsqrt, 57 Sub, 13 MaxPool, 9 ConcatV2, 2 Reshape, 1 AvgPool, 1 BiasAdd, 1 Placeholder, 1 Softmax, 1 Squeeze

    In this case input layer name is input, output layer is InceptionV3/Predictions/Reshape_1.

  3. To generate IR, you need execute MO with necessary options: path to protobuf model, output path, graph input file, input layer name, output layer name.

    E.g.:
    python3 modeloptimizer/scripts/model_optimizer.py \
    --input_model=MODEL_DIR/inception.pb \
    --output_model=IE_INSTALL/deployment_tools/model_optimizer/ModelOptimizerForTensorFlow/gen/v1.pb \
    --input=Placeholder \
    --output=InceptionV1/Logits/Predictions/Reshape_1 \
    --transforms="\
    strip_unused_nodes(type=float;shape=1,224,224,3) \
    remove_nodes(op=Identity) \
    remove_nodes(op=CheckNumerics) \
    fold_constants(ignore_errors=true) \
    fold_batch_norms \
    strip_unused_nodes(type=float; shape=1,224,224,3) \
    remove_nodes(op=Identity) \
    remove_nodes(op=CheckNumerics) \
    fold_constants(ignore_errors=true) \
    fold_batch_norms \
    strip_unused_nodes(type=float; shape=1,224,224,3) \
    remove_nodes(op=Identity) \
    remove_nodes(op=CheckNumerics) \
    fold_constants(ignore_errors=true) \
    fold_batch_norms  \
    calc_shapes(input_types=float; input_shapes=1,224,224,3) \
    create_ir(model_name=v1; output_dir=gen)"

    It is very important to set the name of the input and output layer in --input and--output argument respectively.

    Note that, this execution influences the original model, so make sure you have made a copy of it in advance. If execution of IR generation fails, it would be better to use the clean model copy.

If you don't see any error message, it means that Inception V1 IR was generated and both (.xml - topology description and .bin - weights of the model) are placed in the folder with output model that you specified in the output_model property when running MO (step 3). In this tutorial it is /home/temp/inception.

After you have generated IR, let's run it via the appropriate sample. In this case, as Inception V1 is a classification model, you need to refer to instructions for building IE samples and then running classification sample.

Build IE samples

General info about IE is here.

More specifically samples information and description can be found here.

Follow these instructions and build samples.

Comments for IE samples building steps:

  1. From the build folder in samples directory:
    cmake -DCMAKE_BUILD_TYPE=Release ..
    make
  2. After that you need to go to the applications binaries:
    cd IE_INSTALL/deployment_tools/inference_engine/bin/intel64/Release

You will find there binaries for all samples in IE.

IE provides an opportunity to infer the IR on a specific device. Currently, it supports CPU and GPU.

To make the IE recognize required libraries availability, use the setvars.sh script, which will set all necessary environment variables.

What is left is running the required sample with appropriate commands, providing IR information.

Run IE classification sample

If your model is a classification one, it should be infered using the classification sample of IE. To run it, you can refer to the following instructions page.

We will refer to the directory which contains IR (.xml and .bin files) as IR_DIR.

For that, run (expect that you are in a Release folder):

source ../../setvars.sh

For IR you have generated with MO, the command to run inference can be the following:

./classification_sample \
-i ~/Downloads/cat3.bmp \
-m IR_DIR/AlexNet.xml \
-d CPU

Please note, that it IE assumes that weights are in the same folder as .xml file.

You will see top-10 predictions output for the given image.


What's new? Intel® SDK for OpenCL™ Applications 2017, R1

$
0
0

The following features are added in the 2017 R1 release.

  • Microsoft Visual Studio* 2017 Support
  • Eclipse* Oxygen (4.7) and Neon (4.6) IDEs Support
  • New Operating Systems Support:
    • Microsoft Windows* 10 Creator Update support including full compatibility with latest Intel Graphics driver (15.46)
    • Ubuntu* 16.04 support including full compatibility with latest OpenCL™ 2.0 CPU/GPU driver package for Linux* OS (SRB5)
    • CentOS* 7.3 support
  • Enhanced tools support for 6th and 7th Generation Intel® Core™ Processors on Microsoft Windows* and Linux* operating systems
    • Usability enhancements and bug fixes
  • Improved OpenCL™ 2.1 and SPIR-V* support on Linux* OS
    • OpenCL 2.1 development environment with the experimental CPU-only runtime for OpenCL 2.1
    • SPIR-V generation support with Intel® Code Builder for OpenCL™ offline compiler and Kernel Development Framework including textual representation of SPIR-V binaries
  • New features in Kernel Development Framework
    • Workflow support allowing build, execution and analysis of applications with multiple kernels
    • Build from binary to reduce compilation time for complex kernels
    • Latency analysis on 6th and 7th Generation Intel® Core™ Processors

Intel® SDK for OpenCL™ Applications 2017 includes all the features for OpenCL development for Windows* previously available in Intel® SDK for OpenCL™ Application 2016 R3 and all features for Linux* development which available in Code Builder for Intel® Media Server Studio.

Introduction to Programming with Persistent Memory from Intel

$
0
0

Introduction

For many years computer applications organized their data between two tiers: memory and storage. The new generation of persistent memory from Intel, based on groundbreaking 3D XPoint™ media developed by Intel and Micron*, has introduced a third tier. Learn about the technology, how it is exposed to applications, and why there is so much excitement around enabling persistent memory.

Persistent memory technologies allow development of products with the attributes of both storage and memory. The products are persistent, like storage, meaning they hold their content across power cycles, and they are byte-addressable, like memory, meaning programs can access data structures in-place.

What really makes Intel persistent memory technology stand out is that it’s fast enough for the processor to access directly without stopping to do the block I/O required for traditional storage.

Optimized System Interconnect

The main reason for the excitement around persistent memory is the ability to provide improved performance over existing storage devices. If you compare a modern NAND-based SSD, which plugs into the PCIe* bus and communicates using the NVM Express* protocol, you can see the time it takes to read a block is over 80 µs. In the graphic below, notice how most of the time is spent accessing the media, as indicated by the blue area. The software stack is a small percentage of the overall access time—we could work on making the driver faster, and the difference would be hardly noticeable.

image of map
Figure 1: Application latency comparison

The Intel® Optane™ SSD also plugs into the PCIe bus but uses 3D XPoint technology, so the time spent accessing the media is greatly reduced and the overhead of the software stack and PCIe protocol become a significant portion of the overall latency. To get the most out of the 3D XPoint technology, it now makes sense to tackle the overhead of both software and the interconnect. That’s where persistent memory comes in.

By connecting the media to the memory bus, the CPU can access the data directly, without any driver or PCIe overhead. And since memory is accessed in 64-byte cache lines, the CPU reads only what it needs to read, instead of rounding every access up to a block size, like storage. In Figure 1, you can see how low latency a 64-byte read is here.

With persistent memory, applications have a new tier available for data placement: in addition to the memory and storage tiers, the persistent memory tier offers greater capacity than DRAM and significantly faster performance than storage. Applications can access persistent memory–resident data structures in-place, like they do with traditional memory, eliminating the need to page blocks of data back and forth between memory and storage.

To get this low-latency direct access, we need a software architecture that allows applications to connect up with ranges of persistent memory.

The Non-Volatile Memory (NVM) Programming Model

The storage stack is shown here at a very high level. These basic blocks that make up the stack haven’t changed much over decades of use. Applications use standard file APIs to open files on a file system, and the file system does block I/O as necessary through a driver or set of drivers. All accesses to the storage happens in blocks, typically over an interconnect like PCIe.

image of map
Figure 2: The storage stack

From an operating system perspective, support for basic file APIs like open/close and read/write have existed for a few decades. Developers writing applications in higher level languages may be programming with libraries that provide more convenient APIs. Those libraries will eventually call these basic APIs internally.

Memory Mapping

Both Windows* and Linux* support memory-mapped files, a feature which has been around for a long time, but is not commonly used. For persistent memory, the APIs for memory mapping files are very useful; in fact, they are at the heart of the persistent memory programming model published by the Storage Networking Industry Association (SNIA).

Memory mapping a file is only allowed after the file is already opened, so the permission checks have already happened by the time an application calls CreateFileMapping and MapViewOfFile on Windows, or mmap on Linux.

image of map
Figure 3: Memory-mapped files

Once those calls are made, the file appears in the address space of the application, allowing load/store access to the file contents. An important aspect of memory-mapped files is that changes, done by store instructions, are not guaranteed to be persistent until they are flushed to storage. On Windows, this is done using FlushViewOfFile and FlushFileBuffers; on Linux, it is either msync or fsync.

This is where the power of the memory-mapped file API really benefits persistent memory programming.

The persistent memory programming model allows byte-level access to non-volatile media plugged into the memory bus, shown here by the common industry term NVDIMM, which is short for non-volatile dual in-line memory module. You can see that once the mappings are set up, the application has direct access, provided by the MMU’s virtual-to-physical mappings. The ability to configure these direct mappings to persistent memory is a feature known as direct access (DAX). Support for this feature is what differentiates a normal file system from a persistent memory-aware file system. DAX is supported today by both Windows and Linux.

image of map
Figure 4: Persistent memory programming model

Introduction to the NVM Libraries (NVML)

NVML is a suite of libraries that are open source and are available today for both Linux and Windows. For more information on these libraries please visit pmem.io, the Persistent Memory Programming web site. These libraries facilitate persistent memory programming adoption with higher level language support. Currently, C and C++ support is fully validated and delivered on Linux, and available as early access on Windows.

flowchart
Figure 5:  The NVM Libraries

Conclusion

Persistent memory is a game changer and the programming model described here provides access to this emerging technology. NVM Libraries provide support for transactional operations to keep the data consistent and durable. There are still lot of unknowns, and there continues to be a lot of exciting work in this field.

To learn more, check out the Persistent Memory Programming video series.

Intel® Parallel Computing Center at NERSC, Lawrence Berkeley National Laboratory

$
0
0

Principal Investigators:

Prabhat leads the Data and Analytics Services Group at NERSC. He is responsible for the big data software stack at NERSC, in this role, he tracks technologies spanning data analytics, management, workflows, transfer, portals/gateways and visualization. His personal research interests are in statistics, machine learning and computer vision. Prabhat has a B. Tech in Computer Science and Engineering from IIT Delhi, and received an Sc.M in Computer Science from Brown University. He is currently pursuing a PhD in Earth and Planetary Sciences from UC Berkeley.

Description:

The goal of the NERSC Big Data Center is to solve DOE’s leading data-intensive science problems at scale on Cori. We are interested in problems that involve management of O(100+) TB datasets, and analysis on O(100K+) cores. We will work with Intel staff to improve performance and scaling of the production data stack on Cori. We will enable peer IPCC researchers to utilize (and extend) the production stack for their individual research, and team up with scientists to enable breakthrough science.

Related Websites:

Nersc

The Open vSwitch* Exact-Match Cache

$
0
0

Introduction

The exact-match cache (EMC) is the first and fastest mechanism Open vSwitch* (OVS) uses to determine what to do with an incoming packet. If the action for the packet cannot be found in the EMC, the search continues in the datapath classifier, and failing that the OpenFlow* flow tables are consulted. This can be thought of as similar to how a CPU checks increasingly slower levels of cache when accessing data.

colorful flowchart of vSwictch table hierarchy
Figure 1:The Open vSwitch* table hierarchy.

EMC Processing

Let's look at a pseudocode representation of the workflow for incoming packets as they are looked up in the EMC. The relevant code is in emc_processing() in dpif-netdev.c.

emc_processing( IN/OUT: dp_packet_batch, OUT: netdev_flow_key[]
                OUT: packet_batch_per_flow[])
    foreach packet in batch
        flowkey.miniflow = miniflow_extract (pkt)
        flowkey.hash = dpif_netdev_packet_get_rss_hash (pkt)
        dp_netdev_flow = emc_lookup(flowkey)
        if dp_netdev_flow
            /* EMC hit \0/ */
            Add packet to entry in packet_batch_per_flow[]
        else
            //EMC miss
            Write packet back to dp_packet_batch

Code block:emc_processing pseudocode.

First, incoming packets have their netdev_flow_key calculated. Conceptually, the netdev_flow_key is a concatenation all the packet's header fields that OVS knows how to decode.

Then, this key is used to look up the EMC to find the corresponding dp_netdev_flow, which may (EMC hit) or may not (EMC miss) exist. The dp_netdev_flow structure contains an actions structure that determines how the packet should be processed, without having to perform a more expensive up-call to the datapath classifier.

Once the action for a packet has been determined—which is to say once a dp_netdev_flow for the packet has been found—that action is not executed immediately. Instead, for performance reasons, all the packets for each action are batched together and returned via the packet_batch_per_flow argument. All the packets that missed the EMC are also batched together and returned via the dp_packet_batch argument to dp_netdev_input(). There, the packets that missed the EMC are passed to the datapath classifier with fast_path_processing(), and finally, the packet batches are dispatched using packet_batch_per_flow_execute().

By batching packets in this manner, egressing packets to devices becomes more efficient as the cost of slow memory-mapped input/output (MMIO) operations is spread across multiple packets.

The EMC Cache in Detail

The EMC maps from the flowkey structure described above to a dp_netdev_flow data structure. The notable items in this data structure are the flow and actions item, which indicates how a packet matching the flow should be processed. If a packet's flow is found in the EMC, the packet can be processed appropriately without further processing.

It's worth studying the mechanism of the EMC as it has some surprising features.

The capacity of the EMC is configurable to a power of 2 value (2, 4, 8, 16, …) at compile time by setting EM_FLOW_HASH_SHIFT. The exact capacity is 2EM_FLOW_HASH_SHIFT. So, if EM_FLOW_HASH_SHIFT is set to 13 we get an EMC with 213, or 8192 entries. As of OVS 2.8, each entry takes approximately 570 bytes, so at 8196 entries the EMC will take up about 4.4 MB of RAM.

Generally (see section EMC Insertion, below), when a packet for a new flow is received it will always result in an insertion into the EMC, even if it requires an existing entry to be evicted. But surprisingly, an eviction may be required even when the EMC is holding less than its full capacity of entries.

This is because the EMC can be considered to be an n-way associative cache (similar to a modern CPU cache). If the EMC was a fully associative cache, then any flow (that is, struct dp_netdev_flow) could be stored at any location in the cache. However, n-way associative means that there are only n entries from the 8196 entries that can be used to store any given flow. Currently, n is set to 2 (using #define EM_FLOW_HASH_SEGS). This means that even with a number of flows much less than the size of the EMC it is likely that there will be contention between flows for entry into the EMC. Think of n ways as meaning there being n possible ways to do something; in this case n ways in which to insert the item into the EMC.

How the n possible entries are determined for a flow is interesting. A hash is calculated from a subset of the packet’s header fields. This can be done by the network interface card (NIC) and passed to the host in the packet metadata; or, if that has not been done, OVS will calculate a hash itself (see dpif_netdev_packet_get_rss_hash()).

In any case, for this example assume that EM_FLOW_HASH_SHIFT has been set to 8 (28 = 256 EMC entries) and EM_FLOW_HASH_SEGS has been set to 3 (each dp_netdev_flow can be stored in any one of 3 locations out of that 256). So how are the three possible entries chosen? Say that the 32-bit hash calculated or retrieved by dpif_netdev_packet_get_rss_hash() was 0x00B177EE. Then the three possible locations in the EMC cache allowable to store the dp_netdev_flow of that packet would be 0xB1, 0x77, or 0xEE.

In the current code, the values are different and do not align so nicely on the nibble boundaries, so the calculations are uglier, but the mechanism is identical.

When is the EMC Full?

An eviction may be required even when the EMC is holding less than its full capacity of entries.

Consider an EMC small enough to depict in a single diagram. The shaded squares are used EMC slots.

display of a row of squares indicating full vs empty slots.
Figure 2:A 75-percent full EMC with 16 slots.

Let’s say that two packets for two new flows arrive. The hashes are calculated, and due to the configuration of the EMC, only the two least significant sets of four bits are used to determine possible locations for the new flows.

FlowA has a hash ending in 0xA5. But as both slots 0xA and 0x5 are already full, one or the other is chosen randomly for eviction.

FlowB has a hash ending in 0x58. Slot 0x5 is used but 0x8 is free, so FlowB is assigned to slot 0x8.

It can be shown that for EM_FLOW_HASH_SEGS=2 the probability of an eviction being required for an incoming flow rises above 50 percent when the EMC is over 70.7 percent full. In the case of the EMC depicted here with 16 entries, that occurs with the 12th entry, making it 75 percent full and giving a 56 percent probability that a new entry will require an eviction.

EMC Matching, Insertion, and Deletion

EMC Matching

As the name EMC suggests, when a flow is looked up or stored in the EMC, it is done in an exact manner. There is no wildcard matching, omission of fields, or setting of bits to a don’t-care value.

For instance, even if an OpenFlow rule says to send all packets with a destination media access control (MAC) address of 01:FC:09:xx:xx:xx to a given port, each different matching destination MAC address encountered by OVS will result in a separate entry in the EMC.

As another example, the IPv4 time-to-live (TTL) field is a known field to OVS, and is extracted into the miniflow structure described above. If a packet in a TCP connection takes a slightly different route before traversing OVS that packet will fail to match the existing EMC entry for the other packets in that TCP connection (as it will have a different TTL value); this will result in an up-call to the datapath classifier and a new entry into the EMC just for that packet.

EMC Insertion

Generally, insertion into the EMC never fails. If one of the n-way locations is free then that is used; if there is no free location then one of the n locations is chosen at random and that is used for the new entry. For performance reasons, there is no least-recently used or least-frequently used replacement mechanism employed.

That said, since OVS 2.7 there is a probabilistic insertion feature, which reduces EMC thrashing in situations where there are many more flows being handled than available EMC entries. By default, it means that on average, 1 packet in 100 will result in a flow being inserted into the EMC. This means that only when a flow comprises more than 50 packets does it become likely that an entry will be made into the EMC for that flow.

The exact value can be changed using ovs-vsctl.

$ ovs-vsctl --no-wait set Open_vSwitch . other_config:emc-insert-inv-prob=5

This means that just one in every five packets on average will be inserted into the EMC.

By this mechanism, flows with more frequent packets tend to end up in the EMC where they tend to produce more hits, and flows with less-frequent packets remain outside it.

Probabilistic insertion can avoid some otherwise odd effects; for example, when a port scan is being performed on an IP address. A port scan involves sending packets to each of 64 kilobyte (KB) port addresses on an IP address. As the packets of these very short flows traverse OVS each one results in an EMC entry being created. With the current EMC size of 8 K entries, a 64-KB port scan could potentially thrash the EMC eight times over, but with the default one percent insertion probability approximately 640 entries would be filled.

EMC Sweep

Flow entries in the EMC do not have any associated last-used time or used counter. This means that a least-recently used or least-frequently used replacement mechanism cannot be used. However, unused EMC entries are still periodically removed.

This can be achieved as each EMC entry is associated with dp_netdev_flow in the datapath classifier. This dp_netdev_flow does have a last-used timestamp and that is used to remove the dp_netdev_flow from the datapath classifier when it has been unused for a period of time. As part of the dp_netdev_flow removal process all associated EMC entries are marked as dead. They are then removed periodically as part of a slow sweep carried out by the poll mode driver (PMD).

Additional Information

There is a separate EMC for each PMD. While this can mean that the same flow may have an entry in several EMCs it avoids the overhead of having locks on the EMC.

The Flow Key

A flow key consists of:

  • All the packet header data present in the packet that OVS knows about (MAC and IP addresses, time-to-live (TTL, multiprotocol label switching (MPLS), and so on). As most possible fields are only present in specific protocols the majority of these fields are not set at all; the values of the headers that are present are stored in a special memory efficient form called a miniflow.
  • A hash calculated from a subset of those fields. Like all hashes it is not unique for every combination of packet header data values. But it is used to drastically reduce the search space in the EMC for the packet.

The Miniflow

A packet’s miniflow is calculated by miniflow_extract(). A miniflow is a sparse representation of the header fields of a packet. To understand what sparse means in this context, consider struct flow, which has an individual member for every packet header field of every packet type that OVS knows about. Even though most fields are unused for any given packet, struct flow has a field for each and every one. For example, there is space allocated in a struct flow for both IPv4 and IPv6 addresses, even though both cannot be populated at the same time. So struct flow is a sparse data structure in that for any given packet most of its fields are not set. Due to processor caching effects it is actually more efficient to process the smaller miniflow structure than the larger flow data structure even though the former requires special accessor methods.

It's not necessary to go further in the implementation details of how miniflow implements a memory efficient representation of the flow header fields; only know that it is memory efficient, and that this extra complexity has been introduced for performance reasons.

Hash Calculation

As mentioned above, the hash is calculated from a subset of the fields present in the packet.

For IPv4 and IPv6 packets these fields are src and dst IP address, IP protocol and, if present (that is, for TCP, UDP, ICMP and SCTP), the src and dst port numbers. This hash is commonly called the 5-tuple hash.

As a corollary of this, all non-IP packets have the same hash; and therefore all contend for the same small handful of cache locations—the exact number is determined by EM_FLOW_HASH_SEGS, which is typically 2.

The calculation of the hash can also be offloaded to the NIC. In this case the hash is provided along with the other packet metadata provided by the NIC and the hash is retrieved rather than re-calculated during emc_processing(). As a side note, the hash provided by the NIC in that case is the one it uses for receive-side scaling (RSS).

Summary

The OVS EMC is an important mechanism that OVS uses to be a performant virtual switch. It is important for both developers and users to be aware of its key features (it is an n-way associative cache, it does not support any wildcarding, the hash calculations used are specifically designed for use with certain IP protocols) and the consequences of these. OVS also uses some complicated data structures such as the miniflow for performance reasons. While developers should be aware of the reasons for using such structures they do not need to spend much time on those details.

About the Author

Billy O’Mahony is a network software engineer with Intel. He has worked on the Open Platform for Network Functions Virtualization (OPNFV) project and accelerated software switching solutions in the user space running on Intel® architecture. His contributions to Open vSwitch with DPDK include Ingress Scheduling and RXQ/PMD Assignment.

Getting Started in Linux with Intel® SDK for OpenCL™ Applications

$
0
0

This article is a step by step guide to quickly get started developing using Intel®  SDK for OpenCL™ Applications with the Linux SRB5 driver package.  The OpenCL driver is a prerequisite for using the GPU capabilities of Intel® Computer Vision SDK or Intel® Deep Learning Deployment Toolkit.

  1. Install the driver
  2. Install the SDK
  3. Set up Eclipse

For SRB4.1 instructions, please see https://software.intel.com/en-us/articles/sdk-for-opencl-gsg-srb41.

Step 1: Install the driver

 

This script covers the steps needed to install the SRB5 driver package in Ubuntu 14.04, Ubuntu 16.04, CentOS 7.2, and CentOS 7.3.

 

To use

$ mv install_OCL_driver.sh_.txt install_OCL_driver.sh
$ chmod 755 install_OCL_driver.sh
$ sudo su
$ ./install_OCL_driver.sh install

The script automates downloading the driver package, installing prerequisites and user-mode components, patching the 4.7 kernel, and building it.

Experimental: this version of the script has an option to skip the kernel patch/rebuild step. For newer kernels, such as the 4.8 default kernel for Ubuntu 16.04, nearly all of OpenCL passes basic smoke tests. 

You can check your progress with the System Analyzer Utility.  If successful, you should see smoke test results looking like this at the bottom of the the system analyzer output:

--------------------------
Component Smoke Tests:
--------------------------
 [ OK ] OpenCL check:platform:Intel(R) OpenCL GPU OK CPU OK

 

Experimental installation without kernel patch or rebuild:

If using Ubuntu 16.04 with the default 4.8 kernel you may be able to skip the kernel patch and rebuild steps.  This configuration works fairly well but several features (i.e. OpenCL 2.x device-side enqueue and shared virtual memory, VTune GPU support) require patches.  Install without patches has been "smoke test" validated to check that it is viable to suggest for experimental use only, but it is not fully supported or certified.   

 

Step 2: Install the SDK

This script will set up all prerequisites for successful SDK install for Ubuntu. 

$ mv install_SDK_prereq_ubuntu.sh_.txt install_SDK_prereq_ubuntu.sh
$ sudo su
$ ./install_SDK_prereq_ubuntu.sh

After this, run the SDK installer.

Here is a kernel to test the SDK install:

__kernel void simpleAdd(
                       __global int *pA,
                       __global int *pB,
                       __global int *pC)
{
    const int id = get_global_id(0);
    pC[id] = pA[id] + pB[id];
}                               

Check that the command line compiler ioc64 is installed with

$ ioc64 -input=simpleAdd.cl -asm

(expected output)
No command specified, using 'build' as default
OpenCL Intel(R) Graphics device was found!
Device name: Intel(R) HD Graphics
Device version: OpenCL 2.0
Device vendor: Intel(R) Corporation
Device profile: FULL_PROFILE
fcl build 1 succeeded.
bcl build succeeded.

simpleAdd info:
	Maximum work-group size: 256
	Compiler work-group size: (0, 0, 0)
	Local memory size: 0
	Preferred multiple of work-group size: 32
	Minimum amount of private memory: 0

Build succeeded!

 

Step 3: Set up Eclipse

Intel SDK for OpenCL applications works with Eclipse Mars and Neon.

After installing, copy the CodeBuilder*.jar file from the SDK eclipse-plug-in folder to the Eclipse dropins folder.

$ cd eclipse/dropins
$ find /opt/intel -name 'CodeBuilder*.jar' -exec cp {} . \;

Start Eclipse.  Code-Builder options should be available in the main menu.

Developing for Intel® Active Management Technology (AMT)

$
0
0

Intro

Managing a fleet of computers can be a complex task with computers in hard to reach places, powered off, or with their physical whereabouts unknown. While those are just a few of the on-site challenges, management service providers (MSP) have the added challenge of servicing the computers remotely and often find themselves sending a technician out to handle the issues. Intel® Active Management Technology (AMT) is designed to make remotely managing computers easier with full access from anywhere resulting in reduced truck rolls, saved time and energy, and proactive management. The computer can even be powered off or blue screened and Intel® AMT can tell it to power on or supply a new ISO image to it. This paper will go over some of the features and capabilities of Intel® AMT as well as an overview of the configuration and manageability tools available. Additionally, Intel® AMT ecosystem components will be discussed with how to plan for deployment and get started configuring a system.

 

Chips

Intel® AMT is available on Intel® vPro™ brand chips which are based on either the Intel® Core™ processor or select versions of the Intel® Xeon® processor. Find a list here. However even though the chip is compatible with the Intel® vPro™ platform, it doesn’t mean Intel® AMT is enabled: check with the system or hardware supplier, look for the Intel® vPro™ name on the chip, or reboot the computer and hit CTRL+P to enter the Intel® MEBx (Intel® Management Engine BIOS Extension). The Intel® ME BIOS is a separate BIOS screen used to enable Intel® AMT capability. More detail on how to configure it will be discussed later in Configuration Tools section.  

vPro™ Chips

Figure 1: vPro Chips

Intel®AMT

Intel® AMT lies below the OS at the hardware level and uses out-of-band (OOB) communications. Essentially it is built into the device itself but separate from the OS and other software applications. Intel® AMT is not a stand-alone management system, but designed to be incorporated into and leveraged by a management system to enhance and amplify the system’s capabilities without replacing them. Devices can be fully accessed remotely without the disruption of a physical repair as long as it is connected to a power source and connected to the network via LAN cable or wireless. This will aid in monitoring devices, shortening downtime, and reducing truck rolls.

Connecting wirelessly has a few additional requirements and differences, more detail can be found in this article here.

Notable features and use cases:

  • KVM

Intel® AMT allows for remote KVM (keyboard, video, and mouse) control of a PC. Therefore the need for physical visits and intervention becomes almost unnecessary. Note that the PC must be hooked up to a monitor or physical KVM switch to display the screen through Intel® AMT by design.

  • Remote Power Control

If trying to KVM to the device or push a critical patch only to find the PC is off, Intel® AMT can be used to turn the device on for servicing. Intel® AMT grants full power control to the device like power on, power off, reboot, sleep, boot to BIOS, and more. In addition the Alarm Clock feature will allow power on to be scheduled at a specific time. Hence an alarm can be set during off-hours to turn on all the PCs for an update or patch to be pushed remotely to them.

  • Bare-metal Restore and Disk Reimaging

There is also the case of accessing a PC that has undergone a critical error or has no OS running. As Intel® AMT is below the OS, it can still access the PC and can send a new ISO or IMG to the device through IDE redirect (USB redirection in AMT 11.0). This makes remote remediation in the case of an OS failure or a virus easy.

  • Hardware and software Inventory

Intel® AMT can also be used to track hardware and software inventory, both of which are stored in non-volatile memory for access when powered off. By default, Intel® AMT can remotely access the hardware specifications of the computer. For software, the application has to make use of the Third Party Data Storage (3PDS) to store application name, vendor, and version info (Web Storage in Intel® AMT 11.5).

  • Remote Alerting

Remote alerting through Intel® AMT enables automated error messages in addition to audit and event logging. In the case where the customer is using the machine and needs help, there is Intel® AMT Fast Call for Help feature which allows them to request IT support. This can be set up for either remote or local (eg. within the enterprise network) access using Client-Initiated Remote Access (CIRA) or Client-Initiated Local Access (CILA). More about CIRA will be discussed in later in the Remote Connectivity section.

With these features Intel® AMT can improve customer satisfaction and allow for fewer interruptions which cost time and money on systems that require complex continual maintenance and management from day to day.

 

Tools

The three basic components needed for an Intel® AMT ecosystem are a Management Console machine, a configuration method, and the Intel® AMT Client machines. It is not required for the Management Console machine to be Intel® AMT capable. For remote configuration additional components needed are a Remote Configuration Service (RCS) server and a signed certificate. There are other optional and required components as well based on how AMT needs to be configured and set-up, the above just outlines the minimum needed to get started.  

Basic Components for Intel® AMT setup

Figure 2: Basic Components for Intel® AMT setup

Configuration Tools

There are multiple ways to configure and provision devices to use Intel® AMT, this paper will go over the main methods.

Intel®AMT can be manually configured on a machine through the MEBx, a bios extension. It can be accessed by hitting CTRL+P on the keyboard while the machine boots. For a basic configuration, the MEBx password for Intel® AMT needs to be set, change user consent for KVM access if desired, and activate ‘Network Access’.

Intel also provides the Intel® Setup and Configuration Software (Intel® SCS) for Intel® AMT configuration that can be used in multiple ways. The ACU Wizard (Intel® AMT Configuration Utility) application that comes with it can be used to configure Intel® AMT directly on the local system or save a XML configuration profile to USB to deploy to multiple systems.

It is important to pause now and talk about Client Control Mode and Admin Control Mode as they are tied closely to the method of configuration. Host based, meaning local OS level configuration, is an example of Client Control mode while remote configuration (using Intel® AMT) is an example of Admin Control Mode. The differences between the two are outlined below in Figure 3 with the main being Client Control Mode requires user consent and does not support System Defense capability. Intel® AMT can also support Enterprise networks and Public domain networks. Enterprise mode can be integrated with Active Directory and provides secure authentication with certificates to internal systems inside the corporate domain. 

Client Control Mode vs. Admin Control Mode

Figure 3: Client Control Mode vs. Admin Control Mode

Hence using the ACU Wizard to configure the local system is host based as it is using the OS layer to configure the system. Host-based configuration can also be done remotely using a software deployment tool with the XML configuration profile using the ACUConfig.exe that comes with Intel®SCS.

Intel® SCS also allows for remote configuration through Intel® AMT with a Remote Configuration Service (RCS) server and a signed certificate from a public Certificate Authority (CA). If a more secure setup of Intel® AMT is needed then remote configuration provides the option of using TLS-PKI (Transport Layer Security- Public Key Infrastructure) configuration. It uses the same XML configuration profile as mentioned previously, but will then perform a hand-shake with the Intel® AMT client it is provisioning. The hand-shake starts the same as Host-based configuration by running the ACU configurator (ACUConfig.exe), but then the ACU configurator will request a provisioning certificate from the RCS. The RCS will then send its configuration certificate back for the local client’s Intel® AMT to verify. Then the RCS will apply the XML configuration profile to the client. For more detail on how to set up the RCS and use the certificates, please refer to the ‘Intel(R)_SCS_User_Guide.pdf’ in the ‘SCS download package’ here

Configuration Method’s compatible versions of Intel® AMT

Figure 4: Configuration Method’s compatible versions of Intel® AMT

 

Manageability Tools

Now that the Intel® AMT client has been configured, a management console is needed to maintain and manage the computer or computers.

Intel provides the Intel® Manageability Commander as a lightweight console to utilize some of the capabilities of Intel® AMT. It is downloadable here. It is available on Windows*. It enables the user to KVM, control power, see hardware information, and more. 

Intel® Manageability Commander view of devices

Figure 5: Intel® Manageability Commander view of devices

Similar to Intel® Manageability Commander is MeshCommander* that has a few more features like subscriptions, wake alarms etc. It is completely open source and released under the Apache 2.0 License. Developers are free to download the source code and samples for MeshCommander to develop their own manageability tool. The creator of MeshCommander has a good video tutorial and overview of how to use the source code and create a new version. 

MeshCommander System Status View

Figure 6: MeshCommander System Status View

Also from the creator of MeshCommander is MeshCentral (Figure 7). MeshCentral is available at MeshCentral.com or as MeshCentral 2 (beta) for download to run an independent instance within a domain. MeshCentral is available on a wide range of devices that do not have to be Intel® AMT devices. It can leverage the OOB AMT communication on those Intel® AMT capable devices and communicate In-Band to the other devices. Devices can be grouped into meshes which are configured to control what access is allowed to the devices (Figure 8). To add a device to the mesh there is a Mesh Agent installer which is available for a long list of OS and devices. The Mesh Agent installer can also be configured to do automatic provisioning of Intel® AMT in client control mode. 

MeshCentral

Figure 7: MeshCentral

Creating a new Mesh in MeshCentral

Figure 8: Creating a new Mesh in MeshCentral

The Intel® Active Management Technology SDK is also available that provides an API (application programming interface) and sample code for developers. It is designed to help companies build their own Intel® AMT management software. It supports C++ and C# for Microsoft Windows* and Linux* operating systems. Out of the box, it requires the samples to be compiled with Microsoft Visual Studio* 2013, so if you just want to play around Intel® AMT in the beginning, you might want to try another manageability console first.  

Last but not least, there are other third party management consoles available from various Managed Service Providers (MSP): https://msp.intel.com/management-consoles

 

Remote Connectivity to Remote Sites

By default Intel®AMT works on clients in the same local network as the management console. In order to access the clients remotely on a different network then a proxy or virtual private network (VPN) is required. One of the ways to access Intel® AMT Clients outside of a corporate network is to use the demilitarized zone (DMZ) to handle routing traffic from the internal corporate network’s management console to the remote client machines. This is done with another Intel® AMT enabled gateway in the demilitarized zone (DMZ) called the Management Presence Server (MPS) that will serve as the broker between the management console and the Intel® AMT clients. MeshCentral can be used as an MPS and other third party solutions are available for purchase. The main key of how the MPS creates a connections is through Client Initiated Remote Access (CIRA), previously referenced for its Fast Call For Help capabilities, can also initiate a connection from the client side. The MPS then authenticates the client and notifies the management console of the available connection. From there the management console can then connect through the MPS to the client using a secure tunnel. 

Intel® AMT Remote Environment

Figure 9: Intel® AMT Remote Environment

Security

Communication between the Intel® AMT systems and the management systems can be configured to use Transport Layer Security (TLS) with a digital certificate from a Certification Authority (CA). TLS can be used during configuration for remote set-up and after configuration for secure communication.

Inbound and outbound network traffic can be monitored for threats at a hardware level using time based filters. This can monitor for threats and detect suspicious network traffic. If a thread is detected, the network can be blocked or limit packets before they reach the OS.

Intel® AMT adds a hardware base security level below the OS enabling the device to be reclaimed with remote remediation by deploying a new image of OS if the machine even if the OS has been compromised.

 

Planning Deployment

It is important to first evaluate the features and capabilities of Intel® AMT. This paper has addressed some key features and uses cases of Intel® AMT, but does not encompass all of them. The best place to start integrating Intel® AMT into a solution is to look at the current pain points in day to day maintenance and repair. From there identify use cases based on the capabilities of Intel® AMT and how it can solve the issues. Keep in mind that Intel® AMT can be leveraged to be combined with other non- Intel® AMT features, from third parties or developed yourself, to create a more robust and complete solution for the issue. In addition, evaluate the tools and configuration methods of Intel® AMT for some hands on experience. Then Intel® AMT capable devices can be inventoried or purchased if needed for a small pilot deployment phase. The pilot should be separate from production or done with non-critical systems. Make sure the network infrastructure is setup as needed and identify user groups and roles. If enterprise mode and Fast Call for Help is needed for an IT help desk, set those up as well in the pilot as additional configuration and certificates will be needed. Any third party software and management tools can be included as well. Once the pilot has started, planning for updates, upgrades, and maintenance tasks should also be thought out.

 

Getting started

Let’s walk through setting up Intel® AMT on the Intel® NUC Kit NUC5i5MYHE with a LAN connection, assuming that it already has memory and hard-drive installed with Windows 10 installed.

As the Intel® SCS tool’s local configuration requires user consent as it is a Client Control method of configuration, we will use the MEBx to configure AMT.  If you installed Windows® 10 on the Intel® NUC yourself you will need to install the Intel® Management Engine driver. The drivers for this NUC can be found here, otherwise search for the driver relevant to your Intel® AMT capable device.

Boot into the MEBx screen with CTRL+P. First change the Manageability Engine (ME) password. The default Admin password is ‘admin’, set up a new strong password and remember it. This will be needed to access the Intel® AMT features later from the management console. Next edit the configuration by navigating to the ‘Intel® AMT Configuration’ option. Change User Consent to disabled and activate network access. Test that Intel® AMT has been activated by going to localhost:16992 in the browser on the machine. If you forget the MEBx password, you need to disconnect the RTC CMOS battery inside the device. This will reset the MEBx back to factory default with password admin and Intel® AMT will need to be reconfigured. 

Intel® AMT WebUI

Figure 10: Intel® AMT WebUI

 

To manage your newly configured AMT device download the Intel® Manageability Commander as your management console on another computer on the same local network.

Open it and go to FileàAdd Intel AMT Computer and choose a name for your AMT computer, enter in the IP address for Hostname, and the ME password you just set up. 

Adding a computer to the Manageability Console

Figure 11: Adding a computer to the Manageability Console

Your Intel® AMT computer will now show up in the list of devices and you can click connect to access it.

Intel® Manageability Commander View of devices

Figure 12: Intel® Manageability Commander View of devices

Experiment using remote desktop to access your Intel® AMT device, powering it on and off, and look at all the other features.

 

Summary

This article has covered the basics of Intel® AMT capabilities, how to configure a system, and how to manage that system. Implementing an Intel® AMT manageability solution can help with efficiency and reduce cost of support.

 

References

https://www.intel.com/content/www/us/en/software/scs-8-training-3-amt-configuration-video.html

https://downloadmirror.intel.com/21058/eng/IT%20Project%20Planning%20Guide%20for%20Intel(R)%20AMT.pdf

https://software.intel.com/en-us/documentation/intel-amt-implementation-and-reference-guide-home

https://www.intel.de/content/dam/www/public/us/en/documents/guides/amt-configuration-utility-user-guide.pdf

https://software.intel.com/en-us/articles/an-introduction-to-intel-active-management-technology-wireless-connections

https://www.intel.com/content/www/us/en/software/setup-configuration-software.html

https://www.intel.com/content/www/us/en/support/software/000020976.html

https://www.meshcentral.com/downloads/Mesh-Installation.pdf

 

About the author

Whitney Foster is a software engineer at Intel in the Software Solutions Group working on scale enabling projects for Internet of Things.

 

Notices

You may not use or facilitate the use of this document in connection with any infringement or other legal analysis concerning Intel products described herein. You agree to grant Intel a non-exclusive, royalty-free license to any patent claim thereafter drafted which includes subject matter disclosed herein.

No license (express or implied, by estoppel or otherwise) to any intellectual property rights is granted by this document.

Intel disclaims all express and implied warranties, including without limitation, the implied warranties of merchantability, fitness for a particular purpose, and non-infringement, as well as any warranty arising from course of performance, course of dealing, or usage in trade.

This document contains information on products, services and/or processes in development. All information provided here is subject to change without notice. Contact your Intel representative to obtain the latest forecast, schedule, specifications and roadmaps.

The products and services described may contain defects or errors known as errata which may cause deviations from published specifications. Current characterized errata are available on request.

Copies of documents which have an order number and are referenced in this document may be obtained by calling 1-800-548-4725 or by visiting www.intel.com/design/literature.htm.

Intel, Intel RealSense, Intel Edison. and the Intel logo 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

© 2017 Intel Corporation.

 

Integration Wrappers for Intel® Integrated Performance Primitives (Intel® IPP)

$
0
0

To provide easy-to-use APIs and reduce the effort required to add Intel® Integrated Performance Primitives (Intel® IPP) functions to your application, Intel® IPP library introduces new Integration Wrappers APIs. These APIs aggregate multiple Intel® IPP functions and provide easy interfaces to support external threading of Intel® IPP functions. A technical preview of Integration Wrappers functionality is now available for evaluation.

Integration Wrappers consist of C and C++ interfaces:

  • C interface aggregates Intel IPP functions of similar functionality with various data types and channels into one function. Initialization steps required by several Intel IPP functions are implemented in one initialization function for each functionality. To reduce the size of your code and save time required for integration, the wrappers handle all memory management and Intel IPP function selection routines.
  • C++ interface wraps around the C interface to provide default parameters, easily initialized objects as parameters, exception handling, and objects for complex Intel IPP functions with automatic memory management for specification structures.

Integration Wrappers are available as a separate download in the form of source and pre-built binaries.

1. Intel® IPP Integration Wrappers Preview Overview

1.1 Key Features

Integration Wrappers simplify usage of Intel IPP functions and address some of the advanced use cases of Intel IPP. They consist of the C and C++ APIs which provide the following key features:

C interface provides compatibility with C libraries and applications and enables you to use the following features of Integration Wrappers:

  • Automatic selection of the proper Intel IPP function based on input parameters
  • Automatic handling of temporary memory allocations for Intel IPP functions
  • Improved tiling handling and automatic borders processing for tiles
  • Memory optimizations for threading

C++ interface additionally provides:

  • Easier to use classes like IwSize (image size structure in Integration Wrappers)  instead of IppiSize (image size structure in Intel IPP functions), IwRect instead of IppiRect, and IwValue as a unified scalar parameter for borders and other per-channel input values
  • Complex Intel IPP functions designed as classes to use automatic construction and destruction features

The following two code examples implement the image resizing operation with two APIs 1) Resizing image with the Intel® IPP functions 2) Resizing image using the Intel® IPP Integration Wrappers APIs.  The second implementation is much simpler requires less effort to use the Intel IPP functions.

1.Image Resizing with Intel® IPP functions

{……
     ippSts = ippiResizeGetSize_8u(srcSize, dstSize, ippLinear, 0, &specSize, &initSize);
     if(ippSts < 0) return ippSts;
     //allocate internal buffer
     pSpec = (IppiResizeSpec_32f*)ippsMalloc_8u(specSize);
     if(specSize && !pSpec) return STS_ERR_ALLOC;
     //allocate initialization buffer
     pInitBuf = ippsMalloc_8u(initSize);
     //init ipp resizer
     ippSts = ippiResizeLinearInit_8u(srcSize, dstSize, pSpec);
     ippSts = ippiResizeGetSrcRoi_8u(pSpec, dstRoiOffset, dstRoiSize, &srcRoiOffset, &srcRoiSize);
     // adjust input and output buffers to current ROI
     unsigned char *pSrcPtr = pSrc + srcRoiOffset.y*srcStep + rcRoiOffset.x*CHANNELS;
     unsigned char *pDstPtr = pDst + dstRoiOffset.y*dstStep + dstRoiOffset.x*CHANNELS;
     ippSts = ippiResizeGetBufferSize_8u(pSpec, dstRoiSize, CHANNELS, &bufferSize);
     pBuffer = ippsMalloc_8u(bufferSize);
     // perform resize
     ippSts = ippiResizeLinear_8u_C1R(pSrcPtr, srcStep, pDstPtr, dstStep, dstRoiOffset, dstRoiSize, ippBorderRepl, 0, pSpec, pBuffer);
     .......
}

2. Image Resize with Intel® IPP Integration Wrappers (C++ interface)

{ ......
      //Initialization
      IppDataType dataType = ImageFormatToIpp(src.m_sampleFormat);
      ipp::IwiSize srcSize(ImageSizeToIpp(src.m_size));
      ipp::IwiSize dstSize(ImageSizeToIpp(dst.m_size));
      m_resize.InitAlloc(srcSize, dstSize, dataType, src.m_samples, interpolation, ipp::IwiResizeParams(), ippBorderRepl);
      //Run
      ipp::IwiImage iwSrc = ImageToIwImage(src);
      ipp::IwiImage iwDst = ImageToIwImage(dst);
      ipp::IwiRect rect((int)roi.x, (int)roi.y, (int)roi.width, (int)roi.height);
      ipp::IwiRoi  iwRoi(rect);
      m_resize(&iwSrc, &iwDst, &iwRoi);
  ......
}

1.2 Threading

The API of Integration Wrappers (IW) is designed to simplify tile-based processing of images. Tiling is based on the concept of region of interest (ROI).
Most IW image processing functions operate not only on whole images but also on image areas - ROIs. Image ROI is a rectangular area that is either some part of the image or the whole image.

The sections below explain the following IW tiling techniques:

Manual tiling

IW functions are designed to be tiled using the IwiRoi interface. But if for some reasons automatic tiling with IwiRoi is not suitable, there are special APIs to perform tiling manually.

When using manual tiling you need to:

  • Shift images to a correct position for a tile using iwiImage_GetRoiImage
  • If necessary, pass correct border InMem flags to a function using iwiRoi_GetTileBorder
  • If necessary, check the filter border around the image border using iwiRoi_CorrectBorderOverlap

Here is an example of IW threading with OpenMP* using manual tiling:

#include "iw++/iw.hpp"
#include <omp.h>

int main(int, char**)
{
    // Create images
    ipp::IwiImage srcImage, cvtImage, dstImage;
    srcImage.Alloc(ipp::IwiSize(320, 240), ipp8u, 3);
    cvtImage.Alloc(srcImage.m_size, ipp8u, 1);
    dstImage.Alloc(srcImage.m_size, ipp16s, 1);
    int threads = omp_get_max_threads(); // Get threads number
    ipp::IwiSize   tileSize(dstImage.m_size.width, (dstImage.m_size.height + threads - 1)/threads); // One tile per thread
    IppiBorderSize sobBorderSize = iwiSizeToBorderSize(iwiMaskToSize(ippMskSize3x3)); // Convert mask size to border size
    #pragma omp parallel num_threads(threads)
    {
        // Declare thread-scope variables
        IppiBorderType border;
        ipp::IwiImage srcTile, cvtTile, dstTile;
        // Color convert threading
        #pragma omp for
        for(IppSizeL row = 0; row < dstImage.m_size.height; row += tileSize.height)
        {
            ipp::IwiRect tile(0, row, tileSize.width, tileSize.height); // Create actual tile rectangle
            // Get images for current ROI
            srcTile = srcImage.GetRoiImage(tile);
            cvtTile = cvtImage.GetRoiImage(tile);
            // Run functions
            ipp::iwiColorConvert_RGB(&srcTile, iwiColorRGB, &cvtTile, iwiColorGray);
        }
        // Sobel threading
        #pragma omp for
        for(IppSizeL row = 0; row < dstImage.m_size.height; row += tileSize.height)
        {
            ipp::IwiRect tile(0, row, tileSize.width, tileSize.height); // Create actual tile rectangle
            iwiRoi_CorrectBorderOverlap(sobBorderSize, cvtImage.m_size, &tile); // Check borders overlap and correct tile of necessary
            border = iwiRoi_GetTileBorder(ippBorderRepl, sobBorderSize, cvtImage.m_size, tile); // Get actual tile border
            // Get images for current ROI
            cvtTile = cvtImage.GetRoiImage(tile);
            dstTile = dstImage.GetRoiImage(tile);
            // Run functions
            ipp::iwiFilterSobel(&cvtTile, &dstTile, iwiDerivHorFirst, ippMskSize3x3, border);
        }
    }
}

Basic tiling

You can use basic tiling to tile or thread one standalone function or a group of functions without borders. To apply basic tiling, initialize the IwiRoi structure with the current tile rectangle and pass it to the processing function.

For functions operating with different sizes for source and destination images, use the destination size as a base for tile parameters.

Here is an example of IW threading with OpenMP* using basic tiling with IwiRoi:

#include "iw++/iw.hpp"
#include <omp.h>

int main(int, char**)
{
    // Create images
    ipp::IwiImage srcImage, cvtImage, dstImage;
    srcImage.Alloc(ipp::IwiSize(320, 240), ipp8u, 3);
    cvtImage.Alloc(srcImage.m_size, ipp8u, 1);
    dstImage.Alloc(srcImage.m_size, ipp16s, 1);

    int            threads = omp_get_max_threads(); // Get threads number
    ipp::IwiSize   tileSize(dstImage.m_size.width, (dstImage.m_size.height + threads - 1)/threads); // One tile per thread

    #pragma omp parallel num_threads(threads)
    {
        // Declare thread-scope variables
        ipp::IwiRoi  roi;

        // Color convert threading
        #pragma omp for
        for(IppSizeL row = 0; row < dstImage.m_size.height; row += tileSize.height)
        {
            roi = ipp::IwiRect(0, row, tileSize.width, tileSize.height); // Initialize IwiRoi with current tile rectangle

            // Run functions
            ipp::iwiColorConvert_RGB(&srcImage, iwiColorRGB, &cvtImage, iwiColorGray, IPP_MAXABS_64F, &roi);
        }

        // Sobel threading
        #pragma omp for
        for(IppSizeL row = 0; row < dstImage.m_size.height; row += tileSize.height)
        {
            roi = ipp::IwiRect(0, row, tileSize.width, tileSize.height); // Initialize IwiRoi with current tile rectangle

            // Run functions
            ipp::iwiFilterSobel(&cvtImage, &dstImage, iwiDerivHorFirst, ippMskSize3x3, ippBorderRepl, 0, &roi);
        }
    }
}

Pipeline tiling

With the IwiRoi interface you can easily tile pipelines by applying a current tile to an entire pipeline at once instead of tiling each function one by one. This operation requires borders handling and tracking pipeline dependencies, which increases complexity of the API. But when used properly, pipeline tiling can increase scalability of threading or performance of non-threaded functions by performing all operations inside the CPU cache.

Here are some important details that you should take into account when performing pipeline tiling:

  1. Pipeline tiling is performed in reverse order: from destination to source, therefore:
    • Use the tile size based on the destination image size
    • Initialize the IwiRoi structure with the IwiRoiPipeline_Init for the last operation
    • Initialize the IwiRoi structure for other operations from the last to the first with IwiRoiPipeline_InitChild
  2. Obtain the border size for each operation from its mask size, kernel size, or using the specific function returning the border size, if any.
  3. If you have a geometric transform inside the pipeline, fill in the IwiRoiScale structure for IwiRoi for this transform operation.
  4. In case of threading, copy initialized IwiRoi structures to a local thread or initialize them on a per-thread basis. Access to structures is not thread-safe.
  5. Do not exceed the maximum tile size specified during initialization. Otherwise, this can lead to buffers overflow.

The IW package contains several advanced tiling examples, which can help you understand the details of the process. For more information on how to find and use these examples, please download package and view contained developer reference for Integration Wrappers for Intel IPP.

The following example demonstrates IW threading with OpenMP* using IwiRoi pipeline tiling:

#include "iw++/iw.hpp"
#include <omp.h>

int main(int, char**)
{
    // Create images
    ipp::IwiImage srcImage, dstImage;
    srcImage.Alloc(ipp::IwiSize(320, 240), ipp8u, 3);
    dstImage.Alloc(srcImage.m_size, ipp16s, 1);
    int threads = omp_get_max_threads(); // Get threads number
    ipp::IwiSize   tileSize(dstImage.m_size.width, (dstImage.m_size.height + threads - 1)/threads); // One tile per thread
    IppiBorderSize sobBorderSize = iwiSizeToBorderSize(iwiMaskToSize(ippMskSize3x3)); // Convert mask size to border size

    #pragma omp parallel num_threads(threads)
    {
        // Declare thread-scope variables
        ipp::IwiImage       cvtImage;
        ipp::IwiRoiPipeline roiConvert, roiSobel;
        roiSobel.Init(tileSize, dstImage.m_size, &sobBorderSize); // Initialize last operation ROI first
        roiConvert.InitChild(&roiSobel); // Initialize next operation as a dependent
        // Allocate intermediate buffer
        cvtImage.Alloc(roiConvert.GetDstBufferSize(), ipp8u, 1);
        // Joined pipeline threading
        #pragma omp for
        for(IppSizeL row = 0; row < dstImage.m_size.height; row += tileSize.height)
        {
            roiSobel.SetTile(ipp::IwiRect(0, row, tileSize.width, tileSize.height)); // Set IwiRoi chain to current tile coordinates
            // Run functions
            ipp::iwiColorConvert_RGB(&srcImage, iwiColorRGB, &cvtImage, iwiColorGray, IPP_MAXABS_64F, &roiConvert);
            ipp::iwiFilterSobel(&cvtImage, &dstImage, iwiDerivHorFirst, ippMskSize3x3, ippBorderRepl, 0, &roiSobel);
        }
    }
}

2. Getting Started

2.1 Getting Started Document

Getting Started instructions are provided in the Integration Wrappers Developer Guide and Reference.  You can download the document for Intel® IPP Integration Wrappers Preview package at the bottom of page: ipp_iw_dev_guide.zip.

You can find the following getting started information in the referenced above document:

  • Building Integration Wrappers and Examples
  • Using Integration Wrappers Examples
  • C/C++ API Reference for the Integration Wrappers

2.2 Examples Code

Intel® IPP Integration Wrappers Preview package contains code samples demonstrating how to use these APIs. The example files are located at: interfaces\iw\examples\iw_resize.
These examples demonstrate some of the IW features and help you get started with the IW library.

3. Support

If you have any problems with Intel® IPP Integration Wrappers Preview, post your questions at Intel® IPP forum.  If you already register your Intel® software product at the Intel® Software Development Products Registration Center, you can also submit your question by Intel® Premier Support.

4. Download and Installation

  1. Intel® IPP Integration Wrappers is an add-on library for Intel IPP package. Please install Intel® IPP main package first before using Intel IPP Integration Wrappers.Intel IPP is available as part of Intel® Parallel Studio XE, or Intel® System Studio products. It is also available as a standalone package with the Community License. Any of these products can work with Intel IPP Integration Wrappers.
  2. Use the links in the table below to download the Intel IPP IW package for Linux*, Windows*, or macOS*. To install the Libraries, put the archive file into the IPPROOT/ interfaces folder, and extract all files from the archive.   
      By downloading any sample package you accept the End User License Agreement
  3. Check the “Developer Guide” to learn the library.
    Windows*

    w_ippiw_p_2017.3.015.zip

    Linux*

    l_ippiw_p_2017.3.013.tgz

    macOS*

    m_ippiw_p_2017.3.013.tgz

    Developer Guideipp_iw_dev_guide.zip

Intel Distribution for Python: pyDAAL module

$
0
0

What is it?

pyDAAL is a free package which implements Python bindings to the Intel® Data Analytics Acceleration Library, or Intel® DAAL.

Why do I need it?

 

If you’re a data scientist or a machine learning specialist who cares about performance and scalability of your data analytics problem this is a must-have package.

This is your bridge from fast machine learning prototyping with Python on a laptop or workstation to large full scale deployment on multiple nodes. For convenience Intel DAAL provides bindings for Python and Java/Scala. It is also natively optimized for C/C++.

Based on highly tuned Intel MKL kernels the Intel DAAL brings machine learning performance to HPC levels so that you can do your high-performance data analytics seamlessly from any environment, MPI*-based, Spark*/Hadoop*-based, or Dask*-based.

It is equipped with the most advanced machine learning and other data analysis pipeline algorithms to implement basic and complex data analytics usages, from batch analytics to online and distributed analytics.

How is it different from Scikit-Learn*?

Scikit-learn implements a lot of machine learning algorithms, and as of now it is a richer library in terms of machine learning algorithm richness.

On the other hand the Intel DAAL is more than just a set of machine learning algorithms, as it implements and optimizes the full data analysis pipeline, from loading data and transforming/filtering it to analysis and modeling of data with classic statistical and machine learning techniques as well as advanced deep learning methods.

Intel DAAL is richer in terms of coverage of complex usage scenarios requiring online data analysis, end-to-end analytics on edge devices as well as distributed analytics on multiple nodes.

On the other end, certain Scikit-learn algorithms shipped within Intel Distribution for Python take advantage of pyDAAL bringing Scikit-learn performance to new levels.

Like Scikit-learn the Intel DAAL is an open source project with community contributions aiming to enhance and enlarge data analytics in an open fashion.

How do I get it?

If you’re a user of the Intel® Distribution for Python* it’s already there, it comes preinstalled to work out-of-the box for your machine learning and data analysis problems.

If you’re not a user of the Intel® Distribution for Python* you can also Conda-install it from Anaconda* Cloud.

If you want to build your own version of pyDAAL then you can do it from sources shipped within the Intel DAAL product. See Getting Started with Intel Data Analytics Acceleration Library (Python section) for instructions how to build your own pyDAAL on Windows*, Linux* and OS X*.

How can I use it?

There are plenty of Intel DAAL materials available online.

You can also find plenty of pyDAAL examples and samples here.

Intel® Parallel Computing Center at Shanghai Jiao Tong University

$
0
0

Principle Investigator:

Zheng-Ming Sheng is a distinguished professor of Shanghai Jiao Tong University and a fellow of the American Physical Society (APS). He has served as a member in the scientific advisory committee of the European project ELI and a committee member of the International Committee on Ultrahigh Intensity Lasers (ICUIL), an editorial board member of the journals Plasma and Fusion Research, Communication in Computational Physics, and Plasma Science and Technology. He has coauthored over 200 papers in refereed journals, which have been cited over 2000 times by other researchers. His current H-index is 30 and one of his papers was selected among the Selected Highly Cited Papers from 50 Years of Plasma Physics by Physics of Plasmas in 2008.

James Lin is the vice director at the Center for High-Performance Computing, Shanghai Jiao Tong University (HPC, SJTU). He has been working in HPC for more than 15 years and his current research interests include performance optimizations on emerging architectures. He has served as a TPC member for many HPC conferences, including the SC international conference for high-performance computing, International Parallel and Distributed Processing Symposium (IPDPS), and Symposium on Cluster Computing and the Grid (CCGrid). For the Intel® Parallel Computing Center (IPCC), he is in charge of teaching and organizing ITOC-International, the workshop aiming to bridge the communication gap between world HPC leaders and the HPC community in China.

Description:

Founded in 1896, Shanghai Jiao Tong University (SJTU) is the second oldest university in China. The IPCC at SJTU focuses on two code optimizations (VLPL-S and PILES), and teaching and promoting advancements from Intel and AL Technologies.

First, the particle-in-cell (PIC) simulation is well established kinetic simulations in plasma physics and astrophysics. PIC solves Maxwell equations for the electromagnetic fields and the equations of motion for macro-particles simultaneously. This kind of code has been proved to be very powerful for laser underdense plasma interactions in the hundreds of femtosecond and millimeter scale. The virtual laser plasma laboratory at SJTU (VLPL-S) is a modified in-house code that is used for both theoretical and experimental purpose. We have successfully ported and optimized the code on Intel® Xeon Phi™ products. In this IPCC, we plan to scale VLPL-S to hundreds (or even more) of nodes, port them to Intel Xeon Phi products, and add new physical models, such as the weighted particle technique and the quantum electrodynamics (QED) effects model.

Second, leukemia is the top 10 of cancers in China; children account for 40 percent of the approximately 50,000 newly infected patients each year. Leukemia is a complex combination of many subtypes. Fortunately, some of most deadly subtypes can be cured. The experiences gained in leukemia research may shed light on other cancer research. We have been developing the Precise Diagnoser of Leukemia Subtypes (PILES) code, a deep-learning-based, end-to-end precise diagnosis tool for leukemia subtypes, which includes three main components: the Gene Mutation Analyzer, Abnormal Cell Finder, and Leukemia Subtype Detector. In this IPCC, we plan to optimize PILES on Intel® architectures that include present and future Intel Xeon Phi products.

Third, we teach HPC courses about high-performance computing technologies from Intel and AL Technologies and organize the ITOC-International, the one-day workshop aiming to bridge the communication gap between world HPC leaders and the HPC community in China.

Related Websites:
HPC Center, SJTU: http://hpc.sjtu.edu.cn
Lab for Laser Plasmas, SJTU: http://llp.sjtu.edu.cn
ITOC workshops: http://itoc.sjtu.edu.cn

Intel® Parallel Computing Center at Tsinghua University - School of Life Sciences

$
0
0

Principle Investigator:

Xueming Li has been researching electron microscopy for more than fifteen years, aiming to make the atomic resolution more obtainable. His previous efforts on an electron-counting camera significantly contributed to the resolution revolution of electron cryo-microscopy (CryoEM). His current research mostly focuses on the theoretical and methodological development of CryoEM and its application in structural biology to address important biological questions. He is particularly interested in developing and applying novel image processing and parallel computing technology to advance CryoEM for routine atomic-resolution structure analysis of biological macromolecules and future industrial application for drug discovery.

Description:

CryoEM is becoming a very powerful tool in determining structures of biological macromolecules and cells, which is essential to reveal the mechanism of life process and disease, as well as for drug discovery. Now, more CryoEM facilities are under construction or being planned. How to build a suitable computing cluster for CryoEM and how to make the algorithm better for high efficiency and high resolution are becoming key questions in this field. These are also our aims to be solved in Tsinghua University, which has one of the largest CryoEM facilities in the world and hundreds of users. With this backdrop, the Intel® Parallel Computing Center (IPCC) in Tsinghua aims to find a high-throughput solution for CryoEM computing facility, better algorithms to achieve higher resolution and observe atomic details in life process.

We are planning to expand our computing power from the current approximately 600 Intel CPU nodes to more than a thousand in the next few years in order to fulfil the requirements of CryoEM computing for hundreds of users. We will not only optimize our current codes but also develop new programs to make CryoEM computing work better on the newest Intel®-based CPU clusters with the latest generation of high-speed Intel® Omni-Path Architecture. We are also planning to develop our programs on Intel® Xeon Phi™ coprocessors to take the advantage of new generation of manycore parallel computing. The success of our computing facility and algorithms will set a benchmark for the future CryoEM computing.

We are now developing a new open-source CryoEM computing system to utilize the state-of-the-art machine learning combined with parallel computing techniques, and finally make CryoEM be more efficient and scalable. We had invested significant efforts in introducing new machine-learning techniques to the current CryoEM technology, such as statistical learning based on important sampling, deep learning, and compressed sensing. By better design and optimization, we expect our program will be able to take the advantage of new generation of Intel processors.

The above efforts will definitely make our computing power more efficient and more productive, and accelerate scientific research and potential industrial application of CryoEM in drug discovery.

For life sciences, Tsinghua has hundreds of users and students working on CryoEM. Our facility will be opened to the entire country, including universities and companies, in the next few years by collaborations or public services. One of our targets is to train all users to understand and use the modern computing technology proposed in this project. We will also open some training classes and organize meetings for training and mind-storming purposes. This project is based on the collaborations with labs in computing sciences and electronic engineering. Therefore, we will gather a wide range of new technologies, including parallel computing and signal processing, and help scientists in other fields understand how their techniques can be applied to life sciences.

Related Websites:
http://life.tsinghua.edu.cn/english/
http://life.tsinghua.edu.cn/english/faculty/faculty/2731.html
http://www.icsb.tsinghua.edu.cn/

Export your Intel® XDK Mobile App to PhoneGap* Build or Cordova* CLI

$
0
0

A version of this article was originally published as part of the Intel® XDK documentation book.

When your Intel® XDK project was built by the Intel XDK cloud-based build system, it was converted to an Apache* Cordova* CLI project and then built as a standard Cordova CLI application in that cloud-based build system. With the retirement of the Intel XDK cloud-based build system, a Cordova Build Package tile was added to the Build tab so you can use Adobe* PhoneGap* Build or Cordova CLI to build your Intel XDK mobile app.

To build your Intel XDK project using PhoneGap Build or Cordova CLI you need a Cordova config.xml file. The Cordova Build Package ZIP file generated by the Intel XDK contains a config.xml file and can be submitted directly to PhoneGap Build, or quickly turned into a local Cordova CLI project. See the respective articles, titled Build Your Intel® XDK Mobile App using PhoneGap* Build and Build Your Intel® XDK Mobile App using Cordova* CLI, for details regarding building with these tools.

Two methods are described below on how to create a config.xml file. The first utilizes the built-in Cordova Build Package tile on the Build tab and the second uses an external Node.js* script named xdk-to-cli.

If you want the simplest build experience, or are not sure, you should Build using PhoneGap Build. This build process does not require installation of any software on your development system and performs the build in the cloud, like the retired Intel XDK build system. It has plugin limitations similar to the Intel XDK build system, specifically, plugins that utilize custom gradle scripts are not supported. This is the best place to start, if it does not serve your needs you can easily change to Cordova CLI.

For maximum control and flexibility over your build process you should Build using Cordova CLI. You will have access to the widest range of Cordova plugins. You must install Node.js, Cordova CLI and the requisite backend build tools (Android Studio, Xcode and Visual Studio) to perform your Cordova builds on your local development machine. Building for iOS requires access to a Mac (and Xcode) and building for Windows requires access to a Microsoft Windows machine (and Visual Studio).

Using the “Cordova Build Package” Export Tool

The process described below generates a ZIP file that contains a copy of your project’s source and asset files and an auto-generated config.xml file. That config.xml file contains the instructions needed by Adobe PhoneGap Build or Cordova CLI to build your mobile app package.

In the text below, PGB is shorthand for PhoneGap Build and CLI is shorthand for Cordova CLI.

The basic process is:

  • Projects tab: select the Intel XDK project to be built with PGB or CLI.
  • Projects tab: insure that all project Build Settings are correctly specified.
  • Build tab: click the Create Package button on the Cordova Build Package tile.
  • Build tab: save the ZIP file that is created to your local hard drive.
  • PGB: submit the ZIP file to PhoneGap Build using your PGB account.
  • CLI: extract the ZIP file and use Cordova CLI to build your app.

Create the Cordova Project ZIP File

Use the Cordova Build Package export tool on the Build tab to create the Cordova project ZIP file that you will submit to PhoneGap Build or use to build locally with Cordova CLI. The project settings in the Build Settings section of the Projects tab must be correctly set to create the project ZIP file.

NOTE: The "Developer Certificate" and "Provisioning File" fields in the Android and iOS Build Settings sections of the Projects tab are ignored and not required for this process. You can safely ignore any warnings generated by these fields.

A green checkmark icon next to a build target means you can successfully export your project Build Settings (see the middle target in the image below). An orange <!> icon next to a build target means some warnings will be generated during the export, but the export will succeed (see the top target in the image). A red <!> icon next to a specific build target lets you know that there are some Build Settings that require your attention (see the bottom target):

Hover over the red <!> icon for a link that will take you to the Build Settings on the Project tab. Once on the Project tab you may have to expand the Build Settings and select the specific build target tab in the Build Settings section to make the necessary corrections:

Packages exported for use with PhoneGap Build and Cordova CLI will ignore the “certificate fields” in the Build Settings section of the Projects tab. Your build certificates must be added manually to your PhoneGap Build account or your Cordova CLI project. Adding build certificates to your PhoneGap Build account or your Cordova CLI project is an operation that you must perform, the Intel XDK cannot do this for you.

You can disable a build target if you want to limit the build instructions in the config.xml file to specific targets (e.g., only Android* and iOS*). For example, if you have never built for Windows* you likely do not have any meaningful Build Settings configured for that build target, so you can simply “disable” that build target:

Finally, use the Create Package button to create a ZIP file that includes your app sources and a config.xml file for building with either PhoneGap Build or Cordova CLI:

Cordova Build Package ZIP File Contents

The contents of the ZIP file that is generated by the Cordova Build Package export tool are your source and assets folders along with a config.xml file formatted for use with PhoneGap Build or Cordova CLI:

The www folder contains your application source files and is an identical copy of the www folder in your Intel XDK project folder. Likewise, the package-assets folder is an identical copy of the same-named folder in your Intel XDK project folder; it contains your app icons and splash screen images.

The config.xml file is a merge of your project’s Build Settings from the Projects tab and the intelxdk.config.additions.xml file (if any) located in the root of your Intel XDK project folder (similar to the various intelxdk.config.<target-platform>.xml files that are auto-generated).

Other folders and files may be present in the ZIP file, but they will be ignored by PhoneGap Build and Cordova CLI. Usually, any extra files and folders are just informational elements that were part of a sample or template project that was used to create your project.

If you are familiar with Cordova CLI projects, you will notice there are no plugins, platforms or hooks folders in the root of the exported project. This is by design; those folders are ignored by PhoneGap Build and will be auto-generated by Cordova CLI.

After you have successfully exported a Cordova Build Package you can build your app using either PhoneGap Build or Cordova CLI (or compatible build systems). See the articles titled Build Your Intel® XDK Mobile App using PhoneGap* Build and Build Your Intel® XDK Mobile App using Cordova* CLI for details.

Using the ‘xdk-to-cli’ Node.js Script

If you are unable to successfully create a ZIP file using the Cordova Build Package tile, or if you want more control over that process, you may need to use this xdk-to-cli Node.js script. Full instructions and requirements are provided in the script’s README file.

Using xdk-to-cli with PhoneGap Build

This script does not create a ZIP file, it creates three target- specific build configuration files. Those config files are written to the root folder of your Intel XDK project.

To create a ZIP file for submission to PhoneGap Build:

  • Create a config.xml file (see the script’s README) and save it to the root of your Intel XDK project folder.
  • ZIP the contents of the entire Intel XDK project folder and submit it to PhoneGap Build (PhoneGap Build will ignore the plugins folder in the ZIP file).

If the resulting ZIP file is too large for submission to PhoneGap Build, you can exclude the plugins folder (and any other extraneous folders and files) from the ZIP, to save space. The plugins folder is ignored because PhoneGap Build uses the <plugin> tags in your config.xml file to retrieve the plugins required by your application.

 Using xdk-to-cli with Cordova CLI

If you are going to use Cordova CLI to build your project, you will need to make a copy of the Intel XDK project folder (excluding the plugins folder) and then execute the necessary Cordova CLI commands to create a buildable Cordova CLI project. In general, it is not a good idea to use the existing plugins folder that is already present in the Intel XDK project because the Intel XDK internal pluginadd mechanism that creates that plugins folder short circuits the normal Cordova pluginadd operations, in order to provide support for all build platforms, regardless of your development OS. This short circuit mechanism that is used by the Intel XDK can interfere with a local Cordova CLI build.

For more details on how to continue to use the Intel XDK alongside a Cordova CLI build system, see the section named Integrating Cordova CLI with the Intel XDK in the article titled Build Your Intel® XDK Mobile App using Cordova* CLI.

Back to School: Student Ambassadors Create New Technical Research Videos and We Get a Report Card from CVPR

$
0
0

Intel® Student Ambassador Forum - NYC

The first Intel® Student Ambassador Forum for the Artificial Intelligence (AI) program was held as a companion event to the O’Reilly AI Summit in NYC earlier this summer. This sold-out event was attended by five New York universities and three Student Ambassadors were able to present their work to the audience during live demos.

You can see the excitement and energy of the event come through in this overview video. Bob Duffy explains how this event, a first of its kind, is truly led by students. Students are doing the researching, presenting their work to an audience of students, and working with other students to collaborate and learn. Scott Apeland talks about how these students are shaping the future of AI through the work they are doing with Machine Learning, Deep Learning, and Intel optimized frameworks and tools.

The Intel® Student Ambassador Program, and highly engaging forums like this, show how excited students are about the future and their eagerness to have access to the technology to drive innovation. At Intel, our goal is to help them succeed through access to technology and experts as well as guidance in bringing their projects to life and presenting their work to an audience.

Face It – A Hairstyle Recommendation App by Pallab Paul

Student Ambassador Pallab Paul of Rutger’s University showcased his Early Innovation Project to the student audience. You can watch the technical research video for yourself here. Pallab and his team are working on an app that young men can use to find the right hairstyle, and even facial hair style, for their face shape.

Pallab and his friends figured they had about a 50/50 chance of getting a good haircut. This is a problem; young men want to experiment with trendy hairstyles, but they want to look good while doing it. So they set about seeing if they could solve the problem through the use of deep learning technology.

They started with using computer vision to detect a person’s face, then they needed to identify the shape of the face. Knowing this would help people to find a style that worked for their face shape. They combined this data with some personal information and preferences to come up with personalized recommendations for the user.

Throughout the process they’ve used Intel’s OpenCV Library, Haar-Cascades classifiers, and Intel optimized TensorFlow, Java, and Python on Intel’s Xeon Phi Cluster to create a convolutional neural network (CNN) to train their dataset to give accurate results.

They’ve run into a few roadblocks, the biggest one being the accuracy of the dataset. They are now working to increase the sample size of their dataset to achieve better results. Their plans also include integrating the UI to turn it into a real, usable app. Further down the road they would like to possibly add in emotion detection. For example when a sample style is presented to them if they smile the app would note in their preferences that they liked that style, but alternatively if they frown, the app would note that and not show them that particular style the next time.

Functional Connectivity of Epileptic Brains – Research Presented by Panuwat Janwattanapong

Student Ambassador Panuwat Janwattanapong of Florida International University presenting his research which focuses on data analysis by applying deep learning and AI to the research. His lab works to assess people with disabilities and disorders and find ways to assist them and advance research to help doctors with better diagnosis. Watch his presentation here.

Panuwat’s research centers on Epilepsy which affects 1% of the total population, across all age ranges. And for 90% of those affected, the disorder negatively affects their quality of life due to its unpredictability, impacting their ability to drive, socialize, and work. 

The benefit of the research is help those with the disorder, as well as the people/family around them, to have a better quality of life. They intend to do this by helping to make faster diagnosis of the condition, classifying whether the seizures are focalized or generalized, and attempting to predict seizures.

They are researching to see if they can accomplish all of these goals by analyzing electroencephalogram (EEG) results. EEG’s are an electrophysiological monitoring method that can capture the neural activities of the brain. The benefits to using EEG’s is that they are non-invasive, have high temporal resolution, more affordable compared to other techniques, and they have no side effects for the patient.

Their approach currently consists of using 19 sensors, but could go up as high as 300, placed on the patient’s head. By looking at the EEG in a more advanced way they are working to look at the parts of the brain that interacts with itself to find the functional connectivity. The resulting brain waves operate in four different frequency bands allowing the researches to create a connectivity matrix.

Once they have a matrix created, they work to reduce the noise ratio. Noise is created from many things including heartbeats, eye blinks, nearby electricity, etc. One way they work to do this is to also use an EKG during the EEG. The EKG creates a template of heartbeats that they can then easily remove from the EEG brain wave results.

Panuwat began his research using Matlab but quickly had too much data for it to run. Since joining the Intel Student Ambassador program he now has additional resources such as the Intel distribution for Python which has allowed him increase performance through analyzing data faster and having more models to work with.

The next step Panuwat plans to take is to segment the data. His plan is to separate the connectivity matrix into three second windows in order to not overestimate the connectivity of the brain. Once connected he can then visualize it in a head map plot. Panuwat also wants to use Intel’s Xeon Phi cluster to further analyze the EEG and to plot the Eigen value.

Sensor Fingerprint for Mobile Identity – A Proof of Concept by Srivignessh Pacham Sri Srinivasan

Student Ambassador Srivignessh Pacham Sri Srinivasan of Arizona State University described his AI research designed to uniquely identify mobile devices through noise in their sensors. Watch Srivignessh’s presentation here.

Srivignessh explains how your mobile device, by default, has a lot of sensors inside it which are available to monitor and create a unique pattern to identify your specific device. All mobile and wearable sensors have their own unique manufacturing defects and Srivignessh has developed a way to learn these calibrations in order to use them for identification of devices, creating a fingerprint for each mobile device.

The easiest sensor to do this with is your mobile device’s accelerometer. The accelerometer is what rotates your screen when you turn your phone sideways, and by default this is turned on. A possible use case is for home routers: your network can identify your device through its sensor fingerprint and authenticate you without the need of a password, therefore keeping your network safe from unauthenticated devices.

Accelerometers measure acceleration in x, y, and z directions with linear calibration errors. This creates two calibration metrics for sensitivity, providing six metrics to use. In analyzing these metrics, the next nearest neighbor (KNN) algorithm can be applied to map the sensor reading to the device. The algorithm uses the top 3 neighbors to help classify the device and displays its cluster on a map.

Srivignessh is using Javascript, Python, Django web framework and a cloud server currently. He plans to be moving the data to Intel’s Xeon Phi cluster soon for better performance. He also clarified that this process doesn’t parse out any of your sensitive data, it only reads the sensor imperfections based on the manufactured device.

He sees this project scaling for use in stadiums, airport lounges, and other general single-use areas, when there shouldn’t be a need for you to give credentials in order to identify your specific device trying to access the Wi-Fi network.

Intel® Student Ambassador Forum - Honolulu

Intel hosted its second Student Ambassador Forum in conjunction with the Computer Vision Pattern Recognition (CVPR) conference in Hawaii. More than twelve universities and 300 registrants attended this event to collaborate on projects, discuss industry trends, and learn what to expect with the next generation of AI. Read more about what they are doing In the AI space.

Three Intel Student Ambassadors spoke about their use cases and applications of AI, all using a variety of Intel’s optimized frameworks and tools. Suraj Ravishankar of Arizona State University demonstrated his vehicle detection project which could be extremely useful for self-driving cars as the model gets trained to recognize birds, people, stop signs, and more. Nikhil Murthy of MIT shared his skip-thought vector project which is trained on Intel’s Nervana Neon framework to auto-process new financial documents daily, highlighting topics of interest to the company. And Arun Ramesh Srivasta of Arizona State University showcased his project which highlights the rotation angles of both arms via myo armbands used to reconstruct hand joint rotations. 3D hand models are then animated to generate videos of gestures from the raw data and then use a pre-trained CNN model to classify them.

The highlight of the event however was the official launch of the Movidius Neural Compute Stick. This developer kit with an embedded deep learning platform was designed to further fuel development in AI. Needless to say the Student Ambassadors and attendees were very interested in learning more about what this device could do. An important aspect of the Ambassador Program is access to experts, and Intel’s AI experts held a fireside chat with students focusing on AI today and areas students may want to focus on when considering a career in this field.

Want to learn more about the Intel® Student Developer Program for Artificial Intelligence?

You can read about our program, get a program overview, and we also encourage you to check out Intel® Developer Mesh to learn more about the various projects that our student community is working on.

Interested in more information? Contact Niven Singh

Build Your Intel® XDK Mobile App using PhoneGap* Build

$
0
0

A version of this article was originally published as part of the Intel® XDK documentation book.

This document assumes that you have successfully exported your Intel XDK project using the Cordova Build Package export tool. For instructions on how to export your project, see the doc page titled Export your Intel® XDK Mobile App to PhoneGap* Build or Cordova* CLI.

Submit the ZIP File to PhoneGap Build

The ZIP file generated by the Cordova Build Package export tool is ready for use with PhoneGap Build. You must have an Adobe PhoneGap account to build your app using PhoneGap Build.

Free PhoneGap Build account is limited to one “private” app slot that can be no larger than 50MB in size and does not support private plugins.

Documentation for PhoneGap Build is available on-line. The FAQ section is short and worth reviewing, especially regarding which versions of Cordova CLI are supported and where to find community support for PhoneGap Build.

If you see the message "This app isn't using the latest version of PhoneGap. We recommend upgrading ..." after submitting your exported ZIP file, please read this PhoneGap Build FAQ; in most cases you can ignore that warning.

Do not build with CLI 7.x or later until you have successfully built your app using CLI 6.x!!

The version of CLI specified in the config.xml file exported by the Intel XDK is the closest equivalent to the version of CLI specified in your Intel XDK project's Build Settings. Since PhoneGap Build is regularly updated to offer the latest version of Cordova CLI, the version specified in the exported config.xml file is very likely not the "latest version" of PhoneGap Build.

IMPORTANT: if you change Build Settings or add/remove plugins using the Projects tab of the Intel XDK, you must export a new ZIP file that contains an updated config.xml file and submit that new ZIP file to PhoneGap Build.

Transferring Signing Certificates to PhoneGap Build

iOS Signing Certificates:

You do not need to transfer your iOS signing certificates or mobile provisioning files from the Intel XDK to PhoneGap Build!!

It is much easier to create a new set of iOS signing certificates, using the iOS signing instructions provided by PhoneGap Build, than it is to transfer the iOS developer certificates stored in the Intel XDK certificate management system to PhoneGap Build.

If you have trouble creating your iOS signing certificates on a Mac (when using the Mac instructions), use the Windows iOS signing certificate instructions, instead. The instructions to create an iOS signing certificate on a Windows PC work on all platforms (Windows, Mac and Linux).

Windows Signing Certificates:

Likewise, it also simpler to create a new Windows signing certificate for use with PhoneGap Build using your Microsoft Developer Account. The process is explained in the PhoneGap Build signing instructions for Windows.

Android Signing Certificates:

IMPORTANT: if you have never published an APK to an Android store you can skip this section and create a new signing certificate by following the PhoneGap Build signing instructions for Android.

If, and only if, you have published an APK to an Android store, using the Intel XDK, you should continue to use the same Android signing certificate to publish updates to your app. This means you may want to use your Intel XDK developer certificate to build and sign your APK when using PhoneGap Build (if you are debugging your app you should use the default signing certificate that PhoneGap Build automatically provides).

Find the developer certificate you have been using to sign your published apps in the Intel XDK Certificate Management tool. Then download that certificate and add it to your PhoneGap Build account following these PhoneGap Build instructions (the precise name of the certificate's alias will probably be different than what is shown in the image below):

If the signing certificate you used to publish your APK is not in the Intel XDK Certificate Management tool, we cannot help you retrieve it, the only certificates stored by the Intel XDK build system are those that you can download directly from the Certificate Management tool, under the Account Settings icon, as shown above.

If you have never converted your Android "legacy" certificate you must first do so before you can download it using the Certificate Management tool; see this video for help with that process. If you are not seeing all the fields in the certificate management dialogs, please see this forum post for help.

When it comes time to build your Android app, with the signing certificate you transferred to PhoneGap Build from the Intel XDK, you will be asked by PhoneGap Build for both a certificate password and a keystore password. Any keystore file you created with the Intel XDK and downloaded from the Certificate Management tool contains a single certificate. When you created that keystore using the Intel XDK you were given the opportunity to use one password for both the certificate and the keystore; in that case, submit that one password to both PhoneGap Build password fields to unlock your Intel XDK signing certificate when you import it into PhoneGap Build; otherwise, provide both passwords.

IMPORTANT: PhoneGap Build does not provide a means to export any keystore you import into their certificate management tool. Always keep a copy of your keystore in a safe place and remember the password(s). Once deleted or lost, we cannot help you retrieve that information!!

Building with Crosswalk

The Crosswalk project was retired in February, 2017. We recommend you change your Build Settings to build for Android 4.4 (minimum API level 19) and later and discontinue using Crosswalk unless your application truly requires it. Cordova applications that run on Android versions 5 and above will see little or no benefit from using Crosswalk, unless you are using APIs that are unique to the Crosswalk runtime. If you have been using Crosswalk and choose to stop using it, you may experience some issues with the Android "versionCode" number; see this article for help with Android versionCode issues.

If your project is configured to build for Crosswalk on Android, the exported config.xml file includes a preference tag that directs PhoneGap Build to create a "multi-architecture" APK file. This is different than the cloud-based Intel XDK build system, which created two "single-architecture" APK files that were delivered in a single ZIP file. This behavior is caused by the following tag:

<preference name="xwalkMultipleApk" value="false" />

A “multi-architecture” Crosswalk APK file contains 32-bit Crosswalk libraries for both x86 and ARM mobile devices in a single APK file. The xwalkMultipleApk tag is necessary because PhoneGap Build returns only a single APK file when it performs a Crosswalk build, unlike the retired Intel XDK build system, which returned a ZIP file that contained two APK files, one for x86 and one for ARM.

If you unzip a multi-architecture APK you can see both Crosswalk libraries included in the package.

Removing the xwalkMultipleApk tag from the config.xml file (or changing the tag “value” to “true”) will result in generating two APK files, but they will not be bundled into a single ZIP file. Unfortunately, PhoneGap Build only returns one Crosswalk APK file, so changing this tag value to "true" is not advised if you are building a Crosswalk app with PhoneGap Build.

Using the ‘xdk-to-cli’ Node.js Script

If you are unable to successfully create a ZIP file using the Cordova Build Package tile, or you want more control over that process, you may need to use this xdk-to-cli Node.js script. Full instructions and requirements are provided in the script’s README file.

Using xdk-to-cli with PhoneGap Build

This script does not create a ZIP file, it creates three target-specific build configuration files. Those config files are written to the root folder of your Intel XDK project.

To create a ZIP file for submission to PhoneGap Build:

  • Create a config.xml file (per the script's README) and save it to the root of your Intel XDK project folder.
  • ZIP the contents of the entire Intel XDK project folder and submit it to PhoneGap Build (PhoneGap Build will ignore the plugins folder in the ZIP file).

If the resulting ZIP file is too large for submission to PhoneGap Build, you can exclude the plugins folder (and any other extraneous folders and files) from the ZIP, to save space. The plugins folder is not needed because PhoneGap Build uses the <plugin> tags in your config.xml file to retrieve the plugins required by your application.

Build Your Intel® XDK Mobile App using Cordova* CLI

$
0
0

A version of this article was originally published as part of the Intel® XDK documentation book.

This document assumes that you have successfully exported your Intel XDK project using the Cordova Build Package export tool. For instructions on to export your project, see the doc page titled Export your Intel® XDK Mobile App to PhoneGap* Build or Cordova* CLI.

Requirements to Build with Cordova CLI 6.x

Building your app locally (on your development system) with Cordova CLI 6.x requires installation of Node.jsCordova CLI and the appropriate vendor-specific development tools for the targets of interest (i.e, Android Studio* for Android, Apple* Xcode* for iOS and Microsoft* Visual Studio* for Windows).

IMPORTANT: Building for iOS requires macOS and Xcode; building for Windows requires Microsoft Windows 8.1+ and Visual Studio; building for Android is supported on Windows, OS X and Linux.

Details regarding the necessary tools, versions and system requirements can be found on the following pages of the Cordova CLI 6.x documentation:

Installing Node.js and Cordova CLI 6.x

You must install the appropriate native development tools before you can use Cordova CLI on your development system! The instructions that follow do not explain how to install those native tools. It is best to install them first before installing Cordova CLI. See the links above for details and pointers to install those native development tools.

The instructions in the Create your first Cordova app documentation page provide a detailed discussion about how to create, build and test apps using Cordova CLI 6.x. The following sections will guide you through a typical installation. In the following, we will install the latest version of Node 6.x and Cordova CLI 6.5.0.

Installing Node.js

If you need to manage multiple versions of Node.js on your development system, install Node Version Manager first and then use it to install Node.js. This will allow you to easily install and switch between multiple versions of Node.js. Windows users can use Node Version Manager for Windows to install and manage multiple versions of Node.js.

Assuming you are NOT using Node Version Manager, use the following instructions to install Node.js on your system.

Installing Node.js on Windows or Mac

For Windows or Mac, go to the Node 6.x latest distribution folder and download the Windows MSI installer or the macOS PKG installer. For example, at the time this article was written, the latest version of Node 6.x was 6.11.2. So the following installers were available to downloaded in the Node 6.11.2 distribution folder:

  • node-v6.11.2-x86.msi <  for installation on Windows (32-bit or 64-bit)
  • node-v6.11.2.pkg <  for installation on Mac OSX

Each of the above is a "runnable executable" for the respective platform. You can "double-click" the appropriate installer file that you have downloaded and it will install and configure Node.js 6.x for your system.

Installing Node.js on Debian or Ubuntu

To install the latest version of Node 6.x on a recent Debian or Ubuntu system, use the following command-line:

$ curl -sL https://deb.nodesource.com/setup_6.x | sudo -E bash -
$ sudo apt-get install -y nodejs

For help with installing Node.js on other Linux systems, see this useful GitHub repo > https://github.com/nodesource/distributions.

Testing your Node.js Installation

To test your installation of Node.js on any OS, type the following at a command-line:

> node --version
v6.11.2

If you see a result similar to the above, you have successfully installed Node.js 6.x.

Installing Cordova CLI 6.x

To manage multiple versions of Cordova CLI install Version Manager for Cordova Softwarebefore installing Cordova CLI. You can use then use "cvm" to to install and switch between multiple versions of Cordova CLI.

If you are not using Version Manager for Cordova, follow these instructions to install Cordova CLI 6.5.0 on your development system.

> npm -g install cordova@6.5.0

This will force the installation of Cordova CLI 6.5.0.

IMPORTANT: If you want to match the CLI 6.2.0 option that was in the retired Intel XDK build settings, specify "cordova@6.2.0" instead of "cordova@6.5.0" in the above command line.

To test your installation of Cordova CLI, type the following at the command-line:

> cordova --version
6.5.0

If you see a result identical to the above, you have successfully installed Cordova CLI 6.5.0.

IMPORTANT: Versions of Cordova CLI prior to 6.x do not reliably add all the plugins listed in the config.xml file and Cordova CLI 7.x adds new requirements to project and plugin configuration files that may not be compatible with the config.xml file exported by the Intel XDK.

For best results building your Intel XDK mobile app with Cordova CLI we recommend that you install Cordova CLI 6.2.0 or 6.5.0.

Version 6.2.0 of Cordova CLI will give the same build results as that used by the retired Intel XDK build system, if you had selected the CLI 6.2.0 option in the Build Settings section of the Projects tab. For additional help with CLI versions, see this Intel XDK FAQ.

You can install CLI 6.2.0 using the following npm command:

$ npm -g install cordova@6.2.0

Test Your Node and Cordova CLI Installation

You can use this simple command-line test to confirm that your Cordova CLI build environment is ready to use:

> cordova create test> cd test> cordova platform add android> cordova prepare> cordova build android

This test assumes you are building for Android and using Cordova CLI 6.x.

If the test above failed at the "prepare" or the "build" step, try running the following command to get information on what might be missing:

> cordova requirements

Requirements check results for android:
Java JDK: installed 1.8.0
Android SDK: installed true
Android target: installed android-7,android-8,android-9,android-10,android-11,android-12,android-13,android-14,android-15,android-16,android-17,android-18,android-19,android-20,android-21,android-22,android-23,android-24,android-25,android-26
Gradle: installed 

The results shown above are for a working Android SDK and tools installation. When "cordova requirements" fails, it will look something like this:

> cordova requirements

Requirements check results for android:
Java JDK: installed .
Android SDK: installed
Android target: not installed
Android SDK not found. Make sure that it is installed. If it is not at the default location, set the ANDROID_HOME environment variable.
Gradle: not installed
Could not find gradle wrapper within Android SDK. Might need to update your Android SDK.
Looked here: C:\Users\<userid>\AppData\Local\Android\sdk\tools\templates\gradle\wrapper
Error: Some of requirements check failed

In that case, see this forum thread, especially the details in this forum post located within that thread, for help resolving your Android SDK setup.

If you are building for iOS or Windows simply replace android with ios or windows in the lines above. Note that because Cordova CLI runs on Node.js, the commands you type are identical, regardless of your development machine’s operating system (OS).

Type cordova help for additional commands and see the cordova-cli GitHub* repo for a complete list of the Cordova CLI commands that are available.

Build the ZIP Project with Cordova CLI

Once all the necessary Cordova CLI build tools are in place you can build your app directly at the command line. See the Cordova documentation for complete details.

In essence, you will do the following to build a mobile app package with the contents of the exported ZIP project, using Cordova CLI:

  • Unzip the ZIP file you exported with the Create Cordova Package tile.
  • Perform a cordova platform add <platform-name> for each target platform.
  • Perform a cordova build <platform-name> for each target platform.

When you are ready to build a package to be submitted to an app store, you will need to add your signing certificates to the Cordova CLI project, so you can build a signed app. Otherwise, you can use the default signing certificate provided by Cordova CLI to build a debuggable version of your app.

The Cordova CLI documentation provides instructions regarding how to:

After you have signing certificates in place (see the section below titled Transferring Signing Certificates to Cordova CLI for additional help), you can include them in your build process. In most cases the best option will be to create a build.json file that you can then reference during the build (see the Cordova CLI Using build.json sections contained within the various sign an app links provided above).

If you encounter issues when building for iOS, especially an "error 65" message, you are probably experiencing app signing issues. This StackOverflow post may be of value. Likewise, employing this hook.js file by Darryl Pogue may be helpful. Finally, this guide to signing iOS apps may be of interest to the very curious.

The --debug and --release and --device Cordova CLI options are not well documented, but are essential for creating a "debug" or "release" iOS build and for directing Cordova to build an IPA package rather than a simulator image for use with the Xcode iOS simulator. See this forum post for help configuring and signing your iOS project for a successful build with the Cordova CLI tools.

See the cordova-cli GitHub* repo for a complete list of the Cordova CLI commands that are available.

See this forum post for help configuring and signing your iOS project for a successful build with the Cordova CLI tools.

Transferring Signing Certificates to Cordova CLI

iOS Signing Certificates:

You do not need to transfer your iOS signing certificates or mobile provisioning files from the Intel XDK to PhoneGap Build!!

It is much simpler to create a new set of iOS signing certificates, using the iOS signing instructions provided by PhoneGap Build, than it is to transfer existing iOS developer certificates stored in the Intel XDK build system to your Cordova CLI project.

If you have trouble creating your iOS signing certificates on a Mac (using the Mac instructions), use the Windows iOS signing certificate instructions, instead. The instructions to create an iOS signing certificate on a Windows PC will work on all platforms (Windows, Mac and Linux).

Windows Signing Certificates:

Likewise, it also simpler to create a new Windows signing certificate for use with PhoneGap Build using your Microsoft Developer Account. The process is explained in the PhoneGap Build signing instructions for Windows.

Android Signing Certificates:

IMPORTANT: if you have never published an APK to an Android store you can skip this section and create a new signing certificate by following the PhoneGap Build signing instructions for Android.

If, and only if, you have published an APK to an Android store, using the Intel XDK, you should continue to use the same Android signing certificate to publish updates to your app. This means you may want to use your Intel XDK developer certificate to build and sign your APK when performing a release build with Cordova CLI (if you are only debugging your app you can use the default signing certificate that Cordova CLI automatically provides).

Find the developer certificate you have been using to sign your published apps, in the Intel XDK Certificate Management tool. From there download the certificate and use it to sign your Android app that you are building with Cordova CLI (the precise name of the certificate's alias will probably be different than what is shown in the image below):

If the signing certificate you used to publish your APK is not in the Intel XDK Certificate Management tool, we cannot help you retrieve it, the only certificates stored by the Intel XDK build system are those that you can download directly from the Certificate Management tool, under the Account Settings icon, as shown above.

If you have never converted your Android "legacy" certificate you must first do so before you can download it using the Certificate Management tool; see this video for help with that process. If you are not seeing all the fields in the certificate management dialogs, please see this forum post for help.

When it comes time to build your Android app, with the signing certificate you retrieved from the Intel XDK, you will need both a certificate password and a keystore password. Any keystore file you created with the Intel XDK and downloaded from the Certificate Management tool contains a single certificate. When you created that keystore using the Intel XDK, if you chose to use a single password for both the certificate and the keystore, use that one password to unlock your signing certificate; otherwise, you must provide both passwords.

IMPORTANT: It is very important that you keep a copy of your keystore in a safe place and remember the password(s). Once deleted or lost, we cannot help you retrieve that information!!

Building with Crosswalk

IMPORTANT: The Crosswalk project was retired in February, 2017. We recommend you change your Build Settings to build for Android 4.4 (minimum API level 19) and later and discontinue using Crosswalk unless your application truly requires it. Cordova applications that run on Android versions 5 and above will see little or no benefit from using Crosswalk, unless you are using APIs that are unique to the Crosswalk runtime. If you have been using Crosswalk and choose to stop using it, you may experience some issues with the Android "versionCode" number; see this article for help with Android versionCode issues.

If your project is configured to build for Crosswalk on Android, the exported config.xml file includes a preference tag that directs Cordova CLI to create a "multi-architecture" APK file. This is different than the cloud-based Intel XDK build system, which created two "single-architecture" APK files that were delivered in a single ZIP file. This behavior is caused by the following tag:

<preference name="xwalkMultipleApk" value="false" />

A “multi-architecture” Crosswalk APK file contains 32-bit Crosswalk libraries for both x86 and ARM mobile devices in a single APK file. The xwalkMultipleApk tag is necessary because PhoneGap Build returns only a single APK file when it performs a Crosswalk build, unlike the retired Intel XDK build system, which returned a ZIP file that contained two APK files, one for x86 and one for ARM. 

If you unzip a multi-architecture APK you can see both Crosswalk libraries included in the package.

Since you are using Cordova CLI to build your app, and not PhoneGap Build, you can, optionally, change the value of this preference tag. Removing the xwalkMultipleApk tag from the config.xml file (or changing the tag “value” to “true”) and building with Cordova CLI will result in generating two APK files, but they will not be bundled into a single ZIP file.

Unfortunately, it is not obvious, when you look at the Cordova CLI build messages, that two APK files were generated. The two Crosswalk APK files are located inside your Cordova CLI project:

$ cd platforms/android/build/outputs/apk/
$ ls -al
total 395904
-rw-r--r--  1 username  staff    24M Mar 27 10:09 android-armv7-debug-unaligned.apk
-rw-r--r--  1 username  staff    24M Mar 27 10:09 android-armv7-debug.apk
-rw-r--r--  1 username  staff    46M Mar 27 10:06 android-debug-unaligned.apk
-rw-r--r--  1 username  staff    46M Mar 27 10:06 android-debug.apk
-rw-r--r--  1 username  staff    27M Mar 27 10:10 android-x86-debug-unaligned.apk
-rw-r--r--  1 username  staff    27M Mar 27 10:10 android-x86-debug.apk

See this forum post for a more detailed example.

[OPTIONAL] Integrating Cordova CLI with the Intel XDK

If you want to build your app using Cordova CLI, and continue to use the Intel XDK to edit and debug (e.g., using the Simulate tab) you can create a mirror Cordova CLI project that links back to the Intel XDK project sources. The mirror CLI project contains links to the www and package-assets folders located in your Intel XDK project.

IMPORTANT: the technique described below assumes you are familiar with the use and concept of filesystem “links” and that you are comfortable using OS command-line tools (ln on macOS and Linux and mklink on Windows). If this is not the case you should not use this technique!!

For example, assume you have an Intel XDK project (the master project) named my-project and your mirror CLI project is (the slave project) named my-project-cli.

Here are the contents of the master Intel XDK project folder, named my-project:

And here are the contents of the new slave Cordova CLI project folder, named my-project-cli (before any Cordova commands have been executed):

The small arrows on the www and package-assets folders in the slave folder image indicate a symbolic link that points back to the same-named folders in the master project folder (these images are from macOS, other operating systems may display links differently). If we look at the command-line we see something like this (again shown on an macOS machine, other systems will display differently):

$ ls -gon
total 24
-rw-r--r--  1   1111 Feb  3 18:23 config.xml
lrwxr-xr-x  1     29 Feb  3 15:27 package-assets@ -> ../my-project/package-assets/
lrwxr-xr-x  1     17 Feb  3 15:26 www@ -> ../my-project/www

The following steps were taken to get to this state:

  • Create a mirror CLI folder (in this example: my-project-cli).
  • Generate a config.xml file using the Create Cordova Package tool or the xdk-to-cli script.
  • Copy the config.xml file into the mirror CLI folder (e.g., my-project-cli).
  • Create links to the www and package-assets folders in the master project folder (e.g., my-project).
  • If there are other important folders you need in the mirror project, create similar links to those folders. This is not likely, since Cordova CLI and the Intel XDK only need to share the www and package-assets folders.

Now perform the commands (assuming you will be building for Android):

$ cd my-project-cli
$ cordova platform add android
$ cordova prepare

Following the steps above, your my-project-cli folder should look something like this:

The platforms and plugins folders were created by the cordova platform add  and cordova prepare command(s) and contain the additional source and binaries files needed by Cordova CLI to perform a local build on your machine (assuming all of the necessary build tools have been installed onto your development machine).

Now you can rebuild your app in your my-project-cli folder with Cordova CLI after making changes to your app using the Intel XDK (which is operating on the master files in the my-project folder).

IMPORTANT: if you change Build Settings or add/remove plugins using the Projects tab of the Intel XDK, you must generate a new config.xml file and update that file and plugins within your mirror project.

Keeping plugins in-sync, between the master project and the CLI slave project, can be challenging; especially if you are making frequent changes to the plugins in your project using the Intel XDK Plugin Management tool on the Projects tab. There is no single “right way” to do this. Below are a few suggestions of how to handle this task, in no particular order:

  • Perform the same operation(s), by hand, in your mirror project, using the cordova plugin add  and cordova plugin remove  commands.
  • Use the cordova prepare command to have CLI automatically add plugins per changes to the config.xml file — unfortunately, this procedure will not automatically remove plugins that have been removed from the config.xml file, those you will have to remove by hand using the cordova plugin remove  command.
  • Delete the plugins folder in your slave CLI project and use the cordova prepare command to automatically add back the plugins found in the new config.xml file.
  • Delete the plugins and the platforms folders in your CLI slave project and perform a cordova platform add  operation, which will simultaneously add the plugins listed in the new config.xml file.

All of the above strategies have pros and cons, none is a perfect solution. What works best for you will only be determined through time and experience.

Using the ‘xdk-to-cli’ Node.js Script

If you are unable to successfully create a ZIP file using the Cordova Build Package tile, or you want more control over that process, you may need to use this xdk-to-cli Node.js script. Full instructions and requirements are provided in the script’s README file.


Installing Intel Parallel Studio XE on Google Cloud Platform Windows Instances

$
0
0

Introduction

This article covers the installation steps with troubleshooting and tips for Intel® Parallel Studio XE on Google Cloud Platform (GCP). Note, some of the tools may have functional restrictions due to the cloud environment.  For system requirements, please see Release Notes for details. For further Intel related support, visit https://software.intel.com/support.

Getting Started with Google Cloud Platform

This article assumes you are familiar with GCP environment. To learn more about working with GCP see: https://cloud.google.com/docs/

Specifically, this article assumes:

  • You have a GCP account
  • You are familiar with creating instances within the GCP environment.
  • To learn more about launching an instance see creating an instance.
  • For maximum instance communication please place all instances within the same Virtual Private Cloud (VPC) network.

Creating an Instance

Connecting to the GCP Instance

  • Note: you are likely to encounter an Unknown Publisher warning message. Click Connect to continue with the connection. You will be prompted to enter your password.
  • A security popup will alert you that the identity of the remote computer cannot be verified. Select Yes to continue.
  • For more information see Connecting to Instances

IE Security Settings

Security settings in your IE browser may interfere with product download and installation. To ensure they are turned off do the following:

  1. Close any IE browser you may have open
  2. Run Server Manager
  3. Click on Local Server
  4. Click on the link next to the IE Enhanced Security Configuration
  5. In the popup dialog select the Off option for both Administrators and Users and click OK
  6. Launch IE and click Don’t use recommended settings

Note: Best practices suggest reverting to more secure settings after completing setup and installation.

Installing Intel® Software Development Products

Once your GCP instance is up and running you can proceed with the product installation.

If you received an Intel email for the software product you acquired, follow the instructions in the email to register your Serial Number and create an Intel Registration Center account (if you don’t already have one).

Installing Microsoft* Visual Studio

Intel® Parallel Studio XE requires an existing installation of Microsoft* Visual Studio (MSVS). If you have a license for a full MSVS product please install it at this time. If you don’t have a license, you may get the latest MSVS community license and install it in the instance prior to the installation of the Intel Product.

Important: MSVS must be installed prior to the installation of Intel Parallel Studio XE to enable integration. Make sure MSVS is preinstalled on the instance where Intel Parallel Studio XE will be installed. MSVS is not required for the installation of Intel Software License Manager..

Intel® VTune™ Amplifier 2017

You will only be able to use Intel® VTune™ Amplifier 2017 in basic hotspots and Locks & Waits. This is due to running the tool in a virtual environment. For more information see User Reference Guide.

Downloading

To download the product:

  • Open the registration email and click on the Download link.
  • OR go to Intel Registration Center and log into your account. In the product tab locate your software product and download it

When downloading you have a choice between using the online installer and an offline package.

  • Online Installer – You can choose to customize and install the product now OR
    You can choose to create and download a customized package for a later installation
  • Offline Package – This package includes all the components in the product and as such is larger than the customized package

Installing with a Named-User License

During installation it is recommended to use the serial number to install the product. For alternative activation methods see the Installation Guide and the Product Licensing FAQ.

The majority of the named user licenses are system-locked. The license file associated with a specific activation will contains the host id (mac address) of the instance where it was installed. A named-user license is limited to n simultaneous activations as defined in our Software EULA.

Note:

  • Activation is not released when the product is uninstalled
  • Activation is not released when the instance is terminated

If the host id of the instance changes, the product will no longer work with the original license file. Reinstalling the product will generate a new license file, bound to the new host id. It will also consume another activation. See “Dealing with Instance and Host ID Changes” in “Troubleshooting and Tips”.

If you consumed all available activations and need to install the product on a new instance, you can release existing activations in the Intel Registration Center. See Release Activations.

Installing with a Floating License

Floating license installation has two parts: License Server installation and Product installation.

License Server Installation

  • Download the License Manager
    • Log into Intel Registration Center
    • In the Serial Numbers tab locate your serial number and click it
    • On the Manage License page scroll down and locate the license manager
    • Click on the Download button
  • Install the License Manager
    • When installing the License Manager select ‘I have a serial number’ and enter the serial number of your product.
    • In the Set Firewall dialog, select Local Subnet Only.
  • Once the License Manager had been installed it should start automatically. If you have to start it manually:
    • On the host system desktop
    • Locate and run the Configure Intel® Software License Manager application.
    • Click the Browse button and navigate to the ‘C:\Program Files (x86)\Common Files\Intel\License\’ folder
    • Select the installed license file and click Start to start the license manager.
    • Click Exit to exit the application

Important: Make sure that the instance you install the License Manager on is protected against termination and is accessible from other instances.

Note: License server can serve both Windows and Linux OS however the license type should match the client OS. Please see Product Licensing FAQ for more information.

Product Installation

  • Use the link in the registration email or log into Intel Registration Center to download the product. See detailed information about downloading options in the Download section above.
  • In the activation screen choose the ‘I have a serial number and I want to activate my product’ option. Enter the serial number for your floating license and proceed with the installation. For information on using Intel Parallel Studio XE please refer to our getting started guide (https://software.intel.com/en-us/get-started-with-parallel-studio-xe-for-windows)

Troubleshooting and Tips

Dealing with Instance and Host ID Changes

A product installation activates a license with the Host id of the instance. If the Host id changes the license information will no longer match the instance information and the product will cease to function.

If your MAC address has changed the activated license may need to be updated. In order to update the license file for an existing installation:

Verifying Floating Licenses Checkout

On the client set the environment variable INTEL_LMD_DEBUG to 1 and run a tool such as the compiler. At the bottom of the output you should see where the license came from.

For floating license server you should see a note about successful checkout.

Additional Resources

Installing Intel Parallel Studio XE on Google Cloud Platform Linux Instances

$
0
0

Introduction

This article covers the installation steps with troubleshooting and tips for Intel® Parallel Studio XE on Google Cloud Platform (GCP). Note, some of the tools may have functional restrictions due to the cloud environment.  For system requirements, please see Release Notes for details. For further Intel related support, visit https://software.intel.com/support.

If your applications are built with Intel® Compilers or if you dynamically link to Intel® Performance Libraries*, you must make the respective runtime available on the VM instances. To learn how to access runtimes at no cost – see Installing Intel® Parallel Studio XE Runtime using Linux Package Manager.

Developers can also easily install Intel® Performance Libraries and Intel® Distribution for Python* via popular Linux package managers

Getting Started with Google Cloud Platform

This article assumes you are familiar with GCP environment. To learn more about working with GCP see: https://cloud.google.com/docs/

Specifically, this article assumes:

  • You have a GCP account
  • You are familiar with creating instances within the GCP environment.
  • To learn more about launching an instance see the documentation for creating an instance.
  • For maximum instance communication, create all your instances within the same Virtual Private Cloud (VPC) network.

Creating an Instance

  • Set the instance storage to a minimum of 25GB. For instructions on setting instance storage please refer to https://cloud.google.com/compute/docs/disks/add-persistent-disk#create_disk

Connecting to the GCP Instance

  • When connecting to the VM instance, you are likely to encounter an Unknown Publisher warning message. Click Connect to continue with the connection. Enter your password when prompted..
  • A security popup appears to alert you that the identity of the remote computer cannot be verified. Select Yes to continue.
  • For more information see the documentation for Connecting to Instances

Installing Intel® Software Development Products

Downloading

To download the product:

  • Open the registration email and click on the Download link.
  • OR go to Intel Registration Center and log into your account. In the product tab locate your software product and download it

When downloading you have a choice between using the online installer and an offline package.

  • Online Installer – You can choose to customize and install the product now OR
    You can choose to create and download a customized package for a later installation
  • Offline Package – This package includes all the components in the product and as such is larger than the customized package

You now need to move your download to the GCP instance.  You can use the gcloud tool to move files to the instance by running:

gcloud compute copy-files [LOCAL_FILE_PATH] [INSTANCE_NAME]:~/

Refer to Transferring Files to Instances for detailed instructions.

If you are working from a Windows* host the recommended way to transfer files to your Linux* Instance is through winscp. You can find the instructions here: https://cloud.google.com/compute/docs/instances/transfer-files#winscp

1.Before you begin you will want to make sure that you have an updated system and the following prerequisites installed. You can do that with the following command:

sudo yum update && sudo yum install wget lsb gcc-c++ expect
sudo apt-get upgrade && sudo apt-get install wget lsb g++ expect (Ubuntu)

2.Go to the directory where you transferred the package

3.Untar the archive tar

–xf <package_name>.tgz

4.Run the install.sh and follow the onscreen instructions to complete installation

For more details, see the Installation guide.

Installing with a Named-User License

During installation it is recommended to use the serial number to install the product. For alternative activation methods see the Installation Guide and the Product Licensing FAQ.
The majority of the named user licenses are system-locked. The license file associated with a specific activation will contains the host id (mac address) of the instance where it was installed. A named-user license is limited to n simultaneous activations as defined in our Software EULA.

Note:

  • Activation is not released when the product is uninstalled
  • Activation is not released when the instance is terminated

If the host id of the instance changes, the product will no longer work with the original license file. Reinstalling the product will generate a new license file, bound to the new host id. It will also consume another activation. See “Dealing with Instance and Host ID Changes” in “Troubleshooting and Tips”.

If you consumed all available activations and need to install the product on a new instance, you can release existing activations in the Intel Registration Center. See Release Activations.

Installing with a Floating License

Floating license installation has two parts: License Server installation and Product installation.

License Server Installation

  • Download the License Manager
    • Log into Intel Registration Center
    • In the Serial Numbers tab locate your serial number and click it
    • On the Manage License page scroll down and locate the license manager
    • Click on the Download button
  • Install the License Manager
    • When installing the License Manager select ‘I have a license file’. Browse to the file location and select it.
  • Once the License Manager had been installed it should start automatically. If you have to start it manually:
    • On the host system
    • Go to the directory where you installed the License Server.
    • Run the lmgrd daemon specifying the location of the license file with the –c flag
    • ./lmgrd –c /path/to/server.lic & 

Important: Make sure that the instance you install the License Manager on is protected against termination and is accessible from other instances.

Note: License server can serve both Windows and Linux OS however the license type should match the client OS. Please see Product Licensing FAQ for more information.

Product Installation

  • Use the link in the registration email or log into Intel Registration Center to download the product. See detailed information about downloading options in the Download section above. 
  • In the activation screen choose the ‘I have a serial number and I want to activate my product’ option. Enter the serial number for your floating license and proceed with the installation. 
  • For information on using Intel Parallel Studio XE please refer to our getting started guide (https://software.intel.com/en-us/get-started-with-parallel-studio-xe-for-linux).

Troubleshooting and Tips

Dealing with Instance and Host ID Changes

A product installation activates a license with the Host id of the instance. If the Host id changes the license information will no longer match the instance information and the product will cease to function.

If your MAC address has changed the activated license may need to be updated. In order to update the license file for an existing installation:

Verifying Floating Licenses Checkout

On the client set the environment variable INTEL_LMD_DEBUG to 1 and run a tool such as the compiler. At the bottom of the information you should see where the license came from.

For floating license server you should see a note about successful checkout. 

Additional Resources

Preproduction Reconfigurable Reference Design Get Started Guide

$
0
0

Overview

Purpose of this Guide

This Get Started Guide contains instructions for running the License Plate Detection and Recognition Demo through the Configurable Platform Hub.

Prerequisites

If you have not already setup and powered on your system, please see the Setup Guide to get your system up and running before attempting to follow the steps in this Get Started Guide.

About the Kit

Based on the Intel® Deep Learning Inference Accelerator, the Preproduction Reconfigurable Reference Design combines Intel® Deep Learning Accelerator IP with FPGA hardware and the Intel® Computer Vision SDK (Intel® CV SDK) to create a complete hardware and software solution for enabling developers to accelerate deep learning applications (for example, computer vision tasks such as image recognition).

Highlights

  • Turnkey inference solution to accelerate convolutional neural networks
  • Comprehensive toolkit for developing and deploying vision-oriented solutions on Intel's platforms
  • Heterogeneous support for CPU, integrated graphics (GFX), FPGA, and other accelerators
  • Open Standard based software APIs to simplify development

Audience

Developers who have a working knowledge of computer vision, neural networks, neural network extensions and knowledge of how to use the tools from the Intel® CV SDK. Most importantly, a developer must understand how to create graphs using the Intel® CV SDK.

See the Intel® CV SDK Developer Guide for Creating a Simple OpenVX* Graph Application.

Hardware and Software Components

Below is an outline of the hardware and software components of the kit.

Hardware

  • Intel® Xeon® E3 processor
  • Intel® Deep Learning Accelerator (Intel® DLIA) card based on an Intel® Arria® 10 FPGA
  • Gigabyte* X170 motherboard
  • 32 GB Memory
  • 480 GB SATA SSD
  • 4 TB HDD

Software

  • CentOS* 7.2
  • Configurable Platform Hub
  • License Plate Recognition and Detection Demo

Neural Network Topologies

  • AlexNet
  • GoogLeNet
  • Visual Geometry Group (VGG)

Intel® CV SDK

  • Caffe*
  • OpenVX* API
  • Deep Learning Model Optimizer
  • Vision Algorithm Designer (VAD)
  • Deep Learning Inference Engine
  • Sample Applications

License Plate Detection and Recognition Demo

The purpose of this demo is to demonstrate two things: acceleration and ease of use.

  • Acceleration: We demonstrate the acceleration capabilities of the FPGA. Computationally intensive tasks (i.e., recognition tasks) better-suited for processing by the FPGA hardware are offloaded from the CPU to the FPGA.
  • Ease of Use: we show that deep learning based computer vision algorithms can be readily implemented on platforms that combine Intel® architecture with Intel® FPGA hardware.

About the Demo

The License Plate Detection and Recognition application is based on a Convolutional Neural Network trained to recognize license plates from Chinese provinces (Beijing, Shandong, Sichuan, etc.). The demo application is able to process video input from either a mounted USB camera or pre-recorded video file. Here we use a pre-recorded video file (mp4). The computer vision application presented is fine-tuned for 1080p30 video streams by default but does support other resolutions (configuration may be required).

Executing the Demo from the Configurable Platform Hub

Navigate to the Demos tab in the Configurable Platform Hub to run the license plate detection and recognition demo. If you don't already have a Firefox* browser that opened to the Configurable Platform Hub, please see the Setup Guide.

Click the Demos tab.

Click "Start" to launch the demo.

When the application launches, select “Video” under Video source and "CPU" as the hardware target. CPU implementation is done through the Caffe* framework. When you select CPU, detection and recognition are both running on the CPU.

Click on the “open” button under Video source and select the file name “fullHD.mp4” then double click to use the pre-recorded video for the demo.

The demo should now launch with the video you selected.

From the demo UI you can select either CPU or FPGA and toggle between them without having to pause the video. Select "FPGA" as the hardware target and observe how the performance metrics change.

FPGA implementation is done through the accelerator. Here, detection continues to run on the CPU but the task of recognition is offloaded to the FPGA. The most computationally intensive part of recognition (i.e., identifying symbols and characters on the license plates) are better-suited to be handled by the FPGA.

To end the demo, navigate back to the Demos tab and click "Stop".

Performance Metrics

Execution

  • Total execution time: time spent on the whole pipeline.
  • Average execution rate: frequency with which the application runs, specifically how many frames per second it processed.

Recognition

  • Total recognition time: time spent on the recognition part.
  • Average recognition rate how many license plates per second the application processed.

Where’s the acceleration?

The acceleration results when we switch to FPGA hardware (which yields faster execution times and higher framerates).

Framerate and Execution Time

Here, the pre-recorded video’s playback framerate is 30 fps. And we measure performance by framerate (measured in frames per second or fps) and execution time (milliseconds). To observe an “acceleration” in performance, we compare the performance numbers for the CPU and FPGA hardware. For detection, when we select the FPGA, notice that the Total Detection Time (ms) decreases and Average Detection Rate (fps) increases.The CPU performs the task of detection in both hardware instances but we see an increase in the framerate because the CPU now has more resources available to focus on the task of detection as recognition has been offloaded to the FPGA.

For Total Recognition Time (ms), we see that the FPGA takes less time to recognize the plates and the Average Recognition Rate (fps) increases by hundreds of frames per second. The increase demonstrates that the FPGA is capable of processing more than 30 frames per second (the playback framerate of our video). However, you would need to have more than 30 frames per second to take advantage of the higher framerate capacity of the FPGA.

Note: The demo video we present here does not present a problem that would require hundreds of frames per second as either a requirement or the solution.

Customer Support

As a Preproduction Reconfigurable Reference Design customer, you have automatically been given access to the "Deep Learning with FPGA+IA" product in Intel® Premier Support (IPS). A team of Platform Application Engineers are assigned to directly assist you via IPS where you can also track the status of all cases you file there. If you have any issues accessing IPS or accessing the correct product in IPS, your field representative will be able to assist and provide training as needed.

Using Intel® NUC and Microsoft Azure* IoT Edge to Build a Cloud-Connected Sensor Application

$
0
0

Introduction

This paper will show you how to use an Intel® NUC gateway and Microsoft Azure* IoT Edge to connect a sensor to Microsoft Azure* IoT Hub running in the Azure cloud. You'll see how to create a modular sensor application on the gateway that reads real-time sensor data, processes the data locally, and sends the data to Microsoft Azure IoT Hub where it can be stored, visualized and processed in the cloud. Processing data on the gateway allows you to use edge computing to place functionality closer to the sensor, and allows you to integrate sensors that aren't capable of directly connecting to the cloud. We'll use Node.js* and the Microsoft Azure IoT Edge SDK to perform input, processing and output functions in our application.

Setup and Prerequisites

  • Intel® NUC gateway running Ubuntu* Server 16.04 LTS operating system.
  • Node.js v6.x and NPM installed on the gateway.
  • Gateway connected to a LAN network with Internet connectivity.
  • RH-USB temperature and humidity sensor.
  • A developer workstation or laptop.
  • An active Microsoft Azure cloud account.

Connect RH-USB Sensor

The RH-USB sensor is an industrial temperature and humidity sensor with a serial interface that connects via USB. Plug the RH-USB connector into the USB jack on the front of the NUC. After that's done, Ubuntu will create a serial tty device named /dev/ttyUSB0. Confirm that the device was created by logging into the gateway as the Ubuntu user and running the following command and inspecting the output (the dash option is the lowercase letter L):
$ ls -l /dev/ttyUSB*
crw-rw---- 1 root dialout 188, 0 May 10 12:37 /dev/ttyUSB0

Give the ubuntu user read/write access to the sensor's serial device by running the following command on the gateway:

$ sudo usermod -a -G dialout ubuntu

You must log out and log back in as the ubuntu user to pick up the permission change. Use the screen program to verify the sensor is working. screen is a terminal program that allows you to type characters and view responses. Install and run screen on the gateway using the following commands:

$ sudo apt install -y screen
$ screen /dev/ttyUSB0 9600

After screen has started, press Enter and you should see the > character appear. That is the RH-USB command prompt. Type the letters PA and press Enter. You won't see the letters PA but you should see a set of digits like the following.

>50.4,72.8>

The digits are the humidity (%) and temperature (degrees F) readings from the RH-USB separated by a comma. Exit the screen program by typing Control-A followed by backslash and then typing y to confirm exiting screen.

Set up Local Server for RH-USB Sensor Data

Run these commands on the gateway to download and run the rhusb-server application which provides a local server that exposes RH-USB sensor data to other applications through a REST interface:

$ cd ~
$ sudo apt install -y git
$ git clone https://github.com/gregtoth/rhusb-server.git
$ cd rhusb-server
$ npm install
$ npm start

RH-USB server project on GitHub.

You should see status messages like the following showing the application starting and readings being received from the RH-USB sensor.

> rhusb-server@1.0.0 start /home/ubuntu/rhusb-server> node rhusb-server.js
Server running at http://127.0.0.1:4000
serial.open: Serial port opened
Serial port /dev/ttyUSB0 opened
{"time":"2017-06-13T13:24:25.906Z","temp":"72.9","humid":"57.5","valid":true}
{"time":"2017-06-13T13:24:26.910Z","temp":"72.9","humid":"57.5","valid":true}
{"time":"2017-06-13T13:24:28.141Z","temp":"72.9","humid":"57.5","valid":true}

Leave the application running in a separate terminal session on the  Intel® NUC so it can be used in the next steps.

Install  Microsoft Azure* IoT Edge Runtime

Run these commands on the Intel gateway to install the Azure IoT Edge runtime:

$ sudo apt install -y libcurl4-openssl-dev
$ sudo npm install -g azure-iot-gateway

Create Node.js* Microsoft Azure* IoT Edge Application

A Microsoft Azure IoT Edge application consists of compute modules that can be written in Java*, C, C# or Node.js. Modules are chained together to form a processing pipeline that implements the overall functionality of an application. The processing pipeline is described by a JSON metadata file that can be modified to add, remove or reconfigure the application.

Use these commands to download and prepare the source code for this application:

$ cd ~
$ git clone https://github.com/gregtoth/intel-gateway-azure-iot-edge.git
$ cd intel-gateway-azure-iot-edge
$ npm install
The main files in the application are:
  • gateway_config_rest.json— JSON metadata file that describes how the processing pipeline is to be configured at runtime. It also contains run-time configuration data such as authentication keys.
  • rhusb-rest.js— Node.js module that periodically reads data from the rhusb-rest application on the gateway in order to obtain temperature and humidity sensor readings. Incomplete or erroneous readings are filtered out and valid readings are written to the pipeline so they can be used by other modules.
  • rhusb-sim.js— An alternate Node.js module that generates simulated temperature and humidity data for testing when a real sensor is not available.
  • printer.js— Node.js module that reads sensor data from the pipeline and prints it to the console for inspection purposes.
  • iothub.js— Node.js module that connects to Azure IoT Hub and transmits sensor data from the pipeline to Azure IoT Hub where it can be further processed in the cloud.
  • gateway_config_sim.json— An alternate pipeline configuration file that uses the rhusb-sim.js module (simulated data) instead of the rhusb-rest.js module (real data).
Each of the Node.js files implement the standard Azure IoT Edge pipeline callbacks for create(), start(), receive() and destroy().

Create Microsoft Azure* IoT Hub

Before we can send sensor data to Microsoft Azure IoT Hub, we'll need to create an Microsoft Azure IoT Hub in your Microsoft Azure* cloud account. Log into Azure and navigate to the Dashboard, then create an Microsoft Azure IoT Hub by following these steps:
Click New > Internet of Things > IoT Hub and set these parameters:

Name

iothub-3982

Your IoT Hub name must be unique within Azure. Try different names until you find one that's available.

Pricing and scale tier

F1 - Free

We'll use the free tier for this application.

Resource group

MyIOT

Create a new group.

Subscription

Pay-As-You-Go

 

Location

East US

Pick a location in your geographic region.

Checkmark Pin to dashboard and then click Create. IoT Hub will deploy to your Azure account and appear on your Dashboard after a few minutes.

After it's deployed, find the iothubowner Connection string--primary key which is a text string that you'll need later. Click Dashboard > iothub-3982> Settings > Shared access policies > iothubowner and look for Connection string--primary key under Shared access keys. The string is complex, so copy and paste it for use in the next step.

Create a Device Identity in Azure IoT Hub

Before a device can communicate with Azure IoT Hub it needs to have a device identity in the Azure IoT Hub Device Identity Registry, which is a list of devices authorized to interact with your Azure IoT Hub instance.

Device identities are created and managed through REST APIs provided by Azure IoT Hub. There are different ways to use the REST APIs and we'll use an Azure open source command-line tool called iothub-explorer which is available on GitHub and NPM. iothub-explorer is a Node.js application and you'll need Node.js 6.x or higher installed on your workstation or laptop to use it.

On your workstation use these shell commands to install iothub-explorer:

$ npm install -g iothub-explorer
$ iothub-explorer help

Next we'll create and register a new device named intelnuc using the iothubowner Connection string--primary key we copied earlier from the Azure IoT Hub cloud console. Run this shell command on your workstation using your own iothubowner Connection string--primary key string inside the quotes:

$ iothub-explorer create intelnuc --login "HostName=iothub-3982.azure-devices.net;SharedAccessKeyName=iothubowner;SharedAccessKey=Be0w9Zew08x9LVAKeiseXsdf/adfe274EODo9Iwek9w=" --connection-string

After the device is created you'll see a message "Created device intelnuc" and a list of parameters for the newly created device. Locate the connectionString parameter which will have a long text string value next to it that starts with HostName=. You'll need to copy and paste this device connectionString value in the next step. The device connection string is also visible in the Azure IoT Hub cloud console.

Add Connection String to the Application Configuration

On the gateway, edit the gateway_config_rest.json file and locate the iothub section. In the args section update the connection_string value by pasting your device connectionString value in place of YOUR_CONNECTION_STRING_HERE. The updated section should look something like this:

{"name": "iothub","loader": {"name": "node","entrypoint": {"main.path": "iothub.js"
        }
      },"args": {"connection_string": "HostName=iothub-3982.azure-devices.net;DeviceId=intelnuc;SharedAccessKey=KIBi9e389f87ew7hv78ew9+/s9IIOjLKIJIedil9Qda="
      }
    }

Save the updated file.

Run the Application

Start the application on the gateway by using this command:

$ azure-iot-gateway gateway_config_rest.json

You should see messages printed on the console as the application starts up and then periodic messages containing new sensor data being sent to Azure IoT Hub. 

rhusb-rest.create
printer.create
iothub.create
Gateway is running. Press return to quit.
rhusb-rest.start
printer.start
iothub.start
iothub.connect: Connected to Azure IoT Hub
rhusb-rest query sensor: {"time":"2017-06-14T01:31:21.104Z","temp":"72.9","humid":"57.2","source":"rhusb"}
printer.receive: {"time":"2017-06-14T01:31:21.104Z","temp":"72.9","humid":"57.2","source":"rhusb"}
iothub.receive: {"time":"2017-06-14T01:31:21.104Z","temp":"72.9","humid":"57.2","source":"rhusb"}
iothub.receive: Message sent to Azure IoT Hub

On a developer workstation you can monitor messages being received by Azure IoT Hub by running this command with your own iothubowner connection string:

$ iothub-explorer monitor-events intelnuc --login "HostName=iothub-3982.azure-devices.net;SharedAccessKeyName=iothubowner;SharedAccessKey=Be0w9Zew0909LmAKeiseXsdfBadfe239EODo9iwee9w="

Each new message should look something like this:

==== From: intelnuc ====
{"time": "2017-06-14T01:31:21.104Z","temp": "72.9","humid": "57.2","source": "rhusb"
}
====================
==== From: intelnuc ====
{"time": "2017-06-14T01:31:23.103Z","temp": "72.9","humid": "57.3","source": "rhusb"
}
====================

Press Control-C to stop iothub-explorer on the developer workstation.

To stop the gateway application running on the gateway, press the Enter key. You should see messages as each of the modules run their destroy() function. When you are finished running the rhusb-server on the gateway, press Control-C to terminate it.

The simulated sensor module rhusb-sim.js works in a similar manner except that it uses simulated sensor data and doesn't require the rhusb-server application. You can run with the simulator by adding your device connection string to gateway_config_sim.json and then running the command azure-iot-gateway gateway_config_sim.json.

Where to Go From Here

This application provides the basic foundation for a modular solution to read a sensor connected to an Intel® IoT Gateway, process sensor data locally on the gateway, and send the results to the Microsoft Azure cloud. From here you could connect other types of sensors, add more processing modules and algorithms to the gateway application, integrate edge analytics, machine learning or artificial intelligence functions, configure applications to automatically run on system startup, and/or create more complex applications in the Azure cloud that process data and events received from the gateway

Python* Code Samples for Video Analytics with OpenCV

$
0
0

Video Analytics with OpenCV

Computer vision technologies for both video analytics and attribution are becoming increasingly important across a number of vertical markets. In support of computer vision development efforts, we've created a GitHub* repository of twelve computer vision code samples. These code samples are a good starting point for developers who wish to develop more robust computer vision and analytic solutions. We use the Retail, Digital Signage market in these examples but the technology can be used in a variety of different markets.

The twelve computer vision code samples have been optimized using Intel® Integrated Performance Primitives (Intel® IPP) and the Intel® Math Kernel Library (Intel® MKL). By installing these libraries and others, developers will be able to see performance improvements over the basic installation of OpenCV. Written in Python* and leveraging the Open Source Computer Vision (OpenCV) Library, developers will be able to step through the process and begin experimenting with OpenCV code samples.

Prerequisites:

Code Samples

Under the tutorials folder on the GitHub site linked below, developers will find the twelve code samples. We provide a high-level overview for the code samples and how to deploy them. It is recommended, once you’ve insured that all the pre-requisites have been met, that developers step through the code samples in a sequential order.

The twelve samples are grouped into two categories: diagnostic and application. The diagnostic samples cover setup and configuration of OpenCV to ensure everything has been installed properly, and a few basic functional tests to verify the enabled hardware acceleration features. The application samples demonstrate OpenCV building blocks to get you started on developing an end-to-end analytics application using computer vision, including features such as face detection and real-time tracking.

Diagnostic

  • OpenCV Information
  • OpenCV Build Information
  • OpenCV Image Test
  • OpenCV Video Test
  • OpenCV with OpenCL™
  • OpenCV Hardware Info

Application

  • OpenCV Video Capture
  • OpenCV Digital On-Screen Graphic (DOG) Image
  • OpenCV DOG Video
  • OpenCV Face and Eyes Detection - Still Image
  • OpenCV Real-Time Video Face Detection and Tracking
  • OpenCV Real-Time Video People Counter using Face Detection

Visit GitHub for this project's code samples

To learn more about the use of computer vision and video analytics in digital signage check out an Introduction to Developing and Optimizing Display Technology.

To install OpenCV for the tutorial samples, see Installing OpenCV for Python .

Viewing all 3384 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>