DolphinエミュレーターとOpenGLドライバー、栄光と恥

Official Dolphin Emulator Website - Dolphin Emulator and OpenGL drivers - Hall of Fame/Shame

DolphinというGC/Wiiエミュレーターの開発者が、各種プラットフォームにおけるOpenGLの現状について気を吐いている。以下翻訳。

最近、NVIDIAとAMDが、グラフィックドライバーでLinuxをサポートするということが注目を浴びているが、我々は、Dolphinという、Windows、Linux、Macそして最近ではAndroidで動作するGameCubeとWiiのエミュレーターを開発するオープンソースのプロジェクトの経験から、現状を世界に知らせたい。

今年初め、Dolphin 3.5のリリースのあと、Markus Wick (degasus)とRyan Houdek (Sonicadvance1)は、DolphinのOpenGLバックエンドをOpenGL ES 3.0準拠にするための書き換えを始めた。この書き換えの理由は他にあるのだが（とってもクールな最適化ができるようになる）、モバイルデバイスとの互換性や、将来のAndroidへのエミュレーターの移植（今ベータ）が、目的だ。この書き換えは、数カ月前にメインのDolphinのコードベースにマージされ、何万人ものDolphinユーザーによって使われ始めた。OS XやLinuxでは、これが唯一のまともなグラフィックバックエンドであるし、Windowsでは、D3D11グラフィックバックエンドと並行して提供されている。

残念なことに、最近の高度なOpenGL機能を使うという事は、一部のグラフィックドライバーの悲惨なバグをいくつも発見するという事なのだ。どうやら、本当にごく少数のアプリケーションだけが、我々がGameCube GPUを高精度にエミュレートするために使いたいOpenGL規格の機能を使っているようだ。それについては後ほど書くとして、Androidでは、OpenGL ES 3.0のサポートはとても最近のことで、Play StoreでもES 3.0機能を使っているのは極わずかなアプリケーションだけだ。

これは、いうなれば、グラフィックドライバーの恥の晒しあげだ。問題の数、問題を会社に報告するのがどれだけ困難か、そして実際に修正されたバグがどれほどかということに応じて、ソートされている。

エクセレント - NVIDIA

我々にはNVIDIAのバグリポートへの報告への対応時間を計測する機会がなかった。というのは、NVIDIAのOpenGL実装は、WindowsだろうとLinuxだろうと、我々には問題が見つけられなかったからだ。OpenGLバックエンドの書き換えの前には、OS XをNVIDIAのグラフィックカードで動かした時に一つだけバグがあったが、これは当方の未定義動作のためなのか、NVIDIAのドライバーのバグなのか判然としなかったのだ。基本的に、我々が使うOpenGLのサブセットでは、すばらしくよく動く。我々は、NVIDIAを「パーフェクト」とも呼びたくなるが、ただし、直接にバグではないものの、ドライバーにはいくつかの問題がある。

