OpenGLのダイレクトステートアクセスメカニズムの利点は何ですか？

私はopengl.orgで OpenGL 4.5ダイレクトステートアクセス（DSA）について読んでいますが、正しく機能しているかどうかはわかりません。

古い方法は効率が悪いことを暗示しているようです：

glBind(something)
glSetA(..)
glSetB(..)
glSetC(..)

新しい方法より：

glSetA(something, ..)
glSetB(something, ..)
glSetC(something, ..)

その見た目から、それぞれglSetがglBind(something)その内部に含まれている必要があり、OpenGLがまだ状態マシンである場合、単一のに適用されたストリーム化された変更を利用できませんsomething。

新しいDSAの背後にある理由と利点を説明してください。

その外観から、各glSetは内部にglBind（something）を含める必要があります

ではない正確に。以下のいくつかの段落で説明するように、これは逆です。

それが真実であったとしても、クライアントアプリからGLサーバー（別名ドライバー）へのGLコマンドには、通常の関数呼び出しと比較して、ディスパッチのオーバーヘッドが多いことに注意してください。DSA関数が既存の関数の単なるラッパーであると仮定した場合でも、それらはGLサーバー内に存在するラッパーであるため、オーバーヘッドが（少し）少なくなります。

OpenGLがまだ状態マシンである場合、単一の何かに適用されたストリーム化された変更を利用できません。

GPUはステートマシンではありません。GLステートマシンインターフェイスは、DSAのようなドライバーの内部をラップするエミュレーションであり、その逆ではありません。

ラッピングの1つの層（GLサーバーへの過度の呼び出しを必要とする層）を削除することは、たとえ小さなものであっても、明らかに有利です。

ステートマシンアプローチは、複数のスレッドを処理する場合にも意味がありません。このユースケースではGLは依然としてひどいですが、ドライバーはバックグラウンドでスレッドを使用することが多く、ステートマシンは、多くのスレッドの同期や、物事を確実に機能させるための非常に優れた並列アルゴリズム/構造を必要とします。

DSA拡張は、結局のところ、完全に新しいAPIではなく、既存の状態ベースのドキュメントに対する拡張であるため、状態の変化の観点からその操作をフレーズし続けているため、既存のGL仕様にプラグインする準備ができていなければなりませんでしたドキュメントの言語と用語。その既存の言語が最新のグラフィックスハードウェアAPIとしての仕事にかなりひどく適しているとしても。

新しいDSAの背後にある理由と利点を説明してください。

最大の理由は、古い方法が苦痛だったということです。それぞれがGLの状態を変更したり、GLの状態に依存する可能性のあるライブラリを一緒に構成することは非常に困難になりました。手続き型の状態管理ルートが深いため、GL APIをオブジェクト指向または機能的なスタイルで効率的にラップすることが難しくなり、APIをさまざまな非C言語でラップすることが困難になり、効率的なグラフィックデバイスラッパーを提供することも困難になりました。 Direct3Dからの抽象的なOpenGL。

2つ目は、前述のように、手続き型の状態マシンAPIのオーバーヘッドでした。

第3に、DSA機能は、効率の向上を可能にする古いAPIからセマンティクスを適切に変更しました。以前は変更可能であったものが不変になり、たとえば、GLサーバーから多くの簿記コードが削除されました。GLサーバーが可変オブジェクトを処理する必要がない場合は、アプリケーションによる呼び出しをハードウェアにディスパッチしたり、より早く（またはより並列的に）検証したりできます。

-

追加の正当化と説明は、EXT_direct_state_access拡張仕様に記載されています。

-

API設計に関連するハードウェアの変更はかなり多くあります。

OpenGLは1991年に遡ることを思い出してください。ターゲットハードウェアは、コンシューマーグレードのグラフィックカード（存在しないもの）ではなく、大きなCADワークステーションなどでした。その時代のハードウェアは、今日とはまったく異なるパフォーマンスエンベロープを備えていました。マルチスレッディングはまれであり、メモリバスとCPUの速度ギャップは少なく、GPUは固定関数の三角形レンダリングにすぎませんでした。

ますます多くの固定機能機能が追加されました。さまざまなライティングモデル、テクスチャモードなどがすべて追加されました。それぞれに独自の状態が必要です。単純な状態ベースのアプローチは、少数の状態があるときに機能しました。ステートが追加されるにつれて、APIは継ぎ目でバーストし始めました。APIはより厄介なものになりましたが、実際には多くの状態スイッチに基づいているため、ハードウェアモードからそれほど離れていません。

その後、プログラム可能なハードウェアが登場しました。ハードウェアはますますプログラム可能になり、現在では、ハードウェアが少しの状態、いくつかのユーザー提供のプログラム、および多くのバッファーをサポートしています。その時代のすべての固定機能機能がドライバーによってエミュレートされていたのと同じように、前の時代のそのすべての状態をエミュレートする必要がありました。

ハードウェアも、ますます並列化するように変更されました。これにより、グラフィックスの状態の変更を非常に高価にする他のハードウェアの再設計が必要になりました。ハードウェアは、不変状態の大きなブロックで動作します。これらの変更により、ドライバーは、ユーザーが設定した状態を少しずつ適用するだけではなく、変更を自動的にバッチ処理し、必要に応じて暗黙的に適用する必要がありました。

最新のハードウェアは、従来のOpenGLモデルからさらに機能します。DSAは、D3D10が行ったのと同様に、10年以上前に必要になった1つの小さな変更です（元々はOpenGL 3.0の一部として約束されていました）。上記のハードウェア変更の多くは、OpenGLを適切に維持するためにDSAだけでは足りません。そのため、OpenGLモデルを大幅に変更するさらに大きな拡張機能を利用できます。次に、まったく新しいGLnext APIに加えて、D3D12、Mantle、Metalなどがあり、時代遅れのステートマシンの抽象化を維持するものは1つだけではありません。

概要では、次のことを正当化します。

この拡張の目的は、ライブラリーがセレクターとラッチされた状態の妨げにならないように、ライブラリーをより効率的にすることです。この拡張機能では、セレクター更新コマンドの必要性をなくすことにより、コマンドをより効率的に使用することもできます。

ここで「より効率的」とは、ライブラリ作成者の簿記のオーバーヘッドを減らし、パフォーマンスを向上させることを指します。現在のAPIでは、「適切に動作する」ためには、状態を照会し、それを隠して、必要なことを行うように状態を変更してから、元の状態を復元する必要があります。

お気に入り

oldState = glGet()
glBind()
glDoThings...
glSet(oldState)  // restore, in case anyone needs it just as they left it

おそらく、明示的な状態変更APIを使用すると、古いハードウェアのパフォーマンスが向上する可能性があります。それ以外の場合はかなり奇妙な儀式です。この拡張は、フェッチ、セット、リストアダンスを回避することが、現在のハードウェアでのパフォーマンス向上につながることを意味します（そして、著者リストを参照してください！）。