Как 3D-игры настолько эффективны? [закрыто]

Есть то, чего я никогда не понимал. Как может такая большая игра для ПК, как GTA IV, использовать 50% моего процессора и работать со скоростью 60 кадров в секунду, в то время как демонстрация DX с вращающимся чайником @ 60 кадров в секунду использует колоссальные 30%?

В общем это потому что

1. Игры оптимальны относительно того, что им нужно сделать, и
2. Они пользуются особым преимуществом вашего оборудования.

Например, одна простая оптимизация, которую вы можете сделать, заключается в том, чтобы не пытаться рисовать то, что не видно. Рассмотрим сложную сцену, похожую на городской пейзаж из Grand Theft Auto IV . Рендерер фактически не рендерит все здания и сооружения. Вместо этого он отображает только то, что видит камера. Если бы вы могли лететь к задней части тех же зданий, лицом к оригинальной камере, вы бы увидели половинную конструкцию из полой оболочки. Каждая точка, которую камера не может видеть, не отображается - поскольку вы ее не видите, нет необходимости пытаться показать ее вам.

Кроме того, существуют оптимизированные инструкции и специальные методы, когда вы разрабатываете для определенного набора оборудования, чтобы обеспечить еще более быстрое ускорение.

Другая часть вашего вопроса состоит в том, почему демо использует так много ресурсов процессора:

... в то время как DX-демонстрация вращающегося чайника @ 60fps использует колоссальные 30%?

Демонстрация графических API-интерфейсов (например dxdemo), как правило, обращается к так называемому программному средству визуализации, когда ваше оборудование не поддерживает все функции, необходимые для показа симпатичного примера. Эти функции могут включать такие вещи, как тени, отражение, трассировка лучей, физика и так далее.

Это имитирует функцию полностью полнофункционального аппаратного устройства, которое вряд ли существует, чтобы продемонстрировать все функции API. Но поскольку аппаратного обеспечения на самом деле не существует, оно работает на вашем процессоре. Это гораздо более неэффективно, чем делегирование на видеокарту - отсюда ваша высокая загрузка ЦП.

Терпение, технические навыки и выносливость.

Во-первых, DX Demo - это прежде всего учебное пособие, поэтому оно сделано для ясности, а не для скорости исполнения.

Это довольно большая тема для обсуждения, но разработка игр в первую очередь связана с пониманием ваших данных и ваших путей исполнения почти до патологической степени.

1. Ваш код разработан вокруг двух вещей - ваших данных и вашего целевого оборудования.
2. Самый быстрый код - это код, который никогда не выполняется - сортируйте ваши данные по пакетам и выполняйте только дорогостоящие операции с данными, которые вам нужны
3. Как вы храните свои данные, является ключевым - стремитесь к непрерывному доступу, это позволяет вам пакетировать процесс с высокой скоростью.
4. Парелизировать все, что возможно
5. Современные процессоры работают быстро, современные ОЗУ работают очень медленно. Промахи кеша смертельны.
6. Выдвиньте как можно больше графического процессора - он имеет быструю локальную память, поэтому может пролистывать данные, но вам нужно помочь, правильно организовав свои данные.
7. Избегайте использования большого количества переключателей рендеринга (снова объединяйте одинаковые данные вершин), так как это приводит к остановке графического процессора
8. Переверните ваши текстуры и убедитесь, что они имеют степень двойки - это повышает производительность кеша текстур на GPU.
9. Используйте как можно больше уровней детализации - низкие / средние / высокие версии 3D-моделей и переключайтесь в зависимости от расстояния до проигрывателя камеры - нет смысла рендерить версию с высоким разрешением, если на экране всего 5 пикселей.

3D-игры отлично умеют обманывать ваши глаза. Например, существует метод, называемый окклюзией окружающего пространства экрана (SSAO), который дает более реалистичное ощущение, затеняя те части сцены, которые близки к поверхностным неоднородностям. Если вы посмотрите на углы вашей стены, то увидите, что в большинстве случаев они кажутся немного темнее, чем центры.

Тот же самый эффект может быть достигнут с помощью радиации, которая основана на довольно точном моделировании. Radiosity также учитывает больше эффектов от прыгающих огней и т. Д., Но это вычислительно дорого - это метод трассировки лучей.

Это только один пример. Существуют сотни алгоритмов для компьютерной графики в реальном времени, и они в основном основаны на хороших приближениях и обычно делают много предположений. Например, пространственная сортировка должна выбираться очень тщательно в зависимости от скорости, типичного положения камеры, а также количества изменений в геометрии сцены.

