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

Question

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

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

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

примечание, приложение обычно хорошо работает на середину аппаратного диапазона, мой DEV машина имеет NVidia GTX260 карту в, поэтому отсутствие власти не должно быть проблемой

Answer 1

Я бы инвестировать в профилировании программного обеспечения для отслеживания вниз фактическая причина проблемы.

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

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

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

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

Answer 2

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

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

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

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

Answer 3

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

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

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

Answer 4

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

Answer 5

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

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

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

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

Answer 6

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

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