Гайд по адаптивному разгону процессоров Intel Core 12-го поколения
Разгоняем 12900K до 5.6 ГГц для повседневного использования
30 ноября 2021
Обновлено 31.12.21
Разгон процессоров с использованием статичного напряжения мертв — разгон по всем ядрам позволяет увеличить производительность в многопоточных нагрузках, но про однопоток и игры можно забыть — без турбобуста отдельных ядер до более высоких частот производительность только уменьшится. Так еще и современные функции по энергосбережению перестают работать в полную силу, и постоянно высокий уровень напряжения независимо от типа нагрузок на пользу процессору не идет. На процессорах Intel уже несколько поколений доступа функция адаптивного разгона, которая позволяет оптимизировать отдельные значения напряжения/частоты для достижения более высокой частоты ядер как в многопоточных, так и однопоточных нагрузках с сохранением абсолютно всех современных фишек и оптимизаций по энергосбережению.
Однако процесс разгона и стабилизации напряжения на процессорах 9, 10 и 11 поколений был далеко не самый простой, но с приходом 12-го поколения процессоров все изменилось — выжать максимум из Alder Lake значительно проще и на стабилизацию разгона уходит всего несколько часов — можно за 1-2 вечера управиться, если делать все грамотно и по порядку. Как — именно этому я вас и научу.
Полный список программ, используемых в гайде:
- HWInfo — программа для мониторинга сенсоров
- Cinebench R15 — бенчмарк рендеринга Cinema 4D, использующий SSE-инструкции
- Cinebench R23 — бенчмарк рендеринга Cinema 4D, использующий AVX2-инструкции
- OCCT — набор бенчмарков, стресс-тестов и мониторинга
- y-Cruncher — набор бенчмарков и стресс-тестов CPU и памяти, нам интересен тест n32, который можно использовать, выбрав пункты меню в последовательности 1 — 8 — 15 — 0
- Stockfish — шахматный движок, использующий AVX2 инструкции и предоставляющий отличный стресс-тест CPU. Используется в паре с «доской», как Tarrasch Chess GUI
- x264 — стресс-тест системы на основе x264 видео-энкодера
Подготовка
Во-первых, нам нужна программа для мониторинга температур, напряжений и энергопотребления — лучшим выбором будет HWInfo64, а для начального тестирования будет достаточно Cinebench R15 и Cinebench R23 — понадобятся обе версии программы, так как R15 использует только SSE инструкции, а R23 добавляет AVX2 — напряжения, температуры и энергопотребление будут различаться, а значит и стабильность системы. Также мы будем использовать OCCT для проверки одноядерного разгона.
Далее — настроим BIOS для нашего удобства. Чем дороже и лучше у вас материнская плата, тем больше функционала настройки биоса будет присутствовать. Во-первых, нам интересно снять всевозможные лимиты энергопотребления и напряжения в окне Internal CPU Power Management. По идее, настройка “авто” должна их все отключать, но для избежания потенциальных проблем, багов и некорректного поведения BIOS лучше выставить все ручками в максимум — прописываем 999999 в каждое окно и максимальная отметка выставляется автоматически.
Дополнительно можно выставить пару защитных функций — установить максимальную температуру ядра/пакета на 100/105 градусов и максимально допустимое напряжение IA VR Voltage Limit 1500-1700.
Дальше переходим в окно VRM и выставляем настройки “под разгон”: датчик напряжения — Die Sense (самый точный), 120-140% макс напряжение, можно поднять на максимум герцовку VRM (чем дороже плата, тем выше — у меня 800 кГц), автоматически задействовать все фазы, отключить Spread Spectrum и установить время отклика на Extreme.
Если у вас этих настроек нет — переживать не стоит, практика показывает, что работающая на “экстремальных” настройках система питания позволяет легче стабилизировать разгон, но речь идет о паре процентов разницы.
Дальше мы перейдем в меню TVB или Thermal Velocity Boost, чтобы включить Thermal Velocity Boost Voltage Optimizations = Enabled и отключить дополнительный буст Overclocking TVB = Disabled.
Так как я показываю все настройки на примере материнской платы ASUS, у вас на Гигабайтах и МСИ функционал будет разложен по другим меню — читайте названия, читайте описание, а если и так не получается найти — воспользуйтесь поиском, который обычно забинден на F9.
Настройка LLC
Самый важный и трудоемкий этап — правильная настройка LLC. LLC или Load Line Calibration — это механизм компенсации напряжения, который удерживает колебания напряжения в определенном регионе. Подробнее почитать о принципах работы LLC и настройки, которую мы проводим, лучше на технических ресурсах — мои знания не позволяют корректно и полноценно разобрать вопрос. Грубо говоря — настройка LLC контролирует, как сильно VRM будет компенсировать потенциальные просадки напряжения во время изменения нагрузки на процессор. Расслабленный режим LLC будет допускать большие просадки напряжения и не сильно перегружать процессор во время компенсации, а более агрессивный режим работы LLC будет более агрессивно компенсировать просадки напряжения перенапряжением процессора. Наша цель подобрать режим работы LLC и установить сопротивление материнской платы на отметки, при которых просадки напряжения не будут приводить к нестабильности, а компенсация не будет перегружать и перегревать наш процессор.
На этом этапе мы обратимся к V/F Curve — функционалу кривой напряжения/частоты процессора. На более дорогих материнских платах функционал V/F полностью открыт в BIOS, а обладатели бюджетных материнских плат должны будут установить Intel XTU, чтобы проверить свою кривую работы V/F, как нарисовано на скриншоте. Нажимаем кнопку и записываем напряжение 6 V/F точки — в случае i9-12900K это 4800 МГц.
На моей материнской плате V/F кривая открыта для просмотра в BIOS, поэтому использовать XTU мне не нужно. V/F кривая различается между процессорами ввиду производственных погрешностей — одни процессоры требуют больше напряжения для определенной частоты, другие — меньше. То значение, которое вы видите в BIOS или XTU — это напряжение, которое будет требовать процессор на частоте 4800 МГц — в моем случае 1.199 вольт.
Теперь мы выбираем пункт разгона Per Core и выставляем все ядра на х48 — больше ничего трогать не нужно. Идем в меню LLC и выставляем LLC выше на один уровень “рекомендуемого для разгона” режима — в случае ASUS это LLC5, после этого идем в меню настройки питания и выставляем AC и DC сопротивления на определенную отметку, скажем, 0.7 миллиом, где AC = DC. Загружаем систему, включаем HWInfo и Cinebench R15. Нам интересен датчик vcore или vout, который максимально точно рапортует о напряжении процессора со средней погрешностью в районе ~20-40 милливольт. Учитывайте, что на дешевых материнках этот датчик может давать совсем неточную информацию — ориентируйтесь и на энергопотребление, и на тепловыделение.
Что мы хотим видеть: под нагрузкой датчик должен рапортовать напряжение максимально приближенное к 1.199 вольт или вашей точке кривой V/F, соответствующей 4800 МГц, а в простое не превышать 1.26-1.27 вольт. Если наше напряжение под нагрузкой выше 1.19 вольт, то мы опускаем значения сопротивления — скажем, с 0.6 до 0.5, если значительно ниже — поднимаем сопротивление. Идеальная отметка — это когда напряжение во время прогона R15 прыгает между 1.18-1.19, а в простое процессор не превышает напряжения в 1.26-1.27 вольт.
Более агрессивные режимы работы LLC позволят добиться уменьшения региона колебания, но при этом процессор будет банально перегреваться под нагрузкой — нам этого не нужно. Разница в 0.06-0.08 вольт между отметкой нагрузки и спайками в простое более чем комфортны. Чтобы убедиться, что мы нашли правильное значение LLC и датчик нас не обманывает, включим функцию CEP или Current Execution Protection в меню настроек напряжения BIOS и снова прогоним R15.
Точный принцип работы CEP еще не известен — это новый функционал процессоров Alder Lake, о котором Intel по какой-то причине пока не хочется распространяться. Понятно только то, что CEP предлагает новый алгоритм защиты от пере/недо напряжения процессора при большом vdroop, когда LLC слишком сильно проваливает напряжение. Если процессор будет недополучать напряжения из-за большого vdroop, CEP начнет незаметно снижать производительность процессора, что будет явно видно в результатах Cinebench R15. Если включение CEP привело к падению производительности, то мы увеличим значения сопротивления AC/DC — скажем, с 0.5 до 0.53 и проверим снова. Даже с включенным CEP можно понизить сопротивление AC/DC, чтобы уменьшить напряжение процессора под нагрузкой — CEP поможет найти порог стабильности. Рекомендую опустить отметку до уровня на ~30-50 миливольт ниже отметки V/F 6, что в моем случае соответсвует ~1.140 вольт. После этого отключаем CEP и переходим к следующему этапу.
Поиск стабильности all-core
Правильно настроив LLC, мы обрели контроль над напряжением процессора и можем точно высчитать, какое напряжение он будет получать на какой частоте. Понимая, что хочет процессор, нам будет проще стабилизировать разгон. Начать рекомендую с отметки в 5.1 ГГц — с этим справится практически любой 12900K под качественной водой. Если не тянет — 5.0 ГГц. Рассчитать напряжение для точки 5.1 ГГц поможет формула (V @ 5.3) — (V @ 4.8) / 5 = мв 1 шага, где V — напряжение точки кривой V/F в BIOS или XTU. Андервольт для 5.1 мы начнем производить при помощи понижения напряжения на точке 5.3, однако стоит помнить, что 5.3 ГГц нам будут нужны для последующего разгона — тут и начнем искать стабильность.
Выставляем Per Core OC на P-ядра, ставим модификатор x53 для нагрузок 1-7 ядер и x48 для 8 ядер. Можно сразу выставить небольшой отрицательный оффсет в меню V/F Curve для точки V/F 7 на -0.040 вольт. Меняя оффсет на точке V/F 7 ОБЯЗАТЕЛЬНО выставлять такой же оффсет точкам V/F 8, V/F 9 и V/F 10 иначе компьютер просто не включится! Переходим в Windows, запускаем OCCT и выставляем следующие настройки:
В этом тесте каждые 5 секунды будут нагружаться 2 ядра и 4 потока по кругу. Прогнали 15 минут SSE, делаем то же самое для AVX2 инструкций. Стабильно? Уменьшаем напряжение на точках V/F 7-10. Нашли нестабильность — увеличиваем на 10-20 милливольт и переходим к следующему этапу — комфортной частоты для тяжелой нагрузки.
Выставляем P-ядра на х51 и E-ядра на х40. Больше ничего менять нам не нужно, мы заходим в систему и начинаем гонять Cinebench R15 — скорее всего, на дефолтном напряжении для 5.1 ГГц вы увидите 100 градусов на процессоре и тротлинг частот — теперь мы начинаем андервольтить CPU в поисках стабильности и комфортных температур. Обладатели материнских плат ASUS могут воспользоваться OC Tool, который позволяет андервольтить V/F кривую прямо из Windows, а остальным придется самим перезагружать компьютер, применяя андервольт.
Учитывайте, что кривая V/F может идти только вверх, а значит опустив напряжение до -145 милливольт на V/F 6 мы не сможем идти ниже, т.к. V/F 5 будет = V/F 6 и дальнейший андервольт применяться не будет. Так как мы уже опустили значение V/F 7, скорее всего наша стабильность будет где-то на максимуме отрицательного оффсета для точки V/F 6 — ставим -0.100 вольт и тестируем стабильность при помощи Cinebench R15 и R23 — SSE и AVX2 инструкции требуют разного напряжения и стабильность может хватать для одного типа нагрузок и не хватать другому. Если выставили максимально возможный отрицательный оффсет V/F 6, а процессор все еще стабилен — можно дальше уменьшить сопротивление материнской платы через уменьшением значений AC_LL и DC_LL шагом в 0.01. Нашли нестабильность — увеличили напряжение с запасом в ~20 милливольт. После этого рекомендую прогнать более серьезные тесты на стабильность разгона — OCCT Large AVX2 Extreme, Stockfish, y-Cruncher n32 или x264 Benchmark.
Дальше я рекомендую погонять Cinebench R23 минут десять, чтобы убедиться, что температуры находятся на комфортной отметке и поиграть с разгоном E-ядер. Даже самые лучшие E-ядра гонятся лишь до 4300 МГц, посему среднестатистический оверклок будет в регионе 4000-4200 МГц. Нестабильность Е-ядер сразу проявится в Cinebench R23 в виде ошибки — на этом этапе следует стабилизировать частоту E-ядер. Так как они делятся на два блока из четырех ядер, функцией Specific E-Core можно разделить блоки, чтобы один работал на 4100, а другой на 4000. На моем процессоре удалось стабилизировать E-ядра на отметке х41.
Если R23 все-таки вас перегревает, можно увеличить vdroop путем дальнейшего уменьшения сопротивления AC/DC: скажем, с 0.5 до 0.47 и так далее, пока не потеряем стабильность. Рекомендую настроить систему так, чтобы продолжительный тест при помощи R23 не перегревал процессор выше ~92 градусов, т.к. для стабилизации разгона мы будем применять более тяжелые тесты, которые нагреют его серьезнее.
Разгон Single Core
На следующем этапе мы будем разгонять ядра для достижения более высокого буста в однопоточных нагрузках. Для этого мы посмотрим на VID отдельных ядер прцоессора. В материнсках платах ASUS этот функционал скрывается за окном AI Features. Чем выше VID ядра, тем оно хуже. Запоминаем какие и сколько ядер у нас самые лучше и какие самые худшие. Идем в окно Specific Core и задаем максимальный модификатор х56 для четырех лучших ядер, х55 для двух менее хороших и х54 для двух самых плохих.
После этого ставим Per Core 56х4, 55х6, 54х7 и 51х8 на главное странице, включаем Adaptive Voltage в меню настройки напряжения, в графу Additional Turbo Voltage ставим значение в регионе 1.45 вольт, после этого добавляем напряжения для последней точки V/F — без дополнительного турбо процессор не будет давать напряжения больше, чем значение 5.3. Считаем напряжение Turbo минус V/F 7 = это наше значение для V/F 11 с оффсетом +. Переходим к настройке Thermal Velocity Boost.
Thermal Velocity Boost
TVB или Thermal Velocity Boost позволяет добавить до 200 МГц сверху к частоте процессора, если позволяет система охлаждения. Мы будем пользоваться отрицательным оффсетом, когда исходные значения будут на 200 МГц выше стандартного, а TVB будет их автоматически понижать. 5600 МГц для четырех P-ядер будет применяться в выставляемых нами условиях. Оффсет -1 = -100 МГц. Для температур высоко идти не рекомендую, лучше выставить 65 градусов -1 и 75 градусов -1 для 1-4 ядер, 5-7 60 градусов -1 и 70 градусов -1. Для 8 ядер мы выставляем оффсет 0 и любые температуры, так как для нагрузки на все ядра мы не будем пользоваться TVB.
Заходим в виндовс и начинаем катать R23 тестом для одного ядра. Нестабильно — повышаем V/F 11 и Additional Turbo Voltage. Учитывайте, что вы не будете держать 5.6 ГГц на постоянке — любая случайная нагрузка на P-ядра, когда нагружены больше четырех ядер и вы упадете до 5.5 ГГц. Нагрелись выше установленной отметки TVB — получите -100 МГц, а потом еще -100. Чтобы получить реальные 5.6 ГГц на постоянку, нужно иметь качественную кастомную систему охлаждения, но при нашем разгоне стабильно держать 5.4-5.5 ГГц вполне реально в повседневных нагрузках.
Стабильно в Cinebench? Возвращаемся к OCCT и ставим следующие настройки:
Как и раньше, используем и SSE и AVX2 инструкции. Тест будет по очереди нагружать по 1 ядру и 1 потоку и хорошо позволяет оценить стабильность во время транзиентных скачков напряжения. Не стабильно — увеличиваем положительный оффсет напряжения для точки V/F 11 и Additional Turbo Voltage шагами в 10 милливольт. Стабильно? Пробуем опустить эти же значения шагом в 10 милливольт.
Финальные тесты стабильности
Для тестов стабильность я рекомендую использовать два дополнительных теста к тем, что мы уже использовали: это шахматный движок Stockfish, который помогает анализировать ходы — он использует AVX2, нагружает все ядра и потоки процессора, а также реально используется шахматистами. Использовать его нужно в паре с приложением доски для игры в шахматы. Второй тест — это x264 рендерер, бенчмарк которого можно найти здесь. И тот, и другой серьезно нагрузят вашу систему и протестируют ее стабильность. Т.к. Оба теста нагружают абсолютно все ядра, стабилизируем разгон при помощи уменьшения андервольта для V/F = 6.
Если процессор перезагружается и зависает в играх и других легких нагрузках — увеличиваем оффсет точки V/F 11 и на то же значение Additional Turbo Voltage.
Далее выставляем Ring Ratio на тот же уровень, что и максимальный буст E-ядер, в моем случае — х41, это практически гарантировано стабильная отметка. Ring Down = Enabled, Minimum = 41, Maximum = 41. С отключенными E-ядрами Ring можно поднять на более высокую отметку, чем со включенными. К счастью, кэш больше не требует высокого напряжения, поэтому париться о стабильности или перегреве процессора при разгоне Ring не стоит — просто выставляем на уровень E-ядер и забываем.
Дополнительно повысить стабильность Ring позволяет небольшое увеличение PLL Ring Voltage в регионе от 1.095 до 1.15. Это позволит поднять частоту кэша на 100-200 МГц сверху. Кэш проще всего тестировать при помощи y-Cruncher, стресс-тестом n32 — 20 минут хватит, чтобы проявилась нестабильность. Дополнительным тестом будет поведение компьютера в простое, когда вы ничего с ним не делаете, а Windows зависает. Тут уже придется опустить кэш на 100 МГц.
Хвастаемся бенчмарками
Как я писал в обзоре разогнанного i9-12900K, основным ботлнеком на сегодняшний день является память, и в играх прирост производительности от разгона частоты процессора не всегда заметен. Но посмотрите на эти цифры в бенчмарках! Больше 900 очков сингл треда в CPU-Z, 2175 очков в Cinebench R23 — вах! И обязательно маме расскажите, какими классными вы стали оверклокерами.
В следующих материалах мы поговорим о процессоре Intel Core i5-12600K, рассмотрим его производительность в паре с DDR4 и DDR5 памятью и оценим его разгонный потенциал, чтобы помочь вам сделать правильный выбор. Следите за новостями!
Другие публикации по теме
Собирать сейчас новый ПК с оперативной памятью прошлого поколения, конечно, не запрещено, да и за счет снизившихся цен на комплектующие там можно сильно сэкономить, но если вы задумываетесь о будущем, то стоило бы присмотреться к сборке с DDR5. Моей целью сегодня является обзор оперативной памяти Silicon Power Xpower Zenith RGB DDR5-6000, к которому и предлагаю перейти.
РАЗГОН ВИДЕОКАРТЫ ПОД 3D?
Народ я знаю что современные видеокарты (не только PCI Exress) можно разогнать (путём перепайки) для более быстрой работы с БОЛЬШИМ количеством полигонов при этом с маленьким количеством полигонов видяха работает так-же. кто в курсе вопроса просветите меня пожалуйста и остальных за одно.
Guest
Я разгонял (Рива Тюнером) RivaTuner2.0 прога такая. Частоту ядра и памяти увеличиваеш.У мя Gefors 3Ti 200 производительность увеличилась процентов на 5-7%.Проерял производительность 3DMark 2003.
А ваще если у тя видуха SE определенной монельки мажно перепрошиль ееже вроде шейдеры или чета подобное не помнус 9800SE на 9800Pro.
Разгон движки с чего начать
Приветствую всех.
Сижу и ломаю голову над одним вопросом — как правильно плавно разогнать и главное затормозить шаговик.
В арсенале есть следующие переменные:
Текущая скорость;
Максимальная допустимая скорость;
Минимальнаяидопустимая скорость;
Значение разгона (шагов в секунду);
Значение торможения (шагов в секунду);
Оставшееая количество шагов до полной остановки.
Пока использую такую схему: плавно разгоняю двигатель при старте от минимальной допустимой скорости до максимальной, прибавляя к текущей скорости каждую миллисекунду значение разгона/1000. На этом этапе все хорошо, но теперь нужно дождаться некого значения, чтоб по такому же алгоритму начать торможение.
Вопрос в том, как правильно вычислить это значение с учетом текущей скорости?
Заголовок сообщения: Re: Алгоритм плавного разгона и торможения шгового двигател
Добавлено: Пн фев 12, 2018 15:59:39
Этот вопрос рассматривался в документации старых советских принтеров (9-игольчатых).
Жаль той «фолианты» у меня не сохранилось.
Заголовок сообщения: Re: Алгоритм плавного разгона и торможения шгового двигател
Добавлено: Пн фев 12, 2018 21:11:41
А по памяти ничего не подскажете? Блин, вроде задача простая, но чет никак не соображу.
Сборка печатных плат от $30 + БЕСПЛАТНАЯ доставка по всему миру + трафарет
Заголовок сообщения: Re: Алгоритм плавного разгона и торможения шгового двигател
Добавлено: Вт фев 13, 2018 02:26:14
Надо, наверное, копать в сторону формулы определения расстояния при равноускоренном движении:
где:
S — пройденное расстояние, м
v1 — начальная скорость при ускорении или конечная при замедлении, м/с
v2 — конечная скорость при ускорении или начальная при замедлении, м/с
a — ускорение, м/с^2
Только вместо метров и секунд подставить шаги двигателя и миллисекунды. То есть:
S — количество сделанных шагов
v1 — начальная скорость при ускорении или конечная при замедлении, шагов/миллисекунду
v2 — конечная скорость при ускорении или начальная при замедлении, шагов/миллисекунду
a — ускорение, шагов/мс^2
Тогда получается, что если, к примеру, нужно снизить скорость от 50 до 2 шага в миллисекунду с ускорением (значением торможения) 2 шага в миллисекунду, тогда находим количество шагов, которые двигатель сделает в процессе торможения:
Значит за 624 шага до того как скорость должна стать равной 1 начинаем снижать скорость по 2 шага в миллисекунду.
Я не уверен во всем этом, не пробовал, но мне кажется, что должно работать
UPD: Не, фигня это. Не получается почему-то так.
Добавлено after 1 hour 23 minutes 48 seconds:
Re: Алгоритм плавного разгона и торможения шгового двигателя
Тогда смотреть в сторону суммы членов арифметической прогрессии
S — количество сделанных шагов
v1 — начальная скорость при ускорении или конечная при замедлении, шагов/миллисекунду
v2 — конечная скорость при ускорении или начальная при замедлении, шагов/миллисекунду
a — ускорение, шагов/мс^2
t — это количество шагов уменьшения скорости до достижения нужной
Вот так вроде все сходится с подсчетом в лоб на калькуляторе
Приглашаем всех желающих принять участие в вебинаре, посвященном разработке узла питания в автономных устройствах, что является сложной задачей, т.к. необходимо не только выбрать надежный и качественный аккумулятор, но и правильно спроектировать схему управления и контроля. На вебинаре мы расскажем о линейке аккумуляторной продукции EVE, а также как выбрать правильную модель аккумулятора, режимы его работы, сформулировать требования для проектирования узла управления. Рассмотрим основные функциональные блоки работы аккумуляторного узла и компоненты для их реализации.
Заголовок сообщения: Re: Алгоритм плавного разгона и торможения шгового двигател
Добавлено: Вт фев 13, 2018 07:39:17
делал на таймере, там все просто было вроде
видюху нашел даже управа с переменника
Выбирая продукцию того или иного производителя, важно быть уверенным в надежности продукции. Компэл в качестве официального дистрибьютора представляет различные надежные литиевые аккумуляторы и батарейки от мирового лидера EVE Energy, в том числе популярного типа 18650. Для оказания помощи в подборе аккумуляторов этого типа, сочетающих оптимальные технические параметры и приемлемую цену, инженер Компэл провел собственное тестирование. Аккумуляторы типа 18650 изготавливаются по двум имеющимся электрохимическим системам – ICR и INR – с различной емкостью.
Заголовок сообщения: Re: Алгоритм плавного разгона и торможения шгового двигател
Добавлено: Вт фев 13, 2018 09:21:31
Mishany писал(а):
делал на таймере, там все просто было вроде
Это если не нужно вращать на точно заданное количество шагов.
Заголовок сообщения: Re: Алгоритм плавного разгона и торможения шгового двигател
Добавлено: Вт фев 13, 2018 09:23:13
нет, там все точно было, реализован на 2-х таймерах STM32, смотрел исходник но что то с коментами они какие то левые
Принцип прост передаешь позицию мотор выходит на нее с ускорением и замедлением, причем можно на лету менять позицию
не знаю от куда там скорость в км/час, но это прерывание отвечает за ускорение/замедление
Заголовок сообщения: Re: Алгоритм плавного разгона и торможения шгового двигател
Добавлено: Вт фев 13, 2018 10:36:56
Ну вообще можно посмотреть исходники того же Marlin (управление 3D-принтерами) или LinuxCNC. Там все это (и многое другое) есть.
Заголовок сообщения: Re: Алгоритм плавного разгона и торможения шгового двигател
Добавлено: Ср сен 16, 2020 08:58:55
Надо, наверное, копать в сторону формулы определения расстояния при равноускоренном движении:
.
.
От куда такие картинки ? Какой это софт ?
Заголовок сообщения: Re: Алгоритм плавного разгона и торможения шгового двигател
Добавлено: Ср сен 16, 2020 12:55:07
всё очень просто
разгон:
V=a*t;
if (V>Vmax) V=Vmax;
торможение:
смотри формулу пути до остановки при равнозамедленном движении (например высоты подброшенного вверх камня) из формулы выражай скорость, дальше как и при разгоне если скорость получилась больше, чем максимальня — используй максимальную, если меньше — используй полученную.
П.С. эти три условия (разгон, максимальная, торможение) собери в одну функцию т.к. при коротком пути торможение может потребоваться ещё до окончания разгона.
Добавлено after 1 minute 38 seconds:
Re: Алгоритм плавного разгона и торможения шгового двигателя
ох, ё. опять говно мамонта вырыли.
_________________
Просто не учи физику в школе, и вся твоя жизнь будет наполнена чудесами и волшебством
Вопрошающим про силовую или высоковольную электронику с низкой грамотностью я не отвечаю, а то ещё посадят за участие в (само)убиении оболтуса.
Заголовок сообщения: Re: Алгоритм плавного разгона и торможения шгового двигател
Добавлено: Ср сен 16, 2020 14:03:31
Это я копатель
Заголовок сообщения: Re: Алгоритм плавного разгона и торможения шгового двигател
Добавлено: Ср сен 16, 2020 15:02:00
Делал в прерывании по переполнению таймера, генерирующего меандр: просто проверяется КА состояния, и если надо, в ARR добавляется или вычитается постоянная величина. На гитхабе у меня валяется код — взять тот же фотометр MMPP.
_________________
Linux rules! Windows must die. Здравомыслящий человек добровольно будет пользоваться мастдаем лишь в двух случаях: под дулом автомата или под влиянием анального зонда.
Я на гитхабе, в ЖЖ
Заголовок сообщения: Re: Алгоритм плавного разгона и торможения шгового двигател
Добавлено: Ср сен 16, 2020 15:28:10
Делал в прерывании по переполнению таймера, генерирующего меандр: просто проверяется КА состояния, и если надо, в ARR добавляется или вычитается постоянная величина. На гитхабе у меня валяется код — взять тот же фотометр MMPP.
надо бы в одном таймере сразу несколькими двигателями управлять
Заголовок сообщения: Re: Алгоритм плавного разгона и торможения шгового двигател
Добавлено: Ср сен 16, 2020 15:54:28
Одним таймером невозможно: не получится разгонять и тормозить. Строго по таймеру на движок.
_________________
Linux rules! Windows must die. Здравомыслящий человек добровольно будет пользоваться мастдаем лишь в двух случаях: под дулом автомата или под влиянием анального зонда.
Я на гитхабе, в ЖЖ
Заголовок сообщения: Re: Алгоритм плавного разгона и торможения шгового двигател
Добавлено: Ср сен 16, 2020 16:07:07
Не надо так категорично. Marlin, grbl не тратят по таймеру на двигатель и работают. Даже с 6 двигателями одновременно.
Заголовок сообщения: Re: Алгоритм плавного разгона и торможения шгового двигател
Добавлено: Ср сен 16, 2020 16:14:02
Потому как написаны школьниками за еду! Через одно место.
Стопудово, там управление производится тупым ногодрыгом. И если один двигатель должен делать 2000 шагов в секунду, а второй — 0.03, ничего не выйдет.
_________________
Linux rules! Windows must die. Здравомыслящий человек добровольно будет пользоваться мастдаем лишь в двух случаях: под дулом автомата или под влиянием анального зонда.
Я на гитхабе, в ЖЖ
Заголовок сообщения: Re: Алгоритм плавного разгона и торможения шгового двигател
Добавлено: Ср сен 16, 2020 16:32:50
шаговики (степ-дир) — можно собрать софт-таймер и подключить несколько штук на 1 таймер. макс. обороты будут меньше, чем при использовании индивидуального таймера (и джиттер больше, особенно на больших оборотах). но тоже вполне сносно. по крайней мере 200 и 0,03 разом без проблем.
_________________
Просто не учи физику в школе, и вся твоя жизнь будет наполнена чудесами и волшебством
Вопрошающим про силовую или высоковольную электронику с низкой грамотностью я не отвечаю, а то ещё посадят за участие в (само)убиении оболтуса.
Заголовок сообщения: Re: Алгоритм плавного разгона и торможения шгового двигател
Добавлено: Ср сен 16, 2020 19:38:21
Потому как написаны школьниками за еду! Через одно место.
Стопудово, там управление производится тупым ногодрыгом. И если один двигатель должен делать 2000 шагов в секунду, а второй — 0.03, ничего не выйдет.
Заголовок сообщения: Re: Алгоритм плавного разгона и торможения шгового двигател
Добавлено: Пт янв 20, 2023 18:14:53
Добрый день! Помогите понять принцип (алгоритм) работы линейного интерполятора контроллера двухосевого чпу. Пытался изучить исходники marlin и grbl (файлы stepper.c и stepper.h), но мало чего хорошего из этого получилось. В общем пришлось изобретать свой велосипед с нуля. В файле stepper.c в комментариях авторы приводят краткое пояснение принципа работы интерполятора (скрин во вложении), но этой информации мне не хватило для полного понимания.
Сделал свою простенькую реализацию, которая обрабатывает каждый кадр (каждую команду G0/G1) независимо от предшествующих и последующих команд перемещения (G0/G1). Получилось, что каждое линейное перемещение начинается с нулевой скорости по обеим осям и заканчивается нулевой скоростью. Форма графика зависимости скорости по отдельной оси от времени трапецеидальная (если времени достаточно для достижения заданной скорости в пределах одной команды G0/G1), либо равнобедренный треугольник (если времени не достаточно для достижения заданной скорости в пределах одной команды G0/G1). Время и количество шагов на ускорение и замедление для отдельной оси всегда одинаковое. Но при такой реализации очень неэффективно происходит обработка кривых траекторий, которые преобразуются генератором g-кода в большое количество мелких линейных перемещений.
Понятно, что нужно как-то учитывать последующую команду G0/G1 для определения конечной скорости текущего перемещения. И начинать каждое новое перемещение с нулевой скоростью не обязательно, если изменение направления траектории движения не существенное. Но ведь, получается, что при обсчёте одного кадра (вычисление начальной скорости, количество шагов на ускорение, количества шагов на замедление, конечной скорости) необходимо учитывать несколько кадров предшествующих и как минимум один последующий кадр. Ведь не факт, что за 1 или 2 линейных перемещения удастся достичь заданной скорости, а замедлятся потом (может так случится) придётся также в течении не одного кадра (например отрисовка окружности или дуги или даже простой прямой, но состоящей из отдельных коллинеарных отрезков малой длины).
В описании в файле stepper.c трапеция обозначается, как BLOCK. Что авторы подразумевают под BLOCK? Отдельный кадр (команду G0/G1), или набор нескольких кадров? Для организации конвейера явно используется буфер команд элементарных линейных перемещений, пока исполняются команды из одной его половины происходит заполнение второй половины (из COM порта, SD карты или ещё откуда. ). И этот буфер, явно, вмещает не больше 100-500 команд. Что если количество команд перемещения в BLOCK будет (в каких-то случаях) превышать ёмкость буфера команд? Или (ещё более реальная ситуация) начало BLOCKа попадёт на одну половину буфера, а конец на другую половину, тогда у контроллера вообще не будет единовременного доступа ко всем кадрам данного BLOCKа. В общем не могу понять саму идею реализации линейного интерполятора на микроконтроллерах.
Часовой пояс: UTC + 3 часа
Тестирование игрового движка Amazon Lumberyard. Подходы и инструменты
Amazon. Игры. Звучит необычно? Как тестировать продукт и для разработчиков, и для геймеров? Под катом — тестирование игрового движка Amazon Lumberyard, подходы как в ручном тестировании, так и в автоматизации, а также используемые на проекте инструменты.
Lumberyard — это кроссплатформенный игровой движок, на котором можно бесплатно создавать игры для большинства современных платформ: PC, Mac, iOS/Android, все приставки, в том числе очки виртуальной реальности. Он также довольно глубоко интегрирован с Amazon Web Services и сервисом игровых трансляций Twitch.
Под катом — видео и расшифровка доклада Артема Несиоловского с конференции Heisenbug.
О спикере: окончил МИФИ, факультет Кибернетики, более 8 лет в разработке и тестировании. Поработал как на десктопных проектах, вроде GeForce Experience, онлайновой MMORPG Lineage II, так и в мобильных — игра Cut the Rope, а также в веб-проекте Yandex.Images. В данный момент является инженером по автоматизации в компании Amazon на проекте Amazon Lumberyard.
Структура поста
- Игровой движок: особенности, а также отличия тестирования движка от тестирования игр.
- Ручное тестирование: как мы пытались выяснить покрытие фичей проекта функциональными тестами.
- Автоматизация: ошибки и шишки, которые мы набили и лечили впоследствии.
- Инструменты, при помощи которых мы автоматизируем наш движок.
- Интересные баги с нашего проекта, которые вы наверняка встречали, когда сами играли в игры.
Далее повествование от лица спикера.
Почему вообще Amazon занимается играми? В 2014 году Amazon, как и многие технические гиганты, замечает, что игры становятся вторым по популярности видом развлечения у человечества. Первый, как ни странно, — это телевидение, а точнее, всё, что касается видеостриминга (YouTube, Netflix и всё остальное). Также игростроители начинают активнее пользоваться сервисами AWS для своих онлайн-игр.
Amazon решает построить экосистему на трех китах: открыть свою игровую студию для создания игр, которые люди потом будут стримить и смотреть на Twitch. Также эти игры будут показывать, какие интересные геймплейные идеи можно воплотить, используя клауд AWS.
С чего все начиналось?
В 2004 году немецкая компания Crytek выпускает игру под названием «FarCry». Через какое-то время Crytek начинает лицензировать свой движок, на котором была построена игра, чтобы сторонние компании могли взять готовый движок и начать создавать игру, геймплей, наполнить её контентом без больших инвестиций в технологию. Когда Amazon начал заниматься играми, он также сразу открыл несколько студий и стал разрабатывать несколько игр.
Чтобы каждая студия не изобретала велосипед — свой рендер-движок, свою анимационную систему, физику и так далее, Amazon лицензирует «CryEngine» версии 3 и запускает разработку сразу нескольких игр. Игра «The Grand Tour» уже вышла на приставках Xbox и PlayStation. Ещё две находятся в разработке: MMORPG «New World» и онлайновый шутер «Crucible». После того как запустилась разработка этих игр, Amazon начинает бесплатно предоставлять движок, на котором эти игры разрабатываются. Поскольку он сильно интегрирован с облачными сервисами Amazon, можно привлечь больше людей использовать AWS.
Игровой движок — это набор API, игровой двигатель для построения будущей игры. Чтобы разработчикам не нужно было писать свои игровые системы, можно просто взять набор API, т.е. движок, и начать писать свою игровую логику, добавлять туда контент и заниматься творчеством, вместо того чтобы разрабатывать технологию с нуля. Также у некоторых движков есть редактор. Это десктопная программа, в которой можно создавать уровни, то есть открывать свой левел и добавлять туда контент и игровую логику.
Вместо того чтобы долго рассказывать, иногда проще показать одно видео:
Здесь показан наш редактор и его интерфейс. Внутри него запущена игра, которую мы предоставляем вместе с движком. «Starter Game» существует для того, чтобы люди могли зайти, поиграть, что-то поменять и разобраться, как это работает.
В целом 3D игры можно себе представить как набор трехмерных объектов, которые перемещаются в трехмерном мире и как-то взаимодействуют между собой. В данном видео можно увидеть:
- статическую геометрию с текстурами: земля, камни, трава, деревья;
- динамическую геометрию — персонаж анимирован, реагирует на действия игрока;
- пользовательский интерфейс: в верхнем левом углу виды задачи.
Как тестировать движок?
Тестирование движка строится на трех основных пунктах. Первое — это тестирование редактора и инструментов: корректная работа, инструменты должны открываться, ничего не крашиться, всё должно правильно отображаться, пользовательские сценарии должны выполняться без ошибок, процесс создания игры без сопутствующих багов. Редактором будут пользоваться только создатели игр. Второе — это тестирование самого двигателя или API движка. Игровой движок в свою очередь это та часть кода, которая будет работать в том числе и на компьютерах игроков. Данная часть проекта тестируется через заблаговременное создание уровней и игр. Впоследствии созданные уровни можно тестировать на каждом новом билде движка, чтобы удостовериться, что все игровые элементы использованные на том или ином уровне работают как надо. И третья составляющая — это тестирование инфраструктуры и совместимости: движок можно сконфигурировать и сделать build с разными параметрами, игру можно задеплоить на различные девайсы, и она везде будет выглядеть и работать примерно одинаково.
Особенности проекта
Первая особенность — мы поддерживаем большинство существующих игровых платформ. Несмотря на то что редактор сам работает только на PC, runtime, т.е. игру можно сбилдить на Mac, смартфоны, консоли и даже очки виртуальной реальности.
Вторая особенность — наши пользователи — это два типа людей с абсолютно разными запросами. С одной стороны, это разработчики, программисты, художники и дизайнеры, которые будут работать над созданием игры. А с другой стороны, это геймеры, на машинах которых игра потом будет работать. Требования у этих двух групп совершенно разные.
Третья особенность — в таких программах, позволяющих создавать что-то новое, заранее подразумевается максимально широкий спектр возможных продуктов этого приложения. На нашем движке можно построить абсолютно любую игру, начиная от чего-то простого, вроде тетриса, и заканчивая сложным онлайновым проектом, в который играет тысячи людей одновременно.
Все эти три особенности очень сильно влияют на количество пользовательских сценарием, каждый из которых необходимо тестировать.
Посмотрите на этот скриншот и представьте, сколько тест-кейсов вы могли бы написать просто на данную часть функционала? Всего у нас на проекте больше 11 тысяч тест-кейсов и эта база данных растет примерно на 3-4 тысячи тест-кейсов каждый год.
Большинство багов мы находим во время взаимодействия нескольких компонентов между собой. На этом видео снег в нормальном состоянии отображается на кубике как положено, но стоит только персонажу начать с ним взаимодействовать, снег начинает пропадать. Большинство багов мы находим именно в таких местах сочленения нескольких компонентов.
Однако баги не всегда проявляются, когда условий только два. Часто бывает так, что баги проявляются, когда сходятся сразу несколько компонентов. В данном случае мы рассматриваем баг, в котором в нормальной ситуации персонаж просто стоит на земле. Стоит добавить ещё одну степень свободы — поднять персонажа над землей: когда он упадет, начнет проигрываться анимация и приближаться/удаляться камера — текстура начинает пропадать. Здесь взаимодействуют сразу три компонента: высота, анимация персонажа и расстояние камеры. Продумать все эти варианты заранее невозможно, и часто такие баги мы находим только во время ad-hoc тестирования.
Есть еще одна особенность — у нас много недетерминированных систем. Это системы, в которых, при одинаковых входных данных, итоговый результат может отличаться. Простой пример — в системе есть случайные переменные. В нашем случае это системы физики, в которых много вычислений с числами с плавающей точкой. Floating point operations на разных процессорах или компиляторах могут выполняться немного по-разному. Из-за этого результирующая функциональность будет всегда немного отличаться. В итоге такие системы довольно сложно автоматизировать, потому что сложно объяснить машине, в каком случае это баг, а в каком случае это приемлемые отличия.
В движке и в самом редакторе довольно много нетривиальных взаимодействий. Пользователи часто взаимодействуют внутри трехмерного пространства при помощи мышки и клавиатуры. На данном видео будет изображена фича под названием Simulated object. Вещи, одетые на персонажа должны двигаться согласно законам физики при движении персонажа, на которые эти предметы надеты. Например, одежда или портфель. В качестве такого элемента на видео — рука персонажа. Когда персонаж двигается, рука тоже начинает реагировать. Зачастую, чтобы протестировать такой функционал, нужно делать нетривиальные действия: переключать что-то в UI, двигать объекты в трехмерном пространстве, делать drag-and-drop, также смотреть на анимационные графы, которые расположены снизу, и делать всё в режиме реального времени. Эта особенность влияет на сложность автоматизации.
Как определить покрытие?
В какой-то момент мы поняли, что мы написали очень много тест-кейсов, но определить, какое у нас покрытие, было сложно. Мы находили большинство критических багов не во время нашего полного регрессионного теста, а во время ad-hoc тестирования, которое проводилось в конце релизного цикла. Мы начали думать: у нас есть движок с великим множеством функционала, есть репозиторий, в котором 12 000 кейсов — как понять, в каких местах покрытие достаточно, а в каких стоило бы добавить тест-кейсов?
Мы обратились к теории тестирования, стали читать про то, как люди определяют тестовое покрытие. Один из способов — это определение через исходный код. В нашем случае сделать это сложно. У нас несколько миллионов строк кода и выполнить данную проверку в сжатые сроки оказалось невозможным. Второй метод — оценить покрытие через оценку требований. В agile-процессах требования зачастую хранятся только в голове у людей, а не в документации, поэтому через требования сделать оценку покрытия тоже оказалось не реалистично. В итоге мы обратились к единственному для нас возможному способу — это определение покрытия через написание модели.
Мы выбрали модель под названием ACC — Attribute, Component, Capability. АСС это одна из самых простых моделей, которая довольно распространена в Amazon для моделирования работы софта. Модель строится на трех основных столпах. Во-первых, это компоненты, существительные — основные рабочие части системы. Для нас это viewport, текстура, игровая сущность. Далее следуют capabilities — глаголы — то, что эти компоненты умеют делать. Например, они умеют отображаться на экране, что-то вычислять, что-то двигать и так далее. И третья часть — это атрибуты — прилагательные или наречия, относящиеся как к компонентам, так и к их возможностям. Атрибуты описывают параметры возможностей: быстрый, секьюрный, скалирующийся, безопасный и так далее. Всё это можно свести к трем вопросам: кто? что делает? и как?
Разберем данную модель на небольшом примере. Ниже демка небольшой части функциональности:
Viewport — часть редактора, в которой виден уровень. На видео продемонстрировано, что в нем можно вращать камеру, перемещаться по уровню, есть возможность добавить персонажа из местного проводника игровых объектов. Персонажа можно подвигать, или создать новую игровую сущность через правый клик, можно выделить все текущие сущности на уровне и передвинуть их все вместе. Также можно добавить другой геометрический элемент и (как во всех трехмерных редакторах) поменять не только его положение в пространстве, но также менять угол наклона его и изменить размер. У окошка под названием «Viewport» есть разные режимы рендеринга. Например, отключаются тени, или отключаются какие-то графические эффекты пост-процессинга. Можно войти в игровой режим, чтобы сразу же протестировать только что сделанные изменения.
Посмотрим на саму ACC модель. Мы быстро поняли, что эти модели очень удобно делать при помощи Mindmaps, а потом уже транслировать либо в таблички, либо прямо в структуру в TestRail или в любой другой репозиторий для тест-кейсов. На диаграмме в центре виден сам основной компонент — Viewport — и дальше сверху красная ветка — возможность Viewport, позволяющая перемещаться по уровню: можно вращать камеру, можно летать при помощи кнопок «W», «A», «S», «D».
Вторая его возможность (оранжевая ветка) — создавать игровые сущности либо через Viewport, либо через drag-n-drop из игрового проводника.
И третья — игровыми сущностями можно манипулировать: их можно выделять, менять их местоположение, вращать и так далее. Зеленая ветка слева — это конфигурация Viewport при переключении режимов рендеринга. Синей веткой выделен атрибут, который говорит о том, что Viewport также должен отвечать определенным параметрам по производительности. Если он будет тормозить, то разработчикам будет сложно что-либо сделать.
Вся древовидная структура потом перекладывается в TestRail. Когда мы перевели тест-кейсы из нашей предыдущей системы в новую структуру, сразу стало понятно, где не хватает тест-кейсов — в некоторых местах появились пустые папки.
Эти структуры довольно быстро разрастаются. Viewport на самом деле относится к редактору, который является лишь частью движка. Две основные части: сам редактор и сам игровой движок. Справа на картинке выше можно увидеть несколько компонентов, которые не относятся к дереву. Например, система рендеринга или скриптинга, анимации стоят отдельно, потому что относятся сразу одновременно и к редактору, и к движку. То есть система рендеринга будет работать в runtime на конечных девайсах, но в самом редакторе можно будет изменять некоторые параметры: время дня и ночи, редактирование материалов, система частиц.
Результаты и выводы
ACC моделирование помогло выделить области, в которых страдало покрытые тестами. Заполнив пробелы в покрытии, примерно на 70% сократилось количество багов, находимых после нашего полного регрессионного пасса. Легкие в построении ACC модели, оказались также хорошим источником документации. Новые люди, которые приходили на проект, изучали их и быстро могли получить некоторое представление о движке. Создание/обновление ACC моделей плотно вошло в наш процесс разработки новых фич.
Мы начали автоматизировать движок через автоматизацию пользовательского интерфейса. Интерфейс редактора написан на библиотеке QT. Это библиотека для написания кроссплатформенного UI для десктопных приложений, который может работать и на Mac, и на Windows. Мы использовали инструмент под названием Squish от компании Froglogic, который работает по схожей системе с WebDriver, с поправкой на десктопное окружение. В данном инструменте, используется подход, похожий на Page Object (из мира WebDriver), называется по-другому — Composite Elements Architecture. На основные компоненты (вроде «окошко» или «кнопочка») делаются селекторы и прописываются функции, которые можно выполнять с этими элементами. Например, «нажать правой кнопкой», «левой кнопкой», «сохранить», «закрыть», «выйти». Затем эти элементы складываются в единую структуру, к ним можно обращаться внутри своего скрипта, использовать их, снимать скриншот и сравнивать.
Проблемы и решения
Первая проблема — стабильность. Мы писали тесты, которые тестируют бизнес-логику через пользовательский интерфейс — в чем проблема? Когда бизнес-логика не меняется, а меняется интерфейс — тесты падают, нужно заливать новые скриншоты.
Следующая проблема — отсутствие функциональности. Многие юзкейсы заключаются не просто в нажатии какой-то кнопки, а во взаимодействии с трехмерным миром. Данная библиотека делать этого не позволяла, нужны были новые решения.
Третья проблема — скорость работы. Для любых UI-тестов нужно полноценно рендерить весь движок. Это занимает время, машины для этих тестов должны быть достаточно мощные.
Решение пришло в виде библиотеки Shiboken. Эта библиотека предоставляет биндинги из C++ кода в Python, что дает возможность прямую без рендеринга UI редактора вызывать функции, предоставляемые редактором или движком. Аналог из мира web — Headless automation (что-то похожее на PhantomJS) — можно автоматизировать веб-приложение, не запуская браузер. В данном случае похожая система, только для десктопного приложения, написанного на С++.
Начав вкладываться в данный фреймворк, мы поняли, что его можно использовать не только для автоматизации тестирования, а ещё для автоматизации каких-либо процессов внутри движка. Например, дизайнеру нужно проставить в ряд 100 источников освещения (например, он делает дорогу и нужно поставить фонари). Вместо того, чтобы вручную представлять все эти источники света, просто пишется скрипт, который создает игровую сущность, добавляет туда источник света point light и прописывает, что каждые 10 метров нужно скопировать ранее созданный point light. Бонус для наших пользователей в виде инструмента для автоматизации рутинных задач.
Вторая часть решения проблемы. Мы очень быстро поняли, что для автоматизации различных частей нашего движка, — например, графики и сетевой части — нужны абсолютно разные фреймворки. Невозможно создать единственный, монструозный фреймворк, который поможет автоматизировать сразу всё. Поэтому мы начали разрабатывать фреймворк под названием Lumberyard Test Tools (сокращенно — LyTestTools). Он основывается на Pytest (в движке довольно много всего написано на Python). Мы решили применить так называемый Plug-and-play архитектуру — центральная группа автоматизаторов пишет основную часть фреймворка, который сможет скачивать, конфигурировать движок, деплоить его на различные платформы, запускать тесты и собирать логи, выгружать отчеты в нашу базу данных или на S3 и рисовать графики в Quicksight. Plug-and-play достигается через Test Helper-ы, которые будет писать команды на местах, которые занимается разработкой фич.
То есть команда разработки графики будет тестировать скриншотами, а команда сетевого взаимодействия будет заниматься проверкой пересылаемых пакеты. Все они при этом будут подключаться к нашему единому фреймворку (т.к. обе команды разрабатывают и тестирую модули единого движка), чтобы у всех были одинаковые интерфейсы запуска тестов и генерации отчетов, чтобы всё было более-менее стандартно и корректно работало с нашим CI/CD.
Взаимодействие с Lumberyard
Какие могут быть способы взаимодействия/автоматизации десктопного приложения? Первый тип взаимодействия фреймворка с движком — напрямую из Python процесс запускается при помощи функции Subprocess, если приложение подразумевает запуск через командную строку. Вы можете считывать ввод/вывод из стандартного input/output вывода и таким образом делать ассерты. Следующий тип — это взаимодействие через анализ логов — можно считывать и анализировать логи, оставляемых приложением. Третий — через сеть. В игровых лаунчерах существует модуль, который называется Remote console. Когда на девайсе открыт определенный порт, наш фреймворк может посылать пакеты/определенные команды. Например, взять скриншот или открыть какой-то определенный уровень. Еще один метод — это взаимодействие через сравнение визуальной информации, т.е. скриншотов. Также ранее упоминался метод вызовов функционала приложения напрямую через API продукта (в нашем случае это вызов через Python-bindings к C++ функционалу редактора/движка).
Перейдем к примерам использования нашего фреймворка для автоматизации движка.
Посмотрите на данный скриншот.
Детализация на этом участке довольно высока — большое количество растительности. В современных играх уровни могут занимать до нескольких десятков и сотен игровых километров. Естественно, каждый из этих игровых кустиков не проставляется вручную, иначе разработчики просто сошли бы с ума. Для них в нашем движке есть специальные инструменты.
Один из них называется Vegetation Tool. Небольшое демо:
Мы видим стандартное начало уровня. Есть террейн и можно очень быстро сделать рельеф: на заднем плане сделать горы, в центральной части тоже выделить небольшую возвышенность. Можно покрасить саму землю зеленым цветом с текстурой травы. Дальше продемонстрирован процесс добавления растительности, в данном случае — деревьев. В инструмент добавляется геометрия — деревья, — выделяется их подмножество, и можно рисовать этими деревьями любой необходимый рисунок. Это довольно простенький пример, у данного инструмента много настраиваемых параметров. Например, можно выделить не одно дерево, а сразу несколько и задать для них параметр, стоять друг от друга на каком-то определенном расстоянии, или задать случайные параметры для размеров или вращения этих деревьев. Можно добавить игрового персонажа и сразу же побегать в уровне, протестировать, что же вы только что вырастили в вашем собственном игровом саду.
Давайте теперь посмотрим, как мы автоматизировали эту фичу нашим фреймворком на примере пары тестов.
Есть стандартный террейн и на нём выращено очень много однотипной травы. Такой тип рендеринга очень сильно нагружает процессор. Если таких элементов очень много, можно сделать нагрузочный тест. Здесь добавлен игровой скрипт, который при запуске игрового режима просто будет делать пролет через данный уровень. Задача — протестировать эту функциональность и проверить, что игровой лаунчер стабилен и не будет крашиться.
Это пример того, как команда, которая разработала фичу для выращивания растительности, написала Test Helper, который позволяет работать с этими функционалом. Это пример использования нашего фреймворка. Зеленым выделен класс launcher. Когда запускается тест, лаунчер деплоится, запускается с параметрами тайм-аута, и мы делаем assert на том, чтобы проверить, что краш лаунчера не происходит через какое-то время. Затем мы его выключаем.
На коде параметризации выше видно, что мы можем один и тот же код переиспользовать на разных платформах. Более того, мы можем переиспользовать один и тот же код на разных уровнях или проектах. Например, красным выделены платформы: в одном случае это Windows, в другом случае это Mac; желтым цветом выделен проект; светло-желтым выделено название уровень.
Теперь о работе теста — в данном случае запускаем его через командную строку. Открывается программа под названием Asset Processor, одна из основных частей движка. Данная программа перерабатывает исходные ассеты (к примеру — созданные художниками модели и текстуры) в понятные для движка форматы и записывает все в базу данных (SQLite), чтобы движок мог быстро ориентироваться и подгружать необходимые данные во время игры. Далее запускается сам лаунчер, стартует игровой режим, камера несколько секунд летит над уровнем и тест завершается. Мы видим, что один тест был выполнен успешно и два теста были пропущены. Так произошло потому что во время записи видео тест гонялся на Windows, а в параметризации есть еще две платформы, которые соответственно были пропущены при данном запуске.
Есть более сложный вариант. Мы не просто запускаем лаунчер с готовым уровень, но скрипт взаимодействует напрямую с редактором. Синим выделено название отдельного скрипта, который будет работать с редактором и дергать различные команды через API.
Выше представлен тестовый уровень. В данном случае на стандартном террейне нарисована улыбка при помощи заранее подготовленной текстуры (маски). Нужно проверить, что при использовании маски закрашивание будет осуществляться только по заранее выделенному контуру и не будет заходить за его пределы.
Команда работы с игровым миром написала своё расширение для работы с террейном, которое потом вставляется в наш фреймворк. Создается новая кисть, которая будет рисовать по маске «Cobblestones», кисти выставляется красный цвет и выбранный layer закрашивается.
В продолжении создается новая кисть, ей выставляется другая интенсивность. Маска уже не используется, а в цикле, уже в другой части уровня рисуется новый элемент.
Посмотрим, как работает этот скрипт.
Сначала запустится Asset Processor, который проверит состояния базы данных ассетов и переработает вновь добавленные элементы в случае необходимости. Далее запустится редактор. Откроется уровень с улыбкой, и начнет выполняться скрипт, который работает с редактором. Он закрасит layer по маске, далее создаст синий круг и начнет делать скриншоты. Впоследствии скриншоты сравнятся с эталонными, и, если все в порядке, тест завершится.
Такие скриншоты тест берет для сравнения с эталонами. Здесь видно, что рисовка прошла четко по границе.
Графика
Также мы используем наш фреймворк для тестирования графики.
Графика — одна из самых сложных частей движка, которая занимает большую часть кода. Проверять можно и нужно все — начиная с простых вещей, вроде геометрии и текстур, так и более комплексных фич — динамических теней, освещения, эффектов пост-процессинга. На видео в правом углу можно видеть отражение в луже — это всё работает в реалтайме на нашем движке. Когда камера залетает внутрь, можно увидеть более продвинутые элементы рендеринга, например, блики, прозрачные элементы, вроде стекла, а также отображение таких элементов как металлические поверхности. Как же данный функционал тестируется скриншотами?
Это наш персонаж, Rin. При помощи неё мы часто тестируем пайплайны художников. Художники что-то создают в своем редакторе (например, персонажа), а потом рисуют на нём текстуры. Asset Processor перерабатывает исходные данные, чтобы задеплоить на различные платформы, а графический движок будет заниматься отображением.
Наверняка вы часто сталкивались с багом, когда «текстуры не подгрузились». На самом деле проблем когда что-то случилось с отображением текстур очень много.
Но все их хорошо отлавливать при помощи сравнения скриншотов. На первом скриншоте можно увидеть баг — некоторые материалы плохо подгрузились. На данных скриншотах тот же самый уровень, где стоял мотоцикл и камера залетела внутрь кафе, который был продемонстрирован на видео ранее. Почему здесь всё выглядит гораздо скучнее? Потому что скриншоты берутся не на самом последнем этапе рендеринга, когда графический движок выложил все свои эффекты, а поэтапно. Сначала берется только рендеринг простой геометрии и текстур: убираются тени, убираются сложные элементы освещения. Если тестировать всё уже на самом последнем этапе и смотреть на Diff Image, то будет сложно сказать, что конкретно сломалось.
Если делать это поэтапно, можно примерно понять, в какой части графического движка что-то пошло не так. Здесь показан алгоритм, которым мы сравниваем скриншоты.
При помощи сравнения скриншотов можно тестировать графику, отображение элементов, текстуры, материалы, шейдеры.
Приведу пример одного бага из старой версии нашего движка, когда у нас не было этого фреймворка.
Он касается системы Vegetation. После добавления деревьев графическая часть начинает рисовать тени под ними. Стоит нажать «Ctrl + Z» («Отмена»), деревья пропадают, а тени остаются. Если взять скриншот в начале, когда дерево стоит и после нажатия «Отмена», то такой баг легко поймать в автоматическом режиме после сравнения с эталонными скриншотами До и После.
При помощи сравнения скриншотов также очень хорошо тестируется Asset pipeline. Когда художники что-то создали в 3д редакторах (Maya, 3dsMax), нужно проверить, что в игре всё отображается точно так же, и ничего не пропало: у курицы есть перья, у всех животных — мех, у людей корректно отображается текстура кожи и прочее.
В правой части программы — Asset Processor, который следит как раз за отображением в игре всего того, что нарисовал художник. Он скажет нам, что с этими ассетами всё в порядке — они должны работать. На видео можно заметить, что некоторые деревья окрасились в черный цвет. Некоторые отображаются нормально, а некоторые зеленые текстуры просто пропали. Естественно, в таком виде нельзя выпускать движок или ассеты.
Не все можно поймать
Какие-то баги начинают образовываться только тогда, когда несколько элементов взаимодействуют между собой. Две модельки Rin отображаются нормально, если их удалить друг от друга, но если их приблизить, начинаются проблемы с геометрией. Такие баги, к сожалению, даже автоматизацией сложно поймать заранее. Зачастую их можно заметить, только когда тестировщики начинают что-то делать в режиме exploratory testing или когда движок уже попадает в руки клиентов.
Сравнением скриншотов можно тестировать интерфейс самого редактора.
Игровые компоненты
Также скриншотами можно тестировать какие-то простые игровые компоненты. Пример — простой уровень, на котором есть дверь и скрипт, который при нажатии на пробел начинает дверь открывать и закрывать.
Можно брать скриншот в начале и в конце. Если всё совпадает, значит скрипт, который меняет местоположение элемента, работает корректно.
WARP
Мы быстро поняли, что скриншоты одной и той же функциональности очень сильно отличаются на различных платформах, в некоторых случаях на одной и той же платформе могут быть различия в зависимости от типа видеокарты. Как с этим бороться, чтобы не хранить по 100500 скриншотов? Есть инструмент, Windows Advanced Rasterization Platform — это программный рендерер, который позволяет делать всю графику без обращения к драйверу и к видеокарте. Используя данный инструмент можно гонять большую часть функциональных графических тестов без зависимости от драйверов и от железяк.
Производительность
Игровой движок не в последнюю очередь должен быть производительным! GPU можно тестировать при помощи различных графических профайлеров, вроде PIX. Оперативную память можно тестировать в самой Visual Studio. Далее подробнее о том, как тестируется производительность процессора при помощи инструмента RADTelemetry.
Знаете, что такое Input Lag?
Input Lag — это задержка между нажатием клавиши контроллера/клавиатуры игроком и моментом, когда игра начинает реагировать на нажатие. Input Lag бывает из-за передачи данных по сети, когда пакеты долго идут или сервер долго отвечает, а также в движках и без использования нетворкинга. Когда кто-то накосячил в коде, который отвечает за анимацию, Input lag может стать таким высоким, что персонаж начинает реагировать слишком поздно. В простом приближении это тестируется довольно легко: открывается виртуальная клавиатура и снимается видео, на котором фиксируется момент нажатия на пробел и момент начала анимации.
Смотрим, сколько в данный момент кадров в секунду выдает движок. Можно посчитать, сколько занял каждый кадр в миллисекундах (1000/FPS). Если видео проиграть покадрово, можно посчитать, сколько кадров прошло с момента клика до того, как персонаж начинает двигаться. Зная, сколько миллисекунд занимает каждый кадр, можно посчитать, что между нажатием на пробел и началом анимации прошло, например, 200 миллисекунд. Со стандартной реакцией человека в 100 миллисекунд это слишком медленно и геймеры сразу скажут, что такая задержка никуда не годится. У данного метода тестирования есть свои проблемы. Во-первых, будут погрешности. Например, у виртуальной клавиатуры будет задержка. Во-вторых, в играх художники часто делают анимацию так, что персонаж не сразу начинает делать основное движение. Есть так называемый anticipation: перед основным действием, например, прыжком, персонаж сначала немного нагибается и только потом начинает прыгать. На это может уйти пара кадров. Как же мы с этим боролись? Мы начали тестировать эту часть более точным подходом.
Есть программа под названием RADTelemetry.
Она позволяет профилировать процессор. По вертикали здесь отложены кадры: № 629, 630 — видно, сколько по времени каждый кадр занял. По горизонтали отложены либо ядра процессора, либо потоки выполнения приложения, если приложение многопоточное. Если нажать на какой-либо из потоков, то слева отобразится название всех функций, которые есть в этом потоке, когда они были запущены, сколько они заняли времени на выполнение от общего, сколько раз они были выполнены. При помощи этого приложения можно точно понять, сколько прошло времени с момента, когда игра зарегистрировала нажатие клавиши, до того, как она запустила функцию Play Animation. Эта программа умеет складывать свои логи в текстовые файлы и потом при помощи них можно рисовать полезные графики производительности разных билдов во временном распределении.
И где здесь AWS?
В заключение пару слов про AWS. С одной стороны, мы используем его для того, чтобы гонять наши тесты. Мы запускаем тесты на EC2 и на девайсах из Device Farm. Результаты складываются в базу данных в S3, а графики отображаются на Quicksight. Статистику по тестам можно посмотреть в CloudWatch. Поскольку движок сильно интегрирован с AWS сервисами, мы тестируем в том числе и эти интеграции — как вручную, так и автоматически. К примеру, CloudCanvas — это сервис, который позволяет создавать функциональность для сетевых игр без программирования, то есть на сервере просто можно настроить такие фишки как Leaderboards, таблицы очков, ачивменты. Для таких вещей как игровая монетизация можно не искать своего серверного программиста, а сразу начать использовать CloudCanvas. Amazon GameLift — это по сути скалируемая система для игровых серверов. Интеграция с Twitch — когда пользователи смотрят трансляцию двух игроков, которые соревнуются между собой. Создается опрос на Twitch «Кого из игроков вы поддерживаете?» — люди начинают голосовать в чате, игра считывает ответы, и можно кому-то из игроков (как в «Голодных играх») сбросить дополнительный бонус или помешать.
Резюме
Первое, что мы поняли — в таких больших проектах не бывает единой серебряной пули, при помощи которой можно всё автоматизировать. В нашем случае хорошо сработал Plug-and-play фреймворк. Мы написали общий фреймворк и разрешили остальным командам удобно встраивать их решения. На примерах сравнения скриншотов и vegetation системы показал, как эти фреймворки работают. Надеюсь, что какие-то приложения и индустриальные решения (вроде Software Renderer от Microsoft или RADTelemetry.), приведенные в статье, будут полезны для практикующих инженеров, работающих в играх или CAD-системах.
В заключение — ссылки на все инструменты, которые были показаны в докладе:
- Скачать движок бесплатно и без смс;
- Shiboken the Binding Generator (C++ Qt to Python);
- Windows Software Renderer;
- RAD Telemetry, CPU Performance Profiling;
- AWS Game Tech.
Надеюсь, что у меня получилось рассказать, чем тестирование движков отличается от тестирования игр. За последнее время процесс шагнул далеко вперед — тестировать игровые движки совсем не просто, но при этом очень интересно.
- Дмитрий Алексеев, Евгений Шумаков — Есть ли автотестирование в мобильных видеоиграх;
- Александр Шуков — Автотесты в World of Tanks: боты на страже качества;
- Филипп Кекс — Как научить роботов играть в игры?