1

現在、Sandybridge グラフィックス チップを搭載した 2011 13 インチ MacBook Pro で OpenGL レンダラーを作成しています。

OpenGL コードを開発しているときに、多くのカーネル パニックと再起動が発生していることに気付きました。エラーが発生すると、システムが再起動するだけで、エラーをキャッチしてエラー コードを取得する機会が与えられないことがよくあります。

再起動時に表示される結果の問題報告アプリがクラッシュしたエンティティとしてそれを識別するため、それがグラフィックスドライバーに関連していることを私は知っています.

特定の問題は、テクスチャの作成に密接に関連しているようです。明らかに私のコードにはいくつかのバグがありますが、OpenGL のような高レベル API で OS を再起動するべきではありません。

OS X には、ロシアン ルーレットのデバッグを使用するのではなく、エラーを早期にキャッチできるように、D3D と同様に有効にできるデバッグ モード機能がありますか?

(私は OpenGL プロファイラー、ドライバー モニターなどを認識していますが、これらのツールを使用してこの種の問題を検出することにほとんど成功していません)

4

3 に答える 3

1

他の人は、潜在的な回避策について回答しています。ただし、アプリケーションがマシンをパニックに陥らせてはならないことに注意してください (最近では、単にマシンを再起動し、Apple にレポートを送信するためのダイアログを表示するだけです)。

少なくとも、レポートを Apple に送信する必要があります。さらに、 http://bugreport.apple.comでバグ レポートを提出する必要があります。これには、パニック ログ、システム プロファイラー レポート、再現方法に関する詳細情報 (理想的には、サンプル アプリのバイナリやソース コード) が含まれます。 ）。独自のバグ レポートを提出することは、多くの点で役立ちます。バグに優先順位を付ける (dupes バンプの優先度)、問題と修正がパニック レポートのバックトレースから明らかでない場合の再現手順を提供する、あなたと Apple の間のチャネルを開くそれを追跡するためにあなたからのより多くの情報が必要な場合に備えて。

于 2013-04-22T02:02:44.613 に答える
1

見ている人のためにこれに戻るだけです...問題は、さまざまなスレッドがOpenGLコマンドの発行を開始したときに現在のコンテキストを設定できなかったことに完全に関連していたことが判明しました。

そのため、各スレッドはミューテックスをロックし、開いている gl コンテキストを設定してから、作業を開始する必要がありました。次に、コンテキストを解放してからロックを解放し、1 つの OpenGL コンテキストへの非同時アクセスを保証します。

したがって、ここで深く知られていない動作は実際にはありません。経験の浅い初心者がガイドラインを完全に実装していないだけです。:-)

于 2012-12-19T14:42:32.353 に答える
1

あなたが言及したように、OpenGL Profiler は使用するツールです。少なくとも、「VAR エラーでブレーク」および「スレッド エラーでブレーク」とマークされたボックスをチェックする必要があります。問題がある場合はお知らせください。お手伝いできる場合があります。（私は専門家ではありませんが、運が良かったです。）

さらに、表示されているクラッシュはおそらく、OpenGL へのポインターを指定し、そのポインターからメモリを読み書きしようとしているが、ポインターが正しくない (またはデータの長さが間違っている) ことに関連している可能性があります。テクスチャ関連の場合は、テクスチャをアップロードまたはダウンロードしようとして間違った幅と高さを渡しているか、フォーマットが間違っている可能性があります。glDrawElements() に間違った数の要素を渡すと、これが発生するのを見てきました。「要素」が頂点なのか、それとも実際のオブジェクト (QUAD や TRIANGLE など) なのか混乱しました。VAR エラー報告は、その問題を見つけるのに役立ちました。

于 2012-10-31T04:52:30.393 に答える