ベンダー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の開発者が派遣されてきたら、気をつけるがいい。奴らはマジだぜ。

https://ezoeryou.github.io/blog/article/2014-05-19-The-Truth-on-OpenGL-Driver-Quality.html