Новости про AIDA64, RivaTuner Statistics Server, видеокарты и мониторинг

За пару выходных Алексей Николайчук добавил в него несколько базовых улучшений, на основе которых теперь можно создавать как пассивные, так и комплексные динамические анимации. В видео ниже демонстрируются 3 базовых «кирпичика», лежащих в основе создания анимаций в оверлее:

• Источники данных на основе таймеров.
• Асинхронно обновляемые слои.
• Улучшенный лексический анализатор и транслятор формул, позволяющий использовать в формулах коррекции перекрёстные ссылки на другие источники данных.

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

Активная работа над программой продолжается!

Ключевые изменения новинки мы уже описывали ранее: во-первых, это внутренний HAL и встроенное мини-ядро мониторинга на его основе (только встроенные сенсоры драйвера видеоадаптера с минимальным риском конфликта со сторонними ядрами мониторинга). Во-вторых, это встроенная возможность подключения счётчиков производительности операционной системы (загрузка/скорость чтения/записи накопителей, скорости скачивания/закачки сетевых интерефейсов и так далее) — полный функциональный клон плагина PerfCounter из SDKMSI AB но для тех, кто хочет использовать RivaTuner Statistics Server отдельно от него.

Также добавился альтернативный интерфейс для стриминга абсолютных меток времени кадров в стороннее ПО через именованный пайп. Специально для этого проекта: RTSS_time_reader.

Скачать программное обеспечение можно как обычно — на странице утилиты.

В редакторе появился ещё один встроенный провайдер данных — счётчики производительности Windows. Для мониторингового ПО из этого источника традиционно берутся показания загрузки физических накопителей, их текущие скорости чтения/записи а также текущие скорости скачивания/закачки сетевых интерфейсов. Но, помимо этого, доступны и сотни других видимых операционной системе счётчиков, включая инструментальные дополнительные счётчики от стороннего ПО. В MSI AB всё это давно представлено плагином PerfCounter. Неудивительно, что в редактор гипертекста ядро провайдера счётчиков перекочевало именно оттуда.

Очередная бета ожидается в течение недели-двух.

В нём появился встроенный HAL (уровень абстракции оборудования) и собственное минималистичное ядро мониторинга с открытым кодом на его основе, предоставляющее плагину встроенную поддержку мониторинга современных GPU.

Как говорит автор, этих собственных мониторинговых возможностей HAL хватит большей части тех, кто пользуется оверлеем — температуры, загрузка функциональных блоков GPU, его частоты, энергопотребление и загрузка видеопамяти любых современных GPU в наличии. Словом, доступны любые счётчики производительности GPU, официально и нативно поддерживаемые API обоих вендоров (NVAPI/AMDADL). Соответственно, можно использовать RTSS как полностью самостоятельное мониторинговое решение, не подключая к нему дополнительные приложения-провайдеры данных мониторинга.

При этом принцип разделения низкоуровневого ядра мониторинга и ядра оверлея не нарушается — в отличие от HWiNFO/AIDA/MSIAB, встроенный HAL плагина не использует собственного драйвера для низкоуровневого доступа к железу и считывает показания только через официальные мониторинговые механизмы драйверов видеоадаптеров. Поэтому риск конфликта с другим мониторинговым ПО сведён практически к нулю. Ну а тем, кому нужны и дополнительные сенсоры, использующие низкоуровневый доступ к железу (например температуры CPU), никто по-прежнему не мешает подключить к оверлею любой внешний источник данных из любого внешнего мониторингового ядра.

Исходный код HAL будет открыт, как и код всего плагина — за что Алексею отдельное спасибо!

Как говорит сам Алексей, ещё одна часть функционала из оригинальной RivaTuner перекочевала в MSI Afterburner вслед за плагинами мониторинга. В следующей бете появится знакомый пользователям RT функционал для работы с фрагментами истории. Как и в оригинале, в MSI AB можно будет выделять произвольные фрагменты истории (и в режиме реального времени, и в режиме просмотра логов), автоматически рассчитывать и отображать статистику по выделенному фрагменту, автоматически расставлять маркера в точках локальных экстремумов.

