Как мы разогнали САПР КОМПАС-3D → Часть 1
Уже 20 лет прошло с момента выпуска первой 3D-версии КОМПАС — V5.11. За это время мы поняли, что потребности наших пользователей растут пропорционально возможностям КОМПАС-3D, так же как и функциональность КОМПАС расширяется пропорционально запросам пользователей. Только вот одна загвоздка: наращивая долгие годы технологическую часть, мы упирались в проблему производительности при работе со сложными большими проектами. Теперь и этот рубеж преодолен, и мы готовы рассказать, как нам удалось ускорить КОМПАС-3D на более чем 30 базовых операциях.
Как мы поняли, что пора «ускорять»?
Если 12 лет назад было достаточно работы со сборками до нескольких тысяч компонентов, то сейчас пользователи КОМПАС хотят делать сложные проекты по 300 000 компонентов в сборке, а некоторым миллиона будет мало.
Эволюция проектов пользователей КОМПАС-3D: слева Снегоочистительное фрезерно-роторное оборудование к тракторам К-700А, К-703МБА, справа Паро-Газовая Установка ПГУ-410 Мвт. Если плохо видно — кликните по картинке.
В ServiceDesk — техническую поддержку — нам поступали запросы в стиле «не могу с утра открыть свой завод» и «модель открылась, но не вращается».
Вывод один — КОМПАС требовал серьезной доработки.
Первые изменения
Первостепенная задача — повысить быстродействие системы при работе с большими сборками. Причем повысить не на условные 10–30%, а в несколько раз.
Для решения этих задач мы сформировали в 2015 году рабочую группу по ускорению КОМПАС-3D. Своеобразный отряд быстрого реагирования из программистов, тестировщиков и аналитиков.
Наш отряд по быстродействию
СПРАВКА: мы вели работы по ускорению и ранее — это и оптимизации, и новые функции, позволяющие решить часть проблем при работе с большими сборками. Однако задачи не были такими амбициозными, как сейчас, а работы не были столь объемными.
Как выбирали критерии для ускорения?
Мы выбрали 5 направлений для ускорения:
- отрисовка (вращение, перемещение и зуммирование изображения модели),
- добавление компонентов в большую сборку,
- открытие сборок,
- редактирование в сборках,
- проецирование.
При выборе этих направлений мы опирались на несколько источников:
- собственный опыт и исследования,
- анализ запросов в техподдержку и анализ базы ошибок (в наших инструментах есть специальная метка «производительность», где отмечаются критичные для производительности проблемы),
- результаты анкетирования пользователей (такие анкеты пользователи обычно заполняют на мероприятиях АСКОН),
- высшие силы.
Тут мы что-то обсуждаем
Вместе с образованием рабочей группы мы создали свое информационное пространство — базу знаний, — туда записывали все задачи, собирали и систематизировали идеи по возможным направлениям ускорения. В результате начали формироваться требования со сценариями дальнейшей работы, благодаря которым можно было контролировать быстродействие.
Еще одна аксиома, которую мы приняли во время работы над версией: производительность нельзя просто взять и повысить, а потом забыть об этом. Требовалось измерить и зафиксировать текущее состояние, от которого затем мы могли бы отталкиваться. На тот момент отправной точкой была версия V16 (наше повествование пока находится в 2015 году), которая нуждалась в контроле сценариев из нашего ТЗ. Быстродействие по нескольким ключевым пунктам контролировалось вручную, но сейчас этот процесс автоматизирован благодаря POI.
Антон Сидякин, программист, teamlead:
«Мы автоматизировали процессы благодаря внедренной системе — POI (Points of Interests). Это специальные метки, расставленные в исходном коде. По ним, выполняя сценарии в КОМПАС-3D, описанные пользовательским языком, можно получать отчет, который понятен не только программисту, но и аналитикам с тестировщиками и помогает узнать, что в определенный момент делает КОМПАС-3D и сколько времени на это тратится. Потом эту информацию можно обрабатывать автоматизированно и сравнивать с исходными данными».
Результаты автоматического тестирования производительности. Кстати, кто дочитал до этого места теперь знает, что слоупок из КДПВ — символ нашей команды ускорителей. Слоупоком они считают медленный код)
Какие модели использовали для сравнения?
Мы решили сконцентрироваться на реальных пользовательских моделях, которые подходят под критерии «больших сборок».
Огромную пользу оказала база моделей Конкурса асов компьютерного 3D-моделирования.
Ниже скриншоты полюбившихся нам моделей. Разумеется, это не все, и, более того, мы уверены, что топовые модели последних лет уже совсем скоро станут привычными и КОМПАС с ними будет работать не на пределе, а в своем штатном, скоростном режиме.
Когда нужно было еще больше нагрузить систему, помимо этих моделей использовались также своеобразные «сборные солянки», например:
Использовали и синтетические модели: в ряде случаев на них более ярко проявляются определенные проблемы и их удобней использовать для отладки и тестирования.
О разработке и достигнутых результатах
Отрисовка
В первую очередь стремились ускорить отрисовку (этого просила и большая часть пользователей, участвовавших в анкетировании).
Скорость отрисовки критична во всех процессах, где позиционируется модель или меняется ее отображение. И это не только вращение, перемещение или зуммирование модели. Скорость отрисовки имеет значение и в тех процессах, где обновляется изображение модели:
- добавление компонента в сборку,
- выбор базовых объектов для сопряжений (грани, ребра и т. д.),
- подсветка выбранных частей модели (компонентов, граней),
- изменение видимости объектов (скрыть/показать компонент).
И это далеко не все случаи, где используется подсистема визуализации. Поэтому понятно, почему ускорение отрисовки стало для нас приоритетной задачей.
При этом важно было не только задействовать возможности производительных современных видеокарт, но и не забыть о тех, кто использует не такое сильное и современное железо.
Итогом работ стала реализация двух вариантов отрисовки:
- «Базовый» — задействует расширения Open GL 2.0. Менее требователен к производительности видеокарты. Дает хорошее ускорение отрисовки,
- «Улучшенный» — задействует современные расширения ОpenGL 4.5. Требователен к характеристикам видеокарты. Дает максимальное ускорение отрисовки на современных картах
Настройки отрисовки версии v18.
По умолчанию работает «Автоопределение» — выбирается нужный вариант на основе поддерживаемых расширений OpenGL.
Юрий Корчагин, программист:
«В проблеме производительности отображения больших сцен понятно, что очень много ресурсов тратится на обход сцены и вычисление параметров, с которыми должен отображаться примитив.
Другая проблема связана с большим числом отрисовочных вызовов (обращений к API OpenGL, приводящих к выводу геометрии в буфер кадра).
Исходное состояние также предполагало передачу всех данных на видеокарту из оперативной памяти. А это миллионы треугольников в случае большой сборки.
Косметическими правками тут было не обойтись, поскольку требовалось многократное повышение производительности. Поэтому решено было в значительной степени переписать модуль визуализации.
Первым шагом стало использование видеопамяти для кеширования отрисовочных данных (триангуляция, каркас, грани). Перемещением этих данных в GPU удалось получить 2–3-кратное увеличение FPS.
Затем последовало создание модели данных, адаптированной для визуализации. То есть мы избавились от запросов к 3D-модели, которые могут быть достаточно ресурсоемкими, что также дало свой положительный эффект.
Следующим шагом стало исследование качества и объема триангуляции. Часто мелкие детали отображались с избыточной точностью, и наоборот — в определенных ситуациях вместо гладких поверхностей пользователь видел на экране «рубленую» модель.
Решили использовать несколько уровней детализации и применить аппроксимацию примитивов с учётом углового отклонения. Таким образом убили двух зайцев: повысили качество и устранили чрезмерную нагрузку на GPU».
Уточняет Никита Батьянов, инженер-аналитик:«Для более корректного и в целом приятного отображения моделей мы решили дополнить параметры триангуляции максимальным угловым отклонением. Ранее мы использовали только параметр максимального линейного отклонения.
Напомню: чтобы видеокарта отрисовала наши теоретические представления объектов, необходимо разбить их на треугольники. Чем таких треугольников больше, тем больше изображение будет похоже на «идеальное», но тем сильнее будет нагрузка на видеокарту.
Алгоритм разбивки на треугольники с использованием максимального углового отклонения позволяет более точно отобразить некоторые модели, при этом не так сильно увеличивая количество треугольников, как если бы использовалось только максимальное линейное отклонение.
Мы можем отрисовывать более мелкие относительно габаритов всей модели объекты, несильно завышая количество треугольников».
«Что ж, отображение модели стало быстрее, но не настолько, как нам хотелось бы. На этом этапе мы поняли, что выжать больше из этого подхода не получится.
С другой стороны, использование новейших подходов потребует самых современных видеокарт, что противоречит требованиям к совместимости и явно не понравится части пользователей. Поэтому описанные выше доработки стали доступны в качестве варианта отрисовки «Базовый».
А дальше началось самое интересное…»
В следующей части продолжим наш рассказ про отрисовку, а еще покажем результаты замеров скорости отрисовки при вращении сборки, расчетов МЦХ, добавления компонентов в сборку и расскажем про появление частичного типа загрузки.
А на сладкое оставили для вас видео-ролик по сравнению скорости отрисовки при вращении, масштабировании и сдвиге Редуктора судовой энергетической установки.
Конец первой части. Продолжение следует…
