素人翻訳

適当に翻訳する。

X11 のフェンスを「trigger」する[Sync拡張]

「Compositor, sync fences and redraw lag problems」のまとめ。

フェンスの「trigger」の意味・使い方を確認するための自分用メモである。

----------

再描画の際にラグ(遅れ)が発生する問題について。

X の Sync 拡張と GL_EXT_x11_sync_object を使えば解決できるか。

「コンポジット・マネージャが自身のレンダリング(画像の加工)の際に X サーバと適切に同期しない場合に発生する競合条件」が原因なのか。

----------

コンポジタが DamageNotify イベントを受け取った場合、「その時までにダメージ部分のドローアブルの内容の更新が完了している」と想定することはできない。

コンポジット・マネージャが direct-rendering OpenGL を使用している場合、同コンポジット・マネージャのレンダリングは X サーバのレンダリングとは非同期に行われる。

X サーバは、自身のレンダリングの命令を GPU の命令バッファに書き込んだらすぐに DamageNotify を送信する。
書き込んだ命令が実際に GPU で実行されるまで待ったりしない。

X サーバのレンダリングとコンポジット・マネージャの OpenGL レンダリングとが、メモリを共有している２つの並列 GPU スレッド(thread)で実行されている場合を考える。

X サーバの GPU スレッドがレンダリングの結果を共有メモリに書き込む前にコンポジタの GPU スレッドが共有メモリからの読み込みを開始した場合、コンポジタは古くなったデータを読み込んでしまう。

X Sync 拡張のフェンス(fence)は、上記のような場合に、サーバの書き込み操作が終わるまでコンポジタの読み込み操作が始まらないことを保証するための手段である。

----------

EXT_x11_sync_object は必要なのか。
なぜ NVIDIA のカードだけで問題が起きるのか。

----------

XSyncTriggerFence は、X サーバに対して、同者のレンダリングが完了した時にフェンス(fence)を「trigger」するよう頼むだけのもの。

XSyncAwaitFence は、X サーバに対して、１つあるいはそれ以上のフェンスが「trigger」されるまでクライアントを無視するよう頼むもの。

どちらも OpenGL のレンダリングには影響しない。
なぜかというと、OpenGL のレンダリングは、X サーバが行っている全てのことと非同期に行われているから。

EXT_x11_sync_object を使うと、OpenGL アプリケーションにおいて、 OpenGL に XSync のフェンス(fence)を導入することができる。

これによって、OpenGL アプリケーションは、X11 のフェンスが「trigger」されるまで OpenGL のレンダリングを止めるための手段を得る。(これが無ければ、２つのスレッドは非同期にレンダリングを行う。)

これはコンポジタにとって重要である。
なぜなら、X サーバとコンポジタはウィンドウ・ピクスマップの形でメモリを共有しており、コンポジタはこのウィンドウ・ピクスマップを EXT_texture_from_pixmap 経由で OpenGL に持ち込んでいるからである。

一般に、メモリを共有しながら非同期にレンダリングを行う状況では、何かしらの同期要素が必要である。
XSync のフェンスと GL_EXT_x11_sync_object 拡張とは、EXT_texture_from_pixmap 拡張に欠けている同期の手段を提供するものである。

NVIDIA のドライバで問題が起きやすいのは、同ドライバでは複数のレンダリング・スレッドが非同期に動くことを許しているからである。

他のドライバは、カーネル中のレンダリングを逐次化(serialize)し、全て CPU から受け取った通りの順番で GPU にて実行する。
これこそが、他のドライバで問題が起きない理由である。

----------
「Sync フェンスの輪」について。

フェンスという資源を作成して OpenGL と共有する動作は、高費用である。
そのため、予めフェンスを多めに作っておいて、それを使いまわす。
それがフェンスの輪である。

OpenGL クライアントは、GPU がフェンス・ウェイト(fence wait)命令を消化するのを待ってから、XSyncResetFence リクエストを X サーバへ送信する。
そして、同クライアントは、リセットが完了したこと告げる XSync アラーム(alarm)の受信を待ち、それを受信して初めて同一のフェンスを OpenGL 命令の流れの中に再び投入することができるようになる。

もしフェンスが１つしかなかったら、コンポジタの CPU スレッド、コンポジタの GPU スレッド、X サーバの CPU スレッド、X サーバの GPU スレッド(４つ存在するとすれば)を逐次化して実行しなければならなくなる。

Sync フェンスの輪のおかげで、フェンスを「trigger」すること、消化すること、リセットすることを同時に実行できるようになる。

----------
問題があるコードの例

fence = XSyncCreateFence(...)
XSyncTriggerFence(fence)

/*
* リクエストの処理が再開するまでブロックする
* コードのこの部分に来るまでに、
* フェンスは「trigger」されているはず。
*/
TrivialXRequestWithReply(...)

// GL のレンダリングをここから始める

----------
上記のコードの問題。

XSyncTriggerFence() は、フェンスが「trigger」されるまで待たないものであり、単に「trigger」コマンドを GPU の命令列に書き込むだけである。

TrivialXRequestWithReply() は、X サーバの CPU スレッドがこの関数を処理し終えたらすぐに戻ってしまい、GPU に溜まっている以前のリクエストのレンダリングの完了を待たない。

したがって、GL のレンダリングが始まるまでに GPU がフェンスを「trigger」している保証は無い。

glWaitSync() を使えば、コンポジタに CPU での処理を続けさせながら、GPU に XSync フェンスが「trigger」されるのを待たせることが可能。

----------
依然として問題のあるコードの例

fence = XSyncCreateFence(...)
XSyncTriggerFence(fence)

/*
* 追加の処理。
* このクライアントの X リクエストの処理が止まる
*/
XSyncAwaitFence(fence)

/*
* リクエストの処理が再開するまでブロックする
* コードのこの部分に来るまでに、
* フェンスは「trigger」されているはず。
*/
TrivialXRequestWithReply(...)

// GL のレンダリングをここから始める

----------
上記のコードの問題。

XSyncAwaitFence(fence) は、フェンスが「trigger」されるまでこのクライアントをブロックする。
しかし、X サーバは他のクライアントのリクエストは処理し続ける。
と同時に、コンポジタの CPU スレッドを本来より遅れた状態に留めてしまい、結果として画面の描画にチラつきや遅れが発生する。

XSyncAwaitFence() の代わりに glWaitSync() を用い、CPU スレッドではなく GPU スレッドをブロックするのが良い。

そうすれば、コンポジタは後続の Damage イベントの処理を続けられる。

----------
推測

EXT_x11_sync_object を使っているのは NVIDIA だけ。
最適化のためにコードの行数が多くなっている。