5

さて、これは非常に奇妙な振る舞いです。

TL; DR-テクスチャへのレンダリング設定で、ウィンドウ（フレームバッファ0）のサイズを変更すると、バインドされたフレームバッファ0（ウィンドウのクライアント領域）に対するglClear（GL_COLOR_BUFFER_BIT）の次の呼び出しのみが、2つのうちの1つでのみGL_OUT_OF_MEMORYを生成します。ただし、GPUは、レンダリングが適切かつ正しく進行します。

さて、すべてのザラザラした詳細：

したがって、これは2つのGPUを備えたVaio Z上にあります（マシンの物理的なトグルボタンで切り替えることができます）：

  1. OpenGL 4.2.0 @ NVIDIA Corporation GeForce GT 640M LE / PCIe / SSE2（GLSL：4.20 NVIDIA、Cgコンパイラ経由）

  2. OpenGL4.0.0-ビルド9.17.10.2867@Intel Intel（R）HD Graphics 4000（GLSL：4.00-ビルド9.17.10.2867）

私のプログラムは、GLFW64ビットを使用するWin764ビットの下でGo1.0.364ビットになっています。

私はかなりシンプルでわかりやすいテクスチャへのレンダリング「ミニパイプライン」を持っています。まず、通常の3Dジオメトリは、最も単純なシェーダー（照明なし、何もない、キューブとプレーンの数であるテクスチャ付き三角形メッシュのみ）を使用して、深度/ステンシルアタッチメントとしての深度/ステンシルレンダーバッファーとカラーアタッチメントとしてのtexture2D。テクスチャの場合、ミップマップと同様にすべてのフィルタリングが無効になります。

次に、texelFetch（tex、gl_FragCoord.xy、0）を使用してフレームバッファテクスチャ（カラーアタッチメント）からサンプリングするだけで、フルスクリーンクワッド（実際には単一の「特大」フルスクリーントライ）をレンダリングするため、ラッピングは使用されません。

コアプロファイルを強制する場合と強制しない場合の両方で、両方のGPUがこれを適切にレンダリングします。これについてGLエラーが報告されることはなく、すべてが期待どおりにレンダリングされます。Intel HD 4000GPUのGL4.0レンダラー（コアプロファイルとコンププロファイルの両方）を使用しているときにウィンドウのサイズを変更した場合を除きます。その場合にのみ、1回のサイズ変更でフレームバッファ0（画面）での次のglClear（GL_COLOR_BUFFER_BIT）呼び出しの直後にGL_OUT_OF_MEMORYエラーが記録されますが、サイズ変更後は1回だけであり、後続のループの反復ごとではありません。

興味深いことに、私は実際にはサイズ変更の割り当てさえしていません！ウィンドウのサイズ変更で発生するすべてのロジックを一時的に無効にしました。つまり、現在、ウィンドウのサイズ変更イベントを完全に無視しています。つまり、RTTフレームバッファーとその深度およびカラーアタッチメントの解像度は変更/再作成されていません。つまり、次のglViewPortは、ウィンドウとGLコンテキストが最初に作成されたときと同じディメンションを使用しますが、エラーはglClear（）で発生します（前ではなく、後のみ、一度だけ-ダブルチェックとトリプルチェックを行いました） ）。

これはドライバーのバグでしょうか、それともここで間違っている可能性があることはありますか？

4

1 に答える 1

2

HDのGLドライバーの興味深い不具合は、次のように思われます。

テクスチャへのレンダリングの設定に切り替えたとき、プライマリフレームバッファ0（つまり、画面/ウィンドウ）のGLコンテキスト作成時の深度/ステンシルビットも両方とも0に設定しました。これは、このエラーが表示され始めたときです。フレームレートは以前に比べてかなり遅くなりました。

私は実験的に（厳密に言えば不要な）深度ビットを8に設定しましたが、これらの問題は両方ともなくなりました。したがって、現在のHD 4000 GL 4.0ドライバーバージョンは、GLコンテキスト作成時の深度バッファービットの値0を好まないようです。

于 2013-02-04T18:27:48.710 に答える