Скільки полігонів на сцені може досягати сучасне обладнання, зберігаючи реальний час, і як дістатися?

Досить базове, в чомусь, питання, але таке, на яке я входив багато людей, насправді не знає відповіді. Виробники графічних процесорів часто наводять надзвичайно велику кількість, а розподіл між полігонами вважається, що різні ігрові двигуни підтримують, часто охоплює декілька порядків, а потім все ще сильно залежить від безлічі змінних.

Я усвідомлюю, що це широке, досить відкрите питання, і я вибачаюся за це, я просто подумав, що все-таки це було б цінним питанням.

Я думаю, що прийнято вважати, що реальний час - це все, що вище, ніж інтерактивне. І інтерактив визначається як "відповідає на вхід, але не є рівним у тому, що анімація здається тужливою".
Тож реальний час буде залежати від швидкості рухів, яку потрібно представляти. Кінопроект працює в 24 FPS і є достатньо реальним часом для багатьох випадків.

Тоді скільки полігонів може працювати машина легко перевірити, перевіривши на собі. Просто створіть невеликий патч VBO як простий тест і FPS лічильник, багато зразків DirectX або OpenGL дадуть вам ідеальну пробну версію для цього еталону.

Ви знайдете, якщо у вас є відеокарта високого класу, на якій ви зможете відобразити близько 1 мільйона полігонів у режимі реального часу. Однак, як ви вже говорили, двигуни не будуть вимагати такої підтримки так легко, оскільки реальні дані світової сцени спричинять цілу кількість вивісок продуктивності, не пов'язаних з кількістю полігонів.

Ти маєш:

• швидкість заповнення
  • вибірка текстури
  • ROP вихід
• здійснювати дзвінки
• візуалізація цілі
• оновлення буфера (рівномірне або інше)
• перевитрати
• складність шейдера
• складність трубопроводу (будь-який зворотний зв'язок, що використовується? Ітераційне затінення геометрії? Оклюзія?)
• точки синхронізації з процесором (зчитування пікселів?)
• багатогранність багатства

Залежно від слабких та сильних сторін певної графічної карти одна чи інша з цих точок буде вузьким місцем. Це не так, як ви можете точно сказати "там, це одне".

Редагувати:

Я хотів би додати, що не можна використовувати специфікацію GFlops однієї конкретної карти та лінійно відображати її на потужність багатокутника. Через те, що обробка полігону повинна пройти через послідовне вузьке місце в графічному трубопроводі, як це докладно пояснено тут: https://fgiesen.wordpress.com/2011/07/03/a-trip-through-the-graphics -pipeline-2011-part-3 /
TLDR: вершини повинні вміщуватися в невеликий кеш перед примітивною збіркою, яка є споконвічною послідовністю (має значення порядок вершинного буфера).

Якщо порівняти GeForce 7800 (старий 9 років?) З цьогорічним 980, здається, що кількість операцій в секунду, на які він здатний, збільшилася в тисячу разів. Але можна покластися на те, що полігони не збираються тиснути в тисячу разів швидше (що за цією простою метрикою було б близько 200 мільярдів на секунду).

EDIT2:

Щоб відповісти на питання "що можна зробити для оптимізації двигуна", як в "не втратити занадто велику ефективність у державних вимикачах та інших накладних витратах".
Це питання, таке старе, як і самі двигуни. І стає більш складним у міру прогресу історії.

Насправді в реальній ситуації типові дані сцени містять багато матеріалів, багато текстур, багато різних шейдерів, багато візуалізації цілей та проходів, багато вершинних буферів тощо. Один двигун, з яким я працював, працював з поняттям пакетів:

Один пакет - це те, що можна надати за допомогою одного дзвінка.
Він містить ідентифікатори для:

• вершинний буфер
• індексний буфер
• камера (дає ціль проходу та візуалізації)
• ідентифікатор матеріалу (дає шейдер, текстури та UBO)
• відстань до очей
• видно

Отже, перший крок кожного кадру - це запустити швидке сортування у списку пакетів, використовуючи функцію сортування з оператором, який надає пріоритет видимості, потім проходить, потім матеріал, потім геометрія та нарешті відстань.

Намалювання близьких предметів отримує пріоритет для максимального раннього відбракування Z.
Проходи є фіксованими кроками, тому нам не залишається іншого вибору, як поважати їх.
Матеріал - це найдорожче, що потрібно переключити на стан після досягнення цілей.

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

Після цього замовлення можна застосувати мегатекстурування, віртуальне текстурування та без атрибутів ( посилання ), якщо вважається необхідним.

Щодо API двигуна також одна поширена річ - це відкласти видачу команд встановлення стану, необхідних клієнтові. Якщо клієнт вимагає "встановити камеру 0", найкраще просто зберегти цей запит, і якщо пізніше клієнт викликає "встановити камеру 1", але без інших команд між ними, двигун може виявити непотрібність першої команди і скинути її . Це усунення надмірності, яке можливо за допомогою «повністю збереженої» парадигми. Заперечуючи "негайну" парадигму, яка була б просто обгорткою над рідним API і видала команди правильно, як упорядковано клієнтським кодом. ( приклад: virtrev )

І нарешті, із сучасним обладнанням дуже дорогий (розроблений), але потенційно дуже корисний крок - перехід API на стиль метал / мантія / вулкан / DX12 та підготовка команд візуалізації вручну.

Двигун, який готує команди візуалізації, створює буфер, який містить "список команд", який перезаписується в кожному кадрі.

Зазвичай існує поняття фрейму "бюджет", гра може собі дозволити. Вам потрібно зробити все за 16 мілісекунд, тому ви чітко розділяєте час графічного процесора "2 мс для lightpre проходження", "4 мс для передачі матеріалів", "6 мс для непрямого освітлення", "4 мс для постпроцесів" ...