リアルタイムAIで考える事

はじめに

当サイトでは、応答時間がミリ秒以下になるような、高リアルタイム性のコンピューターシステムを検討対象としており、AI(というか機械学習)もその対象範囲です。

このようなリアルタイム性の条件下でAIを考える場合、通常の AI のように単に高精度な結果を出せる学習モデルを設計するだけではだめで、時間経過の中で今出力できる最善の解に更新を繰り返していくモデルを設計し、 実世界のダイナミクスに追従する適応性 を持たせることが必要になります。

ですので今日はあまり一般的な話ではなく、この分野に閉じて、少し考察をしてみようと思います。

リアルタイム・システムの構造化分析

メモリ階層とモデルの矛盾

一般的な計算機のメモリは階層的になっており、CPUなどでも１次キャッシュから３次キャッシュ、外部SDRAMなどの階層で、容量が小さく高速なものから順に、大容量で低速なものになっていきます。

FPGAなど、自由に計算機アーキテクチャを設計できるデバイスにおいてもこれは同様で、利用できる演算資源としては、階層的になっており、例えば以前に下記のような絵を描いたことがあります。

リアルタイムコンピューティングのメモリ階層

一方で、リアルタイムコンピューティングでは、新しい入力から出力更新までの制約時間の中で読み出せる量のデータしか使えません。 例えば サンプリングレート 1kHz (1000fps) で1ms (1ミリ秒は 1000分の1秒) で応答する処理を行う場合、メモリがどんなに大容量であっても 1ms で読み出せる量のデータやパラメータしか演算に投入することができません。

そうすると、大容量メモリほど少しのデータとパラメータしか使えない という一見矛盾したことが起こり始めます。

容量と速度の逆相関

しかしこれはとても重要なことで、同じくリアルタイム処理であるグラフィックスレンダリングの処理などでは、例えば 60fps でゲーム画像をレンダリングしたい場合、16.6ms で読み出せるデータ(テクスチャやポリゴン頂点など)しか描画に使えません。 そうなると容量よりもデータ帯域が重要となり、GPUには GDDRメモリなど容量は少ないが高速なメモリが採用されてきた歴史があります。

高リアルタイムシステムほど、これのもっと極端なことが起こっていきます。

ではそのような制約下でどのようにAIモデルを考えていくかと言うのが本記事の考察です。

コンピュータの構成と設計　MIPS Edition　第6版 　上・下電子合本版

階層メモリのリアルタイムでの活用方法

それではパターン別に大容量メモリをうまく使う方法を考えていきます。大きくはデータの履歴(状態変数も含む)の保持に使うパターンと、学習パラメータを置いておくのに使うパターンとがあると思います。

データ履歴の活用の工夫

最初に過去のデータを利用する観点で考察します。今入力されたデータだけでなく、過去に入力されたデータを使う事で、空間的な広がりや、時間的な変化を認識できるようになります。

データの古さで置き分ける

もっともオーソドックスな使い方がこれでしょうか。例えば画像処理においては

• 直前のピクセル(水平方向)はレジスタ(フリップフロップ)に記憶
• 直前のライン(垂直方向)は内蔵SRAMに記憶
• 同じピクセル位置周辺の過去のフレームの情報は外部SDRAMに記憶

のようにすると、空間と時間の3次元方向の周辺情報を使ってそのピクセルを処理することができます。 画像のようのものは１フレーム自体が巨大ですし、場合によっては何フレームも過去の情報を使いたい場合は容量の多い外部メモリを活用できます。 内蔵メモリにフレーム全部が収まらないにもかかわらず、カメラデータ入力の数倍程度のメモリ帯域があれば、演算対象のピクセル周辺のデータは常にオンメモリに持ってこれる構成が作れます。

状態空間モデルで、各ピクセル位置に状態を持たせる場合でも、状態変数をフレームと一緒に外部SDRAMに記憶して、次にそのフレーム位置が来た時に状態を復元して、次の時刻の計算を行うのも合理的な使い方と言えるでしょう。

特に周期性を持った時系列処理においてこの考え方は非常に重要で、例えばお店の売り上げのような時系列データでも、曜日や季節に影響を受けるため、昨日の同じ時間、先週の同じ曜日、先月の同じ日、昨年の同じ日、などとはしばし比較評価を行います。 大容量メモリが大量の容量を持っていることを利用して、ピンポイントで古い情報を利用するのに利用するわけです。

お店の売り上げの例だとあまりにも長いですが、我々の身の回りや、産業応用などでは、エンジンの回転周期ぐらいの周期性を持った時系列は沢山あります。特に人間には感知できないぐらい高い周波数でも計算機なら感知できるというのは重要なことだと思います。

選択的に履歴を選ぶ

履歴はそのままフラットに記録しておき、どこを読み出すかを選択的に選ぶことで読み出しデータ帯域を抑えることもできます。

以前に、ハイフレームレートでは動き補償の計算が激減できるという話をしたことがありますが、該当するピクセルに写っていた物体が、過去のフレームのどこにあるか追跡しながらそこだけピンポイントで取り出してくることもできます。

例えばバイクに乗って手を振っている移動している人から、「手を振っている」という時間変化成分を加えてた認識が、限られたメモリ帯域の中でできる可能性など出てくるわけです。

動き補償は極めて強力な武器で、60fps で 16ピクセル移動する物体でも、1000fps なら1ピクセルしか移動せず、CNN の3x3の畳み込みフィルタに収まってくれます。

また ViT などの応用で、画像の中の注目すべきポジションを計算して、次のフレームでそのあたりを重点的に読み出すのも手です。

これもリアルタイムシステムであれば、1ミリ秒の間に最大で何ピクセル移動するかは、物理的に制約できる事が多いですので、対象のダイナミクスにあわせてマージンを設定すればよく、効果的に過去のデータを限られた帯域の中で活用できます。

過去の情報を要約(圧縮)して使う

これには時間方向の要約と空間方向の要約の２つの軸があると思いますが、読み出し時ではなく書き込む際にデータ量を圧縮してしまう方法です。

いずれも要らなくなった情報から順に削除したり圧縮したりしていきます。 例えば古いものを 1/2 に出来れば、 1/2 + 1/4 + 1/8 + ・・・ = 1 ですので、決まったメモリ帯域の中で履歴にアクセスし続けられる計算になります。

例えば以前に単純に画像を縮小していくというMIPMAP方式を提案したことがあります。 Attention 的に有用なものだけ残す手もありますし、また、認識まで行ってもっとメタ情報として圧縮する方法もあるでしょう。

縮小を行うと1つのピクセルの処理において、より広い範囲を俯瞰して判断することが可能になり認識精度が上がります。

画像処理では認識したい画像特徴に対してスケール普遍性がある場合が多く、画像ピラミッドを作って認識することは多いです。 CNNなどでも特徴量の世界でもこれは同じであり同じ認識器をマルチ解像度に適用していくのは合理性があります。