• クライアントサイドのバッファーストレージのサポートがない（最新のベータドライバー版はともかく）：エミュレーションの都合上、Dolphinはクライアントサイドのバッファーストレージが高速であることを要する。この機能は、 ARB_buffer_storage拡張（OpenGL 4.4の一部）として追加された。AMDのドライバーはAMD_pinned_memory拡張によって、この機能をとっくの昔にサポートしている。Dolphinでは、悲惨なハックを用いて、データをunmapped buffersにコピーすることにより、なんとか、この拡張なしでもやっている。一応は動くが、とても悲惨だ。この機能がサポートされていないというのは、むしろKhronosグループを非難するべきなのだろうが、AMDはサポートするのにわざわざKhronosを待たなかったわけだし。
• NVIDIA Graphics SDKのライセンスはGPLライセンスされたアプリケーション(Dolphin)と非互換であることと、GPUパフォーマンス要求のイケてない判定。NVIDIAドライバーは、しょっちゅう、DolphinをGPUパフォーマンスをほとんど必要としない種類のアプリケーションだと判定する。これはおそらく、精度の高いエミュレーションを実現するための操作のためだろう（GPU→CPU間の転送でかなりのストールが発生し、平均的なcommand queue lengthがとても短くなる）。NVIDIA Graphics SDKを使えば、ドライバーにハイパフォーマンスプロファイルを強制させられるのだが、GPLによりそれができず、一部のNVIDIAユーザーのパフォーマンスを落としている。SDKの再ライセンスが可能であれば、NvOptimusEnablementでやっているような方法と同じように、我々のバイナリでexportしているシンボルをみるなどしてくれればいいのだが。
• オープンソース開発者にとって、サポートや技術的な質問を得るのが難しい。毎度毎度、NVIDIAに実装の遅さについて質問しても（ドライバー内のGL callのシリアライズ）、公式フォーラムでは何の回答も得られない。NVIDIAとOS Xの描画の問題について報告しても、何の回答も得られない。NVIDIAの公式フォーラムはしょっちゅうオフラインになり、サポートやドキュメント目的では使えない。追記：この記事を投稿してから6時間後に、3人のNVIDIA社員が独立して我々に連絡をよせ、ドライバーに関する報告がある場合の報告先について知らせてきた。これは大部分のオープンソースの世界には役に立たないが、まあ、我々の将来的には役に立つだろう。ありがとよ。NVIDIA！

後述するように、モバイルドライバーにおける我々の体験は・・・まったくよろしくなかったので（詳細については後述）、NVIDIAドライバーがTegra 4 SoCでどれだけうまくやれるのか非常に興味深くはある。我々はまだTegra 4のデバイスパワーを体験できていないが（クソ高いんだよ！）、Dolphinがどのくらい動くかというのはとても興味深い。DolphinのAndroidにおけるボトルネックとは、GPUとそのドライバーなのだから。

グッド - Mesa

驚くべきことに、オープンソースドライバー(Mesa)は、最悪ではなかった。大方は、QAが貧弱だったりプロフェッショナルなテストがなされてなかったりということを予想しがちだが、Mesaにはバグが少ないし、我々が遭遇したすべてのバグは、最近のMesa 9.0/9.1でサポートされたたったひとつの新機能に端を発していた。しかもしかも、我々がMesaで発見したバグはすべて、正しい報告場所(freedesktop.orgのバグトラッカー)で報告するや、ただちに修正された。ドライバー開発者との連絡は、オープンソースの世界では常識だが、常にとてもよろしかった。IRCでたずねた時、Mesa開発者は、新しい機能を実際に使うアプリケーションが出てきたことを非常に喜んでいた。

anholt: uboの利用者だって！　やったぜ！
anholt: 要するに、とりあえずは動くようにしたってところで、「利用例が出てきたら、最適化が始められる」って段階でさ。

以下が我々がMesaドライバーで発見した4つのバグである。どれも、単一のUniform Buffer Objects(UBO)と呼ばれる機能に関連するもので、すべて安定版のドライバーで修正されている。

• Wrong GLSL built-in functions results with UBO arguments, Mesa 9.1.1で修正, バグを報告してから7日後.
• Dithering effects with UBOs, centroid and i965, Mesa 9.2.0で修正.
• Mesa bug causing black screen on r600 (radeon), IRCで問題を報告してから10分後にパッチが作成され, 同日にマージされ、2週間後に安定版としてリリースされた(9.1.3).
• Nouveau black screen issue with UBOs larger than 64KB, 我々の開発者の手によりデバッグされ、バグ報告から1日後にマージされ、1週間後に安定版としてリリースされた(9.1.6).

我々のUBOの利用例から、この機能のi965における実装は大きく再設計された。MesaとIntelの開発者であるEric AnholtはUBO data fetchingコードの大部分を書き換え、結果として、Dolphinにおけるパフォーマンスと精度を大幅に向上させた。

