Индивидуальная схема питания 1usmus для процессоров Ryzen 3000 Zen 2


Введение

В этой статье мы поделимся с вами индивидуальным планом электропитания для Windows, который должен оказать существенное влияние на ускоряющее поведение процессора Ryzen 3-го поколения, способность использовать предпочтительные ядра даже без пока еще не выпущенной Windows 10 19H2, что даст более высокие частоты прироста, чем даже у AGESA 1.0.0.3ABBA, и меньшие задержки при получении процессора, реагирующего на рабочие нагрузки.

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

В прошлом я писал другие статьи для TechPowerUp, связанные с архитектурой и оптимизацией памяти Ryzen. Сегодня я представляю вам «1usmus Custom Power Plan» для процессоров Ryzen 3-го поколения. Это изменение в том, как процессор и Windows общаются друг с другом о требованиях к производительности, называемых CPPC (сокращение от Collaborative Processor Performance Control), что приводит к тому, что я считаю Precision Boost, как и планировалось AMD: быстро и быстро, но с способность отличать допустимые нагрузки от фонового шума. Этот план питания должен быть особенно полезен для пользователей чипов серии Ryzen 9, таких как Ryzen 9 3900X и грядущие Ryzen 9 3950X, и процессоров Ryzen Threadripper 3-го поколения на сокете sTRX4.

Я также хотел бы поблагодарить Олега Касумова и @Kromaatikse за помощь в этих открытиях.

Техническое образование

В отличие от приложений для бенчмаркинга, которые порождают кучу одинаковых потоков, выполняющих одинаковый код на различных фрагментах данных, современные игры очень разнородны. Каждый поток выполняет свой собственный код, который полностью отличается от других потоков и работает с данными в разном количестве, генерируя нагрузки, которые различаются между потоками. Данные, создаваемые одним потоком, часто используются другим, что приводит к задержкам и может даже передавать свои данные другому ожидающему потоку. Также существует концепция «пула потоков», где каждый рабочий поток выбирает любое задание любого типа, работающее с любыми данными – независимо от того, что готово для запуска. Это означает, что поток данных совершенно хаотичен, что генерирует много трафика между CCX, если некоторые потоки находятся на одном CCX, а другие – на другом.

Это поведение дополнительно усиливается современными графическими API, такими как DirectX 12 и Vulkan, которые поощряют подачу команд рендеринга многопоточным способом. Возможно, вы заметили, как некоторые игры видят снижение производительности на Ryzen (по сравнению с Intel), когда используется более новый Vulkan или DX12 API. Windows любит балансировать загрузку ЦП между несколькими ядрами ЦП, перемещая потоки из занятых ядер в свободные. Это нормальное и ожидаемое поведение для современного планировщика процессов с поддержкой SMP, но Windows на самом деле довольно глупа.

Windows считает ядро ​​«занятым», даже если его использует только один поток, и перемещает этот же поток в свободное ядро, если оно доступно! Кроме того, планировщик процессов Windows не делает различий между физическим и виртуальным ядрами, а также между CCX с их отдельными кэшами. В сравнительно недавних версиях Windows (по крайней мере, начиная с Windows 7) эта тенденция к миграции сдерживается системой «базовой парковки». Если ядро ​​припарковано, планировщик процессов не переносит в него потоки, что позволяет ему переходить в состояние глубокого простоя для экономии энергии. Кроме того, алгоритм парковки ядра отвечает за поддержание выключения второго виртуального ядра каждого физического ядра с поддержкой HT / SMT, если это необходимо, что максимизирует производительность на поток в сценариях с легким многопоточностью.

Просто для пояснения: планировщик Windows не поддерживает SMT, только SMT поддерживает алгоритм ядра ядра. Почему это важно? Потому что в режиме высокой производительности система основной парковки отключена. Каждое отдельное ядро ​​отключено, и поэтому планировщик процессов весело мигрирует потоки через каждое физическое и виртуальное ядро ​​в системе (если все ядра не заняты, например, многопоточной рабочей нагрузкой). Это означает, что даже однопоточная рабочая нагрузка заканчивается перемещением между CCX или даже CCD, и ей приходится перетаскивать все данные, с которыми она работает, за ним, примерно в среднем каждые 40 миллисекунд. В игре умножьте это на количество эффективных потоков, которые игра запускает. Не только это, но и потоки разделяют физическое ядро ​​гораздо чаще. Linux справляется с этим гораздо лучше: она активно предпочитает хранить потоки на одном и том же ядре до тех пор, пока на этом ядре нет конфликтов планирования. Таким образом, однопоточная рабочая нагрузка в Linux обычно будет оставаться на одном и том же ядре в течение нескольких секунд, если не дольше. Это не только позволяет избежать накладных расходов при миграции потока, но также позволяет избежать пропусков кэша и трафика между CCX, который может возникнуть в результате такой миграции. Такое поведение не является специфичным для Райзена, но было стандартным на всех компьютерах SMP / SMT / CMT, работающих под управлением Linux, в течение нескольких лет.

В ближайшем будущем Microsoft выпустит обновление для Windows 10 19H2 (Windows 10 1909), которое дает планировщику ОС возможность определять приоритеты потоков. Я протестировал предварительную сборку этой версии и не заметил значительных улучшений. Довольно часто планировщик использовал более высокий приоритет для фоновых процессов. Я думаю, вы можете себе представить, что произойдет, если Windows отдает приоритет такому процессу, а не вашей текущей запущенной игре.

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

О совместном управлении производительностью питания 2 (CPPC2)

