私は毎秒30フレームで動作する安全性の高いアプリケーションを開発します。 30fpsを提供できない場合やその他のエラーが発生した場合は、代わりに黒い画面が表示されます。glGetErrorはスレッドをブロックできますか？
可能な限り頻繁にglGetError呼び出しでエラーフラグを照会したいのですが、長い時間（数ミリ秒間）描画スレッドをブロックすることができますか？
最新のopenglコマンドが処理されなくなるまで、glGetError呼び出しがスレッドをブロックできますか？
いいえの場合、最新のOpenGLコマンドの実行中にエラーが発生したかどうかを知るにはどうすればよいですか？
技術パラメーター： - Linuxの2.6.20-1.21 - のNvidiaのQuadro NVS 285 - libGL.so.100.14.19
GL仕様保証ではNothing のブロッキングに関するもの（または性能特性のためにその問題）。
私が見たほとんどの実装のglGetErrorは、実際にはGPUハードウェアとのやりとりなしで動作します。ドライバ側のAPI部分だけです。要するに、ブロックするべきではありません（注意：実装の詳細）。
GLエラーが生成され、GPUでチェックされるべき様々な場所では、仕様はエラー生成とは対照的に、特にこの問題がないと定義されていません。
最後に、glxSwapBufferは、GPUが以前のフレームを描画するのにまだ忙しいため、ブロッキングが発生する可能性が高い場所になる可能性が高くなります（CPUがあまり先に進まないように、 。
実際、glGetError（）は別のスレッドで動作しています。しかし、それはエラーをクリアしていない、それは問題だったので。実際、実装に依存します。 –
glGetErrorが現在のコンテキストを持たずに呼び出すとき、つまりglGetError自体がGL_INVALID_OPERATIONを返したときにエラーがクリアされないことがわかったのは唯一のときです。 – Robinson
アプリケーションが正しく動作するように（OpenGLの正しさの観点から）設計した場合は、GLエラーをチェックする必要はありません（ユーザが入力したGLコマンドを実行しない限り）。アプリケーションをデバッグステージでストレステストして、可能なすべてのGLエラーをチェックし、次にプロダクションステージでこれらのチェックを省略します。 GLエラーが発生した場合、おそらくハードウェアの故障を意味します。 – mbaitoff
ありがとうございます。しかし、仕様は100％明確ではないので、glGetErrorコマンドの動作にはまだ興味があります。 – Vereb
私は、glGetErrorが費やす正確な（または保証された、あるいは少なくとも平均的な）時間を提供する仕様はないと考えています。この関数は、明らかにドライバの勇気の内側に潜んでおり、内部フラグを照会します。 OpenGLのコンテキストはスレッドごとに1つであるため、スレッドごとのフラグセットがあります。 glGetErrorタイミングの最小可能な見積もりとして、ring3-> ring0とバックスイッチの時間コストを考慮する必要があります。 – mbaitoff