我们有一个图形密集型应用程序，似乎在英特尔平台上看不到的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（）精度，以使其可靠地工作。
根据你已经完成阴影和其他图形代码的方式，有可能你“脱离了快速路径”，并且图形驱动程序已经开始进行软件仿真。如果你有复杂的流水线，或者在着色器代码中使用了太多的条件（或者太多指令），就会发生这种情况。
我会确保这个特殊的图形卡支持你使用的所有功能。