また動き補償と縮小とを組み合わせると、把握できる範囲が 6x6、12x12、24x24 ・・・ と倍々で広がりますので、多少の移動速度であれば簡単にスコープに捕らえます。過去の動きは大雑把に追跡して、最新位置を最新の最大解像度の画像で正確に認識し、さらにその情報を次のフレームに状態として引き継げるわけです。

コンピュータビジョン最前線 Summer 2025

パラメータ利用の工夫

昨今のAIでは 入力データよりもパラメータの方がはるかに巨大 ということがしばしあります。

すべてのパラメータがFPGA内などにオンメモリにもてれば何の苦労もないわけですが、残念ながら外部SDRAMなどにパラメータを置いておいて動的に入れ替えなければ、極めて小パラメータのモデルしか使えないことになってしまします。

パラメータを動的に変更する

例えば、高速に応答したい物体Xの認識パラメータセットと、その他の認識対象セットがA、B、C、D・・・ と何セットかあった場合

X → A → X → B → X → C → X → D → X →

のようにタイムスロット(画像なら１フレーム毎とか)ごとにパラメータセットを入れ替える手が考えられます。

１つのタイムスロットで読み込めるパラメータ数は決まっていますので、時間ごとに切り替えることで、見逃せない X を頻繁に調べつつ、他のものも探索するようなことは十分にあり得ます。

100クラス認識できるものを 10 回入れ替えて 1000クラス分類に近づけていくようなアプローチでしょうか。

選択的にパラメータ使う(MoEなど)

MoE(Mixture of Experts) も最近よく耳にする技術になってきました。これはもちろんリアルタイムAIでも重要な要素だと思います。

画像認識も、街中や森の中、夜間や霧、顕微鏡画像やMRI画像など、環境の違いもあれば、認識したいものが人間だっり、自動車だったり、交通標識だったり、部品のひび割れだったり、病気の腫瘍だったり様々です。

これらをパラメータセットを沢山持っておいて、適応的に切り替えながらあらゆるシーンで活用することを考えるのも、限られたメモリ帯域を有効に使う上でとても重要です。

例えば、人間が前を向いた時、横を向いたとき、後ろを向いたとき、などそれぞれを学習させた認識器を使って、今どういう運動をしているかを認識しておけば、次のフレームでロードすべき認識パラメータはおのずと決まってきますし、変化や状況を見て適応的に次にロードするパラメータを選ぶことで、一度に使うパラメータ数を抑えながら幅広い認識を応答性良く行える可能性が出てきます。

デジタル回路設計入門 - FPGA時代の論理回路設計 -

ハイブリッドに使う

ここまで挙げたようなテクニックをハイブリッドに組み合わせることももちろんありだと思います。

特に、センサーの値を特徴量として汎用的にとらえる部位と、特徴量から目的に合わせた認識を行う部位はしばし分けて考えられます。

特徴量を作る部分では、例えば昼用と夜用などシーン変化に応じてパラメータを切り替えて常に高品質な特徴量を得られるようにして、後半は認識対象に応じてパラメータを切り替えるような手もあります。

100クラスのうち50クラスだけは常に同じものを認識するようにして、残りの50だけを変えたパラメータを入れ替えるなどもありでしょう。

用途にに応じた組み合わせこそが重要だと思います。

おわりに

アルゴリズム開発をしている多くの人にとって、0.1 秒で以下で終わるものと言うのは、どれも大差ないように思えるかもしれません。

一方で我々の生活するリアルな空間では、その 1/100 である 1ミリ秒(0.001秒)であっても、案外大きな変化をします。 人間は 100mを10秒 (1m を 0.1 秒)で走ってしまう生き物で、時速何百キロのボールを投げることもできます。 一般人がその半分の速度で動いても 1ミリ秒に何cm も移動するのです。

また、人間は応答に 0.1秒以上かかると言われています。ですので人間をアシストする計算機まで 0.1秒遅れてしまうと遅延が倍になります。計算機がアラートを出してから人間が回避行動をとるシステムにしたら ２倍鈍感な動作しか出来なくなった では悲しいわけです。

近年では フィジカルAI とか エンボディドAI と言われている領域の中には、これらが課題になる分野が間違いなくあります。

そしてこれらの分野にむけて学習モデルを作る場合、単に総演算量だけ考えればいいものではなくなります。

アルゴリズムを1ミリ秒などのタイムスロットで細切れにして、どこにどのようにデータを置いて、タイムスロット間では何を渡して、システム全体としてどう振舞うようにするか、を考える必要が出てきます。

考える事が一気に増えて複雑なパズルを解くことになりますが、これは好きな人にはとても楽しい話ですし、新規性のある独自の工夫や、他の方式との差別化がとてもやりやすい領域になります。

昨今の FPGA は、学生が研究用に研究室で買ってもらえるぐらいの価格帯のFPGAで、 ResNet18 を 60fps で動かせる程度の演算リソースは内蔵するようになってきました。これを 60fps の 16.6ms で計算するのではなく、 1/16 の演算量の計算を 16回に分けて行うことで、定常的には従来相当の認識率を保ちつつ、変化に対して 1 ms などの応答性を持たせることが出来れば大変興味深い研究になってきます。 最初の認識に 16ms (16フレーム)かかっても、それは従来と同じですので、そこから先に 1ms の応答性が手に入るなら大きな進歩を手に入れたことになります。

もしこういった分野に興味のある方、是非、いろいろ考えてみて頂けると面白いのではないかと思います。

フィジカルAIについて考えてみる

はじめに

昨今、フィジカルAIや、エンボディドAI などの単語をよく聞くようになってきました。

当サイトのリアルタイム性に対するこだわりが発揮しやすそうな領域であり、FPGA 応用の生きてくる分野でもありますので、少し考察してみたいと思います。

昔からあった領域に新しい名前が付いただけと言う部分も大いにあろうかとは思っておりますが、分かりやすい言葉で一般の人に周知されるという事は非常に重要な事ですので、大変喜ばしい方向に進んでいるように思います。

何より、数千億円規模の大規模GPU環境で学習した LLM が群雄割拠している中で、弱小企業や研究機関や個人が太刀打ちしようとすると勝負の土俵を変えるしかない部分はあり、そういった中で、日本にある、まだ学習につかわれていないデータや、データ化すらされていない技能などをターゲットにしていくのは、戦略としてはありだと思うわけです。

リアルタイムシステムとその応用 (システム制御情報ライブラリー 22)

FPGAによるフィジカルAI考察

リアルタイム性での分類

フィジカルAIの類は、基本的には IoT でありエッジコンピュータの存在が前提になると思います。エッジコンピュータはリアルタイム性以外にもセキュリティーの問題だったり電力の問題だったりいろいろな観点で分類がありますが、当サイト的には、リアルタイム性の観点に絞って考えます。

そうすると大雑把に

• AI をクラウドに投げても良いケース [ノンリアルタイム]
• ノンリアルタイムOS上で動くGPUでよいケース(Jetsonなど) [数十ミリ秒の応答＋ミリ秒単位ーのジッタ]
• リアルタイムOS＋NPU などで頑張るケース [サブミリ秒オーダーの応答＋マイクロ秒単位のジッタ]
• FPGA を使うケース [マイクロ秒オーダーの応答＋ナノ秒単位のジッタ]

