はじめに
FPGAを使ったリアルタイム認識を一緒に研究させて頂いている研究室で「GPU と FPGA を組み合わせて高性能化しよう」というアイデアに興味を持たれる学生さんは定期的に現れますし、過去に実際に何度も取り組んでもらっておりますので今日はそのチュートリアル的な話です。
このブログでも過去に何度か触れているように
- FPGA は様々なデバイスとの接続や超低遅延なリアルタイム処理に優れているが演算能力は乏しい
- GPGPUはその性質上並列化が進むほど低遅延が苦手になるが、演算能力は高い
ですので、この二つを組み合わせて、「高度な演算をリアルタイムにできないか?」というアイデアはみんな思いつくわけですが、なかなか罠も多い話でもあるので、ここで少し整理していこうと思います。
どういった処理になるのか
簡単にタイミングチャートを下記に示します。例えば FPGA の処理時間を 1ms (1000fps)、GPGPUの処理時間を 4ms (200fps) などのようにおいています。

現在、イベントベースカメラのような面白いものもありますが、残念ながら個人で容易に入手できるFPGAに直結できるようなものは存在せず、USB経由だったりするとGPUに信号が届くまでに平気で数ミリ秒の遅延が入ります。 現状の一般的な低遅延信号処理を考えると一般的なグローバルシャッター使って高速にシャッターを切る(短時間露光)するのが、遅延観点では最速かと思いますので、その例で書いております。
露光時間は、照明などを強く焚くなどすれば幾らでも短くできますので理屈上は露光時間はゼロに近づけることができます。そうなるとイメージセンサーからデータを読み出す リードアウトの時間が律速項になるのですが、FPGAでの処理はイメージセンサーからの読み出しと並行してパイプライン処理できますので、結果的に 1ms 後には結果を出すことが出来ます。
実際に1ms遅延のAI認識やオプティカルフロー計測は当サイトで実機実証出来ている通りです。
では GPU はどうかと言うと、こちら で述べた通り、現代の GPU は、ほぼ1フレーム分のデータを一度メモリ貯めるなどしないとその並列性を活かした演算ができません。
つまり、FPGAが認識を完了する頃になってやっとGPUは計算開始条件が整う ようなことになります。
この時、 GPUが計算している間の変化をFPGAで補間(外挿)しよう というのが自然な発想かとは思いますが、設計を難しくするのが下記の2点です。
- FPGA が GPUから受け取る情報は FPGA にとってかなり過去のものである
- 次に GPU から情報を受け取るまでは自身の認識結果で補間しないといけない
と言うものがあります。
特に前者が厄介で、GPUが認識してくれるまでFPGAは補間対象を決定できないが、決まったときには見失っている という、「服を買いに行く服がない(缶詰の中の缶切り 改め)」という状態になりかねません。
力業で攻めるなら 画面内の全部の特徴点なりを追跡しておいて後からGPUの結果で追跡しなおす とかになりますが、なかなか「全部追跡」も非効率です。
この辺りの課題をどう解決していくのかなども重要なポイントです。
幸い、多くのシステムでは
- 電源入れてから数フレーム遅れで認識が始まっても困らない(起動時間がちょっと伸びただけ)
- 新しい物体がフレームインしてきてもワーク領域に来るまでに認識できれば良い
などがあるので、「ある程度疎な追跡から数フレーム掛けてターゲットを捉える」なんてことも視野に入ってきます。
このような許容できそうなシステム制約と相談しながらアルゴリズムを絞り込んでいくことが大事です。
とはいえワーストケースでも必ず一定フレーム数以内に捕らえるという、疎にしても漏らさない天網恢恢な仕組みの考案が必要ですが、そういったところに進歩性を生み出す余地が生まれてくるわけです。
予測と誤差と
また、FPGAで補間する話をしましたが、そもそも 予測(Estimation) を行っておくのは前提条件となる話です。
もともとFPGAで低遅延処理を狙う理由は明確で、世の中には予測しきれない誤差がいっぱいある ということにつきます。そして時間が経てば経つほど、つまり演算遅延が大きければ大きいほどその誤差は大きくなります。
世の中には、物体通しがぶつかりあって跳ねまわったり、振動環境だったり、風に揺れるドローンだったり、急に石につまずいたり、予測不能な成分が急に入ってくることは多々あります。
そして 予測できるだけ予測した後にさらに残る誤差は基本的にランダムウォーク(Random-Walk) です。ブラウン運動みたいなやつです。
ランダムじゃないなら予測できるわけだからそれは予測で取り除けるわけですから、取り除いた後に残るのがランダムになるのは自明ですね。
予測可能なものをGPUで扱い、予測不能なランダム成分をどうやって FPGA で抑え込むかが重要になります。
ちなみに、ここで、フレームレートの低いGPUにとっては、フレーム間の相関がほぼ無く Random-Walk になってしまうものが、フレームレートの高い FPGA から見るとある程度連続性のある動きだったりすることもあるので、このあたりもハイブリッドのメリットになってくると思います。
GPU と FPGA の通信の問題
もう一点、このシステムを考える際にしばし問題になるのが、FPGA と GPU の通信です。
特に GPU はしばしノンリアルタイムOSの上で動きますので、演算時間がばらつくことが多いですし、FPGAとGPU間でのデータ交換でもさらに大きな遅延が入ってしまう事があります。これらの遅延や、GPUの演算が間に合わずフレーム落ちした場合にもロバストになるようにするなど、これらもアルゴリズムに織り込んでおかないといけません。当然難易度が跳ね上がります。
Versal のような AIエンジンも内蔵した FPGA で連携するとか、DPU のようなソフトコアのAIエンジンと、パイプライン型の独自認識コアをハイブリッドにするとか、すべてハードリアルタイムな世界に入れ込む方がまだ現実的になる可能性すらもあります。
それ以前に、FPGAを始めるときの壁でも書きましたが、FPGAとGPUシステムとの間でデータ交換するシステムを開発すること自体が結構難易度高かったりします。
特にフィジカルAIが対象とするような領域では、カメラやアクチュエータとFPGAが密連携するところに強みを出しがちなので、ALVEO などの PCIe 系の資産が活用しづらくなりがちな点も要注意です。Kria などのシステムは一つの解になりえると思います。
FPGAのみでやり切ることも視野に
FPGA は、普通のAI をやる分には、まあ同クラスのGPUとくらべると 1/10 とか 1/100 の性能になってはしまうんですが、とはいえ、「1/100 でもやりたいことができるなら十分じゃないか?」と言うのはあります。
例えばフィジカルAI みたいなことする際に 1ms 級の認識をしないと間に合わないような事をするのであれば、別に最新のGPU向けAIモデルじゃなくても、特定分野で今まで出来なかったことをできるようにするには十分 である可能性があります(新規性の話)。
このあたり でも少し可能性について触れていますが、FPGA は状態空間モデル得意ですので、S4 とか Mamba とかの考え方を取り込める可能性もありますし、そもそも量子化とか枝刈りなども、GPUに出来ないFPGA固有の工夫はいろいろできますし、私のLUT-Net のようなアプローチも含めて、何も GPU向けに設計されたモデルをそのまま持ってくることをやめて、ゼロベースで FPGA-AI を突き詰めていけばいろいろできそうな気はします。
そもそも「AI である必要があるのか? 」というのもあって、ルールベースで出来るところはルールベースでやって、どうしてもデータオリエンティッドに機械学習を使いたい部分だけAIを使えばいいんじゃないかというのもあるわけです。
おわりに
昨今のGPUは非常に強力であることは間違いないので、その欠点をFPGAで補えればそれはそれで大変良い取り組みだと思います。
一方で、安直に組み合わせても失敗してしまう罠はたくさん埋まっている分野とも言えます。
だからこそうまく住み分けて両者を活用できる方法を模索するというのは、まだまだ前人未踏な部分が沢山残っていますし、アルゴリズムモデルにおいても、計算機アーキテクチャにおいても、まだまだ興味深い研究テーマが残っていると思う次第です。
それぞれの計算機のメリット/デメリットをよく理解して、何がボトルネックになるのか、安易に組み合わせると何が起こってしまうのか、よくよく整理して課題をフォーカスしてからから取り組むと良いのではないかと思います。
計算している間に実世界は変化する というのが フィジカルAI の面白い部分でもあり、計算時間も含めたパズルを自在に解くのに適した RTLプログラミングの醍醐味でもあります。 まさに 「物事を4次元的に考えろ」 なのです。
データが演算パイプラインを抜けたその先で世界がどう変化しているか考えながらプログラムを書くというのは、慣れてくるとピタゴラスイッチ的な独特の楽しさがあるのです。

![[増補改訂]GPUを支える技術 ――超並列ハードウェアの快進撃[技術基礎] WEB+DB PRESS plus [増補改訂]GPUを支える技術 ――超並列ハードウェアの快進撃[技術基礎] WEB+DB PRESS plus](https://m.media-amazon.com/images/I/51Mai98jg4L._SL500_.jpg)