Mesa開発者の擁護のために言えば、我々がMesaのUBOを使い始めた時は、まだとても新しくリリースされたばかりの機能で、このバグを引き起こすほど多くのアプリケーションが使っていなかった。UBOオフセットに対するPiglitテストはなかったので、テストはあまり使われない機能もカバーするために拡張されるべきだろう。とにかく、我々はプロフェッショナルなQAは期待していなかったので、Mesa開発者が我々のバグ報告を真剣に受け止め、ただちに、まともな修正やデバッグ方法を考えだしたことは喜ばしいことだ。

我々の現在の問題は、Linuxディストリビューションはアップグレードが遅く、しかも、（Windowsとは違い）、システム全体を巻き込まずにMesaだけをアップグレードする簡単な方法を提供していないという事だ。つまり、我々のアプリケーションは、まだ一部のLinuxディストリビューションのLTSリリースのユーザーでは、壊れたままだ。

OpenGLバージョンのサポートは、あまりよろしくない。だが、我々はあまりオープンソースドライバーを責めるわけにも行かないのだ。とくにNVIDIAのGPUに対しては（nouveauはNVIDIAから基本的にサポート一切なしなのだから）。我々はむしろ、オープンソースドライバーがDolphinのような複雑なアプリケーションをまともに実行できるほどの形になっていることを、幸運に思うべきなのだ。とくに、一部のプロプライエタリなドライバーに比してみれば。

我々は現在、MesaのソフトウェアレンダラーであるLLVMpipeも使っているが、今のところ、修正されていないバグは発見できていない（我々が見つけた唯一のバグは、正しくないAVX検出によるクラッシュだが、発見する二週間前にはすでに修正されていた）

グッド - Intel HD Graphics on Windows

Intelの統合グラフィックチップセットはDolphin用にはあまりふさわしくない。エミュレーターにおけるGPU使用は極端に減らすこともできるが、最低限の設定でも、まだIntel IGPでは動作が遅すぎる。だが、IntelのIGPのWindows用のドライバーで、Dolphinに影響するようなOpenGL実装のバグはみつかっていない。残念ながら、サポートされている機能はとても少ない。我々のフォーラムでささっと調べたところによると、Intel HD3000 IGPが、DolphinユーザーのIGPとしては最も多いのだが、WindowsではOpenGL 3.1とShader Model 4.1しかサポートしていない（最新版のOS XではOpenGL 3.3がサポートされている）

IntelのOpenGLドライバーで変なのは、Intel Ironlake IGPだ。このIGPはOpenGL 3に必要なものをすべて備えている、ただしMSAAは除く。このたったひとつの機能が欠けているために、IntelはIronlakeではOpenGL 3機能を一切実装しておらず、我々はこのIGPをサポートできないでいる。

また、IGP製造者達がUnified Memory関連のOpenGL拡張をもっとプッシュしないのが残念だ。彼らこそ最も恩恵を受けるはずなのに。Intelは現在のところ、INTEL_map_texture拡張のみを提供している。これはtexture mappingには便利だが、buffers mappingのサポートはない。AMDはこの点に関して、コンソールで相当の経験があるので、いずれPCにもOpenGL拡張といった形で持ち込むだろう。GameCubeとWiiはUnified Memoryアーキテクチャなので、PCでも同じ事をできるという事は便利だし、Intel IGPでDolphinが使えるようになるかもしれないのだ。

よろしくない = AMD

我々が出くわした問題の多くは、AMDのプロプライエタリなLinux用のグラフィックドライバー、fglrx/Catalystを使った際に出くわしたものだ。Windowsでは起こらない問題が、Linuxではよく起こる。時として、非常に分かりやすい結果としてエミュレーターに現れる。

AMDのドライバーで頻出する問題は、アプリケーションがドライバーにmipmapを作成させたときのテクスチャーの破損だ。これが、とても単純なテクスチャーを貼りつけたWiiでの立方体のデモを、Dolphinで実行した結果だ。

[画像は原文を参照]

