ChimbaBench 1.1: Несостоятельный Open-Source и практичный NVIDIA System Management Interface

Предисловие и Chi Calculator 2.10Начну пожалуй с "калькулятора", хоть я уже давно и не обязан работать над ним, но я работаю, хотя могу в любой момент забросить, ведь изначально мой калькулятор не должен был ничего уметь, кроме как запускаться в разных дистрибутивах Linux:К текущему моменту Chi Calculator уже вполне сносно выглядит и работает, скриншоты доступны в репозитории калькулятора, как и исходный код: ( github.com/Shedou/Chi-Calculator ).Конечно же я предоставляю и готовые для запуска исполняемые файлы:Это линуксоиды предпочитают издеваться над обычными пользователями, и заставляют компилировать исходные коды своих приложений, чтобы потом плясать над кривыми зависимостями и прочим мракобесием.Для меня не зазорно сделать "грязную" работу скомпилировав проект, хотя я сам ни разу не программист, и разработчик из меня такой себе:Так что линуксоиды, не позорьтесь лишний раз в комментариях, это выглядит весьма глупо, когда пользователь разрабатывает приложение, а вы, линуксоиды, начинаете брызгать слюной рассказывая как всё плохо и вообще автор криворукий.Линуксоиды, это ваш позор, что так называемый "криворукий писака статей" разрабатывает приложения, которые можно запустить буквально двойным кликом в целом зоопарке дистрибутивов: Ubuntu 13.04, Debian 11, EndeavourOS 22.12, Simply Linux 10.1, Fedora 37, openSUSE 15.4 и прочие.А GtkStressTesting на такое способен? Чтобы я, как пользователь взял и скопировал его на флешку, да запустил без геморроя на голову в парочке систем с ОС Linux на борту? Вот нужно мне сравнить производительность процессоров, и никак иначе!Конечно же не способен, для его установки нужен не только доступ к интернету, он еще гигабайты зависимостей с собой притащит в систему пользователя, создавая самую настоящую помойку, которой позавидует даже Microsoft Windows в запущенных случаях:Удобные исполняемые файлы? Зачем, пусть пользователи танцуют с бубном вокруг костра над терминалом!Кто-то скажет, что мой софт имеет проблемы, но разве линуксоидный софт идеален? С AMD Ryzen вышеупомянутый "GST" вполне нормально отображал текущую скорость ОЗУ, но вот с Intel LGA1200 уже показывал неправильно, и этот косяк на "поверхности":Мои Chi Calculator и ChimbaBench можно запустить буквально в два клика мышью, даже без доступа к интернету, а вот GST и многий софт для Linux ставит пользователя в зависимость не только от интернета, но и от болота линуксоидного.Так что позорьтесь дальше мои ненаглядные линуксоиды, а я тем временем продолжу разработку ChimbaBench, чтобы пользователи не насиловали себе мозги когда нужно просто сравнить производительность двух разных ПК, как говорят: Собака лает, а караван идёт.------ChimbaBench 1.1Немного разобравшись с "калькулятором" и Vulkan версией бенчмарка, я вернулся к главной версии ChimbaBench, начало уже положено, но сейчас проект выглядит как нагромождение на свалке:Прежде всего я начал наводить порядок, для основной системной информации выделил отдельный скрипт, и тут же начал экспериментировать с получением информации от сторонних "источников", ведь Godot Engine не может показать максимально подробную информацию о системе пользователя.Да, вот так я взял и вызвал командную строку Windows, получил дату драйвера, и вывел эту информацию в интерфейс бенчмарка: Линуксоиды конечно предпочтут в терминале заклинания колдовать, пусть колдуют, а я постараюсь, чтобы пользователю моего бенчмарка не приходилось колдовать неведомую дичь в терминале.Может у меня и не выйдет всё на лучшем уровне, наверняка не выйдет, но я всё равно буду делать.Узнавать подробную информацию о системе я решил используя внешние инструменты, ибо Godot Engine хоть и позволяет вывести базовую информацию, но вот узнать частоту ГП, DeviceID или иную подробную информацию уже проблематично.Сначала обратился к WMI в среде Windows, а именно к классу Win32_VideoController:Но у Win32_VideoController есть недостаток, он вполне покажет количество памяти у старых видеокарт, но у моей видеокарты 8 ГиБ памяти, и такой способ уже не подходит, он просто показывает неправильное значение ввиду ограничений uint32, ведь максимальное значение такого типа данных "4,294,967,295":Да и в целом таким образом нельзя получить много информации.Потому я вспомнил про такие инструменты как HWiNFO64, но это оказалось не очень то и полезно для работы в режиме командной строки (CLI), да, у HWiNFO есть SDK для таких целей, но совершенно непонятно как его получить, да и "условия использования" просто отвращают подальше от утилиты:Но есть еще hwinfo библиотека, это Open-Source проект, но его использование весьма затруднено в качестве отдельного CLI модуля.Да и в среде Linux эта библиотека не позволяет узнать информацию о количестве памяти видеокарты.Конечно, проект открытый и автор даже предлагает всем развивать библиотеку, но увы, у меня есть сомнения, что эта библиотека будет нормально работать в старых дистрибутивах, да и её функционала мне явно будет мало. Многое что умеет библиотека я могу получить просто послав команду в терминал из Godot, а там осталось только разобрать результат работы "не отходя от кассы"...Так что фактической пользы для меня нет от вышеупомянутого проекта.Мне нужно было получить информацию, но я не знал как это сделать, пока не наткнулся на NVIDIA-SMI...Где есть видеокарта от NVIDIA обязательно присутствует и драйвер, а в драйвере есть System Management Interface, так для чего эта штука нужна?Конечно, "читать мануалы" через консоль/терминал то ещё извращение, потому я перевожу справку в текстовый файл, и читаю уже через нормальный текстовый редактор с графическим интерфейсом, не нужен мне мазохизм линуксоидный с консолями и терминалами...В целом я разобрался как работать с NVIDIA-SMI, и вот пришло время попробовать поработать с ним из Godot Engine:Для наглядности я убрал лишнее с экрана, и вывел только раздел с частотами видеокарты, как можно заметить, аргументы нужно разделять в массиве:Но такие подробности не влазят в экран, а значит их нужно целенаправленно обработать, к счастью NVIDIA позаботились над удобством использования своих инструментов, и я могу просто выбрать нужное мне значение, но с этим возникли небольшие сложности...Вообще оно работает, и выдает ровно то, что нужно, пока оно работает в командной строке Windows:Совсем другое дело вызов из Godot Engine... Я много времени потратил пытаясь правильно вызвать nvidia-smi, сначала я вызывал CMD, а потом уже посылал nvidia-smi как аргумент, в том числе и остальные аргументы, логично ведь, но на самом деле нужно было вызвать напрямую nvidia-smi:Эх, если бы в документации давали наглядные примеры для подобных случаев...А то дали примеры для ls и cmd, а потом думай, заработает ли nvidia-smi без предварительного вызова командной строки, или любое иное консольное приложение, вроде и написано, что исполняет файл, но конкретных примеров нет для исполнения сторонней утилиты, потом люди бегают по форумам и спрашивают, а почему не работает функция как надо... Так или иначе я получил от "OS.execute" что хотел, может быть этот код даже будет полезен новичкам в Godot Engine, ибо работа с "OS.execute" по документации действительно может быть неоднозначной, впрочем, типичный Open-Source.А теперь пора бы остановится, ведь я уже смешал информацию от Godot и внешнего источника, это очень нехорошо, вероятно я запутаюсь в будущем, ибо nvidia-smi нужно использовать только при наличии видеокарты от nvidia.Потому я отделил информацию полученную от NVIDIA-SMI в отдельную ноду и скрипт:Конечно же тестовый "лист" со строками на разных языках тоже следует вынести отдельно, пока что так, потом переделаю:Теперь скрипт GUI_Info гораздо лучше выглядит, нет больше нагромождений всего и вся в одной куче, но тут я понял, что одновременное написание статьи и работа над проектом затормаживает процесс в целом...Для статьи я стараюсь всё в последовательности расписывать как было, но я могу сделать одно, а потом решить сделать по другому, а еще спустя время вообще всё изменить иначе, при этом нужно наглядно показать для статьи сделанное, и это начинает становиться проблемой.Потому я попробую другой подход, сначала сделаю, а потом уже буду думать как представить в статье.Но и в этом подходе есть проблема, мне нужно запоминать каждое своё действие соблюдая последовательность во времени, в том числе и "мотивацию" почему было сделано именно так, а не иначе, иначе могу упустить некоторые моменты, возможно даже важные.Впрочем, я слишком заморачиваюсь судя по всему, так что будь что будет!Таким образом я набросал мониторинг текущих показателей видеокарты через nvidia-smi, но с мониторингом уровня потребления вышла небольшая проблема, nvidia-smi выдает только потребленную мощность от 8-Pin коннектора питания, но не учитывает мощность потребленную через PCI-e слот:Неприятно однако, но эта проблема не заслуживает пристального внимания сейчас, так что продолжу дальше набрасывать код.Так экспериментируя и набрасывая код я обнаружил последствия вызова nvidia-smi, да, это те самые пики на графике времени кадра, микро фризы проще говоря:И решил эту проблему просто отправив вызов nvidia-smi в отдельный поток, правда я облажался немного, и поток отвечающий за вызов nvidia-smi оказался полностью загружен, ведь он молотит вызовы непрерывно в бесконечном цикле.Зато ничего не лагает и нет микро фризов :)Теперь график времени кадра идеален, и пофиг, что там вызовы nvidia-smi молотят неистово в отдельном потоке процессора, оно работает? Работает! Микро фризы исчезли? Исчезли! Что еще надо?Кстати, оверлей MSI Afterburner очень даже заметно влияет на FPS: Но негоже зря растрачивать ресурсы системы пользователя, тем более множественными вызовами nvidia-smi на фоне, потому "укрощаю" поток работающий над вызовом nvidia-smi, но вместе с этим вернулась проблема микро фризов.Я использовал "yield" чтобы приостановить исполнение кода, оно работает, нагрузка на процессор значительно снизилась, но появились фризы, хотя вызов nvidia-smi уже работает в другом потоке, значит поток не спасает, нужно ковырять в сторону самой функции "yield": yield(get_tree().create_timer(chi_thr1_timeout_value), "timeout"); В итоге я решил заменить yield на "OS.delay_msec", и это сработало, фризы исчезли, нагрузка на ЦП осталась низкой, но теперь приложение нельзя закрыть нормально, оно зависает при закрытии...Некоторое время экспериментируя, и даже подчищая лишнее в коде, я понял кое-что...Я же добавил функцию _exit_tree которая ожидала завершение работы потока, а он не завершался никак так как там бесконечный цикл, потому я не мог закрыть нормально приложение и оно зависало.Наверное пора сделать перерыв пока всё работает, и загрузить эту версию в GitHub да закончить статью...А еще я заметил, теперь у меня правильно показывает общее энергопотребление видеокарты, не знаю в какой момент оно "само по себе исправилось", но ведь это же прекрасно, когда баги сами исправляются:А еще у моего корпуса включился ранее неисправный синий индикатор питания, он конечно работал в прошлом году, но в какой-то момент перестал, и вот он снова работает.Наверное линуксоиды собрались в культ колдовства против меня, и никак не могут определиться, как и что мне наколдовать...Ведь ещё вчера разбился десяток яиц, отличная иллюстрация современного оверклокинга:Отвалился кусок петли у двери, он просто отвалился, прямо как куски дистрибутивов Linux при любом неосторожном действии, хотя дверь я особо даже и не пинал, просто открыл: Ну и по мелочи всякое случалось...Впрочем, чуть необычнее обычного.------ЗаключениеНа этом пожалуй завершу работу над ChimbaBench v1.1, за кадром еще немного исправлений сделал, и на этом хватит пока.Конечно, nvidia-smi доступен только для видеокарт от NVIDIA, с видеокартами AMD оно не будет работать, но разве это плохо? Я могу вывести подробную информацию о видеокарте пользователя, частоту ядра, процент загрузки чипа, и многое другое, что недоступно средствами самого Godot Engine, и обычного пользователя наверняка не будет волновать, а как это было сделано.Я бы хотел и для видеокарт AMD нечто подобное, такое-же удобное и практичное как nvidia-smi, но у меня нет в данный момент ни одной видеокарты от AMD.А в слепую ковырять "Open-Source" неблагодарное занятие, одно "устарело", другое тонет в зависимостях (как минимум Python), третье вообще вызывает недоумение в моём случае, в итоге не нашёл адекватного и подходящего аналога NVIDIA-SMI для видеокарт AMD... Будь у меня видеокарта от AMD, я бы еще поковырялся с поделками красного лагеря, но увы, подробная информация о видеокартах будет доступна на данный момент только с видеокартами NVIDIA, просто потому что NVIDIA предоставила удобный и рабочий инструмент, ничего личного.Кстати, меня обычно называют красным фанатиком, мол, я фанат продукции AMD, теперь меня будут называть фанатиком NVIDIA судя по всему...А ведь есть еще видеокарты от Intel, и системы у которых несколько графических процессоров, и это на самом деле не было бы проблемой, если бы все предоставляли такие же практичные и рабочие инструменты как у NVIDIA, а ведь ещё нужно в среде Linux выкрутиться...Впрочем, линуксоиды делают что угодно, кроме действительно необходимого, и когда линуксоид становится ответственным за некоторые фундаментальные вещи - пиши пропало, еще и извратят изначальный смысл, чтобы выставить "своих" чуть получше:Для тех, кто не понял, мейнтейнер отвечающий за сетевую подсистему ядра Linux отказался от исправлений не потому что он был "не уверен", ему просто так захотелось, видите ли, чувствует он себя некомфортно принимая исправления ошибок от "неугодных"...Так что глупо ожидать от "Open-Source" адекватности и работоспособности, люди дают исправления, а ответственные за проекты "чувствуют себя некомфортно", и предпочитают дальше кормить пользователей кривым софтом отвергая исправления от "неугодных".Может быть я прикуплю себе видеокарту от AMD специально для поддержки "красного лагеря", и может быть даже найду костыли, чтобы вывести подробную информацию на уровне nvidia-smi, но как оно будет работать, это уже большой вопрос, потому владельцы видеокарт AMD скорее всего будут довольствоваться лишь базовой информацией о своей видеокарте.Напоминаю, я не программист, но мой софт уже работает во множестве разнообразных дистрибутивов Linux, и вполне успешно ещё разрабатываю свой бенчмарк, ведь у линуксоидов нет адекватного бенчмарка, который можно закинуть на флешку, и запустить на множестве ПК с Linux буквально парой кликов мышью без доступа к интернету.В общем, сейчас мой бенчмарк хоть и не очень пригоден для использования по назначению, но он уже работает:Таки мне не показалось при разработке первой версии, что в Ubuntu 13.04 бенчмарк показывает более высокий FPS относительно других, ведь этот дистрибутив не умеет в OpenGL 3.0 работая с виртуальной машины, и бенчмарк использовал OpenGL 2.0 для работы в столь старом дистрибутиве:Чуть не забыл, бенчмарк нормально переносит смену разрешения экрана: И конечно репозиторий проекта ChimbaBench: ( github.com/Shedou/ChimbaBench ).Очень многое ещё нужно сделать, но в другой раз, пора заканчивать статью.Благодарю за внимание, больше интересных статей в блоге Hard-Workshop.Придумайте сами описание к фотографии.