OpenGLドライバー品質の実情

Rich Geldreich's Blog: The Truth on OpenGL Driver Quality

本の虫: OpenGLでムカつくことに引き続き、Valve社員のRich Geldreichが、OpenGLドライバーの品質について嘆いている。

製品の対象顧客が極めて限定された実行環境でもないかぎり、まともなGL開発者は、ドライバーの実情にぶち当たる。（今、あるいは来年までに製品を実際に出荷しなければならない場合、このドライバーとやりあわねばならないのだ。単にお家で趣味プログラミングしてるだけなら、この手の現実問題と向き合う必要は多分ないだろう）

D3Dしか使ったことがないのならば、覚悟しておいたほうがいいだろう。というのも、Windows/Linux用のGLドライバーはあまりにも多岐にわたるからだ。以下が、筆者の現在のドライバー品質についての意見だ。

ベンダーA

ほとんどの開発者がこのベンダーを使うのは、このベンダーは業界最高のデキるGL開発者を集めていて、テスト工程も最高だからだ。これは「標準」ドライバーだ。かなり速く、このベンダーのドライバー開発者は、完璧に純粋な規格準拠よりも、まともな方法を選ぶ（ちゃんと動くようにするため）。お家の趣味プログラマーがこのドライバーを使うのは、魅力的だし、拡張やGLサポートの点で、楽しいからだ。D3D12やMantleに対してGLが対抗して何かしている話では、たいてい開発者はこのドライバーを使っている。残念なことに、このドライバーだけを想定する実行環境に限定してしまうと、多くの市場シェアを獲得できない。

とはいえ、Source1をLinuxに移植して、Valve開発者がこのドライバーの開発者と手を組むまで、このベンダーはD3D9/11がやっているようなバッファーのアップデート（MapやBufferSbData経由）を、パイプラインをストールさせずに行うことすらできなかったのだ。ここで行っているのは、「ドライバーパフォーマンス初歩」的なことだ。その歴史は汚点なしというわけではない。また、バグに出くわした時、このドライバーはぶっとぶところまでぶっ飛んでしまって、GPUをクラッシュさせるとか、Windowsの場合、システムをTDRさせてしまう。とはいえ、とても信頼性が高く、よく作られたドライバーであることには変わりない。

訳注：TDR(Timeout Detection and Recovery)とは、不自由なMicrosoft Windows OSの機能の一つで、GPUがハングしたことを検出し、GPUリソースを強制解放、GPUドライバーの再初期化を経て、ハング状態から強制的に復帰する機構のこと。詳しくは、Timeout Detection and Recovery (TDR) (Windows Drivers)を参照。

ベンダーAはクッソ大量の拡張（いくつかは傑作だ）をサポートしていて、まあ、大抵のものは動くが、すこしばかり真剣に使おうとすると、ドライバーのよく使われているコードパスを離れて、未開の地に踏み込み、システムをクラッシュさせたり、ほんのわずかなことで即座にTDRしたりする。

このベンダーのツールは、歴史的に、完璧にクソである。動くとしてもほんの僅かな間だけ動いて、すぐ動かなくなってしまう。あるいは、開発部署に直接コンタクトを取って助けてもらうよう請願しなければ動かない。このベンダーには巨大な、おそらくはDillbert風のツール開発部署があって、よくわからんことをしているらしい。もちろん、このベンダーのツールは、このベンダーのドライバー上でしか動かない。

このベンダーは自社社員を有名なゲーム開発部署に送り込んで仕事をさせるということを、意図的、戦略的に行っている。これは諸刃の剣だ。というのも、このベンダー社員は、他のベンダーのドライバー上で起こる問題のデバッグを拒否するし、GLというものを、自社ドライバーの実装の上からしかみていないからだ。このベンダーの派遣社員は、他のドライバーの事情を一切考慮せず、自社ドライバーでのみパフォーマンスがでる手法を、意図的に採用する。

歴史的に、このベンダーは、主要ゲームタイトルのシェーダーを全部置換したりして、よりパフォーマンスがあがるようにしたりしている（時に、相当に向上する）。ほとんどのドライバーは、たまにこの手のことをやっているが、このベンダーは特に、パフォーマンスのためなら手段を選ばない。PCゲーム業界やグラフィック開発者にとって、これは何を意味するのか？　要するに、読者のような「平凡なグラフィック開発者」にとって、自分のゲームで、同じ技術的な結果を発揮できる可能性は極めて低い（たとえ、まったく同じアルゴリズムを使ったとしてもだ！）ということだ。何故ならば、読者諸君には、ベンダーから派遣されたドライバー開発者が、読者のゲームのために（低級に最適化されたシェーダーなどを使い）、そのゲームが実行されている時に、特別にドライバーが正しいことをするように調整するといったはからいがないためだ。言うなれば、歴史的に、PCグラフィックで伝説となっているゲームは、実は喧伝されているほどすごくなかったということでもある。なぜなら、彼らには手助けがあったからね。