これはGL_UNSIGNED_SHORT_5_6_5テクスチャーを作成して、glGenerateMipmapを実行しただけで発生する。このバグへの文句は、二年以上前に言っている。AMDの開発者フォーラムでスレッドを立てたが、無視され、一年後にAMDが新しい開発者フォーラムのシステムに移行したときに、削除された。今日に到るまで、我々はこのバグが修正されたかどうか知らない。Dolphinのmipmapのエミュレート方法を変えたために、この問題は我々の問題ではなくなったのだが。

ユーザーランドのAMDドライバーのコード品質は、外から観察するに、とても悲惨だ。AMDのドライバーを使うプログラムをvalgrindにかけると、valgrindは大量のエラーを吐き出す（iotclが未初期化の構造体に対して使われているとか、未初期化のメモリへのアクセスとか）。いくつかのエラーでは、エラーを呼び出し側に伝えず、AMDのドライバー内で単にexit(123)を呼び出し、アプリケーションごと殺してしまう。この問題はSDL 1.3を悩ませた：calling XCloseDisplay caused the driver to exit。SDL 2.0では、この本来起こるべきではない問題に対処するためのworkaroundが追加された。ところで、この問題は、mipmapの問題を再現する最小プログラムを書いていて発見したのだ。

だがバグはfglrxの専売特許ではない。WindowsのAMDドライバーとて、いくつかの重大なバグを抱えている。AMDは、Dolphinにはとても便利な、ある種のclient-side buffer storageをサポートしている。これはAMD_pinned_buffer拡張で提供されている。AMD_pinned_bufferをVertex BufferやUniform Bufferに使うと完璧に動くのだが、Index Bufferに使おうとすると、ランダムなポリゴンを描画し始める。この問題のため、我々はAMD_pinned_bufferをIndex Bufferに使うのをやめ、結果としてOpenGLバックエンドはAMDユーザーにはパフォーマンス劣化となっている。

いまだに、AMDにfglrxのバグを報告する方法が分からない。開発者が公式フォーラムでバグ報告に返答しているのを見たことがない。非公式のfglrxバグトラッカーがまとめられているが、AMDの開発者達はみていないようで、新たな問題を延々と積み重ね続けている。

とはいえ、AMDはDolphinの将来に役立つことをしている。グラフィックAPIにおけるUnified Memory Accessの先駆者であるし、GPUのより低級な機能をアプリケーションに提供するMantleもある。この2つの改良がやってくれば、AMDのGPUは近代的なコンソールのエミュレーション用のプラットフォームとして最適となれる素質がある。

バッド - ARM/Mali

さて、モバイルGPUドライバーについて語ろうか。我々、オープンソース開発者にとっては、悪夢の始まりだ。

• バイナリブロブだけで、アーキテクチャのまともなドキュメントなど一切なし
• GPUが本来発揮できるはず速度がありながら、ドライバーで足を引っ張っている
• ケータイ製造者とそのOS開発者は、ハードウェアの機能について謳っているが、その機能はとっくの昔、2年前（OpenGL ES 3.0）に提供されているべきものなのだ。もし、ドライバーさえこんなにクソでなければ
• 高度なOpenGL機能を使うアプリケーションが極めて少なく、Dolphinは実に多くのぶっ壊れたGLES3機能にぶち当たる
• ドライバー開発者は、Mesaのようなオープンソース部門よりも、より一層QAをしていない

ARMによって作られたMali GPUは、最悪というわけではない。実際、DolphinはAndoridのMaliデバイスで正しく実行できる。長時間もドライバーバグとどこもかしこも遅いという問題を我々がworkaroundしてきた結果だが。

Maliにはバグを報告できる開発者フォーラムがある。しかし、我々のバグ報告の経験は、「ああ、それが壊れることはこちとらも知ってるよ」と返ってくるだけで、その後一切返事がない。Googleですら、ChromiumでMaliの問題をworkaroundしなければならないようだから、天下のGoogle様ですら、ARMの連中にバグを修正させたり、欠けている機能を宣伝通りに実装させたりできやしないのだろう。

