REPORT: Commit message to change

report/source/sections/work.tex

@@ -3,9 +3,9 @@
 
 \subsection{Build of the runtime}
 The first challenge to tackle was the retrieval and compilation of the OpenCL runtimes.
-The runtime for the Mali GPU is already provided in the Hardkernel repository, so a simple \lstinline{sudo apt-get install mali-fbdev} does the trick.
+The runtime for the \textbf{Mali GPU} is already provided in the Hardkernel repository, so a simple \lstinline{sudo apt-get install mali-fbdev} does the trick.
 For what concenrs the Pocl runtime instead we need to start from scratch.
-The first thing to do is to retrieve the last version of the OpenCL runtime (curenntly version 0.14) from the \href{http://portablecl.org/downloads/pocl-0.14.tar.gz}{website}.
+The first thing to do is to retrieve the last version of the OpenCL runtime (currently version 0.14) from the \href{http://portablecl.org/downloads/pocl-0.14.tar.gz}{website}.
 The next thing to do is to decompress the archive of with simple \lstinline{tar xvfz pocl-0.14.tar.gz}.\\
 Pocl take adavante of \textbf{LLVM} to build itself, so we need to install a few dependencies from the package manager before being able to compile it. We can find at the \href{http://portablecl.org/docs/html/install.html}{dedicated page} on the official wiki a list of all the packages needed for the build. Basically we need LLVM and a bunch of development package of it, CMake to build the Makefiles, the standard utilities for compiòing (gcc, lex, bison), and some packages to have an Installable client driver (ICD) to be able to load the appropriate OpenCL at runtime.\\
 What we need to do on our system is basically:
@@ -13,15 +13,12 @@ What we need to do on our system is basically:
 \begin{lstlisting}
 
 sudo apt-get update && sudo apt-get upgrade -y
-sudo apt-get install -y vim build-essential flex bison libtool\
-libncurses5* git-core htop cmake libhwloc-dev libclang-3.8-dev\
-clang-3.8 and llvm-3.8-dev zlib1g ocl-icd-libopencl1 clinfo\
-libglew-dev time gnuplot clinfo ocl-icd-dev ocl-icd-opencl-dev\
-qt4-qmake libqt4-dev libusb-1.0-0-dev
+sudo apt-get install -y vim build-essential flex bison libtool libncurses5* git-core htop cmake libhwloc-dev libclang-3.8-dev clang-3.8 and llvm-3.8-dev zlib1g ocl-icd-libopencl1 clinfo libglew-dev time gnuplot clinfo ocl-icd-dev ocl-icd-opencl-dev qt4-qmake libqt4-dev libusb-1.0-0-dev
 
 \end{lstlisting}
 
-At this point can proceed and build Pocl. To to that we enter the directory with the sources and create a folder called \textit{build} in which we will have all the compiled stuff. At this point we take advantage of CMake for actually preparing our folder for the build. Usually a \lstinline{cmake ../} should suffice, but on the ODROID we have a little problem. Since our CPU is composed of four cortex a7 and four cortex a15 cores, CMake can't by itself understand what is the target CPU to use for the build. Luckily the two types of cores shares the same ISA, so we can explicitly tell CMake to use the cortex a15 as a target type of cpu. All we have to do is to launch \lstinline{cmake -DLLC\_HOST\_CPU=cortex-a15 ../}.\\
+At this point can proceed and build Pocl. To to that we enter the directory with the sources and create a folder called \textit{build} in which we will have all the compiled stuff. At this point we take advantage of \textbf{CMake} for actually preparing our folder for the build. Usually a \lstinline{cmake ../} should suffice, but on the ODROID we have a little problem.\\
+Since our CPU is composed of four cortex a7 and four cortex a15 cores, CMake can't by itself understand what is the target CPU to use for the build. Luckily the two types of cores shares the \textbf{same ISA}, so we can explicitly tell CMake to use the cortex a15 as a target type of cpu. All we have to do is to launch \lstinline{cmake -DLLC\_HOST\_CPU=cortex-a15 ../} .\\
 At this point we are ready for the build, just type \lstinline{make -j8} and we are done. At this point we can run some tests with \lstinline{ctest -j8} just to be sure that everything went smooth, and finally install the runtime in the system with \lstinline{sudo make install}. At this point if everything went fine we will have a \lstinline{pocl.icd} file in \lstinline{/etc/OpenCL/vendors/}, and running \lstinline{clinfo} we should be able to see our brand new OpenCL runtime.\\
 
 Additionally in order to be able to use the runtime for the Mali GPU we additionally need to place a file containing:
@@ -43,7 +40,8 @@ In bash commands:
 \end{lstlisting}
 
 At this point we should switch to the \textbf{no\_qt} branch with a simple \lstinline{git checkout no_qt}. In this branch all the non essential dependencies to Qt libraries have been removed, in order to avoid cluttering the board with the full KDE framework for just storing an integer representing the consumption.\\
-Unfortunately the HIDAPI library provided with the sources of the utility has been already compiled for x86 and stored in the repository, causing an error when trying to link the utility. To avoid this we need to recompile the library, by entering the HIDAPI folder and giving the following commands:
+Unfortunately the HIDAPI library provided with the sources of the utility has been already compiled for x86 and stored in the repository, causing an error when trying to link the utility.\\
+To avoid this we need to recompile the library, by entering the HIDAPI folder and giving the following commands:
 
 \begin{lstlisting}
   qmake
@@ -71,8 +69,10 @@ SUBSYSTEM=="usb", ATTRS{idVendor}=="04d8", ATTRS{idProduct}=="003f", MODE="0666"
 Reached this point we should be able to take power measurements. To test it simply launch the \textbf{SmartPower} binary with as argument the file in which you want to store the results, let it run for a while and then stop it with a \textbf{SIGUSR1} signal. In the file you should find the power consumption (double check it with the display of the power measurement device). Also take into account that there is a known bug with the software, meaning that sometimes the utility is not able to retrieve the consumption and the process become a zombie process in the system. Take into consideration this if you have trouble in taking measurements.
 
 \subsection{Build of the benchmarks}
-For what concerns the benchmarks, we start from the vanilla Rodinia 3.1 benchmark suite, taken directly from \href{http://lava.cs.virginia.edu/Rodinia/download.htm}{the site} of Virginia University (you need to register on the site, and then you'll receive via mail a link to the real download page).
-Unfortunately the benchmarks are not ready for running. Some of them presents some bugs, and you need to actually apply a lot of fixes and modifications to successfully run them on the ODROID. Since the modifications are really big (I estimate that making the benchmarks usable has in fact taken most of the time of the development of the project), I opted for creating a repository that I initialized with the sources of the benchmarks and on which I worked. You can find the repository at \href{http://gogs.heisenberg.ovh/andreagus/rodinia-benchmark.git}{this url}. There are multiple branches on the repository since I worked in parallel on CPU and GPU benchmarks to make them work, and later I tried to merge all the results in a single branch to use for the benchmarks.\\
-In addition to bugs and other problems the main difficulty was that the creator of the benchmarks hardcoded in the source the OpenCL platform, device and type of device to use. This meant that if you wanted to run benchmarks on different OpenCL devices you had to manually modify the source, recompile the benchmark and run it. At the beginning of the development I also followed this approach and specializing a different branch for running the bencharks on CPU or GPU.\\
-But this approach bugged be since the main advantage and the ultimate goal of having and OpenCl application should be to be able to run it on different devices and accelerators with the minimum effort possible. So in the end I modified heavily the benchmarks in order to take as parameter the platform, the device and the type of device to use. I then added different run scripts that contain the right parameters for each available device.\\
-In this way we compile the benchmarks once, and then at runtime we select the platform and device to use. The selection simply implies to use the \lstinline{run-cpu} or \lstinline{run-gpu} script. In this way we have the more \textit{transparent} interface as possible.
+For what concerns the benchmarks, we start from the vanilla \textbf{Rodinia 3.1} benchmark suite, taken directly from \href{http://lava.cs.virginia.edu/Rodinia/download.htm}{the site} of Virginia University (you need to register on the site, and then you'll receive via mail a link to the real download page).
+Unfortunately the benchmarks are \textbf{not ready for running}.\\
+Some of them presents some bugs, and you need to actually apply a lot of fixes and modifications to successfully run them on the ODROID. Since the modifications are really big (I estimate that making the benchmarks usable has in fact taken most of the time of the development of the project), I opted for creating a repository that I initialized with the sources of the benchmarks and on which I worked.\\
+You can find \textbf{the repository} at \href{http://gogs.heisenberg.ovh/andreagus/rodinia-benchmark.git}{this url}. There are multiple branches on the repository since I worked in parallel on CPU and GPU benchmarks to make them work, and later I tried to merge all the results in a single branch to use for the benchmarks.\\
+In addition to bugs and other problems the main difficulty was that the creator of the benchmarks \textbf{hard-coded} in the source the OpenCL platform, device and type of device to use. This meant that if you wanted to run benchmarks on different OpenCL devices you had to manually modify the source, recompile the benchmark and run it. At the beginning of the development I also followed this approach and specialized a different branch for running the bencharks on CPU or GPU.\\
+But this approach bugged me, since the main advantage and the ultimate goal of having an OpenCL application should be to be able to run it on different devices and accelerators with the minimum effort possible. So in the end I modified heavily the benchmarks in order to take as parameter the platform, the device and the type of device to use. I then added different \textbf{run scripts} that contain the right parameters for each available device.\\
+In this way we \textbf{compile} the benchmarks \textbf{once}, and then at runtime we select the platform and device to use. The selection simply implies to use the \lstinline{run-cpu} or \lstinline{run-gpu} script. In this way we have the more \textit{transparent} interface as possible.