ぐらいの区分を思いつくわけです。

正直、9割ぐらいは「Jetson で十分」という領域かとは思っておりますが、1割ぐらいは FPGA でこそ開拓できる分野があるのではないかと思っています。

Hard Real-Time Computing Systems: Predictable Scheduling Algorithms and Applications (English Edition)

FPGAでしかできない低遅延AI計算

例えば産業用のサーボモーターは 1k～100kHz ぐらいの周期で電流量を変化させているわけですが、たとえばこれを「強化学習によってAIで制御してみよう」なんてことは発想としてはすぐ出てくるわけです。

センサーとしてもIMUとか圧力センサとか一エンコーダとか色々なものが利用可能ですが、例えば当サイトがやっているカメラ画像処理での1ミリ秒でのAI認識とか、1ミリ秒後に視界の変化捉えるオプティカルフロー演算の結果を出すみたいなものも応用範囲に入ってくるかと思います。

こちらなどでも書きましたが、GPUは同じ計算の並列実行を行わないと性能が出ませんので、コア数に応じて何千とか万とかのオーダーでデータを溜めてから演算を開始しないと性能が出ません。 従って原理的にどうやってもメモリに溜める遅延時間を許容しない限りAI演算性能を発揮できない宿命にあります。さらに GPU の多くは Linux などのノンリアルタイムOS上で動くことを前提としています。最近は Linux のリアルタイム機能も充実しては来ていますが、GPUへのデータ転送やキャッシュヒットのバラツキなどでどうしても計算時間に大きなジッタが出てきます。

そうすると、ある程度の大容量のAI計算をリアルタイムにやろうとするとFPGAに利が出てきますし、FPGAにあったパイプライン計算での演算や、データフローを乱さず低遅延で出力できる学習モデルの開発が重要になってきます。

ゼロから作るDeep Learning ❹ ―強化学習編

まず試作しないとデータすら取れない領域

そして何よりここからが重要なのですが、低遅延でリアルな対象を相手にすると、FPGAなどで試作しないとデータすら取れない という事が起こります。

ロボットなどは専門ではないのですがわかりやすいので、例えば「風の中でカメラ画像を見ながらバランスをとってキャッチボールをするドローン」みたいなものを考えてみます。

そうすると、非常に乱暴に言うと、姿勢制御をしながら飛んでくるボールに向かうように、「次の瞬間の各モーターの電流値を決めるAI」を開発したいという話になります。

この際にとても厄介なのが、出力如何で次のセンサー値も変わってしまう という事です。モーターの動き如何で視点となるカメラも移動してしまいますから。

近代のAIのほとんどは、取得済みのデータセットを固定された入力として用いて学習していますが、フィジカルAI分野では AI の学習次第で入力も変化する という事が起こるわけです。

CGなどのシミュレーション(ある種のデジタルツイン)でもある程度補完できるケースもあるかとは思いますが、そのシミュレーションを作るための基礎データは、「実機でリアルにフィードバックして何が起こるか」というデータを集めない事には何もできないわけです。

そしてそのデータ自体も、「マイクロ秒単位でフィードバックを掛けて初めて起こる事象」のデータなわけですから、低遅延計算をまず試作しないと何の実験も出来ないわけです。

逆に言うと、そのようにして作られた学習データや学習モデルはまだ世の中にない唯一無二なものですので、十分に、世界初／世界一を目指して研究開発できる魅力的な分野になってくるわけです。

【改訂2版】FPGAボードで学ぶ 組込みシステム開発入門［Intel FPGA編］

フィジカルだからだからこそのリカバリの効く領域

もう一点、フィジカルAI 分野で、特に、kHz 以上の高サンプリングレートで起こりがちな面白い事象として、リカバリが効く というのがあります。

人間が１本足でバランスを取って立っているようなときに、ふらふらしながらバランスを取りますよね。 ロボットなども同じで、あるマイクロ秒時間で予測を間違えて電流を止めてしまったり流しすぎたりしても、次の瞬間にそれを打ち消すだけ電流を流すとごまかせるなんてことは普通にあります。確率的にON/OFFを繰り返して結果をフィードバックしながら微妙な制御をするというのはルールベースでもいろんなところで行っていることです。

モーターに限らず、PWMで作る光の階調や、D級アンプの音声などでも、そもそも人間の感度より高い周波数でON/OFFを繰り返してますので、最終的に人間が感じる積分値が同じになるように後から多少のリカバリが出来たりもします。

要するにシステムにもとからある程度のマージンがあり、実行時にマージン範囲内で試行錯誤ができるという事です。 これは、学習モデルを考えるうえで、間違った答えを出すと一発アウトな従来AIと大きく違うところだと思っております。

また、このマージンを使って、実働中に「微かな試行錯誤」を行い、実働中に賢くなるAI(いわゆるオンライン学習)のようなものを入れ込む余地なども出てくるのではないかと思います。

製造分野などでも不良品にならない適正値の範囲では当然どんな製品にも微小なバラツキはあるわけで、要は最後にばらつきを規定範囲に収めることが目的なわけです。

オンライン機械学習 (機械学習プロフェッショナルシリーズ)

おわりに

当サイトでは、計算機科学の観点、特に FPGA を起点に、フィジカルAIを眺めております。

AI の良いところは、ルールベースで手に負えなかった部分を扱えるようになった点だと思います。

我が国においては、すでにこの分野は非常に高いレベルで制御工学が発達しており、ルールベースのシステムが多数稼動していると思います。それらの中にAIを入れ込むというのは容易でない部分もありますが、うまく共存しながら拡張としてAIを足しこめれば大きな変化をする分野もあるのではないかと思います。

先のサーボモーターの例を挙げましたが、他にも高速回転するエンジンの点火タイミング制御とか、人間の四肢や視覚／聴覚などの拡張であったり、医療、宇宙までいろいろな研究対象がありそうに思います。

ビジネスの観点でも、製造装置のようなドメイン固有の技能のAI化であったり、汎用ロボットとか人間の拡張(パワードスーツとか電脳メガネとか)のような多目的に使えるAIまで、まだまだ未開拓な領域が広がっているように思います。

AI を研究テーマにしたいという若者の方も増えているかと思います。一方で、パソコン上で Python 使ってできる範囲で論文書いて学位取ろうとすると、やってる人が多すぎてテーマ選びから苦戦するという方も多いと思います。

幸い今フィジカルAIというワードがちょっとしたバスワードになっていて、昔なら「単にFPGA化しただけでしょ」としか見られなかった分野が再注目されているわけですから、FPGAやってみたいなと言う方に興味を持っていただけると嬉しく思う次第です。

もちろん「リアルタイムに動くシステムを試作する」と言うのはそれ自体結構大変ですし、「自分で作ったシステムに適した学習モデル」を考えたり、「実際に学習させたり」はとても大変なことではあるのですが、苦労に見合った楽しさや見返りはある分野だと思っております。