これが我々がMaliドライバーでぶち当たったバグ集だ。

• glBufferSubDataとglMapBufferRangeはGPUドライバーをストールさせ、極端に速度を低下させる。これは他のドライバーでは起こらない問題だ。この問題は、独立してGoogleでも発見されていて、workaroundされている。
• glBufferSubDataはデータのコピーを作成するが、freeするのを忘れていて、Dolphinだと数秒でout of memoryを引き起こす。この問題も、独立してGoogleで発見されていて、ドキュメント化されている
• glClearでクリアすると、非同期であるはずなのに、あたかもドライバーがクリアの完了を待っているかのようなパフォーマンス低下を引き起こす。時として、glClearは完了まで1/60秒以上もかかり（1フレーム丸々かよ！）、完全に使ってはならない機能と化している。この問題は他のAndroid開発者達も、Ouyaのフォーラムや、StackOverflowなどで報告している。
• Maliのシェーダーコンパイラーは定数ではないグローバルシェーダー変数をサポートしない。これはOpenGL ES 3.0標準に違反するが、まあ、こちらがわでの修正は容易だ。

glBufferSubDataの問題のため、我々はVertex streamingコードを、workaroundのため、遅い方法で書かなければならず、これには莫大な労力もかかる。幸運にも、これはMali以外の問題にも対処したことになった（読者は後述で知るであろう）

これは、ちょっとした描画ゴミとかちょっとしたパフォーマンス問題以前の問題だ。ここでは、glClearのような基本的な機能が完全に使えないときていて、なんで開発者達はこんなんでオーケーなのか全然わかんねー。

我々はLIMA projectの成り行きを見守っている。LIMAの連中はMaliドライバーブロブを解析して、このハードウェア用の独自のドライバーを開発している。一年もの開発の末、彼らはいくつかの3Dデモを動かせるドライバーを作ることに成功したのだ。この3DデモにはQuake 3 Arenaも含まれていて、すでに、公式のMaliドライバーより高いフレームレートで動作する。現在のところの問題は、シェーダーコンパイラーで、これにはMali GPUのISAの完全な理解が必要となる。我々は、彼らが来年辺りには、Maliデバイスにおける状況を改善してくれると大きく期待しているし、ARMがまともなドライバーを提供しはじめるのを、そこはかとなく期待している。

悲惨 - Qualcomm/Adreno

どこから始めればいい？　まず、いいところから言おうか。QualcommとMaliは、確実にグラフィックドライバーで一部のコードを共有している。残念すぎることにそのコードはglBufferSubDataとglMapBufferRangeを取り扱っている。そうだよ。Maliでこのふたつの関数が遅くて使えねーバグ（数秒の実行時間でout of memory）は、QualcommのAdrenoデバイス用のドライバーにも健在さ！　まあ、我々のMaliのためのvertex streamingの変更は、他のドライバーでも役だったってことだがな。

それだけじゃない。

• シェーダーコンパイラーは、Uniform Buffer Objectを動的にindexingしようとすると、"internal error"を報告してきやがる。バグは認知されているが、今日に到ってもいまだに修正されていない。bug report
• OpenGL ES 3.0のcentroid attributeのサポートがぶっ壊れている。単純に動かない。使うと、出力は真っ白な画面だ。Qualcommには三ヶ月前に報告してあり、バグであると認知されたが、いまだに修正はなし。bug report
• Shader info log関連の関数の文字列長の扱いがめちゃくちゃで、シェーダーのコンパイル情報に対しては常に長さ0を返し、メッセージは例えば大きなバッファーを提供したとしても、1023文字で打ち切られる。デバッグが悲惨だ。特に、シェーダーコンパイラーがマクロの作成とかで無意味な警告を大量に生成するときは。Qualcommには三ヶ月前に報告したが、誰からも返事がない。bug report
• Adrenoデバイスのデコンパイルしたcommand streamをみると、ARB_draw_elements_base_vertexは愚直にサポートできそうにみえる。実際、Adrenoデバイス用のオープンソースドライバーでは、サポートされている。この件に関して、Qualcommから6ヶ月前によこしてきた返事は、つづめて言うと、「たぶんね」

