1 CPU-GPU同期の基礎
CPU-GPU同期とは、CPU側とGPU側で行われる処理の順序や完了状態を整合させ、計算結果や転送データを安全に利用するための考え方と仕組みの総称である。GPUは並列実行や非同期投入を前提とすることが多く、CPUが「投入した処理がすぐ終わった」と想定すると誤動作につながる。そのため、いつデータが有効になり、どの段階の成果を参照できるかを管理することが中核となる。
同期は「待つ」だけを意味しない。投入順序の制御、依存関係の明示、メモリの可視性の確保、完了検知の仕組みを組み合わせ、正しさと効率の両立を狙う設計分野である。結果として、計算だけでなく転送、描画、後処理など複数フェーズが同一プログラム内で破綻なく連携する。
1.1 非同期実行と順序の課題
1.1.1 CPUとGPUの実行タイミング差
CPUとGPUは異なる実行基盤を持つため、指示の投入と実行完了の時間差が大きくなる。CPUは命令を投入した後に次へ進みやすく、GPUは内部キューに基づいて実行を進める。結果として、CPU側で参照したいデータが、GPU側ではまだ計算中、あるいは転送中である場合が起こり得る。
また、複数の内部ユニット（計算、DMA転送、描画など）が並走する環境では、完了順が投入順と一致しないこともある。同期がない場合、こうした時間的不一致が読み取りの前倒しや書き込み競合を誘発する。
1.1.2 計算・転送の同時実行による影響
GPUは計算と転送を同時に進める構成を取れる場合がある。たとえば、あるデータをホストからデバイスへ送っている間に、別のバッファ上で計算を回すことが可能になる。この並列性は性能向上に寄与する一方、依存関係を意識せずにバッファを再利用すると、まだ到達していない入力を計算が参照したり、計算が書き終える前に転送が次段へ持ち出したりする。
同期は、同時実行の恩恵を保ちつつ「必要な場面だけ」整合を取るために用いられる。どの操作が同一のバッファ領域に対して相互依存を持つのかを整理し、必要な順序だけを保証することが求められる。
1.2 同期で守るべき性質
1.2.1 データ整合性（読み書きの整合）
同期が確保すべき第一の性質はデータ整合性である。具体的には、あるバッファやテクスチャについて「書き込みが完了し、その結果が参照側から見える状態」になっていることを保証する必要がある。整合性の破れは、古い値の参照、未初期化領域の利用、競合による破損といった形で現れる。
整合性は単なる完了待ちでは不十分なことがある。書き込みが完了していても、ホストとデバイス間で観測可能な状態が一致していない場合、可視性の問題として表面化する。したがって同期は、完了と可視性をセットで考える必要がある。
1.2.2 進行保証（いつ完了とみなすか）
第二の性質は進行保証、つまり「いつ完了したと判断するか」である。GPU側の処理には複数段階があり、キュー投入、実行開始、メモリ反映、後続依存の解放など、完了と呼ぶ境界点が異なることがある。CPUが参照可能になる時点を誤認すると、データの整合性だけでなくプログラムの論理も崩れる。
このため、フェンスやイベントの完了シグナルなど、明確な観測点を用意し、それに基づいて制御フローを決定する。進行保証は、最小限の待機で正しさを担保するための前提条件となる。
1.3 同期が必要になる代表パターン
1.3.1 GPU結果のCPU側利用
GPUが計算した結果をCPUが次の処理で利用する場面では同期が必須になる。CPU側が結果バッファを読み取るより前にGPUの書き込みが終わる必要があるほか、必要に応じて転送も完了している必要がある。たとえば、GPU上の中間値を一時的に保持し、一定周期でホストへコピーして分析するような場合、コピー完了と計算完了の境界を明確にすることが重要になる。
同期が欠けると、CPUが古い結果を掴む、部分的に更新された領域を読むといった問題が発生し、結果の統計や判断が大きく歪む。
1.3.2 GPU間のデータ受け渡し
同一GPU内でも、異なるエンジンやキューを跨いだデータ受け渡しでは整合を取る必要がある。たとえば、あるキューで生成したバッファを別キューで参照する場合、生成側の書き込みが観測可能になってから消費側を開始する必要がある。
また、複数GPU構成ではデータの移送経路や到達タイミングがさらに複雑になる。受け渡し経路ごとに依存関係を表現し、正しい順序で処理が流れるように同期を設計することが要点となる。
2 同期プリミティブと機構
同期プリミティブは、処理の進捗を表現し、必要な待機や依存関係を構築するための部品である。代表例として、フェンス・イベント、ストリームやキュー、そしてメモリ可視性に関する機構がある。これらは単独で用いられる場合もあるが、実運用では組み合わせて使われることが多い。
2.1 フェンス・イベント
2.1.1 フェンスの役割と使い所
フェンスは、特定のGPU側操作が進捗したことを示すための同期対象として扱われることが多い。CPUがフェンスを監視し、到達した時点で「その時点までに関連する処理が完了している」とみなす設計が可能になる。
フェンスは「いつ先へ進めるか」を決めるのに向く一方、待機が増えるとレイテンシやスループットを押し下げる。したがって、フェンスの設置点を絞り、必要な区間だけを区切る運用が一般に望まれる。
1 CPU待機とGPU進捗確認の違い
CPU待機は、CPUスレッドがシグナル待ちの状態に入り、以降の処理開始を遅らせる可能性がある。一方、GPU進捗確認は、GPUが進んだかどうかを観測し、待つか別処理に進むかを判断するための情報源として使われる。
設計上は「待機そのもの」ではなく、「待機の要否判断」をより賢く行うことで効率化が進む。たとえば、フェンス到達まで他の作業を実行できるなら、待ち時間を隠蔽できる場合がある。
2.1.2 イベントによる依存関係の表現
イベントは、特定操作の完了を示す信号として利用され、依存関係をグラフ的に表現するのに向く。あるキューの処理がイベントの到達を待ち、到達後に次段の処理が起動されるように設定することで、必要な順序だけを保証できる。
イベントは「待ち」をCPUに押し付けず、デバイス側のスケジューリングに反映できる場合がある。結果として、CPUがブロックしない形でパイプラインを維持しやすい。
2.2 ストリーム・キューと依存関係
2.2.1 ストリーム単位の順序保証
ストリームやキューは、投入された命令の順序を一定の範囲で保証する単位として設計されていることが多い。同一ストリーム内では投入順に実行されるよう管理され、異なるストリーム間では明示的な依存設定がない限り順序は保証されない。
この性質により、依存がない処理は別ストリームへ分離して同時実行の余地を作り、依存がある部分だけイベントやフェンスで接続する、という戦略が取れる。結果として、順序保証の範囲を狭く保つことでオーバーヘッドを抑えやすい。
2.2.2 複数キューでの整合戦略
複数キューでは「どの操作が共有資源を触るか」を軸に整合を組み立てる。バッファの生成→消費、あるいは書き込み→読み取りのように、リード・ライトの方向が衝突する箇所だけを接続し、その他は独立として扱うのが基本方針となる。
実装では、イベント待機の追加や、キュー間での同期点の配置を行う。さらに、コピー系と計算系を分離する場合は、転送完了と参照開始の境界を誤らないよう注意が必要である。
2.3 メモリ同期と可視性
メモリ同期は、単に「処理が終わったか」だけでなく、「他方がその結果を見ることができるか」を保証する領域である。CPUとGPUのメモリ階層が異なる場合、可視性のズレが発生する。
2.3.1 デバイスメモリの書き戻し/反映
デバイス側で行われた書き込みが、観測側に反映されるタイミングを保証する必要がある。特に、書き込みがキャッシュや書き戻し機構を経由している場合、単なる順序待ちだけでは観測値が更新されていない可能性がある。
そのため、メモリの反映や整合を扱う同期操作（またはそれを含むプリミティブ）が使われる。これにより、消費側が正しい更新後データを参照できる。
2.3.2 ホストメモリの一貫性確保
ホストメモリへの転送や参照では、ホスト側が見ている内容がGPU側の更新を反映しているかを確かめる必要がある。転送完了と読み取り開始の間隔が短いと、古い値や不完全な転送が混入することがある。
一貫性確保は、コピー完了通知や依存関係設定と連携して成立する。読み取り前に必要なデータ到達を保証することで、統計や制御判断の誤りを防ぐ。
3 実装上の設計指針
同期の設計では、正しさを満たすだけでなく、待機による損失を抑え、デバイスの並列性を引き出すことが重要になる。以下では、待機の最小化、パイプライン化、危険な同期の回避を中心に述べる。
3.1 待機の最小化（レイテンシとスループット）
3.1.1 ハードウェア待ちのコスト見積もり
待機のコストは一様ではない。GPU側の処理時間、転送帯域、競合するキューの混雑などにより、シグナル到達までのばらつきが生じる。さらに、CPU側がブロックするか、ポーリングで消費するかによって体感上の遅延も変わる。
見積もりでは、同期点がどの資源に対する制約になるかを分類する。たとえば、計算完了待ちなのか、コピー完了待ちなのか、あるいはキュー競合による待ちなのかを切り分けると、最適化の方向が明確になる。
3.1.2 可能な範囲でのオーバーラップ
待機時間の隠蔽は、パイプラインを崩さないことに依存する。CPUが次のフレームの準備や別バッファの準備を進められるなら、同期点までの空白を埋められる。GPU側でも、独立な処理を別キューに分離し、イベントで連結することで同時実行の度合いを高められる。
オーバーラップの効果は「依存がない領域を分離できるか」によって決まる。依存境界を厳密に切るほど、無駄な直列化を避けやすい。
3.2 パイプライン設計
同期は、逐次処理を作るためのものではなく流れを設計するための手段でもある。パイプラインでは、異なる段階が同時期に進行する前提で依存関係を接続する。
3.2.1 ダブルバッファリングとキューイング
ダブルバッファリングは、あるバッファをGPUが扱っている間に、CPUが別のバッファへ次の入力を準備する考え方である。これにより、同期点をフレーム境界やバッチ境界に寄せ、細粒度の待機を減らしやすい。
キューイングを組み合わせると、投入の粒度と依存の配置が整う。結果として、バッファの再利用タイミングが明確になり、競合のリスクが下がる。
3.2.2 バッチ処理と粒度調整
粒度が小さすぎると同期点が増え、待機や管理オーバーヘッドが支配的になる。逆に粒度が大きすぎると、最終結果が得られるまでの遅延が増え、応答性が落ちる。同期設計では、このトレードオフを対象ワークロードに合わせて調整する必要がある。
バッチ処理は、同期回数の削減と転送効率の改善に寄与することがある。ただし、バッチの内部で依存関係が強く、早期に結果が必要な場面では適用が制限される。
3.3 デッドロック・過同期の回避
同期不良は性能低下だけでなく、停止状態（デッドロック）を招くことがある。また、必要以上の同期は「正しいが遅い」結果を生むため、設計段階で抑制が必要になる。
3.3.1 循環依存のパターン
循環依存は、AがBを待ち、同時にBがAを待つような構造で発生する。たとえば、あるキューがイベントXの到達を待つよう設定し、そのイベントXは別キューの処理完了に依存しているが、その処理側も元の待ち条件に結び付いている場合がある。
対策として、依存グラフの方向性を保ち、待機条件が上流へ戻らない形で接続する。データ所有者や生成元を起点に整理すると、循環を検出しやすい。
3.3.2 意図しない直列化を見つける
過同期は、独立してよい操作まで同一の同期点にまとめてしまうことで起こりやすい。結果として、並列実行の利点が失われ、デバイスが待ち状態に入り続ける。
意図しない直列化は、同じ種類の処理が連続するだけでなく、依存設定が広すぎることでも生じる。キュー間接続を最小化し、必要なデータ境界にのみイベントを貼ることで抑制できる。
4 性能評価とデバッグ
同期の成果は、正しさだけでなく性能と再現性によって評価される。計測と可視化は、ボトルネックが待機なのか、計算なのか、転送なのかを切り分けるために重要である。
4.1 計測すべき指標
4.1.1 待機時間、転送時間、実行時間
待機時間は同期点でブロックされた期間、あるいはシグナル待ちのために進めなかった期間を指す。転送時間はホスト・デバイス間のコピーやデバイス内転送の支配度を示す。実行時間はGPUが実際に演算や描画を行う期間である。
これらを分離して測ることで、「同期が原因で遅い」のか「転送が詰まっている」のか「計算自体が重い」のかを判断できる。同期設計の改善案が誤方向になるのを防ぐ効果がある。
4.1.2 同期回数とオーバーヘッド
同期回数はイベントやフェンスの発行・待機の頻度として現れる。回数が多いほど、管理のためのコストやスケジューリング負荷が増えることがある。さらに、同期点ごとにキャッシュやパイプラインの効果が薄れるケースもある。
評価では、同期の粒度と回数の関係を観察し、必要な区切りがどこで成立しているかを確認する。最適化は「同期をゼロにする」ことではなく、「必要な最低限」を探す作業となる。
4.2 デバッグ手法
同期関連の不具合は、ランダムに見える場合がある。なぜならタイミング依存の挙動が多く、実行順が環境で変わるからである。可視化と体系的切り分けが有効になる。
4.2.1 タイムラインと依存関係の可視化
タイムラインは、投入された命令がいつ開始し、いつ完了し、どこで待機が発生したかを時系列で示す。依存関係の可視化では、イベントやフェンスの結線がどの段をまたいでいるかを追跡できる。
この手法により、「本来は独立に走るべき処理が同期点で結ばれ、直列化されている」などの問題を発見しやすい。データ競合の有無も、依存の不足として推測できる。
4.2.2 データ不整合の切り分け手順
データ不整合では、値が変になる対象（どのバッファか）、発生タイミング（どのフレームか）、再現性（常にか、条件付きか）を整理する。次に、当該バッファに対する書き込み側と読み取り側の間に依存が設定されているかを確認し、可視性の更新要否も点検する。
切り分けでは、同期点の追加によって症状が消えるかどうかを利用する。ただし同期を増やしすぎると性能が激減するため、原因特定の短期間テストとして扱うのが望ましい。
4.3 よくある誤解と改善例
4.3.1 「待てば速い」は本当か
「待てば速い」という見方は誤解になりやすい。待機は多くの場合、処理完了までの空白を増やすため、純粋にはレイテンシを悪化させる。とはいえ、待機を「正しい境界で必要最小限」使うことで、無駄な再実行や無効な計算を減らせるため、結果として総時間が短く見えることがある。
改善の鍵は、待機の有無ではなく、待機の配置と依存表現の粒度である。過度な待機は直列化を招くため、効果がある場面かどうかを計測で確認する必要がある。
4.3.2 同期位置の最適化事例
最適化の典型例として、フレームごとの結果受け渡しで、すべての待機を単一の同期点に集約していたケースがある。これを、計算完了に基づく待機と、転送完了に基づく待機を分離し、必要な範囲だけ次段キューを解放するよう修正すると、重なりが増えて全体が縮むことがある。
別の例として、バッチの粒度が細かすぎて同期回数が過剰になっている場合、一定単位でまとめて処理し同期回数を削減することで、オーバーヘッドが減る。いずれも計測に基づき同期境界を再配置する点が共通している。