Эти «оптимизации» огромны - вы можете эффективно реализовать алгоритм и заставить его работать в 10 раз быстрее, но выбор умного алгоритма, который дает аналогичный результат («обман»), может заставить вас перейти от O (N ^ 4) к O ( журнал (N)).

Оптимизация реальной реализации - это то, что делает игры еще более эффективными, но это только линейная оптимизация.

Eeeeek!

Я знаю, что этот вопрос старый, но его волнует, что никто не упомянул VSync !!! ???

Вы сравнили загрузку процессора в игре на скорости 60 кадров в секунду с использованием процессора в демонстрационной версии чайника на скорости 60 кадров в секунду.

Разве не очевидно, что оба работают (более или менее) со скоростью ровно 60 кадров в секунду? Это приводит к ответу ...

Оба приложения работают с включенной vsync! Это означает, что частота кадров рендеринга привязана к «вертикальному интервалу пропуска» вашего монитора. Графическое оборудование (и / или драйвер) будет отображаться только при макс. 60fps. 60fps = 60 Гц (Гц = в секунду) частота обновления. Таким образом, вы, вероятно, используете довольно старый, мерцающий ЭЛТ или обычный ЖК-дисплей. На ЭЛТ, работающем с частотой 100 Гц, вы, вероятно, увидите частоту кадров до 100 Гц. VSync также применяется аналогично ЖК-дисплеям (частота обновления которых обычно составляет 60 Гц).

Таким образом, демонстрация чайника может работать намного эффективнее! Если он использует 30% процессорного времени (по сравнению с 50% процессорного времени для GTA IV), то он, вероятно, использует меньше процессорного времени в каждом кадре и просто дольше ждет следующего вертикального интервала. Чтобы сравнить оба приложения, вы должны отключить vsync и измерить снова (вы будете измерять гораздо более высокие fps для обоих приложений).

Иногда нормально отключить vsync (в большинстве игр есть опция в настройках). Иногда вы увидите «разрывающиеся артефакты», когда vsync отключен.

Вы можете найти подробную информацию об этом и почему он используется в Википедии: http://en.wikipedia.org/wiki/Vsync

Хотя многие ответы здесь дают отличные указания на то, как я вместо этого отвечу на более простой вопрос, почему

• GTA4 взял 400 миллионов долларов за первую неделю
• Crytech написал очень впечатляющую графическую демонстрацию, чтобы nVidia «показалась» на выставке. Полученные впечатления помогли им создать то, что станет FarCry.
• Выручка и операционная прибыль Valve за 2005 год были определены как 70 и 55 миллионов долларов США соответственно.

Возможно, лучшим примером (безусловно, одним из самых известных) является программное обеспечение Id. Они очень рано, во времена Командора Кина (задолго до 3D), осознали, что придумали хитрый способ достичь чего-то ¹ , даже если бы он опирался на современное аппаратное обеспечение (в данном случае графическую карту EGA!), Которое графически превосходило конкуренция, которая сделает вашу игру выдающейся. Это было правдой, но они также поняли, что вместо того, чтобы самим придумывать новые игры и контент, они могли лицензировать технологию, получая таким образом доход от других, в то же время имея возможность разрабатывать движок следующего поколения и, таким образом, перепрыгивать через конкурентов. ,

Способности этих программистов (в сочетании с деловыми знаниями) сделали их богатыми.

Тем не менее, это не обязательно деньги, которые мотивируют таких людей. Скорее всего, столько же желание достичь, выполнить. Деньги, которые они заработали в первые дни, просто означают, что у них теперь есть время посвятить тому, что им нравится. И хотя у многих есть сторонние интересы, почти все они все еще программируют и пытаются найти способы добиться большего успеха, чем на прошлой итерации.

Проще говоря, у человека, написавшего демонстрационную версию чайника, была одна или несколько из следующих проблем:

• меньше времени
• меньше ресурсов
• меньше вознаграждения
• меньше внутренней и внешней конкуренции
• меньшие цели
• меньше талантов

Последнее может показаться грубым ^2, но, несомненно, есть некоторые, которые лучше других, у кривых колокола иногда есть крайние концы, и они, как правило, притягиваются к соответствующим крайним концам того, что делается с этим навыком.

Меньшие цели, вероятно, будут главной причиной. Целью демонстрации чайника была именно эта демонстрация. Но не демонстрация навыка программиста ³ . Это была бы демонстрация одного маленького аспекта (большой) ОС, в данном случае DX-рендеринга.

