Разработка и выпуск новой версии бенчмарка под названием ChimbaBenchXPL (Alpha-3). Часть 3
Внимание! Это продолжение предыдущей статьи! Ранее был доработан новый шейдерный тест и внедрена функция сохранения результатов в файл. Также был доработан раздел с таблицей результатов.

реклама
Теперь можно собрать результаты с видеокартой GTX 750 для дальнейшего совершенствования проекта.
![]() |
![]() |
![]() |
![]() |
Так как я загрузил систему с двумя видеокартами, то без проблем переключил монитор на встроенную Radeon 3100 и снова собрал результаты. К сожалению, столь слабый GPU не потянул Shader Test в разрешении 1280x720, выдав всего 2 fps. В разрешении 640x360 имеем 4–5 fps.
![]() |
![]() |
![]() |
![]() |
Сразу отмечаю неудобство сохранения информации в файле. Да и забываю нажимать кнопку сохранения. Нужно будет сделать автоматическое сохранение после завершения теста и поработать над форматированием. Именно для выявления таких недостатков я и провожу тестирование, да и не один раз. Очень жаль, что разработчики софта для Linux пренебрегают подобным тестированием в реальных условиях. Иначе Linux не оказался бы в положении трёх процентов, спустя три десятилетия «развития».
![]() |
![]() |
реклама
Далее следует тест, загружающий текстуру размером 16384 пикселя. В среде Windows 7 он работает без проблем. А вот в Windows XP текстура максимального размера не загрузилась. Однако под управлением Linux с драйвером Nouveau + Mesa ситуация ещё более скверная. Если под управлением Windows XP «потерялась» только одна текстура, то под Линуксом «теряется» практически всё. Коротко о качестве драйверов, вшитых в монолитное ядро Linux.
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Перехожу к тестированию разнообразных Линуксов. Начинаю с Chimbalix и Radeon 3100.
![]() |
![]() |
![]() |
![]() |
Переключаю монитор на видеокарту GTX 750 и сталкиваюсь с характерными для Linux проблемами в работе с несколькими видеокартами и мониторами. Активной видеокартой так и осталась Radeon 3100, несмотря на то, что монитор подключен к GTX 750. В Windows такого мракобесия не было.
![]() |
![]() |
Благо, у меня в дистрибутиве Chimbalix уже давно реализовано специальное контекстное меню, позволяющее принудительно переключить видеокарту под конкретное приложение. Так как вместо драйвера NVIDIA используются линуксоидные Nouveau и Mesa 25.0.7, в моём случае сработала опция через DRI_PRIME.
![]() |
![]() |
![]() |
реклама
Но записывать эти результаты не будем, так как Linux крайне плохо работает при наличии нескольких видеокарт, даже если может показаться, что всё нормально. Проблема тут в том, что Linux не способен адекватно переключать активную видеокарту, из-за чего может быть перегружена шина подключения GPU к системе из-за паразитных транзакций изображения по вине несостоятельного ядра Linux, до сих пор неспособного на правильную работу с несколькими видеокартами и мониторами.
![]() |
![]() |
Также есть проблемы с датчиками видеокарт. Их просто нет по вине монолитного Linux. Поэтому мы можем лишь косвенно угадывать, какой компонент оказался «бутылочным горлышком»: процессор или видеокарта.
![]() |
![]() |
А это просто артефакты по вине драйвера Nouveau + Mesa. Я отправил компьютер на перезагрузку, и вместо перехода к терминалу Linux экран просто залился шумом. В любом случае пора перейти на Linux под названием Fedora.
![]() |
![]() |
Снова начинаю с видеокарты Radeon 3100. Тут уже установлена более новая Mesa 25.2.4 и Linux 6.17.
![]() |
![]() |
![]() |
![]() |
реклама
Переключаю монитор на дискретную видеокарту и сразу же сталкиваюсь с характерными для Linux проблемами в работе нескольких видеокарт и мониторов. Как всегда.
![]() |
![]() |
![]() |
![]() |
Проблемы ровно такие же, как были в предыдущем проверенном дистрибутиве. Только в отличие от Chimbalix в прочих дистрибутивах нет удобного в использовании контекстного меню, позволяющего принудительно переключить видеокарту. В прочих дистрибутивах Linux нужно «танцевать с бубном» в терминале для выполнения столь элементарных операций. Досадно...
![]() |
![]() |
![]() |
![]() |
Linux Mint оказался таким же проблемным, как и все остальные дистрибутивы. С этого момента я больше не буду останавливаться на характерных для Linux проблемах взаимодействия с несколькими GPU и мониторами.
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Дальше проверяем дистрибутив Nobara. Ничего примечательного.
![]() |
![]() |
![]() |
![]() |
![]() |
Ну а дистрибутив Garuda продемонстрировал ужасающую производительность с видеокартой AMD Radeon. Он и с современными видеокартами так же ужасно работает временами. Так что это не вина конкретного экземпляра GPU.
![]() |
![]() |
![]() |
![]() |
![]() |
Отключаю встроенную графику и продолжаю тестирование с одной GTX 750. Только так и можно нормально протестировать видеокарту, если вместо операционной системы используется Linux.
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Fedora ничем особо не отличается от других дистрибутивов Linux. Всё так же плохо, как и всегда. Из примечательного заметил, что композитор в Fedora работает весьма плохо: при перемещении окон производительность программы значительно падает, как и нагрузка на ЦП.
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Ну а драйверы в ядре Linux и Mesa настолько плохо работают, что часть работы над графикой явно берёт на себя центральный процессор. Небось опять что-то очень важное выкинули из проекта Mesa3D, из-за чего процессору приходится трудиться на пару с видеокартой, хотя в идеале должна работать в основном видеокарта. Это косвенно объясняет, почему официальные драйверы AMD для Windows имеют ужасную зависимость от производительности процессора, в отличие от драйверов NVIDIA. Ведь «красные» драйверы, судя по всему, уже давно основаны на кривом проекте Mesa3D из мира Linux со всеми его проблемами.
![]() |
![]() |
![]() |
![]() |
В дистрибутиве Mint всё аналогично. Хотя я и не смотрю на нагрузку ЦП, по системе охлаждения слышу, что процессор трудится наравне с видеокартой. Так быть не должно. И это одна из причин, почему Linux почти всегда значительно уступает в играх даже старым версиям Windows и в принципе не подходит для установки на старые компьютеры, ведь у старых ПК нет огромного избытка ресурсов для покрытия технической несостоятельности ядра Linux и большинства его компонентов.
![]() |
![]() |
![]() |
![]() |
![]() |
Туда же Nobara и Garuda. Какую бы личину ни принимал Linux, результат один и тот же. Иронично, что Nouveau + Mesa с видеокартой NVIDIA работают сейчас в дистрибутиве Garuda лучше, чем с видеокартой AMD Radeon.
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
В последний момент вспомнил про Windows XP. Да, один драйвер NVIDIA 340.52 поддерживает видеокарты, начиная с GeForce 8000 Series и заканчивая GeForce GTX 700 Series. Вот это называется поддержкой! Мне не нужно танцевать с бубном в поисках подходящих драйверов, как это приходится делать с AMD Radeon, так как «красная» контора постоянно кидает с поддержкой свою продукцию и пользователей. Это всё равно что если бы AMD выпустила один драйвер для поддержки видеокарт, начиная с Radeon HD 2000 Series и заканчивая R9 300 Series (ребренды HD 7000). Но в реальности, у AMD целых три поколения драйверов для такого диапазона оборудования, и все кривые.
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Результаты собраны, осталось доработать таблицу и внести исправления, чтобы результат автоматически сохранялся после завершения теста. Ну а кнопку можно убрать: толку от неё мало, только место лишнее занимает, аж глаза разбегаются.

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

