--- a/paper/chapter1.tex	Fri Dec 26 07:09:22 2014 +0900
+++ b/paper/chapter1.tex	Sun Jan 04 18:42:55 2015 +0900
@@ -1,9 +1,123 @@
 \chapter{既存のマルチプラットフォームフレームワーク}
 \section{OpenCL}
-\section{CUDA}
-\section{STAR PU}
+OpenCL とは、マルチコア CPU と GPU のようなヘテロジニアスな環境を利用した並列計算を支援するフレームワークである。
+
+OpenCL には主に2つの仕様がある。
+
+\begin{itemize}
+\item OpenCL C言語
+\item OpenCL Runtime API
+\end{itemize}
+OpenCL C は演算用プロセッサ上で動作する、 C 言語を拡張したプログラミング言語である。
+一方で OpenCL Runtime API は OpenCL C で記述したプログラムを演算用プロセッサ上で実行させるため、
+制御用のプロセッサが利用する API である。
+
+OpenCL では演算用プロセッサ側を device 、制御用デバイス側を host として定義する。
+また、 Device 上で動作するプログラムの事を kernel と呼ぶ。
+
+\subsection{Command Queue}
+OpenCL では、デバイスの操作に Command Queue を使用する。 Command Queue は Device に命令を送るための仕組みである。
+ Command Queue は clCreateCommandQueue という OpenCL API で作成され、
+ Command Queueが所属するコンテキストや実行対象となるデバイスを指定する。
+
+kernel の実行、input data への書き込み、 output data の読み込みといった
+メモリ操作はこの Command Queue を通して行われる。
+
+\subsection{メモリアクセス}
+host では主に data を input/output するメモリ資源の確保を行う。
+GPU のメモリ空間(図:\ref{fig:gpuarch})はマルチコア CPU (図:\ref{fig:cpuarch})と違い、
+共有メモリでないため host と kernel(Task)間で data の共有ができない。
+
+\begin{figure}[htpb]
+  \begin{center}
+    \includegraphics[scale=0.4]{./images/gpu_arch.pdf}
+  \end{center}
+  \caption{Gpu Architecture}
+  \label{fig:gpuarch}
+\end{figure}
+
+\begin{figure}[htpb]
+  \begin{center}
+    \includegraphics[scale=0.8]{./images/cpu_arch.pdf}
+  \end{center}
+  \caption{Cpu Architecture}
+  \label{fig:cpuarch}
+\end{figure}
+アクセスするにはメモリ空間間でコピーしなければならない。
+
+OpenCLは host 側で memory buffer を作成してメモリのコピーを行う。
+これらの処理や Task は Command Queue に enqueue することで実行される。
+\subsection{データ並列}
+多次元のデータ構造がある場合に高い並列度を保つには、それを分割して並列に実行する機能が必要である。
+データ並列実行という。OpenCLはデータ並列実行もサポートしている。
+OpenCL は次元数に対応する index があり、 OpenCL は一つの記述から異なる index を持つ複数の kernel を自動生成する。
+その添字を global\_id と呼ぶ。この時入力されたデータはワークアイテムという処理単位に分割される。
+
+OpenCL はワークアイテムに対してそれぞれを識別する ID ( global\_id )を割り当てる。
+kernel は get\_global\_id API によって ID を取得し、取得した ID に対応するデータに対して処理を行い、
+データ並列を実現する。
+この ID によって取得してきたワークアイテムをグローバルワークアイテムという。
+また、ワークアイテムは3次元までのデータを渡すことができる。
+
+データ並列による kernel 実行の場合は clEnqueueNDRangeKernel API を使用するが、
+この関数の引数としてワークアイテムのサイズと次元数を指定することでデータ並列で実行できる。
+
+\subsection{ワークグループ}
+前節でワークアイテムという処理単位について述べたが、
+さらに複数個のグローバルワークアイテムを work\_group という単位にまとめることができる。
+work\_group 内では同期やローカルメモリの共有が可能となる。
+
+グローバルワークアイテム(ワークアイテム全体)の個数と、
+ローカルワークアイテム(グループ一つ辺りのアイテム)の個数を指定することでワークアイテムを分割する。
+なお、このときグローバルワークアイテム数はローカルアイテム数の整数倍でなければ
+clEnqueueNDRangeKernel API 呼び出しは失敗する。
+
+ローカルアイテム数は0を指定することで、コンパイル時に最適化させることができる。
+したがってローカルアイテムのサイズは0を指定するのが一般的である。
+
+なお、 work\_group を設定した場合は global\_id の他に work\_group\_id 、local\_id が
+それぞれの kernel に割り当てられる(図:\ref{fig:workitem_id})。
+
+\begin{figure}[htpb]
+  \begin{center}
+    \includegraphics[scale=0.65]{./images/workitem.pdf}
+  \end{center}
+  \caption{WorkItem ID}
+  \label{fig:workitem_id}
+\end{figure}
+
+なお、work\_groupを設定した場合はglobal\_idの他にwork\_group\_id、local\_idが
+それぞれのkernelに割り当てられる(図:\ref{fig:workitem_id})。
+
+kernel 側からそれぞれ ID に対応した API を使用して、各 ID を取得する。
+取得した ID から自分が担当する index を計算して導く。
+表:\ref{table:kernel_id_api}は kernel 側で使用できる、 ID を取得するための API となる。
+\begin{tiny}
+  \begin{table}[htpb]
+    \begin{center}
+      \label{table:kernel_id_api}
+      \small
+      \begin{tabular}[htpb]{c|l}
+        \hline
+        get\_group\_id & work\_group\_id を取得  \\
+        \hline
+        get\_local\_id & local\_id を取得 \\
+        \hline
+        get\_global\_id & global\_id を取得 \\
+        \hline
+      \end{tabular}
+      \caption{kernel で使用する ID 取得の API}
+    \end{center}
+  \end{table}
+\end{tiny}
+なお、 local\_id 、global\_id を取得する API は引数に0、1、2の値を set することができる。
+id は x, y, z 座標があり、それぞれが 0, 1, 2 に対応している。
+例えば get\_global\_id(1) と呼び出した場合は y 座標の、
+get\_global\_id(1) と呼び出した場合は z 座標の global\_id を取得する。
 
 
 
 
 
