Всем привет. За что мы любим 3д графику? За то, что она не дает заскучать, скорость появления новых технологий зашкаливает и нам нужно постоянно держаться на гребне волны, чтобы быть в теме. Мы можем просиживать за компьютером сутками ̶и̶ ̶г̶у̶с̶я̶м̶и̶ . Кто то любит ковыряться в машинах, а мы собираем своих франкенштейнов своими руками, чтобы увеличить скорость рендера на 5%, разгоняем процессоры, жжем материнки и видеокарты, ведь адреналин может выделяться не только в экстримальных местах, но и прямо за рабочим креслом 🙂 С выходом Vray 3.5 сильно захотелось попробовать ГПУ рендеринг, и это превратилось в этот пост. Под катом все подробности выбора железа, установки, настройки, все подводные камни и ощущения от нереальных скоростей 🙂
После просмотра демо ролика мне буквально не сиделось на месте и я начал собирать информацию о ГПУ рендере везде где только мог, выяснилось что Bulgarov уже давно переехал на ГПУ:
и собрал какого-то нереального монстра с водяным охлаждением, а так же небезызсвестный DabartiCGI тоже перешел на ГПУ и во всю пропагандирует вегетарианство и сыроедство его.
У него система уже попроще, но всё равно довольно дорогая. Основные тезицы которые я почерпнул исследовав интернет такие:
1. Видеокарты могут быть разными(но просчет только Nvidia)
2. Количество памяти может быть разным. Оно не суммируется и используется наименьший объем памяти из всех доступных у видеокарт
3. Можно сочетать Ati/AMD(для отображения изображения с мониторов) и Nvidia для рассчетов
4. Sli режим не нужен, достаточно просто выбрать нужное количество видеокарт для просчетов
5. Основная проблема это охлаждение и питание.
Немудурствуя лукаво я зашел на интернет магазин и купил 7 видеокарт Nvidia 1070GTX 8Gb(25-35 тыс руб штука) которые были в наличии разных производителей и цены, чтобы проверить все тезисы выше, а так же 2 БП 1200 и 1000Ватт(8-10тр штука) чтобы точно хватило(заявленное потребление у видеокарт 150 ватт штука).
Первым делом выяснилось, что просто так вставить 7 видеокарт в одну материнскую плату невозможно, даже если в ней есть 7 PCI-express-x16, они попросту туда не влезут, поэтому покупать специальную материнскую плату не надо. Достаточно любой "Gaming" с 4хPCIexpress-x16(это стандартные длинные пазы для видеокарт) и 3xPCIexpress-x1(урезанные, обведены красным)
К сожалению моя настольная материнка была с тремя большими ГПУ слотами и совсем не подходила даже для простой ГПУ станции, поэтому я пошел на балкон:
У нормальных людей на балконе можно найти много чего полезного, а у меня там — рендерферма 🙂 С открытым окном в минус 30 рендерится очень хорошо:) Оказалось что почти все материнки для Xeon "нормальные" и я выбрал Gigabyte x99 Gaming 5:
Она компануется 4мя длинными и 3мя короткими PCI через 1, что позволяет воткнуть 4 видеокарты в обычный корпус MidiTower за 1000 рублей. Вы спросите, а как же всё таки воткнуть все 7 видеокарт в одну материнскую оплату? Оказалось, что тут без рукожопства уже не обойтись и найти детали в обычном супермаркете электроники около дом нереально, потому что нужно расширить короткие PCIexpress слоты с помощью специальных расширителей — "Raiser" или "Extender PCI". Они есть разных видов, но мне посоветовали вот такие:
Попутно выяснилось что Fedex,DHL и все скоростные доставщики больше физлицам в РФ не отправляют ничего, продавец прискорбно сообщил об этом и добавил мне к заказу ещё 2 удлинителя(к 20 которым я купил) и отправил всё Почтой россии/EMS, я превратился в ждуна и собрал 4хГПУ систему:
До этого у меня была 980GTX 4 GB и я решил оставить её для тестов рендера с разной памятью. Zotac был самый дорогой, в металлическом корпусе, с диодной подсветкой и т п + ещё одна самая дешевая 1070gtx от нвидии из пластика и с всего 8 пинами питания вместо 16 как у остальных.
Проблемы при сборке:
1. Видеокарты очень длинные (возможно кому то придется вырезать мешающиеся запчасти)
3. Видеокарты лучше втыкать по одной, почему то на двух материнках изначально заработало только во втором слоте ГПУ с одной видеокартой(в биосе стоит по умолчанию первый PCIe)
4. Биос стартует гораздо дольше!
5. Windows может после старта висеть с черными экранами 2-5 минут каждый запуск(проверено на 7ке и 10ке). Просто ждите 🙂
Ну и вот так это всё примерно выглядит.
Я перешел на 4к рендеринг видео, поэтому мощностей всегда не хватает. Например этот 21 секундный ролик в Corona рендерился почти неделю, это конечно не приемлиемо:
Даже с использованием Vray один кадр с 4к честным дофом или моушен блюром рендерится около 2х часов на моем 44ядерном Xeon, что то типа такого:
GPU на 4х видеокартах рендерит подобные кадры за 25-30 минут. При этом стоимость видеокарт в сумме около 2000$ , а процессор 2500$ Конечно настраивать ГПУ сцены несколько сложнее, некоторые вещи ещё не поддерживаются, но доработка практически любой сцены не занимает много времени.
Первый тест ГПУ я провел на сцене изначально сделанной под ЦПУ :
Превью рендеринг анимации 480*320 с честным дофом занял 3 часа, пока я ездил в магазин за едой на одном компьютере! Это очень круто.(сетка немного глючит изза неверного подбора ФПС, именно за этим такие тесты и прогоняются 🙂
Остальные видеокарты ушли во второй рабочий комп моему напарнику, и в ожидании удлинителей пока всё останется так как есть, а потом будем добивать рабочий объем до 7 ГПУ 🙂 но это уже в следующем посте, а пока все — итак сильно затянул, не забывайте ставить оценки, если вам понравилось и репостить где надо и не надо.
Всем привет. Меня зовут Глеб Булгаков, я — программист. Вместе с тех. артистом Романом Лещенко мы работаем в компании Fractured Byte и хотим поделиться нашими знаниями и опытом в деле оптимизации реалтаймового контент пайплайна.
Работая вместе в компании BWF, мы успели приложить руку ко множеству разных по жанру, целевой платформе и сложности проектов. Среди них было и портирование всемирно известных проектов на мобильные платформы (Life Is Strange, Brothers: A Tale of Two Sons), разработка собственных проектов на разные платформы (In Fear I Trust, Renoir), и даже прототипирование и R’n’D для VR игр. У нас 9 лет опыта работы с движком Unreal Engine, начинали с UE3. Мы успели поработать с такими компаниями как Square Enix, Disney, 505 Games, Framestore, Chillingo и т.д. Таким образом, мы почти никогда не сталкивались с одними и теми же задачами и нам всегда приходилось изыскивать возможности отрисовать много контента на экране за минимальное количество миллисекунд. Так что, можно сказать, что мы съели на этом пару собак 🙂
В этой статье мы разберем принцип работы и отрисовки простейшей сцены на GPU, а также познакомимся с базовыми понятиями, на которые будем впоследствии ссылаться. Надеемся, эта статья будет интересна как техническим специалистам, так и артистам, желающим понять, почему “злые программисты” говорят им уменьшать разрешение текстур.
Содержание
Обзор
Перед тем как погрузиться с головой в оптимизацию, нужно разобраться в том, как работает GPU и процессах, которые происходят в движке.
В упрощенном виде конвейер рендера (именно конвейер, потому что многие последующие процессы зависят от результатов завершения предыдущих) работает по такому принципу:
- Загружаем ассеты (модели, шейдера, текстуры, партиклы и т.д.) в RAM-память и память видеокарты.
- С помощью Culling систем на CPU (детально про них ниже) отбрасываем невидимые в данный момент из камеры объекты, формируя тем самым список объектов, которые мы должны отрисовать.
- Вызываем команды для отрисовки этих объектов на GPU.
- GPU делает ряд сложных вычислений, проецируя 3D-объекты на 2D экран, беря в учет условия освещения в сцене и материалы объектов.
- Применяем пост-эффекты (пост-процессы).
Как вы могли заметить, основная “магия” происходит в четвертом пункте. Что это за сложные вычисления, как они влияют на производительность и как научится их контролировать? Этим мы сегодня и займемся, а начнём с того, какие объекты можно создавать и какие операции можно делать над ними, а потом плавно перейдем к отрисовке сцены.
Также перед тем, как начать, стоит сказать, что эта статья не описывает какой-то конкретный конвейер рендера в конкретном движке (хотя мы и будем приводить много примеров из UE4), а старается обобщить наши знания таким образом, чтобы вы могли понять откуда “растут ноги” у современных контент-пайплайнов и графических фич, а также поняли, почему количество полигонов в модели уже давно не является адекватным мерилом производительности.
Мы также хотим уточнить, что эта статья не затрагивает моменты оптимизации самого рендера, мы хотим научить локализовывать проблемные места в игре, показать способы их обхода, а также показать как бороться с ограничениями платформы — иногда это означает разработку нового пайплайна для создания или оптимизации контента, иногда замену эквивалентными решениями, а иногда — отказ от данной фичи.
Какие ресурсы можно создать на GPU?
Текстуры
Самый известный и самый объемный ресурс — это, наверное, текстура. Чисто для примера мы будем использовать простую текстуру 8х8 пикселей с призраком из игры Pac-man:
Текстура обладает рядом характеристик: размером, форматом, наличием мип мап. Это самые основные настройки текстуры, на которые стоит обращать внимание, поскольку они определяют объем памяти, занимаемый этим ресурсом, определяют — хранится ли текстура со сжатием и т. д. Стоит также разобраться в типах текстур — на удивление, их достаточно много. Итак, поехали:
Одномерные (в терминологии DirectX 11 — Texture1D).
По своей природе одномерные текстуры лучше всего подходят для градиент-маппинга. UE4 не использует этот вид текстур, но предоставляет альтернативу — Curve Atlas , который является оберткой над двумерной текстурой и позволяет работать со множеством одномерных текстур сразу. Детальнее с ними можно ознакомиться тут.
Двумерные (в терминологии DirectX 11 — Texture2D).
Тут и рассказывать особо нечего — это самый распространенный тип текстур, который с большой вероятностью будет делать
90% картинки в вашем проекте. Текстуры объектов, интерфейса, служебные LUT, карты высот — как правило, это все Texture2D.
Трехмерные (в терминологии DirectX 11 — Texture3D).
Такие текстуры можно представить как массив или слои двумерных текстур. В редакторе создавать их как ассеты можно, но для этого их нужно включить ( r.AllowVolumeTextureAssetCreation 1 ). В основном, 3D текстуры используются самим движком для работы с Vector Fields, Distance Fields, Volumetric Lightmaps и т.д. То есть там, где необходимо пространственное представление данных.
Самый последний тип и, наверное, самый интересный — куб текстуры (CubeMaps, в терминологии DirectX 11 — TextureCube).
В памяти они представлены как 6 двухмерных текстур, которые соответствуют граням куба (+x -x +y -y +z -z). По сути, куб текстура — это способ сделать привязку пикселя к направлению. Самый яркий пример — скайбокс. В UE4 эта текстура отображается как Равнопромежуточная проекция ( Long Lat Projection ).
Каждая текстура может обладать уменьшенными копиями самой себя — это так называемые мип-мапы (mip maps). Дело в том, что когда мы рисуем объект, он может находится как близко, так и далеко от игрока и соответственно иметь разный размер на экране. В результате, если объект имеет текстуру большего разрешения, чем его фактический размер на экране в этот момент — невозможно стабильно получить один и тот же цвет пикселя на экране с течением времени. В результате возникает эффект, известный под названием Муар (от фр. Moire).
Чтобы избежать этого, придумали мипмапы, которые по сути являются уменьшенными копиями оригинальной текстуры, из которых значительно проще получить стабильный цвет пикселя на удалении. GPU сам определяет, какую мипмапу ему лучше использовать для каждого пикселя в зависимости от расстояния до пикселя. Генерация мипмап поддерживается аппаратно и нам не нужно заботиться об их создании вручную.
Стоит еще указать об особом свойстве текстур — RenderTarget . Это свойство текстуры, которое позволяет рисовать (рендерить) картинку в неё в реальном времени. С точки зрения GPU, это именно свойство текстуры, хотя в UE4 рендер таргеты — отдельные ассеты, которые можно создавать и использовать. Детальнее — тут. Все рендер таргеты используют формат, который не поддерживает сжатие. Таким образом, простой рендер таргет 1024х1024 с форматом RGBA8 будет занимать 4 Мб. Другими словами, с рендер таргетами нужно знать меру и следить за тем, чтобы они выгружались.
1024х1024 RGBA8 — 4 Мб
2048х2048 RGBA8 — 16 Мб
1920×1080 RGBA8
8 Мб
Константные буферы
Следующий ресурс — константный буфер. Это просто участок памяти, который используется для хранения информации, например, для геометрии модели или же для параметров материалов.
Рассмотрим простейшую модель — куб. Как вам, возможно, известно — треугольник является наименьшим элементом, из которого состоят все 3D-модели. И чтобы описать модель способом, который будет понятен GPU, нам нужно 2 буфера — вершинный и индексный. Вершинный описывает, как ни странно, вершины модели: их позицию, нормали, текстурные координаты и т. д. Индексный буфер содержит индексы вершин, порядок соединения этих вершин, необходимый для построения на экране отдельного треугольника.
Шейдера и стейты
Вместе с ресурсами на GPU можно создавать дополнительные объекты: стейты и шейдера. Первые из них являются объектами, которые описывают правила взаимодействия с конкретным ресурсом, вторые же —отдельные программы для GPU.
SamplerState — стейт, который определяет, как GPU делает выборку с текстуры: фильтрацию, адресацию. Это, наверно, единственный стейт в UE4, на который мы явно можем влиять, когда устанавливаем текстуру в материале или в настройках самой текстуры. При описании текстур я избегал слова “сэмплить” (sample), под сэмплингом подразумевается вычисление цвета, именно вычисление, а не простая загрузка из памяти. Каждый раз, когда мы сэмплим из текстуры, GPU делает много вычислений, чтобы определить, с какой мипмапы брать цвет, возможен даже блендинг между мипмапами; для определенных типов фильтрации, таких как Anisotropic, в учет берется и положение треугольника в пространстве. Сэмплинг — достаточно сложная операция, и чем меньше текстур используется при рендеринге объекта, тем лучше.
А что будет, если мы попытаемся взять пиксель за пределами текстуры (напомним, что текстура находится в пределах 0. 1)? Для этого и была придумана адресация.
Когда мы рендерим какой-то объект в текстуру, мы также указываем способ его наложения, используя Blend State . Например, можно сделать перезапись исходного пикселя или смешивание с ним.
Одним из важных элементов в Render Pipeline является z-buffer. Идея z-buffer заключается в присвоении каждому пикселю значения глубины. Когда GPU рисует геометрию, на экране она сравнивает значение глубины нового пикселя и уже существующего, чтобы определить, какой пиксель находится ближе к камере. Можно рассматривать z-buffer как некоторую версию occlusion кулинга (про него ниже), правда, не очень эффективную, поскольку мы уже отрисовываем объект, который на самом деле никак не повлияет на результирующую картинку. Все взаимодействие с z-buffer происходит с помощью стейта DepthStencilState .
Хоть большую часть стейтов мы и не можем контролировать напрямую, понимание того, как они работают, может помочь нам при профайлинге кадра.
Шейдер — это программа, которая выполняется на GPU. Есть разные виды шейдеров, но мы остановимся только на двух основных: Vertex Shader (вершинный) и Pixel Shader (пиксельный). Основной задачей вершинного шейдера является трансформация объекта в пространстве (перемещение, поворот и масштабирование) и проецирование на экран. После того, как GPU спроецировала примитив на экран, вступает в работу пиксельный шейдер, который и вычисляет цвет пикселя.
В UE4 шейдеры создаются путём визуального программирования в Material Editor. Каждый материал имеет в себе предопределенные входы (инпуты) (Base Color, Metallic, Roughness, Emissive и т.д.), и мы, создавая ноды и соединяя их в определенной последовательности, генерируем код шейдера. Этот код является только частью шейдера и определяет основные параметры материала. В свою очередь, материал генерирует не один шейдер, а целое множество шейдеров для разных проходов материала.
Операции на GPU
Перед тем как начать рисовать новый кадр, нужно почистить весь мусор из предыдущего. Обычно очищают только z-buffer с помощью команды Clear . Текстуру с основной картинкой не очищают: из-за особенностей любой сцены, каждый пиксель будет перезаписан. Другими словами — это лишняя работа.
Когда дело доходит до отрисовки меша, мы используем команды Draw *, а если точнее — семейство команд. Нельзя сказать, насколько тяжелый один DrawCall , нужно учитывать контент, который вы подаете, и сколько он занимает места на экране. Эти факторы прямым образом влияют на производительность в целом. Нарисовав 1000 объектов в сцене, мы не так убьем производительность, как партиклом с прозрачной геометрией, который отображается на весь экран (а то и физически больше него).
На GPU есть особая текстура — Swapchain, которая представляет собой область экрана, где рисуется наша сцена. Swapchain состоит из нескольких буферов: front buffer — содержит то, что сейчас мы видим на экране, и back buffer — текстура, в которую мы рисуем следующий кадр. Когда наша сцена отрисована и находится в back buffer, мы вызываем команду Present — она меняет front buffer и back buffer местами. И отрисовка следующего кадра начинается снова.
Спасибо за внимание, надеемся, вы почерпнули новых знаний и лучше поняли возможности GPU и для чего они используются. Во второй части статьи мы рассмотрим на практическом примере процесс отрисовки сцены. До встречи на UE4 Daily!
Для врея однозначно проц. Если взять VrayRT, то он считает на видеокарте.
В новом Vray Next есть вроде фича использования GPU во время обычного рендера, но не знаю как работает, не щупал.
Процессор CPU такая штука (условно) что может делать рассчеты сложных формул (например трассировка луча света с преломлением и рассеиванием).
Процессор GPU попроще, сложные формулы в нем не помещаются, только простые. Но зато у GPU не одно ядро для рассчетов, и не десять, как в современных CPU, a тысячи. Поэтому, если получается разбить одну сложную формулу на тысячу маленьких, но которые, посчитанные вместе, дадут такой же результат, то GPU будет рендерить в десять, а то и сто раз быстрее, чем CPU. Это уже GPU рендеры, например Otoy Octane или тот же VrayRT.
Но такой подход добавляет ограничений, и отнюдь не каждую формулу можно так разбить. Так что GPU рендеры имеют значительное количество ограничений в работе и годятся не для всех задач.
Но их скорость это конечно большой плюс.
Так что выбирайте для рендеринга проц помощней, чем больше ядер, тем лучше, и обязательно Intel — он поддерживает (совместно с вреем) определенные инструкции для ускорения рендера.
Ну либо осваивайте сетевой рендер Distributed Rendering — несколько компов попроще смогут рендерить одну картинку по сети быстрее, и стоить будут меньше, чем топовый многоядерный проц.
Вроде бы тот же Ryzen 16 ядерный от АМД по бенчмарку обходит такой же по цене камень интел но на 8 ядер. Вот в GPU рендеренге меня отпугивает, что он не умеет рендерить environment fog и много чего ещё.
Я так понимаю Distributed Rendering это тот же vray swarm? Когда все компьютеры в локальной сети рендерят одну сцену?
redpax, да, Vray Swarm это эволюция DR. Когда я работал с 3д, у меня началось с двух ПК на балконе, а закончилось семью ПК в серверной стойке. Сокращение времени рендера в пять раз, и основной комп может оставаться не нагруженным, для продолжения работы, что чертовски удобно.
Насколько обходит? Какой бенчмарк, что или в чем тестируется? В целом думаю результат будет плюс-минус на одном уровне.
Только 16ть ядер single core операции будут делать дольше, яем такого же уровня проц с 8ю ядрами. Для рендера не столь важно, а для работы на такой станции может быть критично.
А еще интелы легко и спокойно разгоняются (не знаю, как сейчас, но раньше у АМД с разгоном не все гладко было), что сокращает время рендера на 10-20%. Достаточно лишь мать подходящую выбрать (ну и проц серии К), и купить хороший большой кулер.
Конечно, дело ваше, какой проц выбрать для работы.
Я просто думаю, купить imac pro (и не переживать об отсутствии GPU рендеринга) или собирать обычный ПК с возможностью GPU рендеринга?
redpax, однозначно ПК — будет и дешевле, и сможете начинку менять по своему усмотрению, хоть три видяшки поставить для GPU ренедра (я так делал, для одного из проектов, но и до и после все на CPU рендерил).
Угу, вижу, что процы АМД по цене выигрывают, но лично я выберу интел, даже если это чуть дороже.