glBlitFramebufferをハードウェアバッファーに適用すると、出力されるバッファーは90度回転される。ありえん。なんでそうなるんだよ。ところで、他の開発者がglBlitFramebufferを呼び出す簡単なコードでAdrenoをクラッシュすることを報告している。

• Dolphinで生成された一部のシェーダーは、Adrenoのシェーダーコンパイラーをクラッシュさせる。この問題についてはデバッグ中で、理由はまだ判然としないものの、Uniform Buffer Objectサポートを無効にすると、この問題が起こらないことから、Adrenoのシェーダーコンパイラーのメモリー破損が原因ではないかとにらんでる。
• 最近まで（V43）、Adrenoのカーネルランドのドライバーはinstruction bufferの長さに制限があり、ユーザーランドのドライバーが長すぎるinstruction streamを生成すると、アプリケーションを勝手に殺す。このため、利用者はデバイスのroot権限を取得して長さの制限を無効にしてからアプリケーションを実行しなければならない。より詳しくは、bug reportを参照。

我々は今も、Qualcomm/Adrenoでしか発生しない、ヘンテコな描画をした上にデバイスをクラッシュさせるバグを検証中である。

Qualcommの開発者フォーラムをみると、AdrenoドライバーとOpenGL ES 3.0で問題に出くわしているのは、我々だけではないとわかる。この最近のレスは、Unity 3Dアプリケーションのクラッシュに文句をつけている。別の古いレスは、vertex shaderのindexicing tableにおけるランダムな結果やout of memoryについてのものだ。

幸運にも、我々はDolphinをAndroidのQualcommデバイスに移植する際、Freedreno開発者の助けを得ることができた。LIMAのように、FreedrenoはAdrenoデバイス用のオープンソースドライバーで、オープンソーススタックの上で、XBMCのような巨大なアプリケーションを実行できるほどの状態になっている。ここでも、FreedrenoのRob Clarkは、Qualcommから一切の協力を得ていない。皆にマシなドライバーを提供するため、彼はQualcommのブロブを解析して、独自のシェーダーコンパイラーバックエンドを、Mesaインフラの上に構築しなければならないのだ。一人の人間が、ほぼ一人で開発して、Qualcommの開発部門全体より、まともな品質のドライバーを作れるのだ。だれもこの問題をきにしないがため、彼の労力は、大手のケータイ製造者 からは使われず、Andoridの中でこの非公式ドライバーを使っているものは、我々の知る限り存在しない。我々がAdrenoの問題に悩まされている時、RobはQualcommの開発部門よりも親切で、彼の支援には感謝の言葉もない。

不明 - PowerVR

PowerVRは、現在のところ、公開されているソフトウェアとハードウェアで、OpenGL ES 3.0をサポートしていないため、我々は彼らのドライバーがどのくらいよくDolphinをサポートしているのかテストすることができないでいる。PowerVRでES 3.0がサポートされた時には、詳細を知りたいものだ。

感想

我々がこの投稿を書いた理由は、モバイルGPUドライバーの究極なまでに悲惨な状態に注目を向けたかったからだ。モバイルが本気でグラフィックを多用するアプリケーションの土台となるには、これらの問題を修正しなければならないし、QualcommやARMは、まともなドライバーを開発できる能力がなく、最新版のグラフィックAPIに十分に早く対応するだけの能力もないようにみえる。NVIDIAがモバイルの世界にやってくるのは、モバイルグラフィック開発者にとって最高のことだ。DolphinはTegra 3デバイスには、ある一つの機能（24bit depth buffer - Tegura 3は16/20bit depthまで）を欠くために対応できないが、将来Tegra 4デバイスを入手したら、WindowsとLinuxにおけるNVIDIAドライバーと同じく、動くことを期待している。