+
+

--- a/paper/introduciton.tex	Fri Dec 26 07:09:22 2014 +0900
+++ b/paper/introduciton.tex	Sun Jan 04 18:42:55 2015 +0900
@@ -1,5 +1,22 @@
 \chapter{研究目的と背景}
 \pagenumbering{arabic}
+% 動画の編集や再生、ゲームといったPCやタブレット等の端末でできる事・やりたい事が増えてきている。
+
+　PCやタブレットの一般的な利用方法として動画の編集や再生、ゲームといったアプリケーションの利用が挙げられる。
+これらのアプリケーションはグラフィックや音質といった点から要求する処理性能が上がってきている。
+
+しかし消費電力や発熱、クロックの限界からCPUの性能自体を上げることによる処理性能の向上は不可能となっている。
+その事からプロセッサメーカーはマルチコアやヘテロジニアス構成の路線を打ち出している。
+そういったアーキテクチャ上でリソースを有効活用するにはプログラムの並列化は必須と言える。
+
+しかしプログラムを並列化するのみではリソースの有効活用としては不充分であり、
+実行の順番やタスクをどのリソース上で実行するかといったSchedulingも行わなければならない。
+こういった部分をサポートするプログラミングフレームワークが必要である。
+
+当研究室ではCeriumというプログラミングフレームワークを開発している。
+Ceriumをマルチプラットフォームに対応させ、高い並列度を維持したプログラミングを可能にする。
+本研究ではマルチプラットフォーム上でのプログラムの実行における最適化について、
+Sort、Word Count、FFTを例題に考察していく。
 
 \newpage
 

Binary file paper/master_paper.pdf has changed