Для тех, кто просматривает демо-версию, это не имеет значения, так как он использует гораздо больше ресурсов процессора, чем требуется, при условии, что он выглядит достаточно хорошо. Там не будет никакого стимула для устранения отходов, когда не будет бенефициара. В сравнении игра хотела бы иметь запасные циклы для лучшего ИИ, лучшего звука, большего количества полигонов, большего количества эффектов.

1. в этом случае плавная прокрутка на ПК
2. Вероятно, больше, чем я, поэтому мы ясно об этом
3. Строго говоря, это было бы демонстрацией и для его / ее менеджера, но опять же, здесь бывают время и / или визуальное качество.

По нескольким причинам

• 3D игровые движки высоко оптимизированы
• большая часть работы выполняется вашим графическим адаптером
• 50% Хм, позвольте мне предположить, что у вас есть двухъядерное и используется только одно ядро ​​;-)

РЕДАКТИРОВАТЬ: дать несколько номеров

Athlon-64 с частотой 2,8 ГГц и графическим процессором NV-6800. Результаты:

• Процессор: 72,78 Мфлопс
• GPU: 2440,32 Мфлопс

Иногда в сцене может происходить больше, чем кажется. Например, вращающийся чайник с тысячами вершин, отображением окружения, рельефным отображением и другими сложными пиксельными шейдерами, которые визуализируются одновременно, представляет собой большую обработку. Часто эти демонстрации чайников просто предназначены для демонстрации какого-то особого эффекта. Они также не всегда могут наилучшим образом использовать графический процессор, когда абсолютная производительность не является целью.

В игре вы можете увидеть похожие эффекты, но обычно они выполняются скомпрометированным способом, чтобы максимизировать частоту кадров. Эти оптимизации распространяются на все, что вы видите в игре. Возникает вопрос: «Как мы можем создать наиболее эффектную и реалистичную сцену с наименьшим количеством вычислительной мощности?» Это то, что делает программистов игр одними из лучших оптимизаторов.

1. Управление сценой. kd-деревья, отбраковка усадочных желез, bsps, иерархические ограничивающие рамки, наборы частичной видимости.
2. LOD. Переключение версий с более низкой детализацией для замены удаленных объектов.
3. Самозванцы. Как LOD, но даже не объект, а просто картинка или «рекламный щит».
4. SIMD.
5. Пользовательское управление памятью. Выровненная память, меньше фрагментации.
6. Пользовательские структуры данных (то есть без STL, относительно минимальные шаблоны).
7. Сборка местами, в основном для SIMD.

Судя по всем квалифицированным и хорошим ответам, тот, который имеет значение, все еще отсутствует: счетчик использования ЦП в Windows не очень надежен. Я предполагаю, что эта простая демонстрация чайника просто вызывает функцию рендеринга в цикле ожидания, блокируя при замене буфера.

Теперь счетчик использования ЦП Windows просто смотрит на то, сколько процессорного времени затрачивается на каждый процесс, а не на то, как используется это ЦП. Попробуйте добавить

Sleep(0);

только после возврата из функции рендеринга и сравнения.

Кроме того, существует множество приемов с художественной точки зрения для экономии вычислительных ресурсов. Во многих играх, особенно старых, тени предварительно рассчитываются и «запекаются» прямо в текстуры карты. Много раз художники пытались использовать плоскости (два треугольника) для представления таких вещей, как деревья и спецэффекты, когда они выглядели в основном одинаково. Туман в играх - это простой способ избежать рендеринга удаленных объектов, и часто игры имеют несколько разрешений каждого объекта для дальнего, среднего и ближнего обзора.

Суть любого ответа должна быть такова: преобразования, которые выполняют трехмерные движки, в основном указываются в сложениях и умножениях (линейная алгебра) (без ветвей и переходов), операции рисования одного кадра часто задаются таким образом, чтобы несколько работа таких аддонов может выполняться параллельно. Ядра GPU очень хороши для добавления дополнений, и они имеют десятки или сотни ядер добавления дополнений.

Процессору остается заниматься простыми вещами - например, ИИ и другой игровой логикой.

Как может такая большая игра для ПК, как GTA IV, использовать 50% моего процессора и работать со скоростью 60 кадров в секунду, в то время как демонстрация DX с вращающимся чайником @ 60 кадров в секунду использует колоссальные 30%?

В то время как GTA, скорее всего, будет более эффективным, чем DX-демо, измерение эффективности ЦП таким способом по существу не работает. Эффективность может быть определена, например, тем, сколько работы вы выполняете в данный момент времени. Простой контрпример: порождает один поток на логический процессор и позволяет запустить на нем простой бесконечный цикл. Вы получите нагрузку на процессор на 100%, но это не эффективно, так как никакой полезной работы не сделано.