Таблицу результатов тоже доработал.

Ещё я подумал об удобстве использования и реализовал автоматическое пакетное тестирование. Нажимаю одну кнопку, и система сама проходит по тестам, предназначенным для проверки производительности.
![]() |
![]() |
![]() |
Потом остаётся только просмотреть файл с результатами. Хотелось бы, конечно, ещё сохранить результаты в виде таблицы, чтобы вручную не переносить их в сводные таблицы, но я и так слишком много сделал для очередной альфа-версии. Так что на этом хотелось бы остановиться.

Теперь нужно в очередной раз провести тестирование. На этот раз возьму ноутбук с пассивной системой охлаждения на базе Intel Celeron N4020 мощностью около 5 Ватт. Сначала просто запускаю ChimbaBenchXPL и смотрю: вроде ничего странного не происходит. Да и текущий шейдерный тест не должен показывать ничего странного даже с графикой Intel.
![]() |
![]() |
![]() |
![]() |
Осталось нажать одну кнопку и ждать, пока мой абсолютно никому не нужный бенчмарк всё сделает сам. Это вам не линуксоидные бенчмарки, которые зачастую требуют танцев с бубном в терминале, чтобы хоть чего-то добиться с ними.
![]() |
![]() |
![]() |
![]() |
В результатах записалось некоторое количество мусора, нужно будет убрать лишний код перед сборкой распространяемой версии проекта. Да и кнопку сохранения тоже нужно будет отключить, ибо она не нужна. Но это никак не влияет на текущее тестирование, так что продолжаем.
![]() |
![]() |
![]() |
Теперь тестирую в Linux под названием Chimbalix 24.8. Правда, есть нюанс: этим ноутбуком так долго не пользовались, что в операционной системе установлена изначальная Mesa 24.2.8.
![]() |
![]() |
Впрочем, никаких проблем, потому что сейчас у нас установлен не абы какой Linux, а проработанный Chimbalix. Я просто беру автономный установочный пакет обновлений CUP-2481 для Chimbalix и устанавливаю обновление без какого-либо доступа к интернету. Таким образом получаю более свежую и менее проблемную Mesa 25.0.7.
![]() |
![]() |
![]() |
![]() |
Всё. Результаты собраны. Хорошо, что я решил автоматизировать весь процесс тестирования и сбора результатов. Автоматизация оказалась настолько полезной, что я больше не тестирую вручную. Это определённо успех.
![]() |
![]() |
Среди интересного можно отметить, что протестированная Intel UHD 600 определённо оказалась быстрее под Линуксом в данном конкретном случае. Хоть где-то fps в Linux оказался выше, чем в Windows...
Так или иначе, ранее неиспользуемая сцена была переименована и установлена первой в тестовом пакете. Эта сцена настолько проста для видеокарт, что в большинстве случаев процессор будет «бутылочным горлышком». Да и лишний «разогрев» не помешает перед началом основных тестов. Также эта сцена даст некоторое понятие о том, насколько производителен процессор, и если результаты в прочих тестах окажутся идентичными, то это означает лишь то, что как раз процессор и есть «бутылочное горлышко».
![]() |
![]() |
Первая пачка результатов для итоговой таблицы собрана. Нажимаю одну кнопку и просто жду завершения.
![]() |
![]() |
![]() |
![]() |
Также были собраны результаты с видеокартой GeForce RTX 5080. К сожалению, эту видеокарту не удалось полностью нагрузить имеющимися тестами. Даже шейдерный тест в разрешении 1280x720 не полностью нагружал видеокарту. Впрочем, ChimbaBenchXPL никогда не ориентировался на тестирование современного компьютерного оборудования. Так что всё нормально.

