G-APIの背景にある動機

G-APIモジュールは、グラフベースの実行モデルをOpenCVにもたらす。この章では、この新しいモデルが画像処理アルゴリズムの最適化と移植という2つの側面でソフトウェア開発者をどのように支援できるかを簡潔に説明する。

Graph APIによる最適化

従来、OpenCVは多くのスタンドアロンな画像処理関数を提供してきた（モジュール core と imgproc を参照）。これらの関数の多くは十分に最適化されている（例えば特定のCPU向けにベクトル化、並列化など）が、それでも標準で得られる最適化の範囲は単一の関数のみに限定されており、それらの関数の上に構築されたアルゴリズム全体を最適化するのはプログラマの責任であった。

OpenCV 3.0 では Transparent API（または T-API）が導入され、OpenCVの関数呼び出しを透過的にOpenCLデバイスへオフロードし、cv::UMat によってホスト/デバイス間のデータ転送を削減できるようになった。これは大きな前進であった。しかし、T-APIは動的なAPIであり、ユーザーコードは依然として制約されず、OpenCLカーネルは任意の順序でキューに入れられるため、それ以上のパイプラインレベルの最適化の可能性は失われていた。

G-APIは、暗黙的なグラフモデルをOpenCV 4.0にもたらす。グラフモデルはパイプライン内のすべての演算とそのデータ依存関係を捕捉し、それによってG-APIフレームワークにパイプラインレベルの最適化を行うための追加情報を提供する。

グラフベースの最適化の要(かなめ)は タイリング(Tiling) である。タイリングを用いると、処理をより小さな部分に分割し、演算を再編成して、データ並列性を可能にし、データ局所性を向上させ、メモリフットプリントを削減できる。データ局所性は、現代のコンピュータアーキテクチャにおけるメモリアクセスのコストの違いゆえに、ソフトウェア最適化において特に重要な側面である。第1レベルキャッシュ内で再利用されるデータが多いほど、パイプラインの効率は高くなる。

確かに、前述の手法は手動でも適用できるが、それには追加のスキルとターゲットプラットフォームの知識が必要であり、アルゴリズムの実装は取り返しのつかない形で変化してしまう。すなわち、より固有化され、柔軟性が低下し、拡張や保守が難しくなる。

G-APIはこの責任と複雑さをユーザーから引き受け、大部分の作業を自ら行うことで、アルゴリズムのコードをデバイスや最適化の詳細から切り離して保つ。ただし、グラフモデルは 制約された モデルであり、すべてのアルゴリズムがグラフとして表現できるわけではないため、この方法には独自の限界がある。そのため、G-APIの適用範囲は通常の画像処理、つまり各種フィルタ、算術演算、二値演算、明確に定義された幾何変換のみに限定される。

Graph APIによる移植

G-APIの本質は、実行する一連の演算を宣言し、その後でその一連の演算を実行することにある。G-APIは制約されたAPIであるため、どの演算がパイプラインを構成できるか、またそれらの演算が互いにどのようなデータをやり取りできるかについて、いくつかの制限を課している。

この形式化は、実際にはアルゴリズムを移植可能にするのに役立つ。G-APIは演算の インターフェース をその実装から明確に分離する。

1つの演算（カーネル）は、単一のデバイスに対してさえ複数の実装を持つことができる（例えば、OpenCVベースの「リファレンス」実装と、タイリングで最適化された実装の両方がCPU上で動作する）。グラフ（G-APIの用語では Computations）は演算のインターフェースのみを用いて構築され、実装は用いない。したがって、同じグラフを、グラフ自体にほとんど変更を加えることなく、異なるデバイス上で（もちろん異なる最適化手法を用いて）実行できる。

G-APIはプラグイン（バックエンド(Backends)）をサポートしており、これらは特定のプラットフォーム上で実行する最善の方法に関するロジックと知識を集約している。いったんG-APIでパイプラインが構築されれば、いずれかのバックエンド（またはそれらの組み合わせ）を使用するようにパラメータ化でき、グラフを新しいプラットフォームへ容易に移植できる。

参照: 高レベル設計の概要