FPGAプログラミング大全 Xilinx編 第2版

VLIWとスーパースカラについて考えてみる

はじめに

少し前に SIMT であるGPUの話 とか SIMDを持ったCPUの話 とか書いてきました。

MIMD についても考察しないといけないなと思いつつ、先だって頭の中で VLIW について気になり始めたので、引き続き個人的な見解を書いてみたいと思います。

また、命令実行方式の違いはあれど、データフローは VLIW と スーパースカラは良く似ているので合わせて考えてみたいと思います。

コンピュータの構成と設計　MIPS Edition　第6版 　上・下電子合本版

VLIW(Very Long Instruction Word)

VLIW というと、IA-64 (Itanium) を思い出す方も多いかもしれませんし、トランスメタ社の Cursor を思い出す方もいるかもしれません。最近だと Qualcomm Hexagon が割と成功しているようです(触ったことないですが)。

また 筆者が知っている範囲ですと、AMD の Versal や Ryzen で利用されている XDNA が VLIW だったと思います。

VLIW はその名の通り、複数の命令を束ねて１つの長い命令を実行できるようにしたものです。 身も蓋もない言い方をすると、近代のCPUがスーパースカラによる並列実行を行う際に性能を出すためのアウトオブオーダー実行機構などを、CPUがハードウェアで実行時に行うのではなく、プログランのコンパイル時に静的に行おうというものです。

必然的にプロセッサの内部構造が生々しく命令セットに反映されがちですので、バイナリ互換性をどう保つか が一つの重要なファクターであり、互換性を無視して使うケースでの VLIW は普通に実用的だと思います(都度都度コンパイラ作る人はたまったもんじゃないのかもしれませんが)。

一方で、「バイナリ互換性を保ったまま、将来並列性を拡張したい」となると途端に難易度が上がり、「プロセッサの並列数が変わっても互換性のある、並列命令ってどうするの？」という素人目に難しい話になるように思います。

たしか Itanium では命令の並列数を固定せずに、並列実行できる区切りだけを与える命令フォーマットにしていたと思いますし、Cursor では、コードモーフィングによって x86 命令から変換する事で次の Efficeon に拡張しようとしました。

が、結果的に、ハードウェアで変換する今の x86-64 が一番柔軟性があって性能が出て生き残ってしまったという歴史になっているように思います。

一方で、おそらく今の x86 の内部で μOPS を実行する部分は VLIW みたいなものにはなっている気はします。

VLIW Microprocessor Hardware Design: On ASIC and FPGA (English Edition)

ソフトウェアパイプライニング

さて、命令セットの問題を置いておくと VLIW にせよ スーパースカラにせよ、異なる命令を同時に実行する と言う点では同じです。 SIMDやSIMTでは同じ命令を同時に実行することしかできませんでした。

しばし当サイトではFPGAの得意な処理として、データ並列の対局としてパイプライン並列の話をしてきましたが、まさにそれが可能でして、ソフトウェアパイプライニングなどと呼ばれます。

これはコンパイラで自動的に行われたり、実行時にアウトオブオーダー機構がいい感じにしてくれたりすることもありますが、明示的に書くなら下記のような感じです。

// prologue
a0 = x[0];

// pipelining
for (i = 1; i < N; i++) {
    a1 = x[i];
    b0 = a0 * 3 + 1;
    y[i-1] = b0;
    a0 = a1;
}

// epilogue
y[N-1] = a0 * 3 + 1;

で、どういう事が起こるかと言うと、下記のような事が起こることを狙っていくことになります。

ソフトウェアパイプラインの狙い

ここでは、あるデータを Store Unit で書いているときに、加算器で次のデータを加算しつつ、その次のデータを乗算器で乗算しつつ、さらにそのまた次のデータを Load Unit で読んでくるという、パイプラインができます。

規模こそ限定的ですが、以前 こちら で発表させて頂いたような動きが CPU でも出来てしまう事になります。

複数の異なる動作ができる実行ユニットを並列実行できるVLIWやスーパースカラ計算機だから出来る事で、特筆すべきことだと思っています。

もっとも、ほとんどの実行ユニットは1サイクルでは処理が終わりませんので、実際にはもう少したくさんのデータで各実行ユニット内のパイプラインの深さを埋めることになります。

１命令で4つずつデータを処理する MN-Core は、非常に合理的に出来ている VLIW の一つだと言えるのではないかと思います。

Principles of High-Performance Processor Design: For High Performance Computing, Deep Neural Networks and Data Science (English Edition)

おわりに

SIMD や SIMT ほど長い話にはならなかったですが、異なる命令を並列実行できる と言う点は、並列化の難しい多くの複雑な問題に対して非常に有効に機能すると思われます。

一方で並列化の規模や粒度の点で、アウトオブオーダーのスーパースカラは命令デコードの負荷から限界があると思います。

しかしながら、「バイナリ互換性を求めないVLIW」であればまだまだ発展の余地がありそうにも思います。

いずれにせよ、同時に異なる演算を実行できる という利点を最も持っているのは FPGA だと思っておりまして、以前、「FPGAは１命令を繰り返すVLIWプロセッサ？」という記事を書かせて頂いた話に繋がるわけです。

世の中で何か面白いアイデアが生まれてくることを祈りつつ、筆をおきます。

FPGAの原理と構成

（おまけ） 続・FPGAに対する誤解

はじめに

前回、FPGAに対する誤解と「どうFPGAを使うべきか」 という記事を書きました。

ちょっと調子に乗ってアンチパターンをイラスト化してみたのでおまけ記事として書いておこうと思います。

実践入門FPGA開発　7日間で学ぶ生成AIによる回路設計 技術の泉シリーズ

本来のFPGAの活用シーン

本来のFPGAの活用シーン

ISPなどの典型ですが、例えばカメラから入ってきた画像を入ってきた順で処理して、そのまま出力するのでとても効率的です。

従来は画像の現像や高画質化処理ノイズ除去などが一般的でしたが、当サイトではこのやり方で「動き計測」とか「AI認識」など、いわゆる CV(Computer Vision) と言われる領域に手広く適用可能であることがだいぶ示せてきていると思います。

CG分野でもこのアーキテクチャでの低遅延ポリゴン描画など示せてきました。

アルゴリズム研究者が使う環境

便利な並列計算機であるGPUの為に、一度データをメモリに溜めて並列化することで並列演算を可能にするように構成したものです。 最先端の半導体製造プロセスで作られた高速大容量の計算能力の恩恵に預かりやすいです。

アルゴリズム研究者が使う環境

画像処理アルゴリズム研究の分野では、多くの領域でAI(深層学習)を使った研究が、特に認識精度(accuracy)の観点で SOTA(state of the art) となっていきました。 必然、非AIの研究はしばし「AIと比べて性能で勝てるの？」と言われてしまう辛い時代になりました。

遅延や電力やコストを置いておけば、GPU上で机上でアルゴリズム精度の研究を行うのは非常に便利ですので、この形で研究されたアルゴリズムが世にあふれることになりました。