Это также приводит к ответу: как игра может быть эффективной? При программировании «больших больших игр» огромные усилия направлены на оптимизацию игры во всех аспектах (которая в настоящее время обычно включает в себя многоядерные оптимизации). Что касается демоверсии DX, то она не в быстром беге, а в демонстрации концепций.

Я думаю, вы должны взглянуть на использование GPU, а не CPU ... Бьюсь об заклад, графическая карта в GTA IV намного загруженнее, чем в образце Teapot (он должен быть практически простаивает).

Может быть, вы могли бы использовать что-то вроде этого монитора, чтобы проверить, что:

http://downloads.guru3d.com/Rivatuner-GPU-Monitor-Vista-Sidebar-Gadget-download-2185.html

Также следует учитывать частоту кадров, возможно, образец чайника работает на полной скорости (возможно, 1000 кадров в секунду), и большинство игр ограничены частотой обновления монитора (около 60 кадров в секунду).

Посмотри ответ на vsync; именно поэтому они работают с одинаковой частотой кадров.

Во-вторых, процессор в игре лидирует. Упрощенное объяснение состоит в том, что основной игровой цикл - это просто бесконечный цикл:

while(1) { 
  update();
  render();
}

Даже если ваша игра (или, в данном случае, чайник) не приносит больших результатов, вы все равно съедаете процессор в цикле.

50% процессоров в GTA «более производительны», чем 30% в демоверсии, так как более чем вероятно, что они вообще ничего не делают; но GTA обновляет тонны деталей. Даже добавление «Sleep (10)» в демонстрационную версию, вероятно, снизит его процессор на тонну.

Наконец, посмотрите на использование GPU. Демонстрация, вероятно, занимает <1% на современной видеокарте, в то время как GTA, вероятно, получит большинство во время игры.

Короче говоря, ваши тесты и измерения не точны.

Демонстрация чайника DX не использует 30% процессорного времени, выполняя полезную работу. Он занят ожиданием, потому что ему больше нечего делать.

Из того, что я знаю о серии Unreal, некоторые соглашения нарушены как инкапсуляция. Код компилируется в байт-код или напрямую в машинный код в зависимости от игры. Кроме того, объекты визуализируются и упаковываются в виде сетки, а такие вещи, как текстуры, освещение и тени, предварительно рассчитываются, тогда как для чистой трехмерной анимации это требуется в реальном времени. Когда игра на самом деле запущена, есть также некоторые оптимизации, такие как рендеринг только видимых частей объекта и отображение деталей текстуры только при приближении. Наконец, вполне вероятно, что видеоигры предназначены для того, чтобы максимально эффективно использовать платформу в данный момент времени (например: Intelx86 MMX / SSE, DirectX, ...).

Я думаю, что здесь отсутствует важная часть ответа. Большинство ответов говорят вам «Знай свои данные». Дело в том, что вы должны точно так же и с той же степенью важности также знать свои:

• Процессор (часы и кеши)
• Память (частота и задержка)
• Жесткий диск (с точки зрения скорости и времени поиска)
• GPU (# ядра, часы и память / кеши)
• Интерфейсы: контроллеры Sata, ревизии PCI и т. Д.

НО , вдобавок ко всему, на современных современных компьютерах вы никогда не сможете воспроизводить настоящее видео 1080p с >> 30 футов в секунду (одно изображение 1080p в 64 битах займет 15 000 Ko / 14,9 МБ). Причиной этого является выборка / точность. В видеоигре никогда бы не использовалась двойная точность (64 бита) для пикселей, изображений, данных и т. Д., А вместо этого использовалась бы более низкая пользовательская точность (~ 4-8 бит), а иногда и меньшая точность, масштабируемая с помощью методов интерполяции, чтобы обеспечить разумные вычисления время.

Существуют и другие методы, такие как отсечение данных (как в стандарте OpenGL, так и в программной реализации), сжатие данных и т. Д. Также следует помнить, что текущие графические процессоры могут быть в> 300 раз быстрее, чем текущие процессоры, с точки зрения аппаратных возможностей. Тем не менее, хороший программист может получить коэффициент в 10–20 раз, если ваша задача не будет полностью оптимизирована и полностью распараллеливаема (особенно распараллеливаемая задача).

По своему опыту я могу сказать, что оптимизация подобна экспоненциальной кривой. Для достижения оптимальной производительности требуемое время может быть невероятно важным.

Итак, чтобы вернуться к чайнику, вы должны увидеть, как геометрия представлена, сэмплирована и с какой точностью V видны в GTA 5, с точки зрения геометрии / текстур и, самое главное, деталей (точность, сэмплирование и т. Д.)