スポンサード リンク

T.Ishii's Software Library

HTML5 レトロ風ゲーム館

無料ブログはココログ

« 映像の拡大・縮小 | トップページ | 色々とやれるのだが »

ソフト処理の方が速い

今は、Mac用AGMPlayerの開発フェーズで、まず、AGM⇔MP4変換用コマンドラインツールを作成しているのだが、追加機能として、映像の拡大・縮小機能も実装する事にして、OS XのGPU処理が可能なAPIを試してみたのだが、CPUで処理させた方が高速になった。

Macで画像を扱おうとしてネット検索すると、微妙に名前が異なるクラスが幾つも出て来る。

具体的には、NSImage / UIImage / CGImage / CIImageになるのだが、この中で、UIImageというのは、iOS専用で、NSImageというのは、Mac専用になる。

なので、Macで画像を扱おうとすると、NSImage / CGImage / CIImageクラスを使い分ける事になるのだが、GUIに関連して良く使われるのは、NSImageになる。

つまり、Macにおける画像データの基本はNSImageという事になるのだが、APIドキュメントによると、NSImageというのは、high-level Interface、という事になっている。

このため、一般アプリでは、目にする事も多いのかもしれないのだが、CGImageというのは、APIドキュメントによると、A bitmap image or image mask、という事になっているので、単に画像を扱う場合には、CGImageの方が単純で望ましいのかもしれない。

で、残ったCIImageについては、APIドキュメントには何と書かれているのか、というと、A representation of an image to be processed or produced by Core Image filters、という事になっている。

と、いう事で、CIImageというのは、何か毛色が違う訳なのだが、GPUを使って画像処理を行おうとする場合には、このCIImageを使う事になる。

なので、やってみたのだが、まず、CIImageを作成する為には、CGImageが必要になるのだが、CGImageはメモリ上のRGBデータから作成可能だ。

現在作成中の変換ツールの映像データは、変換中には単純なメモリデータになっているので、映像の拡大縮小用にCIImageを使う場合には、メモリ→CGImage→CIImageの順で作成する事になる。

CIImageが作成できると、その拡大縮小処理は1行で書けるのだが、処理結果は、また、メモリ上に持ってこないと使えないので、変換後はCIImage→CGImage→メモリの順にデータを変換しつつ取得する事になる。

と、いう事で、これだけの変換が必要になる事を鑑みても、OSのAPIを使って映像の拡大縮小を行おうとすると、何となく、遅そうな訳なのだが、実際には、CGImage→CIImageの変換時には、映像データはCPUメモリからGPUメモリにコピーされる。

また、CIImage→CGImageの変換時には、逆にGPUメモリからCPUメモリにデータはコピーされるので、これらの変換には、見た目以上の処理時間がかかる訳だ。

もっとも、CIImageの変換処理はCPUで行わせる事も可能で、その場合には、変換処理にCPUが使われるので不利になる反面、前述のデータコピー処理は発生しないので、その分は有利になる。

と、いう事で、15分のAGM形式フルHD動画を854x480のDVD画質に縮小してMP4形式にエンコードする場合の処理時間を計測してみたのだが、以下の様になった。

縮小にCIImage(GPU)を使用した場合:6分40秒

縮小にCIImage(CPU)を使用した場合:4分24秒

縮小に自前ルーチン(シングルスレッド)を使用した場合:6分56秒

上記を見ていると、表題にした様に、GPUに処理させるよりは、CPUに処理させた方が、全然、高速な訳だ。

もっとも、GPUを使用させた場合のCIImageも、自前のCPUを使った縮小ルーチンを使うよりは高速に処理が終わっているので、使えないほど遅いという事はない。

ただし、この自前の縮小ルーチンは、テスト用にAmuseGraphicsで画像処理用に使っている速度よりは画質なモノを使ってみていて、なおかつ、シングルスレッド動作なので、処理速度的には、CPU処理の中でも低速な部類に入るかもしれない。

ちなみに、CIImageの本来の用途は、画像に様々なフィルター処理を施す事だ。

画像の拡大縮小というのも、フィルター処理の一つではあるので、CIImageで行える訳なのだが、これらの処理はフィルター処理の中では、まだ、軽い部類に入る。

なので、CPUで処理させた方が総合的には高速になったのだが、試しに、CIColorControlsというフィルターを使ってみた所、CPU処理よりもGPU処理の方が高速になった。

そして、今回は、CIImageの処理結果をCPUメモリ空間に戻しているのだが、処理結果をそのまま表示する場合には、この分のオーバーヘッドは無くなるし、逆に、CPU処理した場合には、その結果をGPUメモリ空間に転送する必要が生じるので、CPU処理のオーバーヘッドは増加する。

なので、画像の拡大縮小についても、映像を画面表示する場合には、GPUに処理させた方が高速化される様な気がするのだが、動画ファイルの変換の様に、変換結果を描画しない場合には、拡大縮小の様な比較的軽いフィルター動作については、CPUで処理させた方が高速になる様だ。

« 映像の拡大・縮小 | トップページ | 色々とやれるのだが »

トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/534482/64571916

この記事へのトラックバック一覧です: ソフト処理の方が速い:

« 映像の拡大・縮小 | トップページ | 色々とやれるのだが »

2017年6月
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30  

広告

プライバシーポリシー

  • 当サイトでは、第三者配信による広告(Google Adsense)サービスを利用しています。

    Google を含む第三者配信事業者は、Cookie を使用して、ユーザーのウェブサイトでの閲覧履歴に基づく広告を配信します。 Google 広告 Cookie を使用することにより、Google や Google のパートナーは当サイトや他のサイトへのアクセス情報に基づく広告をユーザーに表示できます。

    Cookieを無効にする設定およびAdsenseに関する詳細については、以下のリンクを参照下さい。

    広告 - ポリシーと規約 - Google