ここでの答えの多くは本当に、本当に良いです。ただし、OpenGLとDirect3D（D3D）の問題はおそらく対処する必要があります。そしてそれには...歴史のレッスンが必要です。
そして、始める前に、Direct3DについてよりもOpenGLについてずっとよく知っています。私はこれまでにD3Dコードを1行も書いたことがなく、OpenGLのチュートリアルを書いたことがあります。だから私が言いたいのは、バイアスの問題ではありません。それは単に歴史の問題です。
紛争の誕生
ある日、90年代前半のいつか、マイクロソフトは見回しました。彼らはSNESとSega Genesisが素晴らしく、多くのアクションゲームなどを実行しているのを見ました。そして、彼らはDOSを見ました。開発者は、コンソールゲームのようなDOSゲームをコーディングしました：金属に直接。ただし、SNESゲームを作成した開発者がユーザーが使用するハードウェアを知っていたコンソールとは異なり、DOS開発者は複数の可能な構成を作成する必要がありました。そして、これは思ったより難しいです。
また、Microsoftには大きな問題がありました。Windowsです。開発者が何でもできるDOSとは異なり、Windowsはハードウェアの所有を望んでいました。アプリケーション間で協力するためには、ハードウェアの所有が必要です。協力はゲーム開発者が嫌いなものです。なぜなら、それは彼らが素晴らしいものになるために使用できる貴重なハードウェアリソースを占有するからです。
Windows上でゲーム開発を促進するために、Microsoftは、低レベルだった均一なAPIを必要とし、それによって減速されることなく、Windows上で実行し、すべてのほとんどのクロスハードウェア。すべてのグラフィックス、サウンド、および入力ハードウェア用の単一のAPI。
こうして、DirectXが生まれました。
3Dアクセラレータは、数か月後に誕生しました。そして、マイクロソフトはトラブルの現場に出くわしました。DirectXのグラフィックコンポーネントであるDirectDrawを参照してください。2Dグラフィックのみを扱います。グラフィックメモリを割り当て、メモリの異なる割り当てられたセクション間でビットブリットを行います。
だから、マイクロソフトは、ミドルウェアのビットを購入し、それがあったのDirect3Dバージョン3にそれを作ら普遍悪口。そして、十分な理由があります。D3D v3コードを見るのは、契約の箱を見つめるようなものです。
Id SoftwareのOld John Carmackは、そのゴミを一目見ながら、「ネジを締めろ！」と言いました。そして、別のAPI OpenGLに向けて書くことにしました。
マイクロソフトは、Windows向けのOpenGL実装でSGIの作業に忙しかったという、多面的な獣の別の部分を参照してください。ここでのアイデアは、典型的なGLアプリケーションの開発者、つまりワークステーションアプリを裁判することでした。CADツール、モデリング、そのようなこと。ゲームは彼らの心の中で最も遠いものでした。これは主にWindows NTの問題でしたが、MicrosoftはWin95にも追加することにしました。
ワークステーション開発者をWindowsに誘導する方法として、Microsoftは、これらの新しい3Dグラフィックスカードへのアクセスで彼らを買収しようとすることにしました。Microsoftは、Installable Client Driverプロトコルを実装しました。グラフィックカードメーカーは、MicrosoftのソフトウェアOpenGL実装をハードウェアベースのものでオーバーライドできます。コードは、利用可能なハードウェアOpenGL実装を自動的に使用できます。
初期の頃、消費者レベルのビデオカードはOpenGLをサポートしていませんでした。CarmackがSGIワークステーションでQuakeをOpenGL（GLQuake）に移植することを止めませんでした。GLQuake readmeから読むことができるように：
理論的には、glquakeはテクスチャオブジェクト拡張をサポートする準拠OpenGLで実行されますが、必要なすべてを高速化する非常に強力なハードウェアでない限り、ゲームプレイは受け入れられません。ソフトウェアエミュレーションパスを通過する必要がある場合、パフォーマンスは1秒あたり1フレームを大きく下回ります。
現時点（'97年3月）で、glquakeを合理的に再生できる唯一の標準OpenGLハードウェアはintergraph realizmで、これは非常に高価なカードです。3dlabsはパフォーマンスを大幅に改善していますが、利用可能なドライバーではまだプレイするには十分ではありません。glintおよびpermediaボード用の現在の3dlabsドライバーの一部は、フルスクリーン実行を終了するときにNTをクラッシュさせる可能性があるため、3dlabsハードウェアでglquakeを実行することはお勧めしません。
3dfxは、glquakeが必要とするすべてを実装するopengl32.dllを提供していますが、完全なopengl実装ではありません。他のopenglアプリケーションは動作しない可能性が非常に高いため、基本的に「glquakeドライバー」と見なしてください。
これがminiGLドライバーの誕生です。ハードウェアがほとんどのOpenGL機能をハードウェアに実装できるほど強力になったため、これらは最終的に完全なOpenGL実装に進化しました。nVidiaは、完全なOpenGL実装を提供した最初の企業です。他の多くのベンダーは苦労しました。これが、開発者がDirect3Dを好んだ理由の1つです。ベンダーはより広範なハードウェアで互換性がありました。最終的にはnVidiaとATI（現在のAMD）のみが残り、両方ともOpenGLが適切に実装されました。
OpenGLアセンダント
したがって、ステージが設定されます：Direct3DとOpenGL。D3D v3の悪さを考えると、これは本当に素晴らしい話です。
OpenGL Architectural Review Board（ARB）は、OpenGLの保守を担当する組織です。彼らは多くの拡張機能を発行し、拡張機能リポジトリを維持し、APIの新しいバージョンを作成します。ARBは、グラフィックス業界の多くのプレーヤーと一部のOSメーカーで構成される委員会です。AppleとMicrosoftは、ARBのメンバーであります。
3DfxにはVoodoo2が付属しています。これは、マルチテクスチャリングを実行できる最初のハードウェアです。これは、OpenGLがこれまでできなかったことです。3DfxはOpenGLに強く反対していましたが、次のマルチテクスチャグラフィックチップ（TNT1）のメーカーであるNVIDIAはそれを気に入っていました。そのため、ARBは拡張機能GL_ARB_multitextureを発行しました。これにより、マルチテクスチャリングへのアクセスが可能になります。
一方、Direct3D v5が登場します。現在、D3Dは猫が吐き出すようなものではなく、実際のAPIになっています。問題？マルチテクスチャリングなし。
おっと。
人々はマルチテクスチャリングをあまり使用しなかったので、今では、それが本来あるべき程度にほとんど傷つけないでしょう。直接ではありません。マルチテクスチャリングはパフォーマンスをかなり低下させ、多くの場合、マルチパスと比較してそれは価値がありませんでした。そしてもちろん、ゲーム開発者は、マルチテクスチャーを持たない古いハードウェアでゲームが動作することを保証したいので、多くのゲームはそれなしで出荷されました。
したがって、D3Dには猶予が与えられました。
時間が経ち、NVIDIAはGeForce 256（GeForce GT-250ではなく、最初のGeForce）を導入し、今後2年間でグラフィックスカードの競争をほぼ終わらせました。主なセールスポイントは、ハードウェアで頂点変換およびライティング（T＆L）を実行できることです。それだけでなく、NVIDIAは、OpenGLは自分のT＆Lエンジンを効果的にそんなに愛されたのOpenGL。ほとんど文字通り。私が理解しているように、それらのレジスタのいくつかは、実際にはOpenGL列挙子を値として直接使用していました。
Direct3D v6が登場します。やっとマルチテクスチャですが...ハードウェアT＆Lはありません。OpenGLには常に 256の前にソフトウェアで実装されていたにもかかわらず、T＆Lパイプラインがありました。そのため、NVIDIAがソフトウェアの実装をハードウェアソリューションに変換することは非常に簡単でした。D3Dが最終的にハードウェアT＆Lをサポートするまで、D3D v7にはなりません。
Dawn of Shaders、Twilight of OpenGL
その後、GeForce 3が登場しました。そして、多くのことが同時に起こりました。
マイクロソフトは、彼らが再び遅れることはないと決めていました。そのため、NVIDIAが何をしていたかを見てから事実をコピーする代わりに、彼らは彼らに行って話しかけるという驚くべき立場を取りました。そして、彼らは恋に落ち、一緒に小さなコンソールを持っていました。
乱雑な離婚が後に続いた。しかし、それはまた別の時間です。
これがPCにとって意味したことは、GeForce 3がD3D v8と同時に登場したことです。そして、GeForce 3がD3D 8のシェーダーにどのように影響したかを見るのは難しくありません。Shader Model 1.0のピクセルシェーダーは、NVIDIAのハードウェアに非常に固有のものでした。NVIDIAのハードウェアを抽象化する試みは一切行われていません。SM 1.0は、GeForce 3が実行したものでした。
ATIがRadeon 8500でパフォーマンスグラフィックカードレースに飛び込み始めたとき、問題がありました。8500のピクセル処理パイプラインは、NVIDIAのものよりも強力でした。そのため、MicrosoftはShader Model 1.1を発行しました。
これは、D3D側の障害のように聞こえるかもしれません。しかし、失敗と成功は程度の問題です。そして、OpenGLランドで重大な失敗が起きていました。
NVIDIAはOpenGLが大好きだったので、GeForce 3がヒットしたとき、彼らは多数のOpenGL拡張機能をリリースしました。独自の OpenGL拡張：NVIDIAのみ。当然のことながら、8500が登場したとき、それらのどれも使用できませんでした。
少なくともD3D 8の土地では、SM 1.0シェーダーをATIハードウェアで実行できます。確かに、8500のクールさを活用するには新しいシェーダーを作成する必要がありましたが、少なくともコードは機能しました。
OpenGLのRadeon 8500であらゆる種類のシェーダーを使用するために、ATIは多くのOpenGL拡張機能を作成する必要がありました。独自の OpenGL拡張：ATIのみ。したがって、シェーダーを使用するためには、NVIDIAコードパスとATIコードパスが必要でした。
ここで、「OpenGL ARBはどこにあり、その仕事はOpenGLを最新の状態に保つことでしたか？」多くの委員会がしばしば終わる場所：ばかげたこと。
上記を参照してください。ARB_multitextureは、これらすべてに深く関係しているためです。ARBは（部外者の観点から）シェーダーの考えを完全に避けたいように見えました。彼らは、固定機能パイプラインに十分な構成可能性を設定すれば、シェーダーパイプラインの能力に匹敵することができると考えました。
そのため、ARBは拡張後に拡張をリリースしました。「texture_env」という単語が含まれるすべての拡張機能は、このエージングデザインにパッチを当てるもう1つの試みです。レジストリを確認します。ARBとEXT拡張の間に、これらの拡張が8つ作成されました。多くがOpenGLコアバージョンに昇格しました。
マイクロソフトはこの時点でARBの一部でした。彼らはD3D 9がヒットした頃に立ち去った。したがって、彼らが何らかの形でOpenGLを妨害しようとしていた可能性は完全にあります。私は個人的にこの理論を2つの理由で疑っています。1つは、各メンバーが1票しか得られないため、他のARBメンバーから支援を得る必要があったことです。そして最も重要なのは、ARBがMicrosoftの助けを必要としていなかったことです。それについてのさらなる証拠を見るでしょう。
最終的にARBは、おそらくATIとNVIDIA（両方ともアクティブメンバー）の両方の脅威にさらされ、最終的に実際のアセンブリスタイルシェーダーを提供するのに十分な長さで頭を引き出しました。
さらに愚かなものが必要ですか？
ハードウェアT＆L。OpenGLが最初に持っていたもの。面白いですね。ハードウェアT＆Lから最大限のパフォーマンスを得るには、頂点データをGPUに保存する必要があります。結局のところ、頂点データを実際に使用したいのはGPUです。
D3D v7で、Microsoftは頂点バッファーの概念を導入しました。これらには、頂点データを格納するためのGPUメモリのスワスが割り当てられます。
OpenGLがこれに相当するものをいつ入手したか知りたいですか？ああ、NVIDIAは、OpenGLのすべてを愛する（独自のNVIDIA拡張機能である限り）、GeForce 256が最初にヒットしたときに頂点配列範囲拡張機能をリリースしました。しかし、ARBが同様の機能を提供することを決定したのはいつですか？
2年後。これは、頂点シェーダーとフラグメントシェーダー（D3D言語のピクセル）を承認した後のことです。それが、ARBが頂点データをGPUメモリに格納するためのクロスプラットフォームソリューションを開発するのにかかった時間です。繰り返しますが、ハードウェアT＆L が最大のパフォーマンスを達成するために必要なものです。
すべてを台無しにする一つの言語
そのため、OpenGL開発環境はしばらくの間破壊されました。クロスハードウェアシェーダーもクロスハードウェアGPU頂点ストレージもありませんが、D3Dユーザーは両方を楽しみました。悪化する可能性はありますか？
あなた...あなたはそれを言うことができます。3D Labsに入ります。
彼らは誰ですか？彼らは私がOpenGLの真の殺人者であると考えている古い会社です。確かに、ARBの一般的な無能さにより、OpenGLがD3Dを所有するはずだったときにOpenGLが脆弱になりました。しかし、おそらく3D Labsは、OpenGLの現在の市場状態に対する私の最大の最大の理由です。彼らはそれを引き起こすためにおそらく何をしたでしょうか？
彼らはOpenGLシェーディング言語を設計しました。
3D Labsは死にかけている会社でした。高価なGPUは、NVIDIAのワークステーション市場への圧力の高まりによって取り残されていました。また、NVIDIAとは異なり、3D Labsは主流市場に存在していませんでした。NVIDIAが勝った場合、彼らは死にました。
彼らがやった。
そのため、3D Labsは、製品を望まない世界で関連性を維持するため、「OpenGL 2.0」と呼ばれるもののプレゼンテーションを行うGame Developer Conferenceに参加しました。これは、OpenGL APIの完全なゼロからの書き換えになります。そしてそれは理にかなっています。当時、OpenGLのAPI には多くの問題がありました（注：その問題はまだ存在しています）。テクスチャの読み込みとバインドの仕組みを見てください。それは半難解です。
彼らの提案の一部はシェーディング言語でした。当然。ただし、現在のクロスプラットフォームARB拡張とは異なり、それらのシェーディング言語は「高レベル」でした（Cはシェーディング言語の高レベルです。はい、本当に）。
現在、Microsoftは独自の高レベルシェーディング言語に取り組んでいました。それらは、マイクロソフトのすべての集団的想像力の中で、高レベルシェーディング言語（HLSL）と呼ばれていました。しかし、それらは言語に対する根本的に異なるアプローチでした。
3D Labsのシェーダー言語の最大の問題は、組み込みであるということでした。HLSLはマイクロソフトが定義した言語でした。彼らはそのためのコンパイラをリリースし、Shader Model 2.0（またはそれ以降のシェーダーモデル）アセンブリコードを生成し、それをD3Dに送ります。D3D v9の時代には、HLSLはD3Dから直接影響を受けることはありませんでした。それは素晴らしい抽象化でしたが、純粋にオプションでした。そして、開発者は常にコンパイラーの背後に行き、最大のパフォーマンスのために出力を微調整する機会がありました。
3D Labs言語にはそれがありませんでした。ドライバーにCライクな言語を与え、シェーダーを作成しました。物語の終わり。アセンブリシェーダーではなく、他の何かをフィードするものでもありません。シェーダーを表す実際のOpenGLオブジェクト。
これが意味することは、OpenGLユーザーは、アセンブリのような言語をコンパイルするのに苦労している開発者の気まぐれに開放されていたことです。新たに命名されたOpenGL Shading Language（GLSL）では、コンパイラのバグが横行していました。さらに悪いことに、複数のプラットフォームでシェーダーを正しくコンパイルすることができた場合（決して偉業ではありません）、その日のオプティマイザーにさらされていました。それらは可能な限り最適ではありませんでした。
これはGLSLの最大の欠陥でしたが、唯一の欠陥ではありませんでした。はるかに。
D3DおよびOpenGLの古いアセンブリ言語では、頂点シェーダーとフラグメント（ピクセル）シェーダーを組み合わせて使用できます。同じインターフェイスと通信している限り、互換性のあるフラグメントシェーダーと頂点シェーダーを使用できます。そして、受け入れられるレベルの非互換性さえありました。頂点シェーダーは、フラグメントシェーダーが読み取らなかった出力を書き込むことができます。などなど。
GLSLにはそれがありませんでした。頂点シェーダーとフラグメントシェーダーは、3D Labsが「プログラムオブジェクト」と呼んだものに融合されました。したがって、頂点プログラムとフラグメントプログラムを共有する場合は、複数のプログラムオブジェクトを作成する必要がありました。そして、これが2番目に大きな問題を引き起こしました。
ほら、3D Labsは彼らが賢いと思っていた。彼らはGLSLのコンパイルモデルをC / C ++に基づいていました。.cまたは.cppを取り、それをオブジェクトファイルにコンパイルします。次に、1つ以上のオブジェクトファイルを取得し、それらをプログラムにリンクします。これがGLSLのコンパイル方法です。シェーダー（頂点またはフラグメント）をシェーダーオブジェクトにコンパイルします。次に、これらのシェーダーオブジェクトをプログラムオブジェクトに入れ、それらをリンクして実際のプログラムを形成します。
これにより、メインシェーダーが呼び出すことができる追加のコードを含む「ライブラリ」シェーダーを持つなどの潜在的なクールなアイデアが可能になりましたが、実際には、シェーダーは2回コンパイルされました。コンパイル段階で1回、リンク段階で1回。特にNVIDIAのコンパイラは、基本的にコンパイルを2回実行することで知られていました。何らかの種類のオブジェクトコードを生成しませんでした。一度コンパイルして回答を破棄し、リンク時に再度コンパイルしました。
したがって、頂点シェーダーを2つの異なるフラグメントシェーダーにリンクする場合でも、D3Dよりもはるかに多くのコンパイルを行う必要があります。特に、Cに似た言語のコンパイルはすべてオフラインで行われたため、プログラムの実行開始時ではありません。
GLSLには他の問題もありました。おそらく、ARBが最終的に言語を承認し、組み込んだので、3D Labsに責任を負わせるのは間違っているように思われます（ただし、「OpenGL 2.0」イニシアチブの他には何もありません）。しかし、それは彼らのアイデアでした。
そして、ここに本当に悲しい部分があります：3D Labsは正しかった（ほとんど）。GLSLは、当時のHLSLのようなベクトルベースのシェーディング言語ではありません。これは、3D Labsのハードウェアがスカラーハードウェア（最新のNVIDIAハードウェアに類似）であったためでしたが、多くのハードウェアメーカーがハードウェアを使用する方向に最終的には正しかったためです。
彼らは、「高水準」言語用のコンパイルオンラインモデルを使用するのが適切でした。D3Dは最終的にはそれに切り替えました。
問題は、3D Labsが間違った時間に正しかったことです。そして、将来を早めに呼び込もうとするとき、将来を保証しようとするとき、彼らは現在を捨てます。これは、OpenGLがT＆L機能の可能性を常に持っていた方法に似ています。ただし、OpenGLのT＆LパイプラインはハードウェアT＆Lの前にまだ有用でしたが、GLSLは世界がそれに追いつく前の責任でした。
GLSLは今では良い言語です。しかし、しばらくの間？それは恐ろしいことでした。そして、OpenGLはそのために苦しみました。
神格化に向かって落ちる
3D Labsが致命的な打撃を与えたと私は主張していますが、Aの中の最後の釘を動かすのはARBそのものでした。
これはあなたが聞いたことがあるかもしれない物語です。OpenGL 2.1の時点までに、OpenGLは問題に直面していました。これには、多くのレガシーな問題がありました。APIはもう使いやすいものではありませんでした。物事を行うには5つの方法がありましたが、どれが最も速いかはわかりませんでした。簡単なチュートリアルでOpenGLを「学ぶ」ことはできますが、実際のパフォーマンスとグラフィカルなパワーを提供するOpenGL APIを実際には学習していません。
そこで、ARBはOpenGLの別の再発明を試みることにしました。これは3D Labsの「OpenGL 2.0」に似ていましたが、ARBがその背後にあったため、より優れていました。彼らはそれを「ロングピーク」と呼びました。
APIを改善するのに少し時間がかかるのは何が悪いのでしょうか？これは、Microsoftが脆弱なままになっていたため、悪いことでした。ご覧のとおり、これはVistaの切り替え時でした。
Vistaを使用して、Microsoftはディスプレイドライバーに必要な変更を加えることを決定しました。彼らは、グラフィックスメモリの仮想化やその他のさまざまなことのために、ドライバーにOSへの提出を強制しました。
このメリットや実際に可能であったかどうかについて議論することはできますが、事実はこれにとどまります。MicrosoftはD3D 10をVista（およびそれ以上）のみと見なしました。D3D 10 対応のハードウェアがあったとしても、Vistaを実行しないとD3D 10アプリケーションを実行できませんでした。
また、Vistaを覚えているかもしれません...ええと、それはうまくいかなかったと言ってみましょう。したがって、パフォーマンスの低いOS、そのOSでのみ実行される新しいAPI、およびそのAPIとOSが前の世代よりも高速であるために必要な新しい世代のハードウェアがありました。
ただし、開発者は OpenGLを介してD3D 10クラスの機能にアクセスできます。まあ、ARBがロングズピークでの作業で忙しくなかったなら、彼らはできました。
基本的に、ARBはAPIを改善するために1年半から2年分の作業を費やしました。OpenGL 3.0が実際に登場する頃には、Vistaの採用が始まり、Win7はすぐにVistaを後押しし、ほとんどのゲーム開発者はD3D-10クラスの機能を気にしませんでした。結局、D3D 10ハードウェアはD3D 9アプリケーションを問題なく実行しました。また、PCからコンソールへのポートの増加（またはPC開発者がコンソール開発に飛びついています。選択してください）により、開発者はD3D 10クラス機能を必要としませんでした。
現在、開発者がWinXPマシンのOpenGLを介して以前にこれらの機能にアクセスできた場合、OpenGL開発は大いに必要なショットを受け取った可能性があります。しかし、ARBはチャンスを逃しました。そして、あなたは最悪の部分を知りたいですか？
APIをゼロから再構築しようとして2年の貴重な年月を費やしましたが... それでも失敗し、現状に戻りました（廃止メカニズムを除く）。
そのため、ARBは重要な機会の機会を逃しただけでなく、その機会を逃したタスクも完了しませんでした。ほとんどすべての叙事詩が失敗します。
そして、それがOpenGLとDirect3Dの物語です。逃した機会、ひどい愚かさ、故意の失明、単純な愚かさの物語。