Довольно простой, в некотором смысле, вопрос, но тот, на который многие люди, в том числе и я, на самом деле не знают ответа. Производители графических процессоров часто ссылаются на чрезвычайно высокие цифры, а разброс между полигонами, который, как утверждают разные игровые движки, часто поддерживает несколько порядков, а затем все еще сильно зависит от множества переменных.
Я знаю, что это широкий, почти открытый вопрос, и я прошу прощения за это, я просто подумал, что, тем не менее, это будет ценный вопрос.
gpu
optimisation
Llamageddon
источник
источник
Ответы:
Я думаю, что общепризнанно, что в режиме реального времени все, что выше интерактивного. И интерактивный определяется как «реагирует на ввод, но не является гладким в том, что анимация кажется неровной».
Поэтому реальное время будет зависеть от скорости движений, которые нужно представлять. Кинотеатр проецирует со скоростью 24 FPS и достаточно в режиме реального времени для многих случаев.
Тогда сколько полигонов может обработать машина, легко проверить, проверив себя. Просто создайте небольшой патч VBO в виде простого теста и счетчика FPS, многие образцы DirectX или OpenGL предоставят вам идеальный тестовый стенд для этого теста.
Вы найдете, если у вас есть высококачественная видеокарта, которая может отображать около 1 миллиона полигонов в режиме реального времени. Однако, как вы сказали, движки не будут требовать поддержки так легко, потому что реальные данные сцены вызовут ряд скачков производительности, которые не связаны с количеством полигонов.
У тебя есть:
В зависимости от слабых и сильных сторон конкретной графической карты, тем или иным из этих пунктов будет узкое место. Это не так, как вы можете сказать наверняка "там, это один".
РЕДАКТИРОВАТЬ:
Я хотел добавить, что нельзя использовать спецификацию GFlops для одной конкретной карты и отображать ее линейно в соответствии с емкостью выталкивания полигонов. Из-за того, что обработка полигонов должна проходить через последовательное узкое место в графическом конвейере, как подробно объяснено здесь: https://fgiesen.wordpress.com/2011/07/03/a-trip-through-the-graphics -pipeline-2011-part-3 /
TLDR: вершины должны помещаться в небольшой кэш перед примитивной сборкой, которая изначально является последовательной (порядок буфера вершин имеет значение).
Если вы сравните GeForce 7800 (9-летнего возраста?) С 980-м годом в этом году, то число операций в секунду, на которые она способна, увеличилось в тысячу раз. Но вы можете поспорить, что он не будет толкать полигоны в тысячу раз быстрее (что составляет около 200 миллиардов в секунду по этой простой метрике).
EDIT2:
Чтобы ответить на вопрос «что можно сделать для оптимизации двигателя», например, «не потерять слишком много эффективности в переключателях состояния и других издержках».
Этот вопрос так же стара, как сами двигатели. И становится все сложнее по мере развития истории.
Действительно, в реальной ситуации типичные данные сцены будут содержать много материалов, много текстур, много разных шейдеров, много целей рендеринга и проходов, много вершинных буферов и так далее. Один двигатель, с которым я работал, работал с понятием пакетов:
Один пакет - это то, что может быть обработано одним вызовом отрисовки.
Содержит идентификаторы для:
Таким образом, первый шаг каждого кадра - выполнить быструю сортировку в списке пакетов, используя функцию сортировки с оператором, который отдает приоритет видимости, затем передает, затем материал, затем геометрию и, наконец, расстояние.
Рисование близких объектов получает приоритет, чтобы максимизировать раннее выбраковку Z.
Проходы - это фиксированные шаги, поэтому у нас нет другого выбора, кроме как уважать их.
Материал - самая дорогая вещь для переключения состояний после целей рендеринга.
Даже между разными идентификаторами материалов можно выполнить подупорядочение с использованием эвристического критерия, чтобы уменьшить количество изменений шейдера (наиболее затратных в операциях переключения состояния материала) и, во-вторых, изменения привязки текстуры.
После всего этого упорядочения можно применять мега-текстурирование, виртуальное текстурирование и рендеринг без атрибутов ( ссылка ), если это необходимо.
В API движка также есть одна общая вещь - отложить выдачу команд установки состояния, требуемых клиентом. Если клиент запрашивает «установить камеру 0», лучше всего сохранить этот запрос, и если позже клиент вызовет «установить камеру 1», но между ними нет других команд, механизм может обнаружить бесполезность первой команды и отбросить ее. , Это устранение избыточности, что возможно при использовании «полностью сохраненной» парадигмы. В противоположность «немедленной» парадигме, которая будет просто оберткой над нативным API и выдаст команды в порядке, указанном клиентским кодом. ( пример: виртрев )
И, наконец, на современном оборудовании очень дорогой (в разработке), но потенциально очень полезный шаг - переключить API в стиле metal / mantle / vulkan / DX12 и подготовить команды рендеринга вручную.
Механизм, который готовит команды рендеринга, создает буфер, который содержит «список команд», который перезаписывается в каждом кадре.
Обычно существует понятие кадра «бюджет», которое может себе позволить игра. Вам нужно сделать все за 16 миллисекунд, чтобы четко разделить время графического процессора: «2 мс для прохода света», «4 мс для прохода материалов», «6 мс для непрямого освещения», «4 мс для постобработки» ...
источник