Кроме того, реализацию плагинов мониторинга совместно с тестерами практически довели до точки логического завершения. API, SDK и GUI настроек плагинов практически полностью соответствуют тому, что планировалось изначально. В SDK появился последний из запланированных плагинов с открытым кодом — CPU.DLL, предназначенный для демонстрации функций API плагинов для низкоуровневого доступа к MSR и PCR регистрам. Плагин практически полностью дублирует реализацию встроенного температурного мониторинга для всех поддерживаемых ядром RT процессоров (за исключением семейства AMD Ryzen, открыть код мониторинга для которого на данный момент невозможно в силу NDA). Изначально планировалось добавить ещё один плагин — GPU.DLL, демонстрирующий использование функций API для низкоуровневого доступа к регистрам и I2C устройствам графических процессоров. Но в острой необходимости присутствия такого плагина в SDK есть некоторые сомнения, т.к. всех разработчиков утилит мониторинга, умеющих работать с GPU напрямую, можно пересчитать по пальцам одной руки. Так что в том, что такие плагины для расширения функций мониторинга GPU смогут разрабатывать сами пользователи, есть некоторые сомнения.

Алексей провел мозговой штурм с пользователями утилиты после появления улучшенного профайлера производительности. Как результат — в новой панели профайлера производительности теперь вместо одного самого медленного сенсора отображается динамически сортируемая диаграмма времён опроса каждого из сенсоров, позволяющая ещё легче и быстрее выявлять главных «пожирателей» процессорного времени при опросе железа на каждой системе.

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

Ирония в том, что такая маркетинговая лапша остаётся висеть на ушах геймеров, не понимающих, что на самом деле урон игровой производительности в ПО мониторинга практически не зависит от интерфейса ПО и его форм визуализации данных. Главный тормоз системы в ПО такого класса — опрос железа (почти всегда в режиме ядра), поэтому влияние на производительность практически стопроцентно зависит исключительно от набора опрашиваемых аппаратных датчиков и от частоты их опроса. Даже не столько от их количества, сколько от их качества (т. е. от типа датчиков, и от протоколов доступа к ним). Например, внутренние счётчики производительности частоты ядра графического процессора — это почти всегда внутренние PLL регистры, доступ к которым выполняется через MMIO механизм мгновенно, в десятые доли миллисекунды. А счётчики того же энергопотребления GPU — почти всегда внешние чипы на видеоадаптере (часто даже несколько чипов сразу), доступ к которым производится по гораздо более медленной I2C шине. Время опроса таких сенсоров может отличаться уже на порядок и измеряться несколькими миллисекундами. Протоколы доступа к SMART-аттрибутам жёстких дисков, хранящим температуры, обычно ещё боле медленные, и их опрос может занимать уже десятки (а то и сотни, для не слишком удачных аппаратных реализаций) миллисекунд. От набора сенсоров, включенных одновременно в ПО мониторинга, и будет зависеть то, насколько сильно влияет процесс мониторинга на производительность системы.

В RivaTuner, а потом и в EVGA Precision и  MSI Afterburner для правильной в этом плане настройки модуля мониторинга давно существовал профайлер производительности (включается через контекстное меню окна мониторинга по команде <Показать статус>). Старый классический профайлер позволял оценить лишь общее время процессора, затрачиваемое на опрос всех включенных сенсоров, и увидеть, как отключение того или иного сенсора влияет на общее время опроса. Обновлённый же профайлер упростит и процесс выявления и отключения самых медленных из включенных сенсоров. С ростом числа одновременно активированных сенсоров (с учётом появления плагинов в MSI AB их среднее число приближается к сотне) это становится очень актуальным. Например, на скриншоте выше мониторинг системы с тремя активными GPU (2xSLI + встроенный iGPU). Время опроса 80 сенсоров на этой системе составляет 67 миллисекунд, то есть при опросе этих сенсоров с периодом 1000 миллисекунд на опрос тратится около 7 процентов процессорного времени одного ядра. При этом на диаграмме профайлера видно, что треть этого времени тратится на опрос пары сенсоров энергопотребления графических процессоров. Их и можно отключить, если при игре со включенным мониторингом наблюдаются нежелательные побочные эффекты в виде рывков.

