64-битная двухъядерная оптимизация AMD

Question

У нас есть приложение, интенсивно использующее графику, которое, похоже, испытывает проблемы на 64-битных двухъядерных платформах AMD, которые не видны на платформах Intel.

При запуске приложения процессор загружается на 100%, особенно при использовании кода для теней и освещения (Open GL).

Кто-нибудь знает о конкретных проблемах с процессорами AMD, которые могут это вызвать, или знает, где можно найти проблему и / или способы оптимизации базы кода, чтобы избежать этих проблем?

обратите внимание, что приложение обычно хорошо работает на оборудовании среднего уровня, на моем компьютере разработчика установлена ​​карта nvidia gtx260, поэтому проблема с питанием не должна быть проблемой

Answer 1

Обратите внимание, что AMD64 представляет собой архитектуру NUMA - если вы используете многопроцессорную коробку, вы можете получить много обращений к памяти через шину гипертранспорта, которая будет медленнее, чем локальная память, и может поведение.

Это не будет иметь место между ядрами в одном сокете, поэтому не стесняйтесь игнорировать это, если вы не используете машину с несколькими сокетами.

Linux поддерживает NUMA (т. Е. Имеет системные службы для выделения памяти местным банком и привязки процессов к конкретным процессорам). Я считаю, что сервер Win 2k3, 2k8 и Vista поддерживают NUMA, а XP - нет. Большинство проприетарных вариантов Unix, таких как Solaris, также поддерживают NUMA.

Answer 2

В зависимости от того, как вы работали с тенями и другим графическим кодом, возможно, что вы «упали с быстрого пути», и графический драйвер начал выполнять программную эмуляцию. Это может произойти, если у вас сложные конвейеры или вы используете слишком много условных выражений (или просто слишком много инструкций) в шейдерном коде.

Я хотел бы убедиться, что эта конкретная видеокарта поддерживает все функции, которые вы используете.

Answer 3

Поздний ответ здесь.

Не знаю, если это связано, но в некоторых драйверах Win32 OpenGL SwapBuffers () не будет отдавать ЦП во время ожидания vsync, что позволяет очень легко получить 100% загрузку ЦП.

Решение, которое я использую для этого, состоит в том, чтобы измерить время с момента завершения последнего SwapBuffers (), что говорит мне, как далеко находится следующий vsync. Поэтому перед вызовом SwapBuffers () я беру короткие Sleep (), пока не обнаружу, что vsync неизбежен. Таким образом, SwapBuffers () не нужно долго ждать vsync, и поэтому не слишком сильно нагружает процессор.

Обратите внимание, что вам, возможно, придется использовать timeBeginPeriod (), чтобы получить достаточную точность Sleep () для надежной работы.

Answer 4

Кроме того, кэш не используется совместно, что может привести к снижению производительности при совместном использовании данных несколькими потоками.

Answer 5

Хм - если вы используете тени, то графический процессор должен быть загружен, поэтому маловероятно, что графический процессор визуализирует кадры быстрее, чем центральный процессор отправляет графические данные. В этом случае 100% нагрузки в порядке и даже ожидаемо.

Это может быть просто драйвер OpenGL, который выполняет циклы ЦП в спин-блокировке где-нибудь. Чтобы узнать, что именно происходит, я предлагаю вам запустить инструмент профилирования, такой как Code Analyst от AMD (бесплатно, когда я в последний раз использовал его).

Профилируй свою программу пару минут и посмотри, на что тратится время. Если вы видите большой пик в драйверах opengl, а не в вашем приложении, получите новый драйвер. В противном случае вы хотя бы получите представление о том, что происходит.

Кстати, позвольте мне догадаться, вы используете карту ATI, верно? Я не хочу обижать поклонников ATI, но их OpenGL-диски не совсем звездные. Если вам не повезло, вы можете даже использовать функцию, которую карта не поддерживает или которая отключена из-за силиконовой ошибки. В этом случае драйвер перейдет в режим растеризации программного обеспечения. Это сильно замедлит работу и обеспечит 100% загрузку ЦП, даже если ваша программа однопоточная.

Answer 6

Я бы инвестировал в профилирование программного обеспечения, чтобы выяснить истинную причину проблемы.

В Linux Valgrind (который содержит Cachegrind и Callgrind) + KCacheGrind может определить, где происходят все тяжелые вызовы функций.

Кроме того, компилируйте с полными символами отладки, и он может даже показать код ассемблера при медленных вызовах функций.

Если вы используете специальный компилятор Intel, это может быть частью вашей проблемы (не обязательно), и попробуйте семейство GCC.

Кроме того, вы можете погрузиться в OpenMP и Threads, если вы еще этого не сделали.