OpenCL with OpenCV (OpenCV-CL)を使ってみた．
ここに “””つらみ””” があります．
環境を統一しようにもなかなか険しいものがある．(NvidiaのOpenCLはCUDAのドライバ入れれば動く…？)
世界に試されている．
でも今出先なので（＝Geforceを積んでいるデスクトップ環境が使えないので），ノートPC上でできる環境を適当に決めて実装しないと無限に「グレブナ基底と代数多様体入門Ⅰ」を読んでしまう．無限に某ーロッパ企画のゲームをプレイする某員長の動画を見てしまう．
色々と考えた結果，OpenCVの環境作ればOpenCLが使えるらしいことを知って，じゃあこのOpenCL使ったらいいか，という気持ちになった．
OpenCVは全体的にドキュメンテーションに難があってほとんど参考にならないが，神先駆者様がいたのでこれをほとんどコピペでとりあえずサンプルコードを動かしてみた．
とりあえずサンプルは動いたが今後手を加えていくとうまくいかなくなるかもしれないのでしばらく様子見．
カーネルコードをロードしてコンパイルするあたりでRustのシャドーイングを使いたくなったが残念ながらこれはC++なのでそうは問屋が卸さない．
世界中のスクリプトがすべてRustに置き換わらないかな．
せめて世界中の言語がすべて強い静的型付き言語にならないかな．
RustからC++を呼び出すこともなんとなく考えたが，参考サイトに
“C++ exceptions can mostly be caught in D, but that’s not a thing in Rust at all. “
とあって，確かになぁ…という気持ちになった．
ただでさえセーフな言語からアンセーフな言語を呼び出すのは厳しいのに，エラーハンドリングのやり方などの言語仕様も異なるとなると，考えることが増えそう（曖昧）．
コードの印象としては，カーネルコードのロード，コンパイル，呼び出しの流れはPyOpenCLのほうが若干すっきりしていた気がする．（以前書いたPyOpenCLではホストコード中にカーネルコードを書いていたのに対し，今回は別ファイルにカーネルコードを書いているため，ファイルを読み込む処理が追加されているため煩雑に感じるのかもしれない）．
カーネルコードの引数指定の部分は知らないと絶対にわからない仕様（詳しくは参考サイト様参照）なのにドキュメンテーションには記載が見当たらなかったので，このあたり敷居が高いなと感じた．
今回のコードで少し不思議に感じたのは，フレームのグレースケール画像（gray）が更新されたときにデバイスのバッファ(d_frame)へデータを送らなくてもちゃんと更新が反映された点．UMatは今回の例のように直接imshowに渡せるようだし，情報の受け渡しはOpenCV側がやってくれているのだろう．
つまり，cv::UMat d_frame = gray.getUMat(…);が実行された時点で，grayへの書き込みが自動的にd_frameに反映されるようにお膳立てしてくれているのかもしれない．（というかそもそも実体がGPU上に移るのかもしれない）．
確信はないけど．
とりあえず今日はここまで．
参考サイト様
OpenCV 3.0.0での独自カーネルOpenCL
UMatの内部処理（OpenCL編）
Any updates on calling C++ from Rust