もちろん一度メモリに溜めた分遅延は増えますし、コストや電力も増大しますが、「簡単にアルゴリズム実験がいろいろできる」という効率性の前には些細な事です。

これはこれでもちろん世の中をすごく進歩させてくれたのですが、計算機は とにかく AI 性能がいいことだけを求められるようになってきました。

また、遅延等が課題になる分野の研究が置き去りになってしまうという、困ったことも起こっていると思っています。

誤解１：GPU計算をそのままFPGA化してしまうパターン

で、前回記事の続きで、GPU方面からFPGAに興味を持って下さった方が、陥る可能性のアンチパターンその1です。

GPU計算をそのままFPGA化してしまうパターン

「FPGAにする(というかハードウェア化する)と高性能化する」と聞いて、今あるGPU用のプログラムをそのままFPGA化しちゃうパターンですね。

往々にして最先端プロセスで作られ、大量の浮動小数点演算器のハードマクロを持ち、GDDRなどの高速メモリを持つGPUに、汎用ロジックで勝てるわけがなく、苦しむことになります。もっとも計算機の勉強にはなると思います。

誤解２：そのままそこだけストリーム化してしまうパターン

そこだけストリーム化してしまうパターン

FPGAはストリーム処理が得意だと聞いて、そのままそこだけストリーム化してしまうパターンですね。

見ての通り、GPUの為に ストリームを並列データに変換してあるものを、再度ストリーム化するというもったいないことになっています。

とはいえ、「原理的には低遅延なリアルタイム処理に持っていけるアルゴリズム」が生まれてくる可能性がある点では、そこまで悲観的ではないです。

ただ、ストリーム処理は「演算器を再利用する」ことが苦手なので、しばし「リソースが足りなくて収まらない」という事になりがちです。

アルゴリズムを出発点にせずに、ハードウェアアーキテクチャを出発点にアルゴリズムを組み立てる という事が必要です。

考えて欲しいこと

冒頭のFPGAに適した処理は、実はアナログ時代の信号処理に似ています。 アナログ時代は、「信号をメモリに溜める」ということが極めて困難だったため、必然的にメモリによる遅延はありませんでしたが、できる演算に限りがありました。

一方で、デジタル時代ではメモリが使えますので過去のデータが自由に使えます。 (なお、未来のデータを使おうとするとそのデータが来るまで処理を遅延させることになります)。

これをアルゴリズムにうまく組み込むことが重要です。

冒頭の絵では入力が一直線に処理されているだけでしたが、下記のようにメモリを追加すれば、低遅延なストリーム処理に加えて、過去のデータへのアクセスが可能になります。

FPGAで効率よくメモリを使うモデル

AI で言えば RNN などのリカレント構造が作れるという事ですね。

以前「リアルタイムコンピューティングのメモリ階層」という記事を書き、こんな絵を載せました。

リアルタイムコンピューティングのメモリ階層

メモリ階層をしっかり考えて、アルゴリズムや学習モデルに反映させるというのは、リアルタイム性を高める上では非常に重要です。

新・標準プログラマーズライブラリ　RISC-Vで学ぶコンピュータアーキテクチャ　完全入門

おわりに

AIとGPUの台頭で、本来 FPGA が得意だったリアルタイム性の高い分野が、非リアルタイム分野で研究されていた画像処理研究からだいぶ置いて行かれてしまってているように思います。

• 計算機アーキテクチャを勉強しないと太刀打ちできない
• 難しいFPGAプログラミングを覚えなければ実験データすら取れない

などの壁はあるものの、これらを乗り越えれば

• GPUのことしか考えていない人とは一線を課す新しいモデルの提案
• みんなが使っているのとは全く異なるオリジナルなデータを使った研究

という差別化が可能です。

大事なのは本質がわからないまま表面的な理解でFPGAを使うと、余計な苦労をした挙句に成果が出ない、なんていうもったいないことになるので、よく理解して、作戦を立ててから使って欲しいという事です。 ちゃんとわかってしまえば、とても楽しいですし、レッドオーシャンで血の涙を流している研究者を横目に、前人未踏のブルーオーシャンを次々開拓していける事でしょう。

若い学生さん、研究者の皆様、FPGAは楽しいし狙い目ですよ！

私は研究者というよりはエンジニア側の人間ですので、「こんな研究があると面白い」という情報交換だったり、「こんな環境なら作れるよ」というったエンジニアリング側からのお手伝いしか出来ないのですが、新しくて面白い研究が生まれてくるのを楽しみにしております。そしてなにより、研究者の方々にも不毛な作業を減らし充実した日々を送っていただけれれば幸いに思う次第です。

FPGAに対する誤解と「どうFPGAを使うべきか」

はじめに

以前、FPGAを始めるときの壁 というのを書かせて頂きました。 また最近、CPU や GPU についても幾つか個人的意見を書かせて頂きました。

今日は、今のところ私が最も熱を入れている FPGA について私見を書いてみたいと思います。

FPGAの原理と構成

FPGA に対する誤解

今、特に GPU などで AI に取り組んでいる方々が「FPGAというデバイスがあるらしい」と興味を持ってこの分野の門をたたいてくださる機会が増えているように思います。

一方で、高価なFPGAボードを買ってきて、ものすごく苦労してベンダーの出しているツール(AI開発ツール含む)を覚え、慣れない難しいプログラムのデバッグに翻弄され、GPU の 10倍も100倍も苦労して作った挙句、GPU の 1/10 も性能が出ず、性能も電力もコストもリアルタイム性すらGPUに負け、いいとこなしで「意味のない研究だったね」と酷評されて終わってしまうなどという、なんとももったいない話ですが、こんなことも往々に起こっているのではないかと思います。

このパターンが発生する理由は意外とシンプルで、「GPU が最も得意とする処理を、わざわざ余分な苦労を追加して FPGA で無理やり同じことをやっている」からに他ならないケースが多い気がします。そして図らずも 苦労して追加した余計な事 が性能を下げてしまっていることに最後まで気づけないケースです。

そしてこのケースを生み出している要因の一つに、FPGAベンダーが「このツールを使えばGPUでやってるAIをFPGAで開発できるよ」と、「GPUの代替になるFPGA」 を声高に宣伝文句にしている点があるように思います。ベンダーのこのうたい文句は、既にFPGAを使いこなしている人に対して「さらに GPU 市場の AIが簡単に取り込めるよ」という意味も含むので一概に批判もできないのですが、一部の人に誤解を生んでいる可能性はあるように思います。

先日、X で FPGA に USBカメラを繋ぐことについて下記のようなことを書いたら少し反響がありました。

画像認識で USB カメラ使うと、その時点で Linux なりで一度画像取り込む話になり、FPGA が GPU より有利なアクセラレータにならない限り成果にならない。
一方で、FPGA にイメージセンサを直結すれば、低遅延画像処理でるし、シャッターに同期して照明やアクチュエータも制御出来て勝負の土俵が変わる

