始める前に、Direct3DよりもOpenGLについて多くのことを知っています。 私はこれまでにD3Dのコードを1行も書いたことがなく、OpenGLチュートリアルを書きました。 したがって、ここでお話しすることは、偏見の問題ではありません。 これは単なる物語です。
紛争の起源
ある日、90年代前半に、マイクロソフトは見回しました。 彼らは素晴らしいスーパー任天堂とセガジェネシスを見ました。 そして、彼らはDOSを見ました。 開発者は、DOSとコンソールの両方について、ハードウェア上で直接記述しました。 しかし、開発者がユーザーのハードウェアを正確に知っていたコンソールとは異なり、DOSの開発者は多くの異なるハードウェア構成に基づいて記述することを余儀なくされました。 そして、これは一見思われるよりもはるかに複雑です。
当時、Microsoftにはさらに大きな問題がありました：Windows。 Windowsは、開発者が望むことを何でもできるDOSとは異なり、機器を片手で管理したいと考えていました。 アプリケーション間の相互作用を合理化するために、所有機器が必要でした。 ゲーム開発者は、素晴らしいゲームに使用できる貴重なリソースを奪ったため、インタラクションが好きではありませんでした。
Windowsのゲーム開発者を引き付けるために、Microsoftは低レベルで、Windowsで実行され、ブレーキに苦しまず、最も重要なことに
は開発者からハードウェアを抽象化する単一のAPIを必要としてい
ました 。 グラフィック、サウンド、ユーザー入力用の単一のAPI。
そして、DirectXが生まれました。
3Dアクセラレータは、数か月後に誕生しました。 そして、マイクロソフトは一度にいくつかの問題に直面しました。 DirectXグラフィックコンポーネントであるDirectDrawは、2Dグラフィックでのみ機能します：グラフィックメモリの割り当てと、割り当てられた異なるメモリセクション間のビット単位のコピー。
また、Microsoftはいくつかの中間ドライバーを購入し、Direct3Dバージョン3を作成しました。 それだけではありません。 コードを一目見ただけで、恐怖に巻き込まれました。
Id SoftwareのOld John Carmackはこのゴミを見て、「地獄へ！」と言い、別のAPI-OpenGLの下で書くことにしました。
この問題のもつれの別の部分は、MicrosoftがSGIと協力してWindows用のOpenGLを実装するのに非常に忙しかったことです。 アイデアはシンプルでした-典型的な作業GLアプリケーションの開発者を引き付けるために：自動設計システム、モデリング、すべて。 ゲームはMicrosoftが最後に考えたものでした。 すべてWindows NT向けでしたが、Microsoftはこの実装をWin95にも追加することにしました。
プロのソフトウェア開発者の注意をWindowsに引き付けるために、Microsoftは3Dグラフィックスアクセラレータの新機能へのアクセスで彼らを買収しようとしました。 Microsoftは、プロトコルInstallable Client Driverを作成しました。グラフィックアクセラレータの製造元は、OpenGLハードウェアのソフトウェア実装に過負荷をかける可能性があります。 コードは、利用可能な場合、ハードウェア実装を単に自動的に使用しました。
サンライズOpenGL
そのため、Direct3DとOpenGLの力の調整が定義されています。 これは、D3D v3がどれほどひどいものだったかを考えると、本当に興味深い話です。
OpenGLアーキテクチャレビューボード（ARB）は、OpenGL標準のサポートを担当する組織でした。 彼らは多くの拡張機能をリリースし、拡張機能リポジトリに従って、APIの新しいバージョンを作成しました。 委員会には、多くの有力なグラフィック業界のプレーヤーとOS開発者が参加しました。 AppleとMicrosoftもかつてこの委員会のメンバーでした。
次にVoodoo2を搭載した3Dfxが登場しました。 これは、OpenGLがこれまでできなかった最初のマルチテクスチャデバイスでした。 3DfxはOpenGL標準にはまったく適合しませんでしたが、その後のマルチテクスチャグラフィックチップ（TNT1）の開発者であるNVIDIAは、この実装を検討しました。 ARBは拡張機能GL_ARB_multitextureをリリースする必要がありました。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には
常に T＆Lパイプラインがあり、256が登場する前からプログラムで実装されていました。 したがって、NVIDIAがソフトウェア実装をハードウェア実装に変換することはそれほど難しくありませんでした。 D3Dでは、ハードウェアT＆Lは7番目のバージョンでのみ登場しました。
ドーンオブシェーダー、トワイライトOpenGL
その後、GeForce 3が登場し、多くのことが同時に起こりました。
マイクロソフトは、今や彼らが休暇に遅れることはないと確信しました。 そして、NVIDIAが何をしているのかを見て、事実の後にそれをコピーする代わりに、彼らはNVIDIAに来て話しました。 それから彼らは恋に落ち、この組合から小さなゲーム機が現れました。
それから痛みを伴う離婚がありました。 しかし、これはまったく異なる話です。
PCの場合、これはGeForce 3がD3D v8と同時に登場したことを意味します。 また、GeForce 3が8つのシェーダーにどの程度影響したかを簡単に確認できます。 Shader Model 1のピクセルシェーダーは、NVIDIAハードウェアと非常に強く結びついていました。 NVIDIAのハードウェア抽象化はまったくありませんでした。 SM 1.0は、本質的にGeForce 3がしたことです。
ATIがRadeon 8500でパフォーマンスグラフィックレースに参加したとき、問題が発見されました。 8500ピクセルコンベヤーは、NVIDIAよりも強力でした。 マイクロソフトはShader Model 1.1をリリースしました。これは基本的に「8500がやったこと」でした。
これは、D3D側の障害のように思えるかもしれません。 しかし、失敗と成功は相対的な問題です。 本当の失敗はOpenGLキャンプで発生しました。
NVIDIAはOpenGLを愛していたため、GeForce 3が登場したときにOpenGL拡張キットをリリースしました。 NVIDIAのみに適した
独自の拡張機能。 当然、8500が発売されたとき、彼はそれらのどれも使用できませんでした。
D3D v8では、少なくともATIハードウェアでSM 1.0シェーダーを実行できます。 当然、8500の利点を使用するには、新しいシェーダーを作成する必要がありますが、コードは少なくとも
機能しました 。
OpenGLの8500
で少なくともいくつかのシェーダーを取得するに
は 、ATIはいくつかのOpenGL拡張機能を作成する必要がありました。 ATIにのみ適した
独自の拡張機能。 したがって、少なくともいくつかのシェーダーを使用するには、NVIDIAとATIの2つのコード実行方法を作成する必要がありました。
「OpenGL ARBは何をしていて、その仕事はOpenGLを最新の状態に保つことでしたか？」 はい、ほとんどの委員会が行うことと同じこと：愚か。
おわかりのように、ARB_multitextureはこのストーリーの一部でもあるため、上記で言及しました。 外部オブザーバーの観点から、ARBはシェーダーの追加をまったく回避しようとしました。 固定機能を備えたかなり構成可能なコンベヤーを作成すれば、シェーダーコンベヤーの能力と同等になると彼らは考えていました。
そして、ARBは拡張後に拡張のリリースを開始しました。 「texture_env」という名前の各拡張機能は、このエージングデザインにパッチを当てる別の試みでした。 レジストリを確認してください。ARB拡張とEXT拡張の間に、すでに
8つあります。 多くはOpenGLのメジャーバージョンに含まれています。
当時のマイクロソフトはARBのメンバーでした。 彼らはD3D 9のリリースの頃に去りました。したがって、原則として、OpenGLの開発を何らかの形で妨害した可能性があります。 私は個人的に、このバージョンを2つの理由で疑っています。 最初に、彼らは他の委員の助けを得る必要があります。なぜなら、1人の会員は1票しか投票しないからです。 そしてさらに重要なこととして、第二に、委員会はマイクロソフトがそのような失敗に至る必要がなかった。 少し後で、何が起こったのかを確認します。
ATIとNVIDIA（非常に活発な参加者）の猛攻撃の下で、おそらくARBは目覚め、アセンブラー型シェーダーを受け入れるようになりました。
もっと愚かさを見たいですか？
ハードウェアT＆L。 これは
以前にOpenGLに登場しまし
た 。 ここに興味深いものがあります。 ハードウェアT＆Lから最大限のパフォーマンスを引き出すには、データをGPUに保存する必要があります。 結局のところ、それらが使用されるのはGPUです。
D3D v7で、Microsoftは頂点バッファーの概念を導入しました。 これらは、頂点データを保存するための専用のGPUメモリの場所です。
この類似物がOpenGLに登場したことを知りたいですか？ ああ、NVIDIAは、OpenGLに関連するすべてのファンである（書かれている限りNVIDIAのプロプライエタリな拡張である限り）、GeForce 256の最初のリリース中に頂点配列の拡張をリリースしました。
2年後 。 これは、頂点シェーダーとフラグメントシェーダー（D3D言語のピクセル）を承認した
後に発生しまし
た 。 それが、ARBがGPUメモリにデータを保存するためのクロスプラットフォームソリューションを開発するのにかかった時間です。 ハードウェアT＆Lを最大限に活用するために必要なもの。
すべてを破壊する1つの言語
そのため、OpenGLの開発は断片化されています。 D3Dユーザーがすでに両方を楽しんでいたとき、GPUには単一のシェーダーも単一のストレージもありません。 悪化する可能性はありますか？
まあ...あなたはそれを言うことができます。 会う：
3D Labs彼らは誰ですか？ これは、私がOpenGLの本当の殺人者だと思う破産会社です。 当然のことながら、全体の弛緩したARBにより、OpenGLがすべての面でD3Dに勝ると想定されていたときにOpenGLが脆弱になりました。 しかし、3D Labsは間違いなくOpenGLの現在の市場での地位の最大の理由です。 彼らはこれを何ができるでしょうか？
彼らはOpenGLシェーダー言語を開発しました。
実際、3D Labsは死にかけている会社でした。 NVIDIAがデスクトップコンピューター市場に圧力をかけたとき、高価なアクセラレーターは不要になりました。 また、NVIDIAとは異なり、共通市場には存在しませんでした。 NVIDIAが勝った場合、それらは消えます。
そしてそれが起こった。
そして、製品を必要としない世界に浮かんでいるために、3D LabsはGame Developer Conferenceに「OpenGL 2.0」と呼ばれるもののプレゼンテーションを行いました。 これは、OpenGL APIによってゼロから完全に書き直されることになっています。 そしてそれは理にかなっています。 OpenGL APIには
多くの粗さがありました（注：現在は存在しています）。 テクスチャの読み込みとスナップがどのように見えるかを見てください。 それはある種の黒魔術です。
彼らの提案の一部はシェーダー言語でした。 行くぞ ただし、現在のクロスプラットフォームARB拡張とは異なり、それらのシェーダー言語は「高レベル」でした（Cはシェーダーの高レベル言語です。いいえ、本当に）。
そのため、Microsoftはこの時点で独自の高レベルシェーダー言語に取り組んでいました。 彼らは昔の習慣で「ハイレベルシェーダー言語」（HLSL）と呼んでいました。 しかし、言語へのアプローチは根本的に異なっていました。
3D Labsシェーダー言語の最大の問題は、組み込みであったことです。 HLSLはMicrosoftが定義した言語でした。 彼は、D3Dに挿入したShader Model 2.0（およびそれ以降）のアセンブリコードを生成するコンパイラをリリースしました。 D3D v9の時代、HLSLはD3Dから直接呼び出されることはありませんでした。 これは便利な抽象化ですが、完全にオプションです。 開発者は常にコンパイラを延期し、コードを最大のパフォーマンスに修正する機会がありました。
3D Labsでは
、これは起こり
ませんでした。 Cのような言語でドライバーコードをフィードすると、シェーダーが返されました。 これで話は終わりです。 また、アセンブラシェーダではなく、どこにでも挿入できるものでもありません。 シェーダーを表す真のOpenGLオブジェクト。
つまり、OpenGLユーザーは、コンパイルされたアセンブラーに似た言語の処理を始めたばかりの開発者エラーに対して無防備でした。 新しいOpenGLシェーダー言語（GLSL）のコンパイラーのバグは
群れにすぎませんでした。 さらに悪いことに、複数のプラットフォーム用のシェーダーを正しくコンパイルできた場合（それ自体が困難なタスク）、その時点の
オプティマイザーに対処する必要がありました。 それらは可能な限り最適ではありませんでした。
これはGLSLの主な問題でしたが、唯一の問題ではありませんでした。 唯一のものからは
程遠い 。
D3Dでは、古いOpenGLアセンブラー言語のように、頂点シェーダーとフラグメント（ピクセル）シェーダーを混在させることができます。 単一のインターフェイスを使用する限り、互換性のあるフラグメントシェーダーを備えた頂点シェーダーを使用できます。 さらに、原則として許容できるレベルの非互換性がありました。 頂点シェーダーは、フラグメントシェーダーが単に読み取らなかったデータを生成できます。 などなど。
GLSLにはそのようなものはありませんでした。 頂点シェーダーとフラグメントシェーダーは、3D Labsが「ソフトウェアオブジェクト」と呼んだ単一の抽象化にまとめられました。 また、頂点プログラムとフラグメントプログラムを一緒に使用する場合は、そのようなプログラムオブジェクトをいくつか作成する必要がありました。 そして、それが2番目の問題の原因でした。
ご覧のとおり、3D Labsは非常に賢いことをしていると考えていました。 彼らはGLSLのコンパイルモデルをC / C ++に基づいていました。 .cまたは.cppを取得して、オブジェクトファイルにコンパイルします。 次に、1つ以上のオブジェクトファイルを取得し、それらをプログラムにリンクします。 これがGLSLでのコンパイル方法です。シェーダー（頂点またはフラグメント）をシェーダーオブジェクトにコンパイルします。 次に、このシェーダーオブジェクトをプログラムオブジェクトに配置し、それらをリンクしてプログラムを取得します。
これにより、メインシェーダーと共有される追加コードを含むシェーダーの「ライブラリ」など、潜在的にクールなことができますが、実際には、シェーダーは2回コンパイルされました。 コンパイル段階で1回、リンク段階で1回。 中間オブジェクトコードは作成されませんでした。 シェーダーは単純にコンパイルされ、コンパイル結果は破棄され、リンク中にコンパイルが繰り返されました。
したがって、頂点シェーダーを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パイプラインはハードウェアの実装前でも
有用であり、GLSLは世界がそれを受け入れる準備が整う前の負担でした。
GLSLは現在、優れた言語です。 しかし、彼の時間のために彼はひどかった。 そして、OpenGLはそのために苦しみました。
神格化が近づいています
3D Labsは致命的な打撃を与えたと私は主張しますが、OpenGLのlidの蓋に最後の釘を打ち込んだのはARB委員会でした。
この話を聞いたことがあるに違いありません。 OpenGL 2.1の時代、OpenGLは問題に直面していました。 彼にはたくさんの古いバンプがありました。 APIの使用は困難でした。 各アクションには5つの方法があり、どれが最も速いかは誰にもわかりませんでした。 簡単なチュートリアルでOpenGLを「学習」することはできますが、どのAPIが最大のパフォーマンスを提供するかについては誰も説明しませんでした。
そして、ARBは、OpenGLを再発明する別の試みを行うことを決定しました。 3D LabsのOpenGL 2.0のようなものでしたが、ARBが背後にあるためより優れていました。 この試みは「ロングピーク」と呼ばれていました。
古いAPIを修正しようとすると何が問題になりましたか？ 悪いニュースは、マイクロソフトが当時脆弱だったということです。 これはVistaのリリース時間でした。
Vistaでは、Microsoftはディスプレイドライバーに長く必要な変更を導入することを決定しました。 ビデオメモリなどの仮想化のために、ドライバーにOSへのアクセスを強制しました。
必要かどうかは疑わしいが、事実は残っている。Microsoftは、D3D 10はVista（およびそれ以降のOS）専用であると判断した。 D3D 10の機能を実行できるハードウェアがあったとしても、Vistaを起動せずにD3D 10アプリケーションを実行することはできません。
また、おそらくVistaを覚えているでしょう...まあ、それは非常にうまくいかなかったと言ってみましょう。 したがって、ブレーキOS、このOSでのみ実行される新しいAPI、および前世代のアクセラレーターを上回るAPIとOSを必要とする新世代のアクセラレーターがありました。
ただし、開発者
は OpenGLを介してD3D 10レベルの機能にアクセス
できます。 まあ、ARBがLongs Peakでの作業で忙しくないのなら、彼らはできます。
概して、ARBはAPIを改善するために1年半から2年を費やしました。 OpenGL 3.0がリリースされたとき、Vistaは時間切れになり、Win7が登場し、ほとんどの開発者はD3D-10の機能に興味を持ちませんでした。 最終的に、D3D 10の対象となるハードウェアはD3D 9で素晴らしく機能しました。また、PCからセットトップボックス（またはセットトップボックス用に開発しているPC開発者）へのポートの全盛期では、D3D 10クラスの機能は主張されませんでした。
開発者がWinXPを搭載したマシンでOpenGLを介してこれらの機能に以前にアクセスできた場合、OpenGL開発には非常に必要な衝動がかかります。 しかし、ARBはこの機会を逃しました。 そして、あなたは何が最悪なのか知っていますか？
APIをゼロから開発するのに2年の貴重な年月が費やされたという事実にもかかわらず...彼らは
まだ失敗し、以前のバージョンに戻ることを余儀なくされました。
つまり、ARBは素晴らしい機会を逃しただけでなく、機会を逃したタスクも実行しませんでした。 完全な失敗。
これは、OpenGLとDirect3Dの間の闘争の物語です。 逃した機会、大きな愚かさ、失明、無謀さの物語。