Steamの偉い人、インテルのGPUを絶賛、「とにかく動く」 [422186189]
■ このスレッドは過去ログ倉庫に格納されています
ベンダー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
ベンダー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を扱う上では役立つだろう（拡張は別だ）
https://ezoeryou.github.io/blog/article/2014-05-19-The-Truth-on-OpenGL-Driver-Quality.html
ベンダーC - ドライバー #1
ベンダーCに怒るなんてことは出きっこない。そもそも、こいつらはグラフィックなんてやりたくないのだ。このベンダーの主要事業からはちょっと離れているのだが、最近、ひとつのダイに全部載せが流行っていて、このベンダーはダイスペースを余らせているのだ。
このベンダーは、ハードウェアの達人であるが、ソフトウェアには、実際のところ、それほど興味がない。このベンダーは、オープンソースグラフィックドライバー業界におけるリーダーであり、このベンダーのハードウェア仕様は、ほぼ完全に公開されている。
このベンダーは実際、めちゃくちゃ金を持っていて、組織図はめちゃくちゃ深く広く、ドライバー開発部署を二つ持てるほどだ！（そうだよ、このベンダーは、あるプラットフォームではGLドライバー#1を、別のプラットフォームではGLドライバー#2を使っている。この二つは完全に別のコードベースで別の開発部署だ）
とにかく、このベンダーの人事部は賢い。オープンソースウィザードのガキを直接雇って、ドライバー#1を改良させてる。このドライバーは、主要ドライバーのなかでは、最も低機能ではあるが、FPSなる用語の意味を知らないのであれば、とにかく動く。もし動かなくて、やる気があれば、読者は自ら手を汚して問題を修正し、パッチを送りつけることもできる。もし、読者がこのドライバーの修正とパッチ提出に相当たくみであれば、このベンダーから仕事が得られるだろう。
とにかく、ドライバー#1は、残念ながら、GL標準規格の点でいれば、だいぶ遅れている。しかし、後1,2年もすれば追いついて、去年当時ぐらいの規格を実装できるだろう。このドライバーを無視することは出来ない。何故ならば、何しろ市場シェアが圧倒的で戦略的価値があるからだ。そこで、この市場に食いつきたい開発者としては、ベンダーAやベンダーBだけがサポートしている、かっこよさげな拡張とか最新のトレンディーなモダンGLなんかは、使えっこない。読者はよろしくすべてのドライバー間でMIN()操作をしなければならず、多くの場合、このドライバーが、何が使えるかということを決定する。
ベンダーCは、どのプラットフォーム向けにも、GLツールを出していない。すまんね、グラフィック上の問題をデバッグしたいって？ 1999年にようこそ。
https://ezoeryou.github.io/blog/article/2014-05-19-The-Truth-on-OpenGL-Driver-Quality.html ファルシのルシがコクーンでパージみたいなこと言うな
簡単にまとめろアホ ベンダー
A NVIDIA
B AMD
C INTEL
なの？ 要約すると「CPU屋なんだからGPUは遅れてても文句は言わないよ、一応動くし」って話で絶賛ではないだろ この記事を見た当時はユーザー目線で見ても納得感あったがさすがに古い DirectXしか触った事ない俺からするとGLは混沌に見える >>11
スマホは前からそうなってるし、今のMacもそうなってる ■ このスレッドは過去ログ倉庫に格納されています