AMDは最近、Linuxをもっとサポートしたいと発表し、GPU内部のドキュメントを多く公開し（少なくとも、NVIDIAに比べれば）、オープンソースドライバーにも多く貢献している（Gallium3Dの最大の貢献者）。しかし、今のところ、LinuxではNVIDIAドライバーが純然たる優位だ。AMDの新しいグラフィックAPIだとかいうMantleがやってくるまで待つことはできない。現在、我々はユーザーにAMD CPUやAPUを推奨していない。なぜならば、その悲惨なシングルコアのパフォーマンス（PCSX2のベンチマークを参照）からだ。Unified memory Accessのサポートを持ってくれば、Dolphinのパフォーマンスは大幅に上がり、頂点のコピーとストリーミングに費やす多くの時間を低減できるだろう。

ARMとQualcommのGPUは、ハードウェアの性能はともかく、ソフトウェアであるドライバーがお粗末過ぎる。そのお粗末なことは、基本的に一人の人間によって解析して開発した非公式な自由ドライバーに劣るほどである。もちろん、一人の人間というのは不公平だ。LIMAといいFreedrenoといい、Mesaという20年間にわたって開発され続けてきた自由なOpenGL実装を使っているからだ。しかし、Mesaなのだから、MITライセンスなのだから、ARMやQualcommの連中は、Mesaをパクることだってできたはずだ。それをしないで、独自にMesaよりひどいクソを公式に提供している。

もちろん、Mesaのあるバージョンをforkして、独自に保守するのは難しすぎる。だから普通は、Mesaの上流に関わるべきなのだ。それをせず、Mesaもパクらず、Mesa以下のゴミを作って、公式ドライバーをして提供する。何と愚かなことか。

結局、我々はもう十分に先例があるのだ。ブラウザーは、もはや一企業が内部で開発できるようなシロモノではない。いまだに一企業の手で開発されているブラウザーは軒並みクソだ。コンパイラーは、もはや一企業が内部で開発できるようなシロモノではない。一企業の内部で開発されたコンパイラーは軒並みクソだ。グラフィックドライバーは、いつになったら過去の過ちから学ぶのか。もはや、OSやコンパイラーのような大規模なソフトウェアは、一社単独で閉鎖的に開発できるような規模ではなくなっているのだ。自社単独で開発できるということに、マーケティング上の利点すらない。しかも、実際には外注への丸投げだらけで、しかも一人の人間が解析して書いた自由ソフトウェアより劣っている。

OpenGLの実装には、C言語風の文法を持つシェーダーのコンパイラーが必要であり、これを独自に開発した結果、コンパイラーがクラッシュするお粗末なプロプライエタリ実装が山ほどある。コンパイラーは、どのような入力を渡されようと、クラッシュするべきではないというのに。

Hacker Newsでは、このことに関して議論が行われている。

Dolphin Emulator and OpenGL drivers - Hall of Fame/Shame | Hacker News

あるコメントによると、この手のARMやQualcommのようなハード屋は、ソフトウェアの開発能力がなく、外注に外注を重ね、また、あらかじめパッケージ化されたソリューション（わざわざ貧弱なハードウェアでJAVAを動かしたりとか）を好んだりして、結局、質の悪いクソをひりだしているのだとか。

またあるコメントでは、QualcommのQAプロセスは、「我々の出荷するアプリが動くか？」であろうと推測するものまでいる。何でも、スレッドAPIを使うとデバイスをリセットしてしまうが、肝心のデバイスをリセットするはずのAPIは何もしないのだという。

デバイスリセットAPIが何もしないってのは確かなのかい。ひょっとしたらスレッドを作っているのかもしれないぞ？

id=6454871

ひょっとしたらそうかもな。だが何も返さないぞ。

我々は結局、以下の解決方法に落ち着いた。

  int i = 0; 
  while (1) {*i++ = 0;}

id=6455823