OpenCV H/Wアクセラレータ化の検討を再開した。
最終ゴールとしてはアプリケーションを変更せずに使用できるH/Wアクセラレータである。
当然と言ってはなんだけど、アプリケーションのOpenCV関数をH/Wアクセラレータ用の関数に置き換えて、「OpenCVに対応したH/Wアクセラレータです」はOpenCVに対応したんじゃなくって、単にOpenCVを模したグラフィックアクセラレータを作っただけである。
「OpenCVに対応しました」というのであれば、アプリケーションの関数は変更しなくて良いのである。
OpenCVはなんのためのライブラリなんだろうか？
今回のH/Wアクセラレータは当然、アプリケーションは変更しなくても使用できるH/Wアクセラレータを目指す。
PCで使用するときは、S/W処理になり、Zynq上で使用すればH/Wアクセラレータを使用するようにしたい。
したがって、H/Wアクセラレータ化にあたっては、OpenCVのソースコードも手を加えることになる。
まずはターゲットは以前から変わらず、下記の3点をH/Wアクセラレータ化する。
・算術系演算
・フィルター系演算
・リマップ
なぜ、この3点に絞っているかというと、単にサラウンドビューを実現したいからである。OpenCV H/Wアクセラレータ化の検討を再開した。
最終ゴールとしてはアプリケーションを変更せずに使用できるH/Wアクセラレータである。
当然と言ってはなんだけど、アプリケーションのOpenCV関数をH/Wアクセラレータ用の関数に置き換えて、「OpenCVに対応したH/Wアクセラレータです」はOpenCVに対応したんじゃなくって、単にOpenCVを模したグラフィックアクセラレータを作っただけである。
「OpenCVに対応しました」というのであれば、アプリケーションの関数は変更しなくて良いのである。
OpenCVはなんのためのライブラリなんだろうか？
今回のH/Wアクセラレータは当然、アプリケーションは変更しなくても使用できるH/Wアクセラレータを目指す。
PCで使用するときは、S/W処理になり、Zynq上で使用すればH/Wアクセラレータを使用するようにしたい。
したがって、H/Wアクセラレータ化にあたっては、OpenCVのソースコードも手を加えることになる。
まずはターゲットは以前から変わらず、下記の3点をH/Wアクセラレータ化する。
・算術系演算
・フィルター系演算
・リマップ
なぜ、この3点に絞っているかというと、単にサラウンドビューを実現したいからである。
あと、認識処理も・・・って、あるけど・・・
＃サラウンドビュー：本当はアラウンドビューの方が響きや意味合いはいいんだけど、日本じゃ、日産の商標になっているので変に使えないだなぁ。
＃やりたいのは、複数カメラの合成なので、見え方はサラウンドじゃないんですわ。
・算術系演算
算術系演算は単純にAdd、Subなどのライブラリを置き換えるようにする。
これはパイプライン処理ができればよく、データのターゲットはRGBのみとする。
OpenCVのアルゴリズムを、C/C++から高位合成で生成しても良い。
ただ、ZynqのDSP48E1を3つすれば全ての算術系演算を表現できるので今回はこれを採用して、算術系演算のパイプライン化ができるか検討しておくようにする。
算術系演算のパイプラインとは、以下のように算術系演算を並べた場合に、各関数ごとにメモリへ吐き出すのではなく、パッキングしてH/Wアクセラレータを3つ使用して関数自体をパイプライン化できないかということ。
OpenCV_Add
OpenCV_Sub
OpenCV_Mul
これらのパイプライン化はOpenCVに実装されているわけではないので独自の実装になる。
技量があれば、3つの関数を使用していると、コンパイラとかで自動的にパッキングできるようにしたい。
・フィルター系演算
これも算術系演算と同じでパイプライン絵処理ができれば良い。
ただし、5x5までのフィルターに対応するものとして、メモリからのバッファへの読み込みが肝になる。
つまり、DMAの方法が重要なキーワードになるのでここもスクラッチ実装での処理方法を検討する。
・リマップ
リマップはパイプラインで表現すると、最低でも2倍のクロックが必要になるので、高位合成の対象にするつもりはない。
ここもフィルター系演算と同様にメモリからバッファしなければいけないのでDMAの方法が重要になる。
今回の補間は線形補間のみとする。
あと、認識処理も・・・って、あるけど・・・
＃サラウンドビュー：本当はアラウンドビューの方が響きや意味合いはいいんだけど、日本じゃ、日産の商標になっているので変に使えないだなぁ。
＃やりたいのは、複数カメラの合成なので、見え方はサラウンドじゃないんですわ。
・算術系演算
算術系演算は単純にAdd、Subなどのライブラリを置き換えるようにする。
これはパイプライン処理ができればよく、データのターゲットはRGBのみとする。
OpenCVのアルゴリズムを、C/C++から高位合成で生成しても良い。
ただ、ZynqのDSP48E1を3つすれば全ての算術系演算を表現できるので今回はこれを採用して、算術系演算のパイプライン化ができるか検討しておくようにする。
算術系演算のパイプラインとは、以下のように算術系演算を並べた場合に、各関数ごとにメモリへ吐き出すのではなく、パッキングしてH/Wアクセラレータを3つ使用して関数自体をパイプライン化できないかということ。
OpenCV_Add
OpenCV_Sub
OpenCV_Mul
これらのパイプライン化はOpenCVに実装されているわけではないので独自の実装になる。
技量があれば、3つの関数を使用していると、コンパイラとかで自動的にパッキングできるようにしたい。
・フィルター系演算
これも算術系演算と同じでパイプライン絵処理ができれば良い。
ただし、5x5までのフィルターに対応するものとして、メモリからのバッファへの読み込みが肝になる。
つまり、DMAの方法が重要なキーワードになるのでここもスクラッチ実装での処理方法を検討する。
・リマップ
リマップはパイプラインで表現すると、最低でも2倍のクロックが必要になるので、高位合成の対象にするつもりはない。
ここもフィルター系演算と同様にメモリからバッファしなければいけないのでDMAの方法が重要になる。
今回の補間は線形補間のみとする。
Tweet write: 2015/02/04/ 02:38:12