В прошлый раз была разработана и выпущена первая версия бенчмарка под названием ChimbaBenchXPL. Поработал над фундаментальными проблемами игрового движка Godot Engine, сделал заготовку интерфейса пользователя и модуль тестирования. Так же успел проверить утилиту с видеокартой GeForce 9500 GT и остался не совсем доволен.
Хотя Godot Engine является весьма несостоятельным движком с массой проблем, начиная с низкой точности мировых координат и заканчивая неправильной интерпретацией времени при низком fps. Но именно на его основа построен мой новый проект под названием ChimbaBenchXPL. Если с вопиющей проблемой низкой точности мировых координат мы ничего делать не будем, так как для нас это не существенная проблема, то с другими проблемами нам придётся потанцевать.
Есть у нас тут шесть скриншотов тестового проекта при разном fps. Что примечательного можно заметить? Правильно, Godot Engine неправильно возвращает время, потраченное на вывод кадра. В обычных условиях время кадра никогда не превышает 133 миллисекунды. Что нарушает работу внутренней логики игр на основе движка Godot. Потому мне пришлось разработать функцию адаптивной настройки параметров движка, чтобы избежать столь глупой неточности. Всё же я разрабатываю бенчмарк.
Кто-то скажет, мол, это не движок несостоятельный, это просто у меня слишком старая версия! Но позвольте, Godot Engine 4.3 имеет точно такие же проблемы с временем кадра. Так что оправдания не помогут.
Именно потому нужно разрабатывать костыли, которыми прикрываем ужасы игрового движка Godot. Один из таких костылей я только что исправил в своём проекте. Добавил условие проверки для переменной текущего лимита fps. Иначе функция могла не срабатывать.
Далее работаю над интерфейсом. Кнопку настроек удалил. Вместо этого настройки перенесу в окно выбора тестов. Это позволит менять параметры прямо перед запуском тестов. Пока не знаю, как это реализовать, но было бы направление, а остальное уже пойдёт само.
Так же добавляю слой изображения для сравнения качества работы видеокарты и драйвера.
Однако следует отметить, что функция сверки изображения потребует фиксированного разрешения. Это, в свою очередь, накладывает ограничения на количество доступных размеров окна в настройках. Я не хочу делать бенчмарк слишком тяжёлым на десятки гигабайт, а скриншоты для сравнения в исходном качестве потребуют много места.
Теперь образцовый слой включается по нажатию кнопки. Как и задумывалось. Сюда же можно добавить краткую справку по использованию нового бенчмарка.
Кнопку начала теста было решено сделать отдельной от тестовых сцен. Но это порождает другую проблему. Пользователь может нажимать что угодно во время проведения теста, так что придётся блокировать лишние кнопки в процессе тестирования. Зато можно провести тест даже в главном меню. Если уж совсем тухлая видеокарта, что даже хуже самой младшей GeForce 6100.
Теперь кнопки интерфейса блокируются во время проведения тестирования. Разумеется, все лишние открытые окна внутри программы будут закрыты автоматически при начале тестирования, чтобы ничего не мешало процессу сбора результатов.
Так же автоматизировал переключение разделов меню, чтобы не получалось ситуаций, когда открыто одновременно несколько разделов. У меня нет развитой оконной системы, потому закрытие всех лишних окон при активации нужного пользователю — вполне правильное поведение. Будет неправильно, если пользователю придётся ковырять каждую кнопку в отдельности, чтобы закрыть все окна. Программа должна сама выполнять всю основную рутинную работу.
Теперь нужно разобраться с окном выбора тестов. Я хочу иметь разные тесты, но выбрать можно только один для загрузки. Кнопка с выпадающим списком выглядит как хороший выбор
Некоторые могут задаться вопросом: почему нет функций локализации приложения на разные языки? Но ответ прост: я не хочу усложнять проект такими вещами. Сообщество Open-Source в реальности оказалось бесполезным для существующих моих проектов. Ну а большинству пользователей вряд ли нужна локализация интерфейса. Это не сюжетная игра на несколько десятков часов геймплея.
Тем более разработкой проекта занимаюсь я один. Пока «диванные эксперты» возмущаются и необоснованно злорадствуют надо мной и моим проектом с открытым исходным кодом, в который не внесли даже одного полезного символа. Это, кстати, весомый повод закрыть исходный код нового проекта от сообщества. Особенно, если надумаю модифицировать сам движок Godot, чтобы не досталось такому «сообществу» ничего.
Некоторые из таких комментаторов, возможно, попытаются оправдаться: мол, они не злорадствуют, а просто критикуют, как я критикую Линуксы и открытые проекты. Но вот в чём нюанс: когда я критикую Линуксы и чужие проекты, я критикую по фактам за плохой пользовательский опыт и серьёзные проблемы в работе софта, подаваемого как нечто функциональное и рабочее, а не за то, как разработчики написали исходный код. Плевать, как написаны исходники, пусть хоть максимально убого, пусть хоть с идеальным блеском. Это всё ничего не стоит, если программа работает неправильно.
Потом всякие линуксоиды никак не могут понять, почему большинство качественного и функционального софта (в том числе игры) разрабатывается в виде закрытых проектов и в основном под Windows. Не помогут и вирусные лицензии вроде GNU GPL. Особенно учитывая, какие законодательные проекты пытаются проталкивать у некоторых крупных иностранных соседей по планете...
Поворчали и хватит. Вернёмся к разработке. Слева сделаю раздел с настройками, а справа будет кнопка выбора тестов и описание выбранного варианта.
А потом я решил поработать над настройками. Но Godot Engine, выпущенный в 2018 году, оказался не способен на элементарное MSAA сглаживание. Это всё, что нужно знать про качество и функциональность Open-Source софта в целом.
Я более чем уверен, что и под этой статьей отметятся некоторые «диванные эксперты» с предложениями писать код через нейронные сети. Но «диванных экспертов» не просто так называют диванными экспертами. Нейронные сети, как всегда, галлюцинируют и пишут бред даже от простых вопросов по движку. Впрочем, это не новость. Ещё в самом начале разработки проекта выяснилось, что нейронные сети непригодны для написания кода.
Какой бы ИИ я не пробовал, итог всегда один — лютые галлюцинации и бред, непригодный для реального применения в программировании. Ну или пригодный, но со значительными исправлениями от настоящего программиста с мозгами. Пусть я и не смогу полностью полагаться на выдачу нейронных сетей, но временами можно взять за основу галлюцинации и бред от ИИ, переработать и применить.
Нам придётся смириться с тем фактом, что движок Godot 2018 года выпуска оказался не способен на сглаживание MSAA. Я уже не говорю о том, чтобы с помощью нейронных сетей писать рабочий код, когда они порой не способны даже две переменные правильно определить. Ладно. Нам же проще от того. Меньше настроек — меньше забот.
Потому отложил возню с настройками и занялся экспериментами над загрузкой тестовых сцен. У меня есть отдельный узел, предназначенный для загрузки тестовых сцен в него, а это значит, что могу сделать функцию полной очистки узла от любого содержимого перед загрузкой следующих файлов. Пожалуй, управление узлом нужно перенести в сам узел, чтобы не разбрасывать функции как попало.
Не забываю и про графическое оформление проекта. Из подручных материалов с помощью графического планшета слепил иконку нового бенчмарка.
Получилось не очень выразительно. Нужно будет поработать ещё над иконкой. Хотя для варианта, набросанного на скорую руку, сойдёт.
Ну и приступаю к разработке первой тестовой сцены.
Хотя рано я взялся за создание тестовой сцены. Нужно ведь разработать функции адаптивной настройки интерфейса под размер окна.
Почему я не использую встроенные функции масштабирования Godot Engine? Правильно! Потому что это приводит к размытию элементов интерфейса и искажениям при изменении размера окна. Хотя это и не критично для проекта, но мне неприятно смотреть на искажённую графику.
Вот и первый тест новой функции для правильного масштабирования интерфейса.
Данный метод масштабирования требует перечисления всех масштабируемых узлов в массиве. Это сложно назвать недостатком, хотя оно им и является. Но более существенный недостаток в том, что данный метод использует коэффициент для масштабирования. То есть нельзя просто вписать нужный размер, до которого масштабировать. Всё. Дальше начинаются преимущества, выражающиеся в простоте кода. Так же простая проверка не позволяет установить размер окна, превышающий разрешение экрана.
Теперь я могу правильно масштабировать окно программы. Да, шрифты нужно масштабировать отдельно. Но этим займусь позже. Или не займусь. Пока что нет в этом необходимости.
Так же пришлось поработать над функцией установки образцового изображения для сравнения. На данный момент нужно держать по одному изображению на каждый тест в разрешениях 640x290 и 1280x580.
Не забываю и про оптимизацию. Изображения в формате Webp занимают явно меньше места, чем в классическом PNG.
Качество получаем такое же, как у оригинального PNG. Так что не вижу причин отказываться от сжатия Webp без потерь при хранении образцовых изображений. Jpeg при качестве 100 единиц весит значительно больше, но не даёт полного сходства с оригиналом.
Есть только одна неприятная проблема... Используемый Godot Engine выдаёт ошибку при попытке изменить параметры импорта Webp и Jpeg изображений.
Что-то я совсем забыл про окно About... Заодно доработал систему масштабирования. Теперь шрифты подстраиваются под размер окна.
Ещё создаю краткую справку при нажатии кнопки под названием Reference. Может, справка получилась далеко не лучшей, но не будем тратить на это много времени. А кому не нравится — вперёд и с песней! Сделайте лучше.
К сожалению, мне так и не удалось заняться первой тестовой сценой. Так как движок не имеет встроенных функций для определения имени процессора и видеокарты, мне пришлось самому заняться получением информации об оборудовании. Если с процессором вышло достаточно легко, то с видеокартой будет гораздо сложнее. Это надо будет оформить в отдельную функцию и аналогичное разработать для Windows.
Первый блин вышел комом. Ещё и какой-то лишний временный файл создался. Да и имя процессора неправильное. Но это может быть по вине виртуальной машины. Да и утилита Wmic хоть и базовая и стабильная, но Microsoft, уподобившийся линуксоидам в самых последних версиях Windows 11, сделал данную базовую утилиту необязательной. То есть её может и не оказаться в самых последних версиях Windows 11 по вине линуксоидного подхода к разработке ОС. Хотя я и не собирался поддерживать Windows 11, но реализуем немного иначе данный функционал.
Пришлось создать вспомогательные скрипты для получения информации о системе, так как встроенные средства Godot Engine оказались слишком сложны в использовании, чтобы добиться желаемого результата. Вот так мне приходиться прикручивать функционал к игровому движку 2018 года выпуска.
Далее мне понадобилось изменить исполняемый файл. С иконкой справилась утилита Rcedit, но с описанием файла возникли трудности. Не то чтобы нужно было особо менять строки исполняемого файла Godot Engine, но в описании указано, что это редактор, хотя на самом деле просто исполняемый файл без функционала редактора. Не хотелось бы вводить в заблуждение никого такой очепяткой в описании исполняемого файла.
Так что утилитой Resource Hacker исправляю кривые данные.
Хотя это и не обязательно было делать, но опыт лишним не будет. И нет, я не буду вносить изменения в свой набор разработки на основе Godot Engine 2.1.5 из-за такой мелочи.
Обязательно добавляю примеры в README файл. Просто чтобы если забуду, то не пришлось заново думать над правильным использованием инструментов.
Ладно. Мы реализовали определение имени видеокарты и процессора в среде Windows. Осталось разобраться с определением имени видеокарты в Linux. Вот тут начинаются танцы с бубном, потому что в Линуксах вечно всё не по-человечески. Самое простое, что можно сделать — это вывести Vendor ID и Device ID в чистом виде. Пока обойдёмся без таблиц преобразования ID в имена видеокарт. Я не хочу полагаться на линуксоидные утилиты по той простой причине, что они весьма ненадёжны.
Но Linux архитектурно своеобразен, так что даже при прямом доступе к информации об устройстве не факт, что вся необходимая информация окажется на положенном для неё месте. Так же стоит заметить, что на текущий момент выводится только первая видеокарта в системе. Если же в ПК несколько видеокарт, информация может оказаться неточной.
Можно, конечно, использовать lspci для определения имени видеокарты, но там такие длинные строки выдаёт, что такой вывод банально не влезет в окно приложения. Думаю, это можно оставить на тот случай, если не сработает основной метод получения ID видеокарты.
Так или иначе, базовый минимум я разработал. Даже разработал функционал, проверяющий, запущена ли программа в WINE или работает из под настоящей Windows. Теперь можно заняться первой тестовой сценой.
Нам нужно от чего-то оттолкнуться, и это будет модель импровизированной земли. Не забываю про оптимизацию, удаляя лишние вершины по краям геометрии, которая всё равно не будет видна особо.
На этот раз текстуру сохранил в формате Jpeg с потерями. Просто так меньше размер и выше детализация благодаря артефактам сжатия. Порой даже артефакты сжатия можно использовать себе на пользу.
Пустая поверхность не очень интересна, потому создаю дом на скорую руку.
Первая сцена практически готова. Она получилась тяжелее ожидаемого. Нужно будет проверить производительность с очень слабой GeForce 6100 и подкорректировать при необходимости.
Тут же проверяем работу функции сравнения качества изображения. В идеале пользователь не должен ничего заметить при нажатии кнопки Reference.
Но в реальности можно прекрасно увидеть, как халтурит драйвер Mesa Llvmpipe с фильтрацией текстур. Изображение заметно не соответствует оригинальному.
Пришло время проверить на реальном оборудовании.
Увы. GeForce 6100 выдала слишком яркое изображение. Похоже, есть проблемы с обработкой источников освещения. Но в остальном работает без проблем. Имеем 17 fps со столь слабой видеокартой из старой серии 2004 года выпуска.
Процессор осилил всего 4 кадра в секунду через драйвер Mesa. Проблемы с фильтрацией текстур на месте.
Дальше проверяем Radeon X800 GTO из серии видеокарт 2004 года выпуска. Получаем 80 Fps с чёрным окном. Удивительно, что интерфейс работает без проблем. Однако имя видеокарты определяется неправильно. Нужно будет серьёзно переработать функционал определения GPU.
На очереди AMD Radeon HD 4870. Первый старт с артефактами. У меня есть две разные HD 4870 и обе выдали одинаковые артефакты при первом запуске. GPU Caps Viewer говорит про 1 гигабайт памяти, GPU-Z говорит про 512 мегабайт. С драйвером Catalyst 9.2 имеем OpenGL 2.1.
К сожалению, HD 4870 показала ровно такое же чёрное окно, как и X800 GTO. А это значит, что проблема не в старой видеокарте, как я раньше считал, а в драйверах AMD, у которых неважная реализация OpenGL API.
Устанавливаю Catalyst 13.4. Наверное, места не хватило на диске для установки панели управления. К сожалению, данный драйвер невозможно использовать со старой X800 GTO. Это печально, потому что подходящие драйверы для X800-X1000 серий идут в комплекте с поломанными и кривыми графическими API вроде OpenGL, потому что ATi/AMD не осилили разработку нормальных драйверов.
С новым драйвером 2013 года древний OpenGL 2.1, наконец, заработал, как положено. Только процессор оказался слишком слаб. Итого имеем 431 fps с видеокартой, нагруженной на четверть. А ещё я обнаружил артефакты в виде отдельных светящихся пикселей. Похоже, HD 4870 оказалась не совсем исправной.
Ради интереса достал старую GTX 570. На обслуживании такой видеокарты можно разориться. Но какой же красивый кристалл.
С драйвером 2012 года от NVIDIA уже имеем поддержку OpenGL 4.0 и OpenCL 1.1 в среде Windows XP. У видеокарт AMD в принципе отсутствует поддержка OpenCL под Windows XP. Да и стоит ли говорить о том, что драйвер NVIDIA 2012 года работает как с GeForce 6100, так и с GTX 570, когда AMD бросила поддержку Radeon X800 ещё в 2010 году.
Запускаем тест и получаем 777 fps, что почти в 2 раза больше, чем могла осилить AMD Radeon с тем же самым процессором. О чём это говорит? Правильно: Видеокарты NVIDIA менее требовательны к производительности процессора.
К качеству графики претензий нет.
На этом можно закончить работу над текущей версией бенчмарка под названием ChimbaBenchXPL. Хотя у нас ещё много недочётов и проблем, но оставим это на следующую версию бенчмарка. Осталось загрузить исходный код текущей версии проекта в репозиторий GitHub.
Отлично. Вторая Alpha версия бенчмарка под названием ChimbaBenchXPL готова.
https://github.com/Shedou/ChimbaBenchXPL
Теперь можно и тестированием заниматься. Заодно будет опыт реального использования, а там и недостатки будут выявляться для исправления и доработки.
Благодарю за внимание, больше интересных статей в блоге Hard-Workshop.
Читайте далее на сайте
AMD представила настольные процессоры Ryzen AI 400 с графикой RDNA 3.5 и нейронными блоками XDNA 2