我們有一個圖形密集型應用程序，似乎在英特爾平臺上看不到的AMD 64位雙核平臺上遇到問題。AMD 64位雙核優化
運行應用程序會導致CPU以100％運行，特別是在使用代碼進行陰影和照明（Open GL）時。
有沒有人知道AMD處理器的具體問題，可能會導致這種情況，或知道在哪裏尋找問題，和/或優化代碼庫以避免這些問題？
筆記，應用程序通常會正常工作在多種硬件中旬，我開發的機器在一個NVIDIA GTX260卡，所以缺乏權力不應該是一個問題
我會投資剖析軟件追查下來問題的實際原因。
在Linux上，Valgrind（其中包含Cachegrind & Callgrind）+ KCacheGrind可以確定所有重函數調用的進行方向。
此外，使用完整的調試符號進行編譯，它甚至可以在慢速函數調用中顯示彙編代碼。
如果您使用的是Intel特定的編譯器，這可能是您的問題的一部分（而不是定義壽命），並嘗試GCC系列。
此外，如果您尚未使用OpenMP和線程，則可能需要進行深入研究。
嗯 - 如果使用陰影，GPU應該處於加載狀態，所以GPU渲染幀的速度不可能比CPU發送圖形數據的速度快。在這種情況下，100％的負載是可以的，甚至是預期的。
它可能只是一個borked OpenGL驅動程序，它會在某處自旋鎖中燒燬CPU週期。爲了找出究竟發生了什麼，我建議你運行一個分析工具，例如AMD的代碼分析器（上次免費使用它）。
簡介您的程序幾分鐘，看看時間花在哪裏。如果你在opengl驅動程序中看到一個大的峯值，而不是在你的應用程序中得到一個新的驅動程序。否則，你至少會明白髮生了什麼。
順便說一句 - 讓我猜，你正在使用ATI卡，對吧？我不想冒犯任何ATI粉絲，但他們的OpenGL驅動器並不是非常出色。如果你不走運，你甚至可能會使用該卡不支持或由於硅錯誤而被禁用的功能。在這種情況下，驅動程序將回退到軟件光柵化模式。這會減慢很多事情，即使程序是單線程的，也會給你100％的CPU負載。
請注意，AMD64是一個NUMA體系結構 - 如果您使用的是多處理器盒，您可能在整個hypertransport總線上運行大量內存訪問，這會比本地內存慢，並可能解釋這種行爲。
在單個插槽上的內核之間不會出現這種情況，所以如果您不使用多插槽機器，請隨時忽略此情況。
Linux是NUMA感知的（即它有系統服務來分配本地銀行內存並將進程綁定到特定的CPU）。我相信Win 2k3服務器，2k8和Vista都支持NUMA，但XP不支持。大多數專有的unix變體（如Solaris）也支持NUMA。
此外緩存不共享，這可能會導致在多個線程之間共享數據時性能不足。
遲到的答案在這裏。
不知道如果這是相關的，但在某些win32 OpenGL驅動程序中，SwapBuffers（）在等待vsync時不會產生CPU，因此非常容易獲得100％的CPU利用率。
我使用的解決方案是測量自上次SwapBuffers（）完成以來的時間，它告訴我下一個vsync有多遠。所以在調用SwapBuffers（）之前，我會使用較短的Sleep（），直到檢測到vsync即將發生。這樣SwapBuffers（）不需要長時間等待vsync，所以不會太糟糕。
請注意，您可能必須使用timeBeginPeriod（）以獲得足夠的Sleep（）精度，以使其可靠地工作。
根據你已經完成陰影和其他圖形代碼的方式，有可能你「脫離了快速路徑」，並且圖形驅動程序已經開始進行軟件仿真。如果你有複雜的流水線，或者在着色器代碼中使用了太多的條件（或者太多指令），就會發生這種情況。
我會確保這個特殊的圖形卡支持你使用的所有功能。