— Ryuji Fuchikami (@Ryuz88) 2025年12月17日

FPGAを カメラのISP(Image Signal Processor) 代わりに使うのが便利だとして使っていたような層には、私と同様に FPGA + USBカメラに違和感を感じる方もおられたようです。

一方で、「GPU の代わりに FPGA を使ってみよう」というところから入ってくる方は、今の Jetson を KV260 に置き換えてみたり、PC で GPUボードが挿さっているところに替わりに Alveo や Agilex を挿さしてみるなどの話になるので、「カメラはそのまま今まで使っていたUSBカメラでいいよね」となってしまい、そこに疑問すら持たないわけです(むしろ条件を揃えて比較しないといけないと思ってわざわざGPUの土俵で比較評価をしてしまうわけです)。

一方で、先に違和感を感じた方からすると「そんなことしたらそれだけでFPGAのいいとこ全部死んじゃうよ！」という悲鳴が上がるのもまたよくわかります。

このやり方で FPGA に入ってきた場合、GPU と同じ条件で GPU に勝たないといけないので、実はかなり大変です。

• GPUの得意な「同時に同じ計算を大量に」が効かないアルゴリズムで戦う
• INT7以下とか 独自定義の非線形浮動小数点型とか、GPUにない演算を多用する
• ホモジニアスなGPUに不利でヘテロジニアスな演算器構造を使うモデルを捻りだして勝ちに行く

などなど、GPUと同じ土俵で戦う際のノウハウと戦略を持っていないと、手も足も出ませんし、これらを駆使しても、常に先端製造プロセスで作られているGPUの地力でねじ伏せられてしまい、とても苦しむことになります。

RECONF研のこちらの天野先生のメッセージで リコンフ8策 というのを見かけました。まさに金言だと思います。

実践入門FPGA開発　7日間で学ぶ生成AIによる回路設計 技術の泉シリーズ

ではどういうときにFPGAを使うべきなのか

ここではカメラの例を出しましたので引き続きそのまま例にしますが、FPGA を ISP として使っている層は、ISP に関しては GPU でやるより FPGA でやる方が、はるかに計算効率が良く、電力もコストもリアルタイム性も勝てることを知っています。

つまり、FPGA がすでに GPU に勝っている領域からスタートし、そこに AI など新しいものを足していく というのが個人的に最もお勧めするやり方です。

画像処理(マシンビジョン)であったり、スマートNICやネットワークスイッチのような通信分野、ロボットなどのリアルタイム制御、特殊なセンサー／アクチュエータなどのデバイス制御、などなど何もしなくても FPGA が圧勝していたり、そもそもCPU/GPUでは不可能なものだったり、FPGAが得意な分野は多数あります。

ここを出発点として、FPGAの強みを失わない範囲で拡張していくことが重要です。

これはズルでも何でもなく、裏返せば GPU も同じことを既にやっていて、自分の得意分野で戦っているから、FPGA より優位に見えているだけです。

プログラムはなぜ動くのか 第３版　知っておきたいプログラミングの基礎知識

計算機科学に触れよう

ここで、多くの場合、GPUはなぜAIが得意で、CPU は何故AI計算でGPUに負けているのか、などの なぜ？ に踏み込まず、「FPGAと言うものがあってなんかGPUより高性能らしい」という話だけで、意味も分からず使ってしまうと失敗します。

先のリコンフ8策の分中でも「ハードウェアで実装したんだからソフトウェアに比べて速くなるに決まっている」なんて言葉が飛び出しておりましたが、アカデミック分野に属する先生方からですらこんな声が出る事もあるわけですから、やる側がそのレベルで飛びついてしまってはいけないのです。

もちろん、FPGA は正しく使えば、GPUより高性能になりえますし、わかってくるととても楽しいものです。

ですので、入り口で躓かないために計算機科学に興味を持っていただきたい ということをすごく感じてしまうのです。

ヘネパタ読めとまでは言いませんので、ネット上でいろいろ計算機の仕組みを調べてみたり、実際に CUDAのコードを書いてみて GPU の仕組みに触れてみるとか、いろいろ試してほしいと思います。 そのうえで、自分のやりたいこと、考えているアイデア、拘りたいポイントなどよく考えて、「これFPGAなら試せるアイデアじゃないか？」というゴールまでの道筋をしっかり考えて取り組むことをお勧めする次第です。

GPUパワー炸裂！初心者から始めるCUDAプログラミング

新しい時代の FPGA-AI 8策が必要

最後に、今なぜこんなことになっているかを少し振り返っておきます。

私にとって比較的なじみの深い画像信号処理の分野で言えば、アルゴリズムと計算機アーキテクチャをセットで考え、新規性と進歩性のある、新しいシステムを生み出すことが重要です。

ところが、認識率という観点でのみアルゴリズムを研究されている方々の中で、「それはAIと比べてどうなのか？」という ルールベースアルゴリズムの研究の成果の価値がAIと比較されてて、精度観点だけで駆逐されていった と言うのがあります。

また、ビジネスの観点でも、AIにあらずんば投資対象にあらず と言わんばかりに、AIでないと研究予算が取れなくなり、AI人材でないと就職先が絞られていく という事情変化もありました。

必然的に、多くの学生や研究者が何かしら AI と絡めた研究をこぞってやり始めて現状に至ります。

加えて AI の台頭で、GPUを使った GPGPU計算が台頭してきたため、今まで CPUに勝てればOK であったアーキテクチャ研究が、GPU にも勝たなければいけなくなりました。しかもGPUが得意とするAI分野でです。

正直、私はそこまでAIに拘りも無いのですが、時代がそれを許してくれないので、何とか、世の中の需要を満たす建前も必要です。

拙作の LUT-Network などが生まれてきた背景にもそういう部分は無視できません。

時代の変化に合わせて 8策 をアップデートするが必要があるのかもしれません。

GPU と比較されたときの理論武装が必要です。

• GPU向けのモデルをそのまま使わない(同じ土俵で戦わない)
• GPUが持つハードマクロ演算器が役立たない演算を入れる(GPUの苦手を狙う)
• FPGAのLUTやDSPやBRAMの特性を生かしまくるモデルにする(FPGAの得意を活かす)
• Sparce性、ヘテロ性など、均一でない計算を作る
• 演算器へのデータ投入でキャッシュより効率の良いメモリアーキテクチャで差をつける
• リアルタイム性を活かしたアルゴリズムモデルを考える(リカレント構造など)
• 他の特殊なデバイスと連携する、RGB以外のデータを扱う
• 複数のセンサーやタイミングを組み合わせる

などなど、様々な要素を考えてみて欲しいと思います。

FPGA はストリーム処理が得意

FPGA は基本的にストリームデータに対するパイプライン処理が得意です。

カメラからのデータはストリーム的に出てきますし、出力もDVIやHDMIなどにストリーム的にそのまま出力できます。

一方で、ストリームデータは一度メモリに貯めれば、GPU などで並列演算可能であり、メモリに格納された GPU の処理結果をまた ストリームに戻すことができます。

この際に