ベンダーAは、冗談で「グラフィックマフィア」と称されている。読者の開発部署に、ベンダーAの開発者が派遣されてきたら、気をつけるがいい。奴らはマジだぜ。

ベンダーB

完全にカオス、パフォーマンス不安定すぎ、バグありすぎ、regressionテストまともにやってない、ドライバーのマルチスレッド部分は完全に機能しておらず、もはや開発者自身にもどうしようもできてない。クソなことに、このベンダーのGPUは結構標準的で、ハードウェア的には、まあまあできるということで、組織としては、ソフトウェア面で無能集団であるにも関わらず、無視することもできないのだ。glTexStorage()のような基本的なものですらクラッシュするし、出荷されたゲームがこのバグにぶち当たって、ドライバーが修正するまで何ヶ月もかかった。Bのドライバー開発者は、ベンダーAよりも規格に準拠しようとしているが、その結果として、たいした利点もないときている。というのも、ほとんどの開発者はベンダーAのドライバーを開発に使って、ベンダーBで上手く動かなかったら、ベンダーのせいにするからだ。GL規格の品質は無視される。

ベンダーBのドライバーの主要な拡張は、全然動かない。オモチャか机上の空論拡張だ。成果表を埋めて上司に進捗報告で使うためのものだ。主要なGL開発者は、絶対にこのベンダーの拡張を使わない。動かないからだ。論文の上ではよさそうにみえて、将来性を感じさせる拡張ではある。ベンダーBの拡張は、なぜGL拡張が現実ではクソなのかといういい見本だ。

このベンダーはなにかぶっ壊さずにドライバーをアップデートできたためしがない。やつらのよこすアップデートやらhotfixやらは、なにか一つの問題を直すが、別の二つはぶっ壊す。このドライバーのエントリーポイントにステップインしてみろよ、もうこの会社で働いてすらいないだろう元開発者の残したクソみたいな何層ものレイヤーがうずたかく積み上がっている。ベンダーBには、このフジツボみたいなソフトウェアレイヤーを理解してて、安全に変更できる開発者は残ってねーとみたね。

voglreplayで有名ゲームのGLコールストリームをこのドライバー上でリプレイすると、たまにぶっ飛んだ現象に出くわす。ゲーム自体はちゃんと動くのだが、GLコールストリームをリプレイしてみると、フレームバッファーがぶっ壊れてしまう（描画ごとにGLパイプラインをフラッシュすると直る）。筆者の予想だが、このドライバーはアプリごとにプロファイルを使って、ゲームごとに個別にバグだらけの機能を無効にしてるんじゃないかな。

面白いことに、ベンダーBにはちょっとしたツール開発部署があって、実際、便利で大抵の場合はちゃんと動くデバッグツールを作ってる。まあ、ベンダーBのGPUで使うならばの話だが。ベンダーBのツールなしでは、toglとSource1 Linuxは、出荷するのにもっと時間がかかっただろう。

これは一時的な傾向かも知れないが、ベンダーBのドライバーは、どうやら安定性軸に対して下降傾向にあるようだ（そうだ。これからますますひどくなるんだぜ）

いい点としては、信じられないかも知れないが、ベンダーBはOpenGL規格について、その一音節に至るまで、熟知している。もしこのベンダーの助けが得られたならば、彼らのよこす助言は素のGLを扱う上では役立つだろう（拡張は別だ）

ベンダーC - ドライバー #1

ベンダーCに怒るなんてことは出きっこない。そもそも、こいつらはグラフィックなんてやりたくないのだ。このベンダーの主要事業からはちょっと離れているのだが、最近、ひとつのダイに全部載せが流行っていて、このベンダーはダイスペースを余らせているのだ。このベンダーは、ハードウェアの達人であるが、ソフトウェアには、実際のところ、それほど興味がない。このベンダーは、オープンソースグラフィックドライバー業界におけるリーダーであり、このベンダーのハードウェア仕様は、ほぼ完全に公開されている。このベンダーは実際、めちゃくちゃ金を持っていて、組織図はめちゃくちゃ深く広く、ドライバー開発部署を二つ持てるほどだ！（そうだよ、このベンダーは、あるプラットフォームではGLドライバー#1を、別のプラットフォームではGLドライバー#2を使っている。この二つは完全に別のコードベースで別の開発部署だ）

