同時に作成できるOpenGLレンダリングコンテキストの数には制限がありますか？

Question

私のメインウィンドウに3つのOpenGLレンダリングコンテキストを作成し、各ウィンドウに2つのレンダリングコンテキストがある別のウィンドウをポップアップすることができます（スプリッタを使用）。 26回目のレンダリングの前後で、物事は本当に遅くなり始める。フレームをレンダリングするのに数ミリ秒かかるのではなく、新しいレンダリングコンテキストは5〜10秒かかります。それはまだ動作します、本当に遅い！ OpenGLはエラーを返さない（glGetError）。

他のウィンドウは正常に動作します。特定の数のスローダウン後の新しいレンダリングコンテキスト。私がそれらのウィンドウを閉じると、すべてがうまくいきます - 私は限界を通過するのに十分なウィンドウを開くまで。各レンダリングコンテキストには独自のスレッドがあり、それぞれが単純なシェーダを使用します。スローダウンは、テクスチャをアップロードするときに発生します。しかし、テクスチャのサイズは、作成できるコンテキストの数やOpenGLウィンドウのサイズには影響しません。

私はnVidiaカードで動作していますが、これは異なる量のメモリとさまざまなドライババージョンで、異なるGPUで表示されます。どうしたんだ？アプリケーションが作成できるレンダリングコンテキストの数には、いくつかの制限がありますか？

他の誰かが同時にレンダリングコンテキストのLOTSを持つアプリケーションを持っていますか？

Answer 1

この質問に対する真の答えがないのが最善の策です。おそらくOSのハードウェア、ハードウェアの内部制限に依存するでしょう。あなたがチェックしようと思うかもしれない何かは、glGet(GL_MAX_TEXTURE_UNITS)を使用して利用可能なテクスチャユニットの数ですが、それは指標であるかもしれません。

これを回避する一般的な解決策は、1つのウィンドウ内の複数のコンテキストではなく、単一のコンテキスト内に複数のビューポートを作成することです。 2つのビューポートと1つの種類のUIウィジェットを持つ単一のコンテキストにウィンドウを共有する2つのコンテキストをスプリッタとして機能させるのは難しいことではありません。複数のウィンドウは異なるストーリーです。実際に26個の別々のOpenGLウィンドウが必要な場合は、UIデザインを完全に再考することを検討してください。
実際には同時に26種類のOpenGLウィンドウを必要とする実際のUIの使用例を考えるのは難しいです。多分、別の選択肢として、5-10文脈のプールを作成し、それらが現在ユーザに見えるウィンドウ（タブ？）でのみ再利用することがあります。私はそれを試していないが、他の何も含まれていないプレーンウィンドウ内のコンテキストを作成し、親ウィンドウから親ウィンドウに必要なトップレベルのウィンドウにそのウィンドウを移動することが可能でなければなりません。

EDIT -
実際、それを考えるのは難しいことではありません。 WebGLをサポートしている最新のChrome（9.x.x）は、それぞれWebGLコンテキストで複数のタブを開くことができます。ちょうど試してみて、13個のタブの後にメモリがなくなってしまった...それは実際にあなたが間違っていることがあるかどうか、あるいはchromeとfirefox（4.0.x-beta）問題

Answer 2

OpenGLドライバの多様性を考えると、メジャーなドライバ（AMD/Intel/NVIDIA/MSソフトウェアレンダリング）の動作を確認し、最初の起動時にテストを実行することをお勧めします。例えば。あなたが見たようにNVIDIAが常に減速するのを見ることができたら、そのマシン（またはカード）の制限がどこにあるかを見るまで、ただちにループを実行してください。あまり楽しいことではありませんが、それ以外の場合は確実に制限を確実に押し込むことはかなり難しいと思います。

つまり、「ベストベット」は以前の回答と同じです。事前に知ることはできません。

Answer 3

Nathan Kiddが正しく言っているように、制限は実装固有であり、できることは共通のハードウェアでいくつかのテストを実行することです。

今日の学会で退屈していたので、OpenGLコンテキストを作成してレンダリングを試みるコードをまとめました。私はテクスチャの有無にかかわらず、フォワード互換のOpenGLコンテキストの有無にかかわらずレンダリングを試みました。

GeForceカードでは限界がかなり高いことが判明しました。デスクトップQuadroでは、正しく再塗りつぶしできたコンテキストは128個でしたが、プログラムはエラーなしで128個のコンテキストを作成できましたが、ウィンドウにはゴミが含まれていました。

ATi Radeon 6950では、ウィンドウ105で再描画が中止され、描画コンテキスト＃200の作成が失敗しました。

あなた自身で試してみたい方は、Max OpenGL Contexts test（完全なソースコード+ win32バイナリがあります）のプログラムをご覧ください。

これが結果です。 1つのアドバイス - 可能な場合は複数のコンテキストを使用しないでください。マルチコンテキストで動作するアプリケーションでは複数のコンテキストを理解できますが、1つのモニタ上のアプリケーションは単一のコンテキストに依存する必要があります。コンテキストの切り替えが遅い。それだけではありません。 OpenGLウィンドウと他のウィンドウが重なっているアプリケーションでは、ハードウェアクリッピング領域が必要です。 GeForceにはハードウェアクリッピング領域が1つ、Quadroには8つ以上の領域があります（CADアプリケーションでは、ゲームとは対照的に、OpenGLウィンドウと重なるウィンドウとメニューがよく使用されます）。より多くの領域が必要な場合は、レンダリングがソフトウェアに戻ってしまうので、OpenGLのウィンドウ（コンテキスト）がたくさんあることはあまり良い考えではありません。

Answer 4

OpenGLをover-the-topのマルチスレッドの方法で設定するのがずっと面倒なことがあれば、そこから利益を得てVulkanに切り替えることもできます。設計上、OpenGLアーキテクチャは困難なコンテキスト/スレッドで分離されたすべての描画操作を単一のドライバスレッドに集約し、各コンテキストにマッピングされる仮想ハードウェアスレッドを介してこれらの呼び出しをすべて再配布します。ドライバーは本質的に大きなボトルネックになっています。これは単にこれをうまく処理するようには設計されていません。

それは、古いバージョンのGlewを使用した場合、または他の方法ですべての拡張処理を行った場合、私は興味があります。最新のglewライブラリはもはやmxをサポートしていません。切り替えるもう一つの理由。