ブログランキング・にほんブログ村へ


iPhone/iPad用潜水艦ゲームアプリ ソナーエコー iTunesにて公開中

2012年06月20日

2次ベジェ曲線の点

頻繁にテクスチャの文字を生成するのが処理速度の負担になるようなので、文字表示の方法を変更してみる。

ちょうど自分で作った手書きのANKのフォントのベクタデータがあったので、それを使って線を引くようにしてみた。
まぁこれはこれで軽いとはいわないが、テクスチャを作る処理がなくなったので風通しは良くなった気がする。

それでそのフォントのデータがもともとフラッシュ用だったので2次ベジェ曲線で記述されていた。それを自力で展開。

2次ベジェ曲線の中間点を得る関数。

void getBezier2Point( float p0x,float p0y,float p1x,float p1y,float p2x,float p2y,float t,float* rx,float* ry ){
// p0,p1,p2から成る2次ベジェの媒介変数(0<=t<=1)の時の座標を得る。

float ox = 0;
float oy = 0;

float tmp = (1-t) * (1-t);
ox += tmp * p0x;
oy += tmp * p0y;

tmp = 2 * t * (1-t);
ox += tmp * p1x;
oy += tmp * p1y;

tmp = t * t;
ox += tmp * p2x;
oy += tmp * p2y;

*rx = ox;
*ry = oy;
}
posted by みこあいさ at 11:44| C++

2012年04月20日

CUDA GPU 並列処理

OpenMPはCPUに並列処理させる仕組みだったが、CUDAはGPUにそれをやらせる仕組み。NVidiaが作ってる?らしい。

面白いのは、GPUに渡すコードをCの構文で直接ソースコードに書けること。GPUは並列処理得意中の得意なので、それを描画以外の処理に使っちゃおう、ということだ。

CUDA入門・サンプル集

CUDA(Wiki)

試してないのであまり大したことは書けないが、コストとしてGPUに演算に必要なデータを送り送られする処理、(おそらく)実行時にGPUに実行コードを転送する処理分が上乗せされるので、それなりに重い処理をできるだけまとめてやらせるのがよいと思われる。
あとこれは推測だが、GPUはCPUではないので、あまりでかい処理をするのは制約があるのではなかろうかと思う。
関数はホスト(CPU)側を呼び出す仕組みはあるようだが、あまり頻繁にCPUを呼び出しているとそこで排他処理が入ってGPUで超絶並列処理をしている意味が相当低下するだろう。
そのため、ある程度の関数はGPU側で用意してくれているようだ。
例えばすぐ思いつくのは数学関数だが、三角関数sinは
__sinf
はデバイス(GPU)側で処理される(SFUというGPUで処理される高速な数学関数)関数らしい。


なんとなくFM-8とか7のサブCPUのことを思い出した自分は古い人間なんだろうな。
posted by みこあいさ at 16:26| C++

OpenMP マルチコア マルチスレッド 並列処理

最近のCPUはマルチコア流行りである。
マルチコアにあらずんば人(CPU)に非ず、といった空気さえある。
マルチコアといえばなんだかかっこいいかもしれないが、要するにCPU1コアのクロックアップが難しいから並列化することでこれをなカバーしようということである。
4コアにしなくてもCPUのクロックを4倍にして、従来のインタラプトでスレッド処理すれば同じ効果が得られるのに、それはもうできないってことだ。
ペンティアムの33Mhzあたりから始まったクロックアップインフレ時代は終焉を迎えたということなのかもしれない。

ないものは仕方がない。マルチコアをパフォーマンス改善のために使うようにプログラマが積極的に対応していくしかない。
そんなマルチコア(スレッド)を便利に使う仕組みというのが色々考案されていて、表題のOpenMPもその1つ。
だいぶ前になるが自分はWindows Visual C++ 2005で使った。

色々使い方があるが、一番簡単に使えるのは

#include <omp.h>
:
:
#pragma omp parallel for
for( int i=0;i<n;i++ ){
job( i );
}

とやると、
job( 0 );
job( 1 );
job( 2 );
:
:
job( n-1 );
をスレッド(コア)に適当に割り振ってうまいこと並列処理してくれる仕組みだ。この仕組みをLinuxのptheradとかWindowsのCreateThreadで書くことを考えたら、どんだけこれが便利かわかろうというもの。

ただ、自分が試したときは、まだ本物のマルチコアがあまり市場に出回ってなくてハイパースレッディングの時代だった。ハイパースレッディングだと、妙なウエイトがかかってOpenMPの並列処理がきちんと並列にならず、実行速度の向上につながらなかった。その証拠にほんとうのマルチコアCPU(たしかその当時のAMD CPU)ではちゃんと速くなった。

上の例ではもし将来100コアCPUというものができてn=100なら、job(0)〜job(99)は一斉に開始され、一回もループ処理はされないことになる。それは速そうだ。


将来的に技術が革新されて再び大幅なクロックアップが始まることもあるかもしれないがそれまではコアが増えるだけの時代が続くのだろうか。

もしこの先1000コアとか1万コアとかいう時代がきたら、コーディングスタイルやプログラムの記述概念は根底から変わってしまうような気がする。例えば1ピクセルごとに1コアCPUが付いている液晶ディスプレイとか。
シリコンチップのまま光学コンピュータとか量子コンピュータとかの世界に近寄って行くのだろうか?

みてみたいようなそうでないような。
posted by みこあいさ at 15:52| C++