Как говорится — мало с умом выбрать средство диагностики, необходимо еще и уметь хотя бы минимально его настроить под свои нужды.

Основной фокус в разработке текущей версии — дальнейшая «прокачка» системы плагинов, API для их настроек, GUI настроек для плагинов AIDA64/PerfCounter/HwInfo и демонстрация новых возможностей в SDK для сторонних разработчиков. Также улучшился встроенный профайлер производительности модуля мониторинга: теперь в статусной строке окна мониторинга помимо общего времени опроса железа можно видеть и наиболее медленный сенсор, который «ест» максимальное количество процессорного времени на каждой итерации опроса железа. Это может облегчить процесс выявления проблематичных сенсоров (например, аномально медленный сенсор энергопотребления GPU в некоторых версиях драйверов NV).

Полный список изменений включает в себя следующее:

• Минимальная, средняя, максимальная, 1% снижение и 0,1% снижение частоты кадров теперь отображается в OSD со специальными тегами форматирования. Теги позволяют отображать статистику одновременно для разных 3D-приложений.
• Улучшен встроенный профайлер производительности. Теперь при зажатии кнопок + при включённой опции в окне аппаратного мониторинга «Показать статус», можно увидеть дополнительный набор статистики в окне статуса аппаратного мониторинга. Дополнительная статистика включает информацию о самом медленном датчике с максимальным временем опроса, что позволяет выявить проблемный сенсор.
• Улучшен скин MSI Cyborg White.
• Улучшен мониторинг плагинов архитектуры. Добавлена функция API SetupSource, позволяющая сконфигурировать плагины. Она позволяет настраивать плагины глобально из окна выбора плагинов (например, сконфигурировать весь список данных с каждого плагина). Также добавлена функция API GetHostAppProperty, позволяющая плагинам получать данные из хост-приложения (т. е. MSI Afterburner), которые включают, например, цветовую схему интерфейса.
• Улучшены плагины мониторинга. Теперь пользовательские плагины и плагины по умолчанию хранятся отдельно, так что обновление не приведёт к потерям. Добавлен GUI для конфигурации плагинов AIDA64, HwInfo и PerfCounter. Теперь каждый интерфейс пользователя позволяет редактировать список датчиков для каждого плагина. Также улучшен плагин SMART, добавлена температура воздуха в SSD Intel и Samsung.
• Исправлены ошибки в контекстной справочной системе.

Кроме этого обновился и RTSS до версии 7.1.0. Изменения в нём включают:

• Добавлен механизм закрепления OSD для сторонних приложений. Механизм призван исключить эффекты мерцания.
• Добавлены теги форматирования текста для отображения минимальной, средней, максимальной, 1% снижения и 0,1% снижения частоты кадров в режиме бенчмарка.
• Появилась возможность настроить размер графика истории времени кадра посредством свойств RivaTuner Statistics Server. Положительные значения используются для задачи размера в пикселях, а отрицательные — в символах.
• Теперь появилась возможность переключить состояние режима бенчмарка из свойств RTSS. Для сторонних приложений для этого по-прежнему требуется нажимать горячую кнопку.
• Появилась возможность переключаться между средним и постоянным режимами расчётов для пиковых частот кадров для режима бенчмарка через свойства RTSS.
• Исправлены ошибки в контекстной справочной системе.
• Изменён SDK. Теперь образец кода RTSSSharedMemorySample демонстрирует реализацию закрепления OSD и фильтра мерцания.
• Обновлён список профилей.