グラフィックスを多用するアプリケーションがあり、AMD 64ビットデュアルコアプラットフォームで問題が発生しているようですが、Intelプラットフォームでは明らかではありません。
アプリケーションを実行すると、特にシャドウとライティング（Open GL）にコードを使用する場合に、CPUが100％で実行されます。
これを引き起こす可能性のあるAMDプロセッサの特定の問題、または問題を追跡する場所、および/またはこれらの問題を回避するためにコードベースを最適化する方法を知っている人はいますか？
アプリケーションは通常、ミッドレンジのハードウェアで正常に動作します。私の開発マシンにはnvidia gtx260カードが搭載されているため、電力不足は問題になりません。
AMD64 はNUMAアーキテクチャであることに注意してください。マルチプロセッサ ボックスを使用している場合、ハイパートランスポート バスを介して大量のメモリ アクセスを実行している可能性があり、ローカル メモリよりも遅くなり、動作が説明される場合があります。
これは単一ソケットのコア間では当てはまらないため、マルチソケット マシンを使用していない場合は無視してかまいません。
Linux は NUMA に対応しています (つまり、ローカル バンクごとにメモリを割り当て、プロセスを特定の CPU にバインドするシステム サービスがあります)。Win 2k3 サーバー、2k8、および Vista は NUMA に対応していると思いますが、XP は対応していません。Solaris などの独自仕様の UNIX バリアントのほとんどは、NUMA もサポートしています。
影やその他のグラフィックス コードをどのように処理したかによっては、「高速パスから外れて」、グラフィックス ドライバーがソフトウェア エミュレーションを開始した可能性があります。これは、複雑なパイプラインがある場合、またはシェーダー コードで使用する条件が多すぎる (または命令が多すぎる) 場合に発生する可能性があります。
この特定のグラフィックス カードが、使用しているすべての機能をサポートしていることを確認します。
ここで遅い答え。
これが関連しているかどうかはわかりませんが、一部の win32 OpenGL ドライバーでは、vsync の待機中に SwapBuffers() が CPU を解放しないため、100% の CPU 使用率を非常に簡単に得ることができます。
私がこれに使用する解決策は、最後の SwapBuffers() が完了してからの時間を測定することです。これにより、次の vsync がどれだけ離れているかがわかります。そのため、SwapBuffers() を呼び出す前に、vsync が差し迫っていることを検出するまで、短い Sleep() を実行します。このように、SwapBuffers() は vsync を長く待つ必要がないため、CPU を過度に占有することはありません。
これが確実に機能するには、十分な Sleep() 精度を得るために timeBeginPeriod() を使用する必要がある場合があることに注意してください。
問題の実際の原因を突き止めるために、プロファイリングソフトウェアに投資します。
Linuxでは、Valgrind（CachegrindとCallgrindを含む）+ KCacheGrindは、すべての重い関数呼び出しが行われている場所を特定できます。
また、完全なデバッグシンボルを使用してコンパイルすると、遅い関数呼び出しでアセンブルコードを表示することもできます。
インテル固有のコンパイラーを使用している場合、これは問題の一部である可能性があり（定義されていない）、GCCファミリーを試してください。
また、まだ行っていない場合は、OpenMPとスレッドに飛び込むことをお勧めします。
うーん-シャドウを使用する場合、GPUに負荷がかかるはずなので、CPUがグラフィックデータを送信するよりもGPUがフレームを高速にレンダリングする可能性はほとんどありません。この場合、100％の負荷は問題なく、予想されます。
それは単にどこかのスピンロックでCPUサイクルを燃やす、壊れたOpenGLドライバーである可能性があります。正確に何が起こっているのかを知るために、AMDのCode Analystなどのプロファイリングツールを実行することをお勧めします（前回使用したときは無料です）。
プログラムのプロファイルを数分作成し、時間が費やされている場所を確認します。アプリケーションではなくopenglドライバーに大きなピークが見られる場合は、新しいドライバーを入手してください。そうでなければ、少なくとも何が起こっているのかがわかります。
ところで-推測させてください、あなたはATIカードを使用していますよね？私はそこにいるATIファンを怒らせたくありませんが、彼らのOpenGLドライブは正確には素晴らしいものではありません。運が悪ければ、カードがサポートしていない機能や、シリコンのバグが原因で無効になっている機能を使用することもできます。この場合、ドライバーはソフトウェアラスタライズモードにフォールバックします。これにより、処理速度が大幅に低下し、プログラムがシングルスレッドの場合でも100％のCPU負荷が発生します。
また、キャッシュは共有されないため、複数のスレッド間でデータを共有するときにパフォーマンスが低下する可能性があります。