• メモリに溜めた遅延が増加する
• メモリと言う新しいコストと電力が発生する
• メモリとデータ転送を行うDMAなりの新しいコストと電力が発生する

などの不利が発生します。

しかしながら、先に述べた USBカメラの例の場合、

• USBのプロトコルスタックや V4L などが画像読み出しの段階で、GPUに便利なフレーム単位にメモリに貯めてしまう
• 結果を表示するにも OpenGL などの為に GPU と同じようにビデオバッファにデータを並べないといけない

という制約の為に、

• わざわざ GPU用に並列化されたデータをコストを掛けてFPGA用に再ストリーム化する
• FPGAの出力ストリームをわざわざフレームバッファに貯めなおして、GPUと同じ結果にした後、実は再度、再ストリーム化されて表示される

という非常にもったいないことになっていたわけです。

これで勝とうとすると、よほど「並列に実行したときでもGPUに非効率な計算列」になってない限り勝てず、とても不利な戦いを求められます。

なので、ストリーム入力＆ストリーム出力で、リアルタイム性が重要なFPGAの得意な土俵で戦うべきなのです。

リアルタイム性については、「単にサクサク応答すると気持ちい」と言うだけではなく

• 今の音を逆位相の音で打ち消すノイズキャンセリングのような信号処理
• 揺れているドローンを安定させる
• 転ぶ前に足を出してバランスをとるロボット
• 新しい情報を瞬時に判断して株の売買をするシステム
• 絶対に負けないジャンケンゲーム

みたいなものを考えていくと、AIを使う事も生きてきますし、FPGAの強みが出てくるわけです。

おわりに

これまで FPGA 人口ってどんどん高齢化していると思っていたのですが、最近 FPGAやってみたいという若手とお話しさせて頂く機会も増えました。大変ありがたいことです。

一方で「FPGA やってみたけど成果が出ない」という相談も増えるようになってきております。

FPGAは苦労も多く手戻りも大きい為、早い段階で 成果の出る道筋 に軌道を向けることが大事です。

同じようなことで悩んでおられる方、「これからFPGAに触ってみたいという方」に、失敗しないFPGAの始め方 を模索する上でのヒントになれば幸いです。

コンピュータの構成と設計　MIPS Edition　第6版 　上・下電子合本版

なぜGPUは高性能なのか

はじめに

最近 FPGA をやっているとよく GPU と比べられるという事が起こります。

本来の FPGA の得意分野(通信処理とか画像信号処理とか)を考えると、不思議な感じもするのですが、逆に FPGA が汎用計算機と比較されてしまうぐらい守備範囲を広げているとも考えられますので、喜ばしいことです。

FPGA との比較は後に回して、まずは どうしてCPUに対してGPUは高性能になれたのか？ について考えてみたいと思います。

HPC は一旦おいていて、コンシューマでも手の届くレンジで最新のものとして GeForce RTX 50 series を眺めていたのですが、TSMC 4N での製造でダイサイズが 16.9 ～ 750mm² までラインナップがあり、CUDAコア数が 2,560 ～ 21,760、TensorCore も含めた演算性能だと 13.2 ～ 104.8 TFLOPS(FP32) となっているようです。

同世代の Core Ultra 9(Intel) や Ryzen(AMD) などのコンシューマ向け x86 CPU が 0.5～10 TFLOPS 程度のレンジだと思いますので、同じ半導体プロセスをもってして、計算機アーキテクチャの差で数十倍程度の性能差は出していることになるようです。

GPUパワー炸裂！初心者から始めるCUDAプログラミング

SIMD と SIMT と

この二つは計算機のアーキテクチャとしてはかなり似ていると思っているのですが、ソフトウェアから見た見え方はだいぶ変わってくると思います。

SIMD(Single Instruction Multiple Data)は、CPU の命令の中に並列計算を行う命令を用意して１つの命令で同じ演算を並列に沢山計算するというもので、x86 の AVX や ARM の NEONなどが有名です。

一方、SIMT(Single Instruction Multiple Thread)は、主に GPU で用いられているもので、同じ命令を実行する沢山のスレッドを同時に実行します。

どちらもハードウェアとしては、大量のALU(演算ユニット)に対して、１つの命令デコーダで構成されますので、かなり良く似ています。

ではなぜ SIMD は SIMT に十分に迫ることが出来ていないのでしょうか？

一つの理由に、SIMD はソフトウェア互換性を保ったまま並列度を増やすのがとても難しいという事があるように思います。

AVX-2(256bit) が AVX-512(512bit) に並列度倍増しようとしたときに、Linux の作者である Linus Torvalds 氏がこんな苦言 を呈したのは有名なのでご存じの方も多いかもしれません。

SIMD の並列度の増強は、新命令の追加だけでなくレジスタ幅も広げなければなりません。レジスタはOSなどがプロセスやスレッドをスイッチするときに退避復帰する部分ですので、まずOSがアップデートされなければその機能を使う事が出来ません。 加えて当然ながらコンパイラも新命令に対応を迫られ、アプリケーション側もその新命令を使ってプログラムしなければ恩恵に預かれません。 要するにSIMDの性能向上は方々のソフトウェアエコシステムに都度対応してもらうという迷惑を掛けないと進化できません。

一方で、SIMT はもともと「このスレッドをできるだけ沢山一度に実行して」という形でプログラミングする為、同じプログラムが、コア数の少ないGPUでは少しのスレッドに分けて何度も実行され、大量のコアを持つGPUでは一度に大量に数度だけ実行される、という動きになります。 早い話が元のプログラムはそのままで、デバイスドライバ層以下の狭い範囲の対応だけで並列度の高い新しいGPUの恩恵が受けられます。 これがGPUの強みの一つと考えており、半導体プロセスの進化とともにどんどんコア数を増やし、並列度を上げてきました。

それでは「CPUでもSIMTをやればいいじゃないか」と思われるかもしれません。 しかし残念ながら、CPU では過去にあまりにも複雑な命令を沢山実装しすぎたせいで簡単にはそれができません。SIMTをやりたければ、互換性の為に過去のすべての命令に対応したスレッドを並列実行しないといけないため極めて高コストになってしまいます。 SIMD は 新しく追加した「演算に特化したシンプルな命令だけ並列化する」からこそCPUでも採用できている部分があると思われます。

だったら、シンプルな命令だけ実行できるコアを別に用意して、それ用の命令列も別に作ってSIMTを追加すればいいじゃないかとも思われるかもしれません。が、それは GPU入りCPUに外ならず、既にあちこちに存在している通りです。

CUDAプログラミング実践講座 － 超並列プロセッサにおけるプログラミング手法

最先端プロセスの威力

次に、FPGA と比較するために、最先端プロセスの凄さにも触れておきます。

半導体は大量に製造販売できる需要の見えているものは、最先端プロセスでの製造に投資しやすく、大量生産の効果で価格も抑えやすいです。 今GPUはご承知の通りAI需要で引っ張りだこでですので、惜しげもなく先端プロセスに投資できる状況にあるかと思います。

