Тёмная тема
- Ruslan
- Постоялец
MikeNew
> У меня свой движок и откуллить десять тысяч сфер нагрузит проц в пределах
> погрешности, то есть практически незаметно на общем фоне.
> Сразу признаюсь, я не делал точных замеров и могу ошибаться, но субъективное
> впечатление, взятое из диспетчера задач, сложилось именно такое.
> Повторюсь, вполне возможно что я преувеличиваю, я всего лишь посредственный
> любитель, а не профи в таких вопросах, пусть меня поправят если что кто лучше
> разбирается.
Да, действительно чаще статический батчинг как его называют, иным словом culling на cpu обьектов-клонов работает с бОльшей производительностью. Правило справедливо и для Unity, именно поэтому просто так отключить его сложно, и чтобы откуллить что то на gpu приходится использовать обходные пути, и проделать некоторую работу.
Немного расскажу о своих тестах, и почему я так думаю:
По моим наблюдениям, GPU instancing работал хорошо в случае с травой, когда было огромное кол-во одинаковых чанков травинок на большой карте и в поле зрения игрока. После переключения на проход draw call видеокарты для построения сетки, это действительно дало прирост примерно на 20%.
Но, надо понимать, что в каждом случае меш обьекта индивидуален, и приравнивать все тесты в отрыве от модели, платформы, пост-эффектов, и сложности сцены в общем, полагаю, будет не очень обьективно.
В ряде случаев подобной техникой действительно можно добиться производительности на ровном месте.
А вот если например в вашем случае важно, чтобы у вас не было задержки рендера кадров, буффера кадров, например вы делаете fps шутер по сети, и delay по cpu играет критическое значение, от него зависит как быстро на вашем экране вы сможете наблюдать модель игрока-противника. Есть такая штука Nvidia Reflex, которая убирает буффер кадров из cpu, уменьшая задержку ввода и актуализируя текущий кадр который видит игрок. В такой ситуации важно, чтобы cpu не был завален запросами, ведь чем меньше delay, тем быстрее кадр будет подготовлен, и карта его обработает в режиме реального времени. Как правило многие вещи завязаны на main thread, даже банально игровая логика. Теоретически подобные техники могут помочь в этом. Я не транслирую какую-то новую информацию, публичные тесты этих подходов есть в интернете. И сомневаюсь что можно однозначно утверждать что лучше, в отрыве от контекста задачи. В целом и то и то справедливо.
ps. Unity действительно сильно кастомизирует стек рендера в каждом отдельно взятом пайплайне, поэтому на кастомном движке тесты могут конечно различаться.
ДобрыйБарин
если на cpu куллить не тупым перебором сотен тысяч объектов сцены, а по по ускоряющей структуре, то это вообще смешное время будет, по сути бесплатно.
Ruslan
> если на cpu куллить не тупым перебором сотен тысяч объектов сцены, а по по
> ускоряющей структуре, то это вообще смешное время будет, по сути бесплатно.
Интересно.. есть ссылки на эту тему почитать, или ключевые слова на английском, погуглить?
Это по аналогии как с колижнами, регулярная сетка и тому подобное?
MikeNew
Смысл в том, что строим ускоряющую структуру для сцены или группы объектов, и можем делать проверку попадания в фрустум камеры не единичных объектов, а сразу группы объектов, то есть если группа не попадает во фрустум целиком, значит все объекты в нее входящие тоже не попадают, если же группа попадает частично, то мы спускаемся ниже по иерархии и продолжаем тестировать более мелкие группы, это если общими словами.
Ruslan
> Смысл в том, что строим ускоряющую структуру для сцены или группы объектов, и
> можем делать проверку попадания в фрустум камеры не единичных объектов, а сразу
> группы объектов
Ясно, спасибо.
MikeNew
> Интересно.. есть ссылки на эту тему почитать, или ключевые слова на английском,
> погуглить?
Ключевые слова: space-partitioning data structure
Наиболее известные алгоритмы из древовидных структур: Octree, BVH, R-Tree (и его различные вариации), BSP, K-d tree, VP-tree, PH-tree
И одноуровневая адресация: grid, spatial hash, z-ordering/hilbert-curve
Мой вопрос даже не в том, выгодно ли куллить на CPU - это я могу отпрофилировать.
Мой вопрос как разные вендоры относятся к инстансингу всего на уровне. Будет ли это быстро всегда или рассчитывать на это не стоит?
Технически инстанс-моделька не шибко полигональная - 2-3 тысячи поликов, деревья, вообщем. И текстурка с матрицами трансформации - до мегабайта, чаще гораздо меньше - килобайт 300-400. Т.е. по меркам GPU пустяшный объем данных. Казалось бы что тут может пойти не так?
С точки зрения абстрактной логики - всё должно быть отлично. Пока мы не столкнёмся с конкретными драйверами и загадочными тормозами.
Поэтому я больше за реальный опыт спрашиваю, чем за теорию.
g-cont
Ты сделай сначала а потом уже сталкивайся с допйверами
g-cont
> Такой вопрос. Есть несколько тысяч инстанс-деревьев, допустим ёлок.
> Понятное дело, что какая-то часть ёлок окажется позади камеры.
Для того что бы позади камеры ёлок не оказалось, по заветам Кармака нужно использовать Quad Tree Culling.
g-cont
Мегабайт матриц это примерно 16к елок. Если каждая елка по 3к полика, то это суммарно 48 миллионов полигонов, которые пойдут по конвееру. Так почти любая видеокарта сдохнет. Т.е. куллить их так или иначе - придется.
g-cont
> Мой вопрос как разные вендоры относятся к инстансингу всего на уровне. Будет ли
> это быстро всегда или рассчитывать на это не стоит?
Вендоры отлично относятся к инстансингу. Но инстансить надо после куллинга. Это из личного опыта.
В контексте старых API (например DX11 или OGL) - инстансить есть смысл даже по одному объекту, чтобы каждый раз не биндить новый UBO на каждый дроуколл.
HolyDel
> Мегабайт матриц это примерно 16к елок.
Не, никто же не станет рисовать 16к трехмерных елок, разве что захочет саботировать разработку игры.
MikeNew
> Не, никто же не станет рисовать 16к трехмерных елок, разве что захочет
> саботировать разработку игры.
А если так:
?
MrShoor
> если так:
Даже если это не биллборды, то я сильно сомневаюсь что каждое дерево на таком удалении имеет свою полноценную личную матрицу.
MikeNew
> то я сильно сомневаюсь что каждое дерево на таком удалении имеет свою
> полноценную личную матрицу.
А в чем проблема иметь личную матрицу? Ну т.е. представь, что каждое дерево - это импостер в форме куба. В чем проблема с матрицами?