Потом было обнаружено, что некоторые антивирусы ругаются на исполняемый файл, предназначенный для получения имени активной видеокарты в системе. Можно ли получить конкретное имя вируса, исходя из показаний «недовольных» антивирусов? Конечно же, нельзя: каждый антивирус выдает что-то своё, оторванное от реальности. Главное — чтобы выглядело устрашающе, даже если никаких вирусов на самом деле нет.
![]() |
![]() |
![]() |
Что может быть вредоносного в этих десяти строках исходного кода? Многие, вероятно, начнут искать причину в перечислении устройств или даже в строке вывода найденной видеокарты. Но мало кто догадается, что причина — в заголовочном файле windows.h, для обращения к которому нужно иметь разрешение с сертификатами. Ну а без обращения к windows.h не выйдет определить название используемой видеокарты таким вот простым способом.

Буду ли я лишать проект очень важных функций просто потому, что некоторые антивирусы ругаются на файл? Конечно, нет! Эти антивирусы даже не могут внятно обозначить «угрозу». Стоит ли подстраиваться под такие антивирусы? Разумеется, нет.
Однако у моего текущего подхода к определению оборудования действительно есть проблема: движок Godot 2.1 не способен исполнять файлы через OS.execute без вызова видимых окон консоли, а у меня уже целых 4 прослойки, каждая из которых вызывает своё окно на мгновение. Это неприятно.
Даже нашелся способ определения оборудования без запуска вспомогательных утилит, но в среде Windows XP работает он не лучшим образом. По крайней мере, это только начало.
![]() |
![]() |
В итоге получилось неплохо, но как оно поведёт себя в реальных испытаниях — уже совсем другой вопрос, нужно проверять и тестировать.
Эх, а ведь я хотел закончить с нововведениями...

Выглядит не очень изящно. К тому же движок Godot оказался не способен собрать результат безоконного исполнения таких скриптов, но мне совсем не нравятся всплывающие окна консоли при каждом обращении к утилитам в форматах .bat и .exe, поэтому я пробую собирать базовую информацию о системе через VBS-скрипты.

Однако на этом завершим данную часть статьи. Хотелось бы уже выпустить третью альфа-версию проекта, но над ним нужно ещё поработать. Об этом мы поговорим в следующей части.

Благодарю за внимание, больше интересных статей в блоге Hard-Workshop.
Лента материалов
Соблюдение Правил конференции строго обязательно!
Флуд, флейм и оффтоп преследуются по всей строгости закона!
Комментарии, содержащие оскорбления, нецензурные выражения (в т.ч. замаскированный мат), экстремистские высказывания, рекламу и спам, удаляются независимо от содержимого, а к их авторам могут применяться меры вплоть до запрета написания комментариев и, в случае написания комментария через социальные сети, жалобы в администрацию данной сети.




































































































































