Внимание! Это продолжение предыдущей статьи. В прошлый раз мы закончили работу над тестами, добавили автоматизацию и приступили к переработке системы сбора базовой информации о конфигурации тестируемого ПК.
Мне очень не нравится тот факт, что при каждом выполнении вспомогательных скриптов, необходимых для получения информации о тестируемой системе, постоянно всплывают окна консоли. Godot Engine 2.1 просто не умеет запускать что-либо через функцию OS.execute без вызова окна консоли. А ещё в проекте есть исполняемый файл, необходимый для получения имени используемой видеокарты, буквально на десяток строк исходного кода. Именно благодаря этому файлу мой бенчмарк может показать пользователю имя используемой видеокарты.
Но забавный момент в том, что есть так называемые «антивирусные программы», которые запугивают пользователей вымышленными угрозами. И если на такие антивирусы совершенно плевать, то всплывающие окна терминала во время сбора информации о системе действительно раздражают.
Тут же выясняется, что проект уже прилично увеличился в объёме исходного кода и дальше не получится просто набрасывать код для выполнения конкретных задач. Обычным пользователям совершенно всё равно, как программа устроена внутри, но мне, как разработчику, становится сложнее работать над проектом. Пока ещё проблем нет, я спокойно могу исправить и переделать любой участок проекта, но в будущем сложность будет только возрастать, поэтому нужно заняться рефакторингом.
Первым делом разнёс скрипты по отдельным папкам, чтобы они не перемешивались с прочими файлами проекта.
Далее в настройках проекта добавляю несколько скриптов в раздел автоматической загрузки. К этим же скриптам будет обеспечен простой доступ через имя класса из любого места проекта.
Вместо обращения к определённому узлу через функцию get_node для получения доступа к нужной переменной в скрипте, теперь можно просто прописать имя класса и переменной. Таким образом будет уменьшено количество потенциальных ошибок при разработке.
А потом я снова взялся за переработку базы данных с результатами. Было бы неплохо сократить количество файлов и размещать каждый результат в нескольких строках. Основная строка содержит имя компьютера и технические характеристики в произвольном порядке, а последующие — результаты с версиями ОС и драйверов видеокарты. Хотя совмещение результатов с разными размерами окон раздувает список, это будет ощутимо только в комплексной таблице при тестировании множества разных операционных систем в равных условиях.
В итоге формат хранения результатов существенно изменился. Теперь в одной строке указаны оба результата в разрешениях 360p и 720p. Если какой-то из результатов не будет собран, то достаточно будет поставить прочерк.
Таким образом, количество файлов, требующих обслуживания, сократилось вдвое.
Ну а пользователю больше не нужно перебирать большие списки, чтобы получить информацию. Кроме того, были удалены лишние колонки вроде «бутылочного горлышка» и соответствия образцу. Сбор таких данных никак не автоматизирован и требует от тестирующего использовать сторонние инструменты вроде GPU-Z для выявления уровня нагрузки на GPU. Да и не всегда 100% нагрузка на GPU означает полную загруженность видеокарты. Нам такие сложности не нужны на раннем этапе разработки проекта.
Нам бы для начала реализовать систему сбора информации о системе: какая операционная система, видеокарта, процессор, и чтобы без тысячи всплывающих консолей…
Раз уж у меня появились новые результаты тестов с видеокартой RTX 3070 Frankenstein, думаю, следует заняться наполнением встроенной базы данных. Благодаря тесту PreHeat, минимально нагружающему GPU, сразу видно, что Ryzen 7 1700 является явным «бутылочным горлышком» в большинстве случаев. Сцены Simple и Shader немного сложнее для процессора, чем самая простая PreHeat, но результаты говорят о том, что только при разрешении 1280x720 в тесте Shader мы добились ситуации, когда именно видеокарта оказалась узким местом.
Выглядит неплохо. Причём из результатов становится ясно, что производительность явно ограничивается процессором. Очень заметно благодаря результатам в разрешении 360p и 720p, находящимся в одной строке. Если в 720p имеем такой же fps как и в 360p, очевидно, что производительность ограничена процессором.
Ну а так как я не трогаю сами тестовые сцены, уже собранные результаты остаются актуальными. Только компьютер с GTX 750 нужно будет заново протестировать, так как с момента последнего теста в цепочку была добавлена дополнительная сцена.
Попутно дорабатываю новый способ определения имен видеокарт и процессора. Пробую методы сбора информации через VBS-скрипт с записью данных в текстовый файл и последующим считыванием. Да, никаких всплывающих окон с консолью больше нет при использовании VBS-скрипта, но и характеристики определяются недостаточно точно, да и появляется зависимость от файловой системы. Первый запуск с флешки получился неудачным: файл не успел записаться за одну секунду, поэтому ничего не считалось.
Пока что старые методы с вызовом вспомогательных утилит через OS.execute работают лучше. Да, способ через VBS-скрипт работает без лишних окон, но он всегда выдаёт список видеокарт в одном и том же порядке, независимо от того, к какой видеокарте подключён монитор. Я уже задумываюсь над тем, чтобы вернуться обратно к старому, но действительно рабочему методу и просто объединить всё в один исполняемый файл, чтобы вместо четырёх окон с консолью открывалось лишь одно и не мозолило глаза.
Да и отпадёт проблема записи временного файла с информацией о системе, который может не записаться по вине медленного накопителя пользователя. Хотя проблему медленного накопителя можно решить повторными попытками чтения файла, пока не выйдет лимит попыток или файл не будет прочитан. Но опять же, проблема определения активной используемой видеокарты никуда не исчезает.
Много времени было потрачено на попытки определить активную видеокарту через VBS-скрипт; я даже попытался встроить в скрипт свой .exe-файл, который правильно работает и выдает верный результат, но всё безрезультатно. Я уже пожалел, что решил избавиться от окон консоли, всплывающих по вине движка Godot, из-за неполноценности которого и приходится городить такие костыли.
В итоге было решено вернуться к изначальному методу определения оборудования, но функции будут разделены по платформам для удобства внесения исправлений.
Таким образом, мы возвращаемся к проблеме вредоносных антивирусов, генерирующих устрашающий бред под видом угроз. Но мне всё равно, потому что иные способы получения имени активной видеокарты попросту не работают как положено.
Если присмотреться, можно заметить, что утилита GPU-Z ведёт себя точно так же при определении активного GPU, как и мой способ определения видеокарт.
Понятия не имею, как разработчики GPU-Z реализовали определение активной видеокарты, но можно заметить, что многие антивирусы просто не были задействованы при сканировании исполняемого файла утилиты GPU-Z. Среди незадействованных антивирусов есть много таких, которые заведомо ложно пугали пользователей опасностью при проверке «неугодного» файла.
Это всё выглядит как откровенная дискриминация в мире программного обеспечения: одних помечают флагом «опасен», а других проверяют, отключив ряд антивирусов, выдающих заведомо ложный флаг «опасен». Именно так это и выглядит с моей точки зрения.
Но, как уже говорилось, подстраиваться под вредоносные антивирусы я не буду. Почему некоторые антивирусы я называю вредоносными? Правильно: потому что они, по сути, наносят вред мне — разработчику программы, вводя пользователей в заблуждение по поводу угроз. Тем более что исходный код лежит рядом с исполняемым файлом: любой может изменить и скомпилировать этот код заново.
Ну а раз я взялся за рефакторинг и оптимизацию, то есть смысл объединить .bat-файлы в один и сократить количество вызовов при запуске движка Godot, который просто не способен исполнять файлы без открытия окон консоли. Заодно переработал утилиту определения установленных в системе видеокарт.
Про что-то очень важное я забыл... Точно! Версию драйвера нужно ещё вывести!
Таким образом, у нас есть новый доработанный исполняемый файл для определения видеокарт в компьютере. На первое место выводится активная видеокарта. Вероятно, это сработает не во всех возможных комбинациях GPU с мониторами, но пока что нам этого достаточно.
Исходный код получился гораздо сложнее из-за функционала определения драйвера видеокарты.
Даже стало интересно, что там антивирусы скажут по поводу скомпилированного исполняемого файла? Большинство антивирусов ничего не нашли. Оно и понятно: вирусов-то нет в файле. Но отсеялась и горстка недовольных антивирусов. Правда, кроме запугивающего бреда эти антивирусы не смогли ничего выдать.
И хотя никаких вирусов в файле нет, наверняка найдётся хоть один человек, который поверит этому бреду с угрозами, что уже является определённым ущербом для разработчика. А ведь наверняка я не один такой, чьи программы заведомо ложно помечают как угрозу. Каждую версию файла посылать антивирусным компаниям, чтобы её внесли в исключения? А как тогда развивать и совершенствовать проект? Ведь придётся заново «обивать пороги» антивирусных компаний с каждой новой версией... Именно поэтому я не лучшего мнения о любых антивирусах, ибо этими инструментами можно откровенно злоупотреблять...
Все наработки оформляю одним .bat-файлом, останется только послать этот вывод в движок Godot и разложить по своим местам.
Функция определения оборудования и операционной системы на стороне движка Godot получилась намного проще первого варианта и многократно проще варианта с VBS-скриптами. Хотя вариант с VBS-скриптами я не удаляю из проекта, так как он ещё может пригодиться.
Также доработал функцию записи результатов в файл. Теперь лишняя информация не дублируется при пакетном запуске тестов. При втором прогоне у меня ноутбук «передернул» батарею и начал зарядку как раз во время шейдерного теста при разрешении 1280x720, поэтому результат отклонился от нормы. Да и это не чистые результаты, потому что ChimbaBenchXPL сейчас работает в режиме отладки.
Также я позаботился о том, чтобы после завершения тестирования сцена менялась на самую лёгкую, а fps снижался до низкого значения. Это необходимо для тех случаев, когда пользователь оставляет тест включённым и забывает про него. Однажды про тест забыли и заснули, а система так и стояла под нагрузкой без ограничителя производительности. И хотя прочие бенчмарки редко заботятся о том, чтобы снизить нагрузку на систему после завершения теста, я реализовал эту функцию, потому что был реальный запрос от пользователей ещё не выпущенной новой версии ChimbaBenchXPL.
Дальше осталось только проверить бенчмарк в реальных условиях и собрать данные. Но об этом мы уже поговорим в следующей части. Она будет заключительной, так как я не собираюсь делать ничего существенного перед выпуском третьей альфа-версии бенчмарка ChimbaBenchXPL.
Благодарю за внимание, больше интересных статей в блоге Hard-Workshop.
Читайте далее на сайте
Основатель Framework заявил о возможном исчезновении привычных ПК
В Китае создали натриевую батарею с «умной стеной» внутри — она не загорается даже при 300°C