トリプルバッファリングに対応
Mutter 48（GNOME 48）で公式にトリプルバッファリングに対応しました。
GNOME を採用するすべての Linux ディストリビューションで利用可能
デスクトップ環境に GNOME を採用する Ubuntu だけでなく、同じく GNOME を採用する他の Linux ディストリビューションでも、トリプルバッファリングを利用できるようになりました。Mutter
Mutter は GNOME で開発及び利用されている Wayland ディスプレイサーバー / Wayland コンポジター / X11 ウィンドウマネージャー / X11 コンポジターです。端的に言えばユーザーが利用するデスクトップを支えるソフトウェアです。
Xorg セッションと Wayland セッションで役割や担当範囲に違いがありますが、GNOME デスクトップを支えるソフトウェアである点には何ら変わりありません。
数年間かけてサポートに至る
様々な環境及び状況で最適なフレームレートを確保するため、フレームのスケジューリングを継続的に見直し続け、数年間かけてトリプルバッファリングのサポートに取り組んできました。そしてようやくトリプルバッファリングのサポートに至るわけですが、まだ残作業がいくつかあります。
多くの OpenGL ドライバーはトリプルバッファリングをサポートしているが
多くの OpenGL ドライバーはデフォルトでトリプルバッファリングをサポートしていますが、なぜここまでトリプルバッファリングのサポートに時間がかかったのでしょうか。その理由をサポート作業の振り返りと共に Mutter のアーキテクチャーを踏まえ見てみましょう。
GPU がフル活用されていないことに気づく
今から約5年前の2020年、Ubuntu Desktop チームが野心的なアイデアを試そうと Hack Day を楽しんでいました。Hack Day とは
Hack Day とはハッカソンのことであり、チームメンバーが同じ場所に集まって新しいアイデアを共有したり、話し合ったり、実装したり、新機能をデモンストレーションするイベントのことです。エンジニア向けのイベントと思えば分かりやすいでしょう。
何かおかしいことに気づく
とある開発者が GNOME でおもろアプリを紹介していた時のことでした。GNOME Shell のフレームレートがモニターのリフレッシュレートに一度も追いつかないことに気づきました。
表現を変えれば高速道路（モニター）を時速40kmで車（デスクトップ）が走っているようなものです。
GPU の性能の問題と思いきや、その時 GPU の活用状況を見てみると、全く GPU が活用されていない状況でした。
その時ハードウェアの状況は
その時 GPU 含めほとんどのハードウェア（デバイス）はアイドル状態であり、モニターのリフレッシュレートに追従するようデバイスのパフォーマンスを上げる振る舞いは一度も見られませんでした。ということは・・・
ハードウェアに大きな負担がかかり処理が間に合わずモニターのリフレッシュレートに追いつけないならば、ハードウェア側に何か問題があるかもしれないと想像できます。しかしほとんどのハードウェアがアイドルならば、原因はまずソフトウェア側にあると考えるのが自然です。
GNOME でこの現象に関わりそうなソフトウェアと言えば、Mutter です。
Ubuntu Desktop チームは Mutter の何かが間違っているのではないかと Mutter に目を向け、そしてその間違いが明らかになりました。
問題を解決しよう
ここから本現象の原因の追求と問題の解消作業が始まります。そしてこの問題の解決策が、トリプルバッファリングのサポートになります。
Xorg セッションでトリプルバッファリングの対応
時は同じく2020年、Xorg セッションでトリプルバッファリングの対応が完了しました。対応作業は円滑に進んだ
Xorg セッションではフレームクロックの変更をサポートするだけで対応でき、また GLX がトリプルバッファリングと追加フレームの受け入れに対応していたため、Xorg セッションでのトリプルバッファリングの対応作業は円滑に進みました。Wayland セッションでトリプルバッファリングの対応
こちらに時間がかかりました。Xorg 並の柔軟さを実現する
まず2020年の終わりから2022年の初頭にかけ（1.5年間）、Mutter のバックエンドが Xorg 並の柔軟さを実現できるよう、その実現作業に重点が置かれました。この実現には複数のフレームを同時にうまく処理する仕組みが必要です。
この仕組みを簡潔に表現すれば GPU がフレームのレンダリングを完了する前に、CPU が次のフレームを処理しておく仕組みです。
CPU と GPU は異なるデバイスであるため、このような並列及び協調して動作する仕組みは実現可能です。
ついに作業が一段落つく
そして2022年の初頭にこの仕組みが実装され、すべての既知の不具合も解消されました。これにより Wayland セッションでトリプルバッファリングをサポートできるようになりました。
Ubuntu 22.04 に搭載
まずトリプルバッファリングのサポートは Ubuntu 22.04 に搭載され、デフォルトでトリプルバッファリングが有効になりました。しかしこの時まだ、トリプルバッファリングのサポートは GNOME に取り込まれていませんでした。
GNOME はレビュー待ちだった
Ubuntu はなるべく GNOME の方針に沿ってユーザーに GNOME デスクトップを提供する方針を持っています。GNOME にも実装を提供
もちろんこのトリプルバッファリングの実装はアップストリームの GNOME に取り込んでもらうべく GNOME にも提供され、GNOME でもトリプルバッファリングのサポートが期待されました。GNOME にトリプルバッファリングのサポートが取り込まれれば、別途 Ubuntu でトリプルバッファリングのサポートを行う必要がなくなり、作業負担が軽減されます。
遅々として承認されなかった
しかし2022年から2025年の3年間は、GNOME によるレビュー待ちや、この3年間で数回起きた Wayland バックエンドの再設計に関する議論に反応するぐらいで、実装提案者は特に何もすることなく時間が過ぎ去っていきました。ちなみに OSS プロジェクトの多くは会社の業務ではないため、メッセージの返信や回答などに時間がかかることもあります。
メッセージの送信から3日経ち、1週間経ち、1ヶ月経ち、そして1年が過ぎ去ることもあるでしょう。
ついに GNOME に取り込まれる
そしてもうすぐリリース予定の Mutter 48（GNOME 48）で、ついにトリプルバッファリングのサポートが取り込まれました。ここまでがトリプルバッファリングをサポートするまでの経緯となります。
そんなにバッファリングしたら、遅延が発生するんじゃないの？
トリプルバッファリングは三重にバッファリングするため、その分遅延が発生するのではないかと心配するゲームユーザーや、グラフィックのプロユーザーがいるかもしれません。遅延の回避
確かにバッファーの活用方法や実装方法によっては、遅延ペナルティーが発生します。しかし Mutter の実装は遅延を回避するようになっています。
今回トリプルバッファリングに対応した Ubuntu Desktop チームの開発者は、Mir の初期バージョンで同じ仕組みを持つトリプルバッファリングを実装した開発者であり、そのアルゴリズムが今回の実装に生かされています。
一つのフレームのみレンダリングを維持する
モニターのスキャンに先駆け一つのフレームのみレンダリングを維持するようにします。これだけ聞くとダブルバッファリングとさして変わらないように見えます。
しかしそれとは別に、そのレンダリングフレームとは独立してフレームをスケジューリングする仕組みを設けることで、フルフレームレートでのレンダリングを可能にします。
トリプルバッファリングへの切り替え
この仕組みを活用し、システムがフレームレートを維持できている場合はダブルバッファリングが維持され、フレームレートを維持できなくなった時にトリプルバッファリングに移行し、フレームレートの向上に貢献します。残作業とアプリの対応
上記で残作業がいくつかあると紹介しました。トリプルバッファリングは Mutter に実装された機能であるため、GNOME Shell のアニメーションや GNOME デスクトップ上で動作するアプリのレンダリングにも効果があります。
しかしそれだけではまだ不十分です。
Firefox の例
Firefox でタッチパッド操作によるスクロール実行時、スムーススクロールの慣性に伴う描画が円滑に行われないことがあります。ただし PC の電源モードをパフォーマンスに設定している場合は、クロックが高めに維持されるため、この問題は起きません。
GTK にも似たような問題がある
Firefox と同様に GTK で作られたアプリにも同様の現象が発生することがあります。例えばファイルアプリで大量のファイルがあるフォルダーでスクロールした時に、同様の現象が発生することがあります。
ちなみに Flutter もツールキットに GTK を採用しているため、Flutter 製のアプリでも同様の現象が発生することがあります。
アプリ側でダブルバッファリングをしている
この現象が発生するアプリの共通点として、アプリ側もしくはツールキット側でダブルバッファリングをしている点が挙げられます。次はアプリやツールキットの修正
これらの課題を解消していくため、次はアプリやツールキットの修正が検討及び期待されています。トリプルバッファリングが十分に機能しないケースもある
ハードウェア構成によっては、トリプルバッファリングによるパフォーマンスの改善が十分に発揮されない構成もあります。ただし期待値に届かないだけで、パフォーマンスの改善には有用です。
例えば Xilinx Kria 開発ボードや、プロプライエタリーな NVIDIA GPU ドライバーがこのケースに相当します。
またソフトウェアレンダリングでも十分なパフォーマンスの改善は期待できません。
これはソフトウェアレンダリングでは、CPU が GPU の役割を担うことになるためです。