私が普段使っている KV260 などの 16nm プロセスの FPGA の載ったものは DSP(積和演算器)の数も1000個程度の規模であるため、CUDAコアが数万個もある最新のGPUと比べると性能に圧倒されるわけですが、逆に同じ 16nm 世代の GPU として GeForce 10 series あたりを参照すると、CUDA コア数も 256 ～ 3840個で、同じ世代の FPGA でも積和演算性能であれば近いものが狙っていけますし、価格帯も数万から数十万円のGPUの値段に対して同じ価格でFPGAも同クラスの規模感が狙っていけます。

要するにアーキテクチャではそれほど優劣は無いと思っているのですが、現実には、最先端プロセスの採用に関して GPU がだいぶ先を行っている感があります。

今のところ FPGA は先端プロセスで作っても直ぐに大量に売れるわけではありませんので、こなれた価格で使える品種のプロセス世代が変わるにはどうしても時間がかかってしまいます。

プロセスの進化で圧倒的に変わるのがダイ面積あたりに詰め込めるトランジスタの数でありそのまま演算量となります。半導体の価格は面積と強い相関があるので、FLOPS/$ が改善します。 またしばし微細化が進むと１つあたりのトランジスタでの電力も減るため FLOPS/W も改善します(これとは別に「面積当たりの電力」は近年悪化の一途のようですが)。

今朝方、試しに RTX 50 series の性能を Wikipedia を見ながらプロットしてみました。

GeForce RTX 50 series

1mm² 増えるごとに コア数が 31.5個ぐらい増え、0.149 TFLOPS 程度上昇する計算のようです。

同じことを GeForce 10 series でもやってみました。

GeForce 10 series

1mm² 増えるごとに コア数が 8.45個ぐらい増え、0.0259 TFLOPS 程度上昇する計算のようです。

ものすごく大雑把な計算ですが、TFLOPSで見ると TSMC の 16nm を 4N にすると GPU では 5.75 倍ぐらい面積当たりの性能効率が上がっているようです。

はやい話が FPGA は、10倍まではいかなくても 5 倍ぐらい不利なプロセスで戦っているというのが見えてきたのではないかと思う次第です。

FPGAの原理と構成

おわりに

「敵を知り己を知れば、百戦危うからず」と言いますが、まあ敵とは言わないまでも他のプロセッサアーキテクチャの特性をよく理解して、何を選択するのが最適なのか考える事は大事だと思います。

せっかく「FPGA で尖ったことがやりたい」と思っていたのに、「やってみたら、GPUでやるのに比べて良いところなしだった」だと寂しいですので、どういうところが強みで、弱みなのかと合わせて、「どれぐらい弱いのか」、または「どれぐらい強いのか」をもう少し定量的に見ておくこともまた必要なことのように思いました。

しかし、久々に最新スペックを見てみましたが、GPU凄いですね。 とはいえまだまだ GPU より凄い物を作れる余地は沢山あるのだと思いますので、また新しいものが出てくることを期待している今日この頃であります。

コンピュータの構成と設計　MIPS Edition　第6版 　上・下電子合本版

撮影ボックス買ってみた

以前、マクベスチャート(カラーチェッカー)欲しいけど高いと呟いたら、安いのあるよと言うお話を頂いたことがあります。

お礼が遅くなってしまいましたが、MIPI 4-laneを引き出せる素敵な基板の頒布ありがとうございました。

自分が使ったカラーチャートはSpyderCHECKR24という1万円しない安物ですが、リファレンス値は公開されているので正しく使えばこの程度の色補正は可能です。https://t.co/wr7igSHcCT

— timit (@timit3) 2025年7月13日

Datacolor SpyderCHECKR 24 - SCK200、24色パッチとグレーカード

今回は、照明環境の話です。

画像処理開発していると、カメラで対象が綺麗に写らず「ドーム照明ほしい」、「同軸照明欲しい」、「積分球欲しい」、となりがちなシーンはしばしあるわけですが、個人ではスペースも金額も辛いので、何かないかなと思っていたらスマホ向けの撮影ボックスなるものがあることを知ったので買ってみました。

私が買ったのはナカバヤシ株式会社さんの SAC-BOX04 という製品になります。探すと他にもいろいろなものがありそうです。

こんな使い方をしております(まあMNISTには要らないけど、例として(笑))。

MNISTの撮影

多くの場合一般家庭にあるような照明環境ですと、照明が一部だけ鏡面反射で強く光ってしまい均一な画像が撮れないという事がよくあります。身近な例だと「口座を開くのにマイナカードの撮影認証がうまくいかない！」などがその典型でしょうか。

ですのでなるべく、360度全体から間接光を当てたいという要求が出てくるわけです。

これを極めてちゃんとやる場合は、積分球と言うランバート反射(すべての方向に一律に反射する)特性に近い素材で物体でドーム状に覆って、それを経由して間接光を当てるという装置を使うそうです。

SAC-BOX02 LEDライト搭載 折りたたみ撮影ボックス 20cmタイプ

そうでない場合でも被写体に対してなるべく360度すべての方向から均一な光がやってくるようにするとムラのない撮影が可能です。

この場合の条件は

• 直接的な反射光が入る角度に光源を置かない
• 間接光を反射してくれる対象はなるべく全方向にある

のような事をなるべく実現したいわけです。

その場合に撮影ボックスがとても便利そうに思いました。

本来の用途としては、メルカリとかヤフオクに出品するものを撮影する用途だと思いますが、個人や小さな研究室レベルの画像処理の研究でも案外便利そうな気がします。

で、届いたものを開けてみたのですが。

コンパクトサイズ

なかなかコンパクトです。

収納用の袋

持ち運び用の袋もついていました。

照明はLEDのリング照明で、薄いのでコンパクトにしまえる理由がわかりました。

LEDむき出しなので何かしらディフューザーになるものを追加で加工しても面白いかもしれません。

照明

USBを電源とするようで、輝度や色合いをリモコンで調整できるのもいいですね。

照明の調整

背景のシートも複数色あって便利そうです。

背景のシートも複数色

真上に穴も開いていて、リング照明の中心からも撮影できるようです。

上から撮影

近年は AI の学習の為の撮影を行う人も増えていると思います。

もちろん AI自身に写りの悪い画像に対する耐性を持たせたいケースももちろんあるかとは思うのですが、そうではなくもっと画像の持つ本質的な情報を学習させたいとき、綺麗に対象が写っていないというのは研究の本来の目的からすると遠回りになってしまいます。

こういったグッズをうまく活用するのもいいなと思った次第でした。

ちなみに私の作ったカメラをスマホで撮ってみたら、本来の用途通り結構きれいに写りました。

たまにこういうものを買ってみると楽しいですね。

PULUZ 撮影ボックス 写真スタジオ「ミニ的に小物専用」20cm簡易 LEDライト2本付き 6色背景布 卓上撮影ブース 持ち運び便利 折りたたみ 撮影用 USB給電 組立簡単 物撮り 自宅 写真撮影用キット (20cm·LEDライト2本)