AMD 64 位双核优化

Posted 2023-02-16

【中文标题】AMD 64 位双核优化

【英文标题】：AMD 64 bit Dual Core Optimization

【发布时间】：2008-09-19 10:24:23

【问题描述】：

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

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

是否有人知道 AMD 处理器可能导致此问题的具体问题，或知道在哪里追查问题，和/或优化代码库以避免这些问题的方法？

请注意，该应用程序通常在中档硬件上运行良好，我的开发机器有一个 nvidia gtx260 卡，所以电源不足应该不是问题

【参考方案1】：

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

单个插槽上的内核之间不会出现这种情况，因此如果您不使用多插槽机器，请随意忽略这一点。

Linux 支持 NUMA（即它具有系统服务来按本地银行分配内存并将进程绑定到特定 CPU）。我相信 Win 2k3 服务器、2k8 和 Vista 支持 NUMA，但 XP 不支持。大多数专有的 unix 变体（例如 Solaris）也支持 NUMA。

【参考方案2】：

这里迟到的答案。

不知道这是否相关，但在某些 win32 OpenGL 驱动程序中，SwapBuffers() 在等待 vsync 时不会产生 CPU，因此很容易获得 100% 的 CPU 利用率。

我使用的解决方案是测量自上次 SwapBuffers() 完成以来的时间，它告诉我下一个 vsync 有多远。因此，在调用 SwapBuffers() 之前，我会使用短暂的 Sleep()，直到我检测到 vsync 迫在眉睫。这样一来，SwapBuffers() 就不必为 vsync 等待很长时间，因此不会过多地占用 CPU。

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

【参考方案3】：

根据您处理阴影和其他图形代码的方式，您可能已经“掉队”并且图形驱动程序已经开始进行软件仿真。如果您有复杂的管道，或者在着色器代码中使用太多条件（或太多指令），则可能会发生这种情况。

我会确保这个特定的显卡支持您正在使用的所有功能。

【参考方案4】：

我会投资分析软件来追踪问题的实际原因。

在 linux 上，Valgrind（包含 Cachegrind 和 Callgrind）+ KCacheGrind 可以确定所有繁重的函数调用在哪里进行。

此外，使用完整的调试符号进行编译，它甚至可以在慢速函数调用时显示汇编代码。

如果您使用的是英特尔专用编译器，这可能是您的问题的一部分（不是明确的），请尝试使用 GCC 系列。

此外，如果您还没有深入了解 OpenMP 和 Threads，您可能还想了解一下。

【参考方案5】：

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

它可能只是一个无聊的 OpenGL 驱动程序，它确实在某处的自旋锁中消耗 CPU 周期。要了解到底发生了什么，我建议您运行分析工具，例如 AMD 的 Code Analyst（我上次使用时免费）。

花几分钟时间分析你的程序，看看时间花在了哪里。如果您在 opengl 驱动程序中看到一个高峰，而不是在您的应用程序中，请获取一个新驱动程序。否则你至少知道发生了什么。

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

【参考方案6】：

而且缓存是不共享的，这可能会导致在多个线程之间共享数据时性能不足。