Основной проблемой является скорость, с которой процессоры «Zen 2» и операционная система говорят друг с другом о необходимой мощности процессора. Это ошеломляющая 1 мс по сравнению с 15 мс на большинстве старых процессоров. Когда у вас есть большое количество приложений с низким приоритетом, запрашивающих процессорное время, или определенные виды утилит мониторинга, пытающихся измерить статистику процессора, процессор "Zen 2" ложно воспринимает требования к производительности и воспринимает эти утилиты и программное обеспечение как нагрузку это требует пробуждения ядер и повышения частот.

С «Zen 2» AMD представила платформу UEFI CPPC2 (совместный контроль мощности и производительности UEFI). Эта возможность позволяет встроенному микропрограммному обеспечению процессора постоянно контролировать выбор тактовой частоты / напряжения. Процессор может вносить эти изменения с головокружительной скоростью один раз в 1 мс. Windows 10 не может идти в ногу с этой скоростью, так как ее стандартная «сбалансированная» схема питания сообщает процессору о требованиях к производительности только один раз каждые 15 мс. Таким образом, AMD устанавливает специальную схему питания через драйвер набора микросхем, который называется «Ryzen Balanced Power Plan». Это заставляет ОС и процессор общаться друг с другом каждые 1 мс.

Когда на компьютере среднего энтузиаста нет игры или нет, он работает с веб-браузером, приложением чата, периферийным устройством и приложением для мониторинга, которое опрашивает оборудование. Процессор может интерпретировать свою нагрузку как необходимость повышения, если процессор и ОС разговаривают друг с другом в течение 1 мс. Это дает пользователям вид процессора, который застрял в более высоком состоянии, чем в режиме ожидания.

Решением проблемы AMD является обновленный драйвер набора микросхем с обновленным профилем «Ryzen Balanced», который снижает частоту, с которой процессор получает запросы производительности от ОС, до 15 мс, когда процессор работает на холостом ходу, и увеличивает эту скорость до 1 мс при столкновении с «реальной» рабочей нагрузкой. Драйверы также изменяют поведение процессора при низких нагрузках. Любое ядро ​​без питания будет работать на 99% от номинальной тактовой частоты процессора. Это значение 99% удерживает активное ядро ​​на грани повышения, так что любая «серьезная» рабочая нагрузка может легко вызвать усиление ЦП и отправить процессор обратно на частоту опроса 1 мс.

AMD внедрила это и многое другое, используя новую версию драйвера чипсета 1.07.29, доступную для загрузки на сайте AMD.

Настройки скрытого плана питания

Несмотря на то, что вы, вероятно, знакомы с панелью управления питанием в Microsoft Windows и уже видели варианты там ранее, есть несколько дополнительных настроек, которые можно настроить с помощью плана электропитания, но которые скрыты от просмотра пользователем.

  • «Автономный режим производительности процессора» контролирует, включен ли автономный режим в системах, в которых реализован CPPC2, и определяет, выбираются ли состояния производительности операционной системой или ядра ЦП могут сами определять свое целевое состояние производительности. В системах без CPPC2 этот параметр не влияет.
  • «Окно автономной активности процессора» указывает значение для программирования в регистре автономного окна активности в системах, которые реализуют CPPC2 в автономном режиме. Более длинные значения говорят платформе, что она должна быть менее чувствительной к кратковременным скачкам / провалам при использовании процессора.
  • «Политика предпочтения энергетической эффективности процессора для класса энергопотребления процессора 1» определяет уровень детализированного смещения (от 0 до 255), который контролирует, насколько агрессивно процессор должен пытаться оптимизировать работу с низким энергопотреблением, вместо того, чтобы поддерживать производительность на уровне возможно.
  • «Политика гетерогенного краткосрочного планирования потоков» указывает, какую политику планирования потоков использовать для коротких потоков в гетерогенных системах. Отвечает за выбор способа выбора сердечников при однопоточных нагрузках (качество или маркировка).

P-государства и C-государства

Существует два механизма управления для снижения энергопотребления процессора.

  • Подсистемы отключения питания: C-States
  • Уменьшение напряжения / частоты: P-состояния

C-состояния описывают различные возможности простоя (энергосбережения). Прежде чем подсистему можно отключить, эта подсистема не должна ничего запускать, поэтому она должна находиться в режиме ожидания, ничего не делать, ничего не выполнять. Таким образом, C-состояние x (или Cx) означает, что одна или несколько подсистем ЦП находятся в режиме ожидания и выключены.

С другой стороны, P-состояния выполняют переключение в определенные (энергосберегающие) состояния. Подсистема фактически работает, но она не требует полной производительности, поэтому напряжение и / или частота, на которой она работает, снижается. P-состояние x (или Px) означает, что подсистема, к которой он относится (например, ядро ​​ЦП), работает на определенной паре (частота, напряжение).

Поскольку большинство современных процессоров имеют несколько ядер в одном пакете, C-состояния далее делятся на C-состояния ядра (CC-состояния) и C-состояния пакета (состояния ПК). Причина состояний ПК состоит в том, что в процессоре есть другие (общие) компоненты, которые также могут быть выключены, как только все все ядра, использующие их, выключены (например, общий кэш). Однако, как пользователь или программист, мы не можем контролировать их, так как мы не взаимодействуем с пакетом напрямую, а взаимодействуем с отдельными ядрами. Таким образом, мы можем воздействовать только на CC-состояния напрямую, на PC-состояния косвенно влияют, основываясь на CC-состояниях ядер.

Состояния нумеруются, начиная с нуля, как C0, C1 … и P0, P1 … Чем выше число, тем больше энергопотребления. C0 означает отсутствие энергосбережения при выключении чего-либо, поэтому все включено. P0 означает максимальную производительность, то есть максимальную частоту, напряжение и мощность.


0 Comments

Ваш e-mail не будет опубликован. Обязательные поля помечены *