我们有一个图形密集型应用程序，在AMD 64位双核平台上似乎遇到了问题，而在Intel平台上却不明显。

运行该应用程序会使CPU以100％的速度运行，尤其是在使用阴影和照明代码(Open GL)时。

是否有人知道可能导致此问题的AMD处理器的特定问题，或者知道从何处查找问题和/或者优化代码库以避免这些问题的方法？

请注意，该应用程序通常在中端硬件上运行良好，我的开发机中装有nvidia gtx260卡，因此电源不足应该不是问题

解决方案

我将投资配置文件软件以查找问题的实际原因。

在linux上，Valgrind(包含Cachegrind和Callgrind)+ KCacheGrind可以确定所有繁重的函数调用正在进行的位置。

同样，使用完整的调试符号进行编译，它甚至可以在缓慢的函数调用中显示汇编代码。

如果我们使用的是Intel特定的编译器，则可能是问题的一部分(不确定)，请尝试使用GCC家族。

另外，如果我们还没有的话，可能想深入了解OpenMP和线程。

嗯，如果使用阴影，GPU应该处于负载状态，因此GPU渲染帧的速度不可能比CPU发送图形数据的速度快。在这种情况下，100％的负载就可以了，甚至可以预期。

它可能只是一个乏味的OpenGL驱动程序，确实会在某个地方的自旋锁中燃烧CPU周期。为了弄清楚到底发生了什么，我建议我们运行一个分析工具，例如AMD的Code Analyst(我上次使用它是免费的)。

几分钟分析程序，看看时间花在哪里。如果我们在opengl驱动程序中看到一个很大的高峰，而在应用程序中却没有，请获取一个新的驱动程序。否则，我们至少会知道发生了什么。

顺便说一句，我猜，我们使用的是ATI卡，对吗？我不想冒犯任何ATI风扇，但是他们的OpenGL驱动器并不完全出色。如果我们不走运，我们甚至可以使用该卡不支持的功能或者由于硅错误而被禁用的功能。在这种情况下，驱动程序将退回到软件光栅化模式。即使程序是单线程的，这也会大大降低速度，并为我们提供100％的CPU负载。

请注意，如果我们使用的是多处理器盒，则AMD64是NUMA架构，我们可能正在超传输总线上运行大量内存访问，这将比本地内存慢，并且可以解释其行为。

单个插槽上的内核之间不是这种情况，因此如果我们不使用多插槽计算机，则可以忽略它。

Linux支持NUMA(即它具有系统服务，可以通过本地存储区分配内存并将进程绑定到特定的CPU)。我相信Win 2k3服务器，2k8和Vista可以识别NUMA，而XP则不可以。大多数专有的unix变体(例如Solaris)也具有NUMA支持。

另外，不共享缓存，这可能会导致在多个线程之间共享数据时性能下降。

迟到的答案在这里。

Dunno(如果与此相关)，但是在某些win32 OpenGL驱动程序中，SwapBuffers()在等待vsync时不会产生CPU，这使得获得100％CPU使用率非常容易。

我使用的解决方案是测量自上一次SwapBuffers()完成以来的时间，这告诉我下一个vsync有多远。因此，在调用SwapBuffers()之前，我会先进行短暂的Sleep()操作，直到检测到即将发生vsync。这样，SwapBuffers()不必等待很长的时间就可以进行vsync，因此也不会使CPU占用过多时间。

请注意，我们可能必须使用timeBeginPeriod()获得足够的Sleep()精度才能可靠地工作。

根据我们完成阴影和其他图形代码的方式，可能我们"掉进了快速通道"，并且图形驱动程序已开始进行软件仿真。如果我们具有复杂的管道，或者在着色器代码中使用了太多的条件(或者只是太多的指令)，则可能会发生这种情况。

我将确保该特定的图形卡支持我们正在使用的所有功能。