Недавно был разработан и выпущен ChimbaBenchXPL версии Alpha-2. После бенчмарк был протестирован в реальных условиях, используя Windows XP, 7 и 10, а так же пять Линуксов. При этом были выявлены разнообразные проблемы и недостатки проекта, требующие исправлений и доработки.
Прежде всего, хотелось бы разработать новые тесты для нагрузки видеокарт. Совсем недавно я отремонтировал и протестировал GeForce 8600 GT. Мне пришлось использовать сторонние программы для нагрузки шейдерных ядер, потому что мой тест оказался не способен это сделать.
Разумеется, для полной нагрузки основных вычислительных ядер GPU потребуется работа с шейдерами. А так как я вообще ничего не понимаю в шейдерах, я попытался обратиться к ИИ за помощью. Стоит ли говорить, что нейронная сеть постоянно галлюцинировала, ошибалась и оказалась абсолютно бесполезна в реальных задачах. Впрочем, ничего нового. Как показывает практика, ИИ только в фантазиях сможет заменить настоящих программистов. ИИ не может заменить даже меня, хотя и являюсь весьма посредственным программистом.
Было потрачено много времени на взаимодействие с ИИ. Однажды даже удалось просадить мобильную RTX 3060 до 1330 МГц по частоте GPU в нагрузке при ограниченной мощности. Выглядит оно странно, но мы не гонимся за красотой, нам важно нагрузить видеокарту любой ценой.
Однако меховой кубик от стороннего приложения был способен опустить частоту GPU до 1230 МГц при ограниченной мощности в 80 Вт. Именно к такой нагрузке мне нужно стремиться.
Сколько бы я не танцевал с нейронными сетями, постоянно исправляя выдаваемый исходный код, мне не удавалось получить желаемый результат.
В итоге было решено набросать всякого в графическом редакторе шейдеров.
Визуально получалось намного лучше, чем выдавали нейронные сети, особенно учитывая, что я не разбираюсь в разработке шейдеров.
Моя задача — сделать сложный шейдер, способный нагрузить видеокарту.
И вот я близок к тому, чтобы достичь уровня нагрузки мехового кубика. Пусть это выглядит как полная каша и неразбериха, но оно работает.
Спустя некоторое количество экспериментов мне удалось «уронить» частоту GPU до 1305 МГц в разрешении 640x360.
Это очень близко к тому, чего я хотел достичь. При этом уложился всего в 86 вызовов отрисовки.
Почему я не возьму готовый пример из библиотеки ассетов движка Godot Engine? Зачем танцую с бубном? Правильно, потому что репозиторий в котором хранился пример, давно мёртв вместе с файлами. Да и не факт, что умерший в репозиториях проект был бы полезен. Такая же судьба ждёт любой зависимый проект, который не распространялся автономными архивами или автономными установочными пакетами.
Дальше хотелось бы поработать над графическим интерфейсом программы, но тут в комментариях обнаружилась толковая идея. Ведь у меня нет ни одного теста, способного заполнить память видеокарты.
Но сначала нужно навести порядок в проекте. Переименовал сцену Fur в Shader. Пусть я и пытался изначально создать что-то пушистое и красивое, но не с моими навыками в работе с шейдерами такое делать.
Теперь нужно поработать над графическим интерфейсом пользователя. Потому что не всегда понятно, что и где нажимать. Если бы я был типичным разработчиком от мира Open-Source и Linux, я бы так и оставил всё. Ведь и так же всё работает. Зачем делать более понятный интерфейс?
Так как моя система масштабирования интерфейса работает слишком хорошо, я вывел текущий размер окна перед разрешением экрана в верхней строке с информацией. Потому что бенчмарк выглядит практически одинаково при разных разрешениях. Так же думаю о том, чтобы оставить страницу с выбором тестов и настроек изначально активной при запуске программы. Просто небольшое улучшение пользовательского опыта.
Попутно добавил ещё одну экспериментальную сцену.
Но проблема в том, что Godot Engine не освобождает память видеокарты после переключения сцены. Таким образом, возникает своеобразная утечка, когда память заполняется одной и той же текстурой многократно. Пока непонятно, как решать эту проблему игрового движка Godot, но с этим нужно что-то делать.
Как бы я не танцевал с бубном перед удалением предыдущей сцены, старые текстуры всё равно застревали в памяти видеокарты. И хотя она иногда освобождается от старых текстур, но не полностью. Однако, объём занятой памяти и до бесконечности не увеличивается. Если это не драйвер видеокарты подтирает остатки, то выходит, что движок Godot всё же управляет памятью, только делает это бездарно.
Мне пришлось создать в каждой сцене специальную функцию очистки, вызываемую перед уничтожением сцены. Потому что движок Godot не выполняет свои обязанности в полной мере по освобождению памяти от неиспользуемых ресурсов. Так я пытаюсь вручную очищать всё лишнее, иначе программа может «сожрать» слишком много памяти видеокарты. Правда, ничего из этого не вышло. А потом удивляются некоторые, почему движок Godot называют несостоятельным.
Как разработчик я ожидаю, что движок сам будет очищать память после удаления лишних ресурсов. Но память очищается от мусора как попало и не полностью. Это действительно серьезная проблема, потому что она мешает разработчику оценивать и управлять потреблением ресурсов системы. Слишком много мусора движок хранит в памяти. Но эту проблему я оставлю как есть, ведь её устранение может оказаться слишком затратной задачей, которая, возможно, потребует внести модификации в сам движок.
Тест, заполняющий память видеокарты, будет весьма сомнительным, но без дополнительного тестирования на отдельном компьютере выбрасывать ничего не будем. Сначала нужно проверить, будет ли эта проблема с заполнением памяти видеокарты мешать прочим тестовым сценам. Если нет, то не вижу причин отказываться от реализации тестовых сцен, предназначенных для заполнения памяти.
Для удобства работы над тестами заполнения памяти GPU была разработана вспомогательная таблица с данными о жирности текстур. Одна текстура с размером сторон 1024 занимает всего 8 мегабайт памяти. Текстура размерами 2048 уже занимает 24 мегабайта. А вот одна текстура размером 4096 занимает уже внушительные 88 мегабайт. Разумеется, это с использованием Mip Maps, когда большая текстура уменьшается до маленьких размеров в памяти видеокарты для лучшей масштабируемости.
Хотя видеокарты NVIDIA способны переварить текстуры размером до 32768x32768, но мы остановимся на размере 16384x16384, потому что это предел для видеокарт Radeon и движка Godot. Единственная проблема — это объём занимаемой оперативной памяти при загрузке больших текстур. У старых компьютеров может не быть столько оперативной памяти. Но тут опять же нужно лезть в потроха движка и вносить модификации, чтобы работал иначе. Если я буду этим всем заниматься, мне просто некогда будет разрабатывать свой проект.
Хотя планировалось использовать процедурно сгенерированные текстуры, но было решено перейти к классическому методу хранения отдельными файлами. Да, пара функций в виде исходного кода занимают на порядки меньше места, чем графические файлы с текстурами, но это не критично с учетом оптимального выбора формата и содержания текстур. Тем более, загрузить файл многократно быстрее, чем сгенерировать текстуру, используя мощности процессора.
Комбинируя разные размеры текстур, мне удалось сделать тест, заполняющий 120 мегабайт памяти в разрешении 640x360. В разрешении 1280x720 занимает около 133 мегабайт памяти. Небольшое переполнение выходит. Впрочем, этот тест не для проверки производительности, а для заполнения памяти видеокарты. Такое же нужно проделать для видеокарт с объёмом памяти 256 мегабайт, 512 мегабайт и так далее. Немного памяти обязательно оставляю свободной под нужды операционной системы.
Итого было создано пять новых тестов для заполнения памяти видеокарты до двух гигабайт. Конечно, лучше воспользоваться специализированными утилитами для проверки памяти видеокарты, но это тоже может оказаться полезным для быстрой проверки работоспособности без применения сторонних утилит.
Теперь программа встречает пользователя сразу окном настройки и загрузки тестовой сцены. И я тут подумал, что нет смысла разрабатывать какую-либо справку в виде фонового изображения. Но это не точно.
Теперь нужно разобраться с проблемой отображения имени видеокарты. Мне очень не хотелось, но придётся отказаться от скриптов в виде BAT файлов. Скрипты позволяли руками прописать имя видеокарты, подаваемое в бенчмарк, если она определялась неправильно. Но скомпилированная утилита должна работать гораздо надёжнее, чтобы не приходилось руками делать какие-то правки со стороны пользователя.
Только не знаю, как оно отработает в ситуации при наличии нескольких видеокарт. По крайней мере, это работает при запуске через WINE. А что насчёт старого компьютера?
В тестовом компьютере сейчас установлена модифицированная видеокарта GeForce 8600 GT, и в среде Windows XP пришлось настроить драйвер так как он сбрасывается при смене видеокарты.
Первым делом проверяю безумный шейдерный тест. Если честно, я ожидал меньшей производительности. Но меховой кубик всё же оказался мощнее за счёт большей нагрузки на шину памяти. И да, видеокарта правильно определилась благодаря новому скомпилированному файлу, что специально предназначен для получения имени активной видеокарты.
Ну а со сценами, нагружающими память GPU, получилось неоднозначно. Так как движок Godot весьма паршиво управляет памятью, мне не удалось сходу загрузить всю память, перебирая тесты с малого. Просто оставалось много мусора от предыдущих сцен, и драйвер видеокарты сбрасывал излишки в ОЗУ. Ну а самый тяжёлый вариант вообще приводит к вылету.
Зато если запустить сразу подходящий вариант, не перебирая все остальные, то вполне неплохо удаётся заполнить память видеокарты. В любом случае это получился сомнительный функционал по вине движка Godot.
А что до сцены с шейдерами, то тут следует установить одну из GeForce 9500 GT с заводской системой охлаждения и посмотреть, насколько высокие температуры смогу получить.
Вставляю GeForce 9500 GT и на этот раз запускаю Windows 7. Это далеко не худшая система охлаждения размером в один слот, но не для 50+ Ватт мощности...
Вот и причина вылетов при попытке загрузить самый тяжёлый текстурный тест. Старые видеокарты просто не поддерживают размер текстур выше, чем 8192x8192. Под меховым кубиком чип разогрелся до 75 градусов.
Имя видеокарты определено правильно. В остальном ничего хорошего. Шейдерный тест, конечно, разогрел видеокарту до 65 градусов, но должен был разогреть минимум до 70 градусов. Отправляем на переработку. Хотя этот тест и нагружал RTX 3060 до сильного снижения частоты, близкой к уровню мехового кубика, но старая видеокарта не так хорошо разогревается. Видимо, нужно увеличить нагрузку на шину памяти и прочие части GPU.
Похоже, я просто отключил и забыл вернуть обратно одну важную функцию в скрипте, которая является необходимой для повышения нагрузки на видеокарту.
Это уже немного лучше, но всё равно сильно не дотягивает до желаемого уровня. Оно неплохо нагружало RTX 3060, но весьма посредственно нагружает GeForce 9500 GT.
В итоге я снова взялся за ковыряние шейдеров. Только желаемого уровня нагрузки так и не получается добиться. Может я и не разбираюсь в разработке шейдеров, но что-то мне подсказывает, что отчасти виноват и движок Godot.
Попробую набросать простенькую программу на C++. Вдруг получится сделать то, что на движке Godot я не могу реализовать уже несколько дней... В итоге простой шейдер оказался ещё слабее в плане нагрузки на видеокарту. Грузить нужно не только шейдерные ядра, но и контроллер памяти, иначе толку мало. Но да, нагрузка получилась гораздо более чистая и менее требовательная к процессору, чем у движка Godot.
Более сложный шейдер нагрузил и контроллер памяти, но упала нагрузка на GPU. Теперь уже явно процессор стал узким местом...
Хотя я научился более осознанно работать с шейдерами и даже заставил мобильную RTX 3060 опустить частоту ниже 1300 МГц. Но достаточно ли этого, чтобы нагрузить 9500 GT? Тут основная проблема в том, что я использую при разработке программы Linux, вместо операционной системы, потому не имею обширных возможностей, как в Windows, для мониторинга всевозможных датчиков. Я просто не могу понять, как сильно нагружается шина памяти у видеокарты под управлением Linux.
Ну а так как у меня установлен обычный официальный драйвер видеокарты NVIDIA, а не полноценный CUDA Tool Kit, то и инструментов от NVIDIA у меня особо нет. Да и муторное это дело. Гораздо полезнее и нагляднее было бы просто узнать процент использования контроллера памяти ГП. Но, увы, это же Linux.
Получилось у меня что-то среднее между меховым кубом и простым бенчмарком.
Чтобы отвлечься, я поработал над текстурными тестами. Снизил потребляемое количество памяти GPU и один тест превратил в проверку возможностей видеокарты. В идеале текстурные тесты следовало бы процедурно генерировать, дублируя объекты с текстурами. Так удалось бы достичь наилучшего распределения памяти и минимального сброса в ОЗУ при переполнении. Но Godot Engine настолько плохо дублирует объекты, что буквально зависает в момент создания каждой уникальной копии.
Текстурные тесты определённо буду дорабатывать в будущем. Ну а что до шейдеров, то было решено создать альтернативную сцену для экспериментов с нуля, учитывая накопленный опыт.
Но об этом поговорим уже в следующей части.
Благодарю за внимание, больше интересных статей в блоге Hard-Workshop.
Читайте далее на сайте
Linux обеспечил более высокий fps на фоне Windows 11 в Crimson Desert и других играх на RX 6700 XT
В Ubuntu Linux минимальные требования к ОЗУ выросли до 6 ГБ
Представлена предварительная версия Xbox PC Remote Tools для разработки игр на удалённых устройствах
В приложении Xbox для игровых КПК под управлением Windows 11 появился виджет с настройками дисплея