Windows上のターミナルを以前はMinGW+minttyを使用していましたが、タブが使えるConEmuの方が便利で使いやすいと知ったので、乗り換えました。
MinGWでの開発環境の設定については以下のサイトを参考にしました。
PENGUINITIS - MinGW 64 bit 版 のセットアップ
設定が細かくできるようですが、とりあえず上のサイトで紹介されている設定を流用させていただきました。
起動も速く、軽くて快適です。
２０１６年８月１６日追加情報です。
"MSYS2で快適なターミナル生活"というmsys2の紹介ページがありましたので、こちらも参考にするといいです。
qiita.com
2017年6月12日 リンク先がなくなっていたので削除し、minGWでの開発環境設定のページへのリンクを追加しました。
ついにProcessing3.0の正式版がリリースされましたので早速導入しました。
以前からのバージョンと同じで、インストーラーなどは必要なく解凍して実行ファイルを実行するだけです。
ただし、前から使っていた方は以前の環境設定ファイルを読み込んでくれます。
前にも書きましたがちょっとした実験やrapid prototypingにProcessingを使おうと思っていますので、私が今興味のある画像処理関係について簡単に触れるようにするためにOpenCVを追加で導入することにしました。
Processingの Tools -> Add toolでLibrariesやModes, Toolsなどが簡単にインストールできますが、Librariesの中にあるOpenCVはここからはインストールできなかったので（2015/10/3時点）手動でインストールしました。
やり方は以下のブログをみました。tkitao.hatenablog.com
ブログに書いてある通りに解凍して、ファイルをコピーするだけですので、簡単ですね。
導入したOpenCV for Processing のバージョンは0.5.2です。
さらにWEBカメラの映像をリアルタイム処理したいので、Videoライブラリーもインストールしました。
こちらは、Tools -> Add tool-> Librariesでvideoで検索して出てきた"GStreamer-based video library for Processing."をインストールしました。
さっそくOpneCVのサンプルを動かしてみます。
まずは、BackgroundSubtractionサンプルです。
このサンプルは、BackgroundSubtraction.pdeをダブルクリックしてProcessingを起動後、実行するとdataフォルダーの中にある動画street.movにフレーム間差分処理をした結果が表示されます。
OpenCVを使用しているのは、ソースコードは非常に短いですが処理の大部分がブラックボックスになってしまっています。
さらに、WEBカメラを使用しているサンプルを動かしてみます。
LiveCamTestというサンプルがそれっぽいので、起動するとWEBカメラからの映像が表示され、顔のエリアに緑色の枠が表示されます。
faces = opencv.detect();
の部分がおそらく顔認識なのでしょう。
ＵＳＢドライバも正しくインストールして、さらにデバイスマネージャーからもスマホやタブレットがきちんと見えているのに、Android StudioからRunボタンを押すと、エミュレーターが立ち上がっってしまい、実機実行できないことがあります。
これは、実行の設定がEmulatorになってしまっているためです。
設定メニューの Run -> Edit Configurationで、
General -> Target Device の設定を USB Device もしくは Show chooser dialog
にする必要があります。
何かの拍子でEmulatorの設定にしてしまうと、結構はまりますのでご注意ください。
私も何度もはまって、必要のないＵＳＢドライバのアンインストールとインストールを繰り返してしまいました。
このサイトから、サンプルをダウンロードしてみた。
Samples: Overview | Android Developers
include fileへのパスがつながっていないみたいでビルドできない。
#include
#include
などのところでエラーがでる。
build.gradle を編集すればよさそうな気もするがよくわからない。
前回の記事で、Eclipse + ADT からAndroid Studioに移行をもくろみうまくいきませんでした。
その後しばらく放置していましたが、最近また触り始めました。
いくつか設定が必要なことに気づきました。
File->Other Settings->Default Project Structure->SDKs
でJAVA SDKのパスを正しく設定しないといけないです。
ついでにこのメニューでＮＤＫもインストールしました。Eclipse + ADTの時にはＮＤＫも手動で設定が必要だったのですが、Android Studioではそういう面倒なことは必要ないようです。
また、各プロジェクトで
'File' -> 'Project Structure'->'Modules'で Module SDK のNEWを押して、例えばAndroid 4.4などを指定しなければいかなかったです。
上記設定で、以下のサイト置いてあったGLESのサンプルが実機で動きました。
Displaying Graphics with OpenGL ES | Android Developers
Khronosグループが発表している、2015年8月時点で最新のVulkan Overviewを読んでみました。
https://www.khronos.org/assets/uploads/developers/library/overview/vulkan-overview.pdf
※ Khronosグループとは、OpenGL/ES, WebGLといったGraphics APIのオープンスタンダードを手掛ける非営利の共同コンソーシアムで、日本の企業も参加しています。
Vulkanの特徴
いろんなデバイスにＧＰＵが乗るようになってきた。
ＧＰＵは３Ｄグラフィックスだけのためじゃなくなってきた。
じゃあ、そのＧＰＵを効率的に使えるようにしないといけない。
Vulkanはlow-overheadで多くのベンダーのＧＰＵをサポートする。
mobile, desktop, console, embedded platformすべてで同一のＡＰＩを提供
デバッグ、評価のレイヤーと最終製品レイヤーを分けられる。
OpenGL/ES とVulkanとの大きな違い
OpenGL/ES
複雑なドライバＧＰＵドライバ層、overheadが大きい、負荷の予想ができない
ドライバがＧＰＵコンテクスト保持・更新、メモリーマネジメント、エラーマネジメントすべてを行う。
エラーマネジメントが常に動いている（安全ともいえる）
APIはGLとESで、デスクトップとモバイル用に分かれている
Vulkan
メモリマネジメント、スレッドマネジメント、コマンドバッファの生成・更新のすべてをユーザーアプリが行う。
ドライバはシンプルになり、low-overhead。
エラーマネジメントは必要な時だけ動かせる。
モバイル、デスクトップ、組み込み機器のすべてで同じＡＰＩを使用
上記特徴を知ったうえで、開発者はGL/ESを使うか、Vulkanを使うかを選択できる。
ミドルウェア、エンジン
ユーザーアプリとVulkanの中間にミドルウェアやゲームエンジンなどが入ることがあり、これらのエンジンがハードウェアをダイレクトに操作することで処理速度が向上する。
Vulkanのmulti-threading
コマンドバッファ作成スレッドと、コマンドを投げるスレッドを別々に並列に実行できる。ＧＰＵがＣＰＵを待つことなく次々とコマンドを受け取ることができるようになる。
SPIR-Vという中間言語が提供される。
３ＤグラフィックスＡＰＩとして、２大勢力がOpenGLとDirectXがあります。
DirectXはマイクロソフト、でOpenGLはクロノスグループがそれぞれ作成・アップデートを行っています。
これらのGraphics APIは、ハードウェアであるＧＰＵの違いを吸収しいろいろなハードでプログラムが動作するように、ハードウェアを抽象化するような分厚い中間レイヤーを持っています。
そのおかげで、異なるＧＰＵを積んでいるような様々なＰＣで同じコードが動作するようになっています。
しかし、便利な反面、ＡＰＩコールのオーバーヘッドが大きくなり、実行速度が遅くなる場合があります。
例えばDraw call一つとっても、異なるＧＰＵに合わせて多くのコンテキストの設定が必要になりますが、それらはＧＰＵの負荷ではなくＣＰＵの負荷として、効いてきます。
つまり、Graphics APIのＣＰＵ負荷が無視できないくらい大きいのです。
Xboxやプレステ, Wiiなどのゲーム機では、このグラフィックスＡＰＩのオーバーヘッドが軽く作ってあり、ハードに最適化したプログラムが書けるようになっています。対象となるハードが１種類なのでこのようなことができるのです。
もちろん、ＧＰＵ内のシェーダーやＧＰＵ内部の処理がネックになっている場合はＡＰＩのオーバーヘッドが変わっても実行速度が変わることはありません。
余談ですが最近目にしたLow overhead APIの記事でもＧＰＵの処理を軽くするような記述がありました。あくまでGraphics APIの持つ、ＣＰＵのoverheadの軽量化が主で、ＧＰＵ処理の最適化はまた別の話です。誤解しやすい点ですので注意しましょう。
前置きが長くなりましたが、最近このＡＰＩのオーバーヘッドが低いLow layerのGraphics APIがあちこちから発表されています。
DrectXは、DirectX12
OpneGLは、Vulkan
また、AndroidもVulkanをサポートするとGoogleから発表されています。
Low-overhead rendering with Vulkan | Android Developers Blog
Appleは、Metal
AMDはMantleという名前で独自のAPIを発表しています。
http://www.amd.com/ja-jp/innovations/software-technologies/technologies-gaming/mantle#
この中で、Mantleに関してはかなり前に発表されたのですが、今はあまり話題になっていません。
現状ではDirectX12とVulkanがメジャーになりそうな予感です。
Metalに関しては、よくわかりません。
とくにDirectX12は、Windows10に合わせてリリースされたこともあり話題になっていますが、最初に書いたようにLow OverheadのAPIというのは、速度が速いといういい面だけではなく、
ハードに合わせた記述をしないと最悪ハングしたり、うまく速度が出なかったり、プログラマの力量がそのまま出てしまう面がありますし、移植もやりにくくなるのではないかと思われます。