とにかく、このベンダーの人事部は賢い。オープンソースウィザードのガキを直接雇って、ドライバー#1を改良させてる。このドライバーは、主要ドライバーのなかでは、最も低機能ではあるが、FPSなる用語の意味を知らないのであれば、とにかく動く。もし動かなくて、やる気があれば、読者は自ら手を汚して問題を修正し、パッチを送りつけることもできる。もし、読者がこのドライバーの修正とパッチ提出に相当たくみであれば、このベンダーから仕事が得られるだろう。

とにかく、ドライバー#1は、残念ながら、GL標準規格の点でいれば、だいぶ遅れている。しかし、後1,2年もすれば追いついて、去年当時ぐらいの規格を実装できるだろう。このドライバーを無視することは出来ない。何故ならば、何しろ市場シェアが圧倒的で戦略的価値があるからだ。そこで、この市場に食いつきたい開発者としては、ベンダーAやベンダーBだけがサポートしている、かっこよさげな拡張とか最新のトレンディーなモダンGLなんかは、使えっこない。読者はよろしくすべてのドライバー間でMIN()操作をしなければならず、多くの場合、このドライバーが、何が使えるかということを決定する。

ベンダーCは、どのプラットフォーム向けにも、GLツールを出していない。すまんね、グラフィック上の問題をデバッグしたいって？　1999年にようこそ。

ベンダーC - ドライバー #2

悲壮悲劇極まりない。この開発部署のドライバーはゲームではまず使われてない。つーかこのプラットフォームのGLなんて完全に二級市民じゃんか。多くのコードパスが全然動かねぇ。バッファーをアップデートするだけでよくわからんぶっ壊れ方をする。この開発部署はパフォーマンス解析とテスト用の記録に、ゲームごとに全然違った、ユニークで、バグだらけのクソをひねり落とす。この開発部署は、「パフォーマンス」とか「正しさ」ってのは、そもそも重要なのかどうかという究極の疑問を読者に叩きつけてくれやがる。

筆者は、ある有名なゲームエンジンの開発が、一年以上も、最新のGL 4.xとトレンディーな拡張を使ったバックエンドを、このドライバー上で動かそうと苦戦するのを見てきた。よう、お前ら、このドライバーは動かないんだったら。良いかげん明らめて、workaround満載の素のGL 3.xバックエンドを作れよ（toglや他の出荷済みゲームタイトルがやっているようにさ）

まあ、ベンダーCは、こっちの開発部署には、もう一方の開発部署より詳細なハードウェアの内部情報を与えてる。そんなわけで、同じゲーム、同じハードウェアの場合、ドライバー#1よりこっちの方が数パーセント速い傾向にある。まあ、動けばの話だがな。

他のドライバー

上記の主要なドライバーの他にも、いくつかのオープンソースドライバーがある。たいていはコミュニティによって開発されている、ベンダーAとベンダーB向けのドライバーだ。GLという観点から言えば、この手のドライバーは大きく時代に遅れている。だが、少なくとも動くということは聞いている。この手のドライバーについて筆者自身の経験はなく、また十分な情報も持っていない。というのも、この手のリバースエンジニアリングによるオープンソースのドライバーに関わると、ベンダーのクローズドソース開発部署を怒らせて、手助けが得られないんじゃないかと、筆者は恐れているからだ。

結論

大きなGLゲームタイトルを出荷するには、すべてのドライバー上でコードをテストして、すべての問題をworkaroundしないといけない。よくわからんGPU不具合、ヒープ破壊、ロックアップ、TDRに出くわした時は、GL神の助けあれかし。ドライバー開発者部署とその上司や取締役とは仲良くしとけ。こいつらの助けなしには、何もできやしないのだから。

ちなみに、分かる人にはまるわかりで、余興をそぐ蛇足的なネタバレだが、一応補足しておくと。ベンダーAはnVidia、ベンダーBはAMD、ベンダーCはIntelで、ベンダーCのドライバー#1は、GNU/LinuxやMesaなどからなる、自由なドライバースタック、ベンダーCのドライバー#2は、不自由なWindows OS用の不自由なドライバーである。

まあ、筆者の意見では、ベンダーCのドライバー#1が、現時点で最適だろう。