OpenGLのバージョンとgpus - どのような互換性がありますか？

Question

私はグラフィックカードのバージョン、OpenGLのバージョンとAPIヘッダーがどのように連携しているかを理解しようとしています。私はOpenGLフォーラムや他の場所でOpenGL 2.0/3.0/3.1のバカラを読んだことがありますが、これが開発者（OpenGL初心者）としてどのように機能するかはまだ分かりません。 （私はカードの1つを購入しているので、この質問ではnVidiaを例として使用していますが、明らかに私が開発したソフトウェアにはベンダーに依存したくありません）。

まず、OpenGLバージョンをサポートする必要があるGPUがあります。しかし、例えば。 nVidiaには、古いビデオカード用のドライバがあり、OpenGL 3をサポートしています。これは、これらのドライバがハードウェアにない新しい機能をエミュレートするためにソフトウェアで特定の機能を実装していることを意味しますか？

次に、APIヘッダーがあります。 OpenGL 3用のアプリケーションを作成することにした場合、このバージョンをサポートするヘッダーを持つプラットフォームSDKの更新版をリリースするまで待つ必要がありますか？コード内のプリプロセッサ定義でどのAPIを使用するかを選択するか、最新のプラットフォームSDKに更新するだけで最新のバージョンにアップグレードしますか（この最後のオプションは想像できませんが、わかりません）。 ..）。

下位互換性はどうですか？ OpenGL 1.2を対象としたアプリケーションを作成した場合、OpenGL 3をサポートするカードのドライバをインストールしたユーザーは、それを実行できますか？または、アプリケーションのカードの機能/サポートされているバージョンをテストする必要がありますか？ http://developer.nvidia.com/object/opengl_3_driver.htmlを読むと、少なくとも1.2に対して書かれたnVidiaカードアプリケーションは引き続き動作することが確認されているようですが、これは他のベンダーが1.2 APIをサポートするのを止めるかもしれないことを意味します。基本的には、今後も1.2をサポートしていないため、ソフトウェアが最近のカードで動作しない将来の位置に（潜在的に）私を置きます。しかし、私がOpenGL 3または2を今日開発した場合、gpuの唯一のサポートである1.2をシャットアウトすることがあります。

私はOpenGLのファンシーな機能は必要ありません。シェーディングをほとんど使用していないので、固定パイプラインがうまく動作します（私のアプリケーションはCAD風です）。新しいアプリケーションをベースにしたベストバージョンは、何年にもわたって増分アップデートされて長寿命のアプリケーションになると期待していますか？

この文脈に関連する他の問題を忘れている可能性があります。洞察力は非常に高く評価されています。

Answer 1

私のOpenGLの経験から、特定のバージョンを「対象とする」とは、そのバージョン用に追加されたさまざまな拡張機能にアクセスしているようです。したがって、OpenGLバージョン3をターゲットにする唯一の理由は、バージョン3の新しい拡張機能を使用する場合です。バージョン3拡張機能を実際に使用していない場合（基本的なOpenGLの機能を使用している場合）当然のことながら、あなたは「バージョン3」を「ターゲット設定」していません。

Visual Studioでは、アプリケーションを常にopengl32.libにリンクし、opengl32.libは異なるOpenGLバージョン間で変更されません。代わりにOpenGLはwglGetProcAddress（）を使用して、コンパイル時ではなく実行時にOpenGL拡張/バージョンに動的にアクセスします。つまり、あるドライバが拡張機能をサポートしていない場合、wglGetProcAddress（）は、その拡張機能のプロシージャが要求されたときに実行時にNULLを返します。あなたのコードでは、NULLの戻りケースを処理するロジックを実装する必要があります。最も単純なシナリオでは、単にエラーを出力し、「この機能は利用できないので、このプログラムは動作します...」と言うことができます。または、拡張機能を使用しない同じことを行うための他の代替方法を見つけることもできます。ほとんどの場合、あなたが探している拡張機能を追加したOpenGLバージョンをサポートしていない古いハードウェア/ドライバでアプリケーションを実行している場合にのみ、wglGetProcAddressからNULLを返します。しかし、将来的には、OpenGLの新しいバージョンが廃止することを決定したものに遅れを取らないようにしたいと考えています。私は3.1仕様をあまり読んでいないのですが、明らかに古いテクノロジー/拡張機能が推奨されない廃止予定モデルを導入しているため、廃止予定の拡張機能をもはやサポートしなくなる新しいハードウェア/ドライバの扉が開かれますwglGetProcAddressはこれらの拡張機能に対して再びNULLを返します。したがって、wglGetProcAddress（）のNULL戻り値を処理するためのロジックを配置する場合は、非推奨の拡張機能であっても問題ありません。よりよい選択肢を実装したり、新しい拡張機能をデフォルトにすることが必要になるかもしれません。

バージョンが変更されたAPIヘッダーがある限り、ヘッダーの変更はほとんどの場合、wglGetProcAddress（）によって返された新しい関数へのアクセスを許可するように変更されています。したがって、バージョン2用のAPIヘッダーを含めると、OpenGL 2用の拡張機能だけが必要な場合は有効です。バージョン3で追加された関数/拡張機能にアクセスする必要がある場合は、バージョンを置き換えます2ヘッダーにバージョン3ヘッダーを追加しました。新しい拡張機能に関連付けられた関数ポインタのtypedefを追加するだけで、wglGetProcAddress（）を呼び出すときに正しい関数ポインタに戻り値をキャストできます。例：上記の例で

PFNGLGENQUERIESARBPROC glGenQueriesARB = NULL; 

... 

glGenQueriesARB = (PFNGLGENQUERIESARBPROC)wglGetProcAddress("glGenQueriesARB"); 

、PFNGLGENQUERIESARBPROCのtypedefは、APIヘッダに定義されています。 glGenQueriesARBが1.2で追加されたと思います。PFNGLGENQUERIESARBPROCの定義を取得するには、少なくとも1.2のAPIヘッダーが必要です。それは本当にヘッダーのすべてです。

もう1つ、私は3.1について言及したいと思います。明らかに3.1では、表示リスト、glBegin/glEndメカニズム、GL_SELECTレンダリングモードなど、私の会社がかなり一般的に使用していた多くのOpenGL機能を非難しています。詳細についてはあまりよく分かりませんが、リンクする新しいopengl32.libを作成しなくても、どうやってそれを行うことはできません。なぜなら、そのほとんどの機能がopengl32.libに組み込まれているように見えるからです。 wglGetProcAddressによってアクセスされません。さらに、Microsoftは、新しいopengl32.libをVisual Studioのバージョンに含める予定ですか？私はこれらの質問に対する答えはありませんが、3.1がそれを非難しても、この機能は長い間存在すると思います。現在のopengl32.libにリンクしている場合、ハードウェアのアクセラレーションが失われることもありますが、ほぼ無期限に動作するはずです。 Web上で利用可能なOpenGLチュートリアルの大部分は、プリミティブを描画するためのglBegin/glEndメソッドを使用しています。 GL_SELECTについても同じことが当てはまりますが、多くのハードウェアがGL_SELECTレンダリングモードを加速しなくなりました。 opengl.orgのチュートリアルでさえ廃止予定のglBegin/glEndメソッドを使用しています。そして、私はまだ3.1の機能しか使っていない「始めている」チュートリアルを見つけていない。機能がなくなるのを避けている。とにかく、3.1は新しいもののために古いものをたくさん投げ捨ててしまったようですが、私は古いものはまだかなり長い間使われていると思います。

短いストーリー、ここに私のアドバイスです。 OpenGLのニーズが単純な場合は、基本的なOpenGL機能を使用してください。頂点配列はバージョン1.1-3でサポートされています。1だから、あなたが最高の生涯を探していて、新鮮になっているのなら、それはおそらくあなたが使うべきものです。しかし、私の意見はglBegin/glEndであり、表示リストはバージョン3では廃止予定ですが、しばらくの間使用されていますので、使用したい場合はあまりにも心配しません。私は代わりの方法のためにピッキングのGL_SELECTモードを避けるだろう。多くのハードウェアベンダーは、バージョン3で非推奨になっていますが、GL_SELECTは数年前から廃止されていると考えています。アプリケーションでは、ATIカードや統合GMAカードでは動作しません。その後、問題を解決するように思われるオクルージョンクエリを使用してピッキングメソッドを実装しました。だから最初に正しく行うには、GL_SELECTを避けてください。

Good Luck。

Answer 2

ドライバに関しては、ソフトウェアで書かれた機能が不足していることがあります。 OpenGLを使用する全面的なポイント（アクセラレーションを除いて）は、APIへの書き込みであり、実装方法は気にしません。

私の経験では、OpenGLのバージョンを宣言していません。 APIバージョン間の関数呼び出しはオーバーラップしません。仕様に注意してください。たとえば、2.0メソッドを呼び出すと、アプリケーションの最小バージョンは2.0になりました。私は、OpenGL（愚かな古いSunのビデオカード）をターゲットにしたディスプレイアプリケーションを持っています。これは、新しいnvidia 200シリーズカードでうまくいきます。

今後、APIが変更されないことを保証するものはありません。特にあなたがそれを制御しなければ。 OpenGL 6.4を使用している場合、アプリケーションは10年後に動作を停止する可能性があります。うまくいけば、あなたはアップグレードのために顧客が支払うことができる充分なアプリケーションを書いていることを望みます。

Answer 3

MarK J. Kilgardは、90年代からOpenGLに関するnVidiaのソースコードとドキュメントを公開しており、ゲームハードウェアの2大名の1つに代わってこれを行っています。

// -------------------------------------------- ----------------------------------------- ...という概念OpenGLアプリケーションが「間違っている」というのは即時モードを使用するには過度です。 OpenGL 3.0の仕様は、OpenGLで「廃止予定」のために即時モードをマークするまでさえ進んでいます（それは何でも意味します）。このような過激主義は反生産的で愚かなことです。適切なAPIの使用を推奨する適切な方法は、APIの使用を非難または禁止することではなく、特定の状況で適切なAPIの使用方法を開発者に教えることです。