Як кешувати ресурси в моїй системі візуалізації домашнього перекладу

Фон:

Я розробляю просту 3D-систему візуалізації для архітектури типу компонентної системи об'єкта за допомогою C ++ та OpenGL. Система складається з візуалізації та графіку сцени. Коли я закінчу першу ітерацію візуалізації, я можу розподілити графік сцени в архітектуру ECS. На сьогоднішній день воно є тим, чи іншим способом. Якщо можливо, мої цілі для рендерінга:

1. Простота . Це для дослідницького проекту, і я хочу, щоб я міг легко змінити та розширити свої системи (звідси підхід ECS).
2. Продуктивність . Моя сцена може мати багато маленьких моделей, а також великі обсяги з великою кількістю геометрії. Неприпустимо купувати об'єкти з контексту OGL та геометрії буфера в кожному кадрі візуалізації. Я прагну локалізації даних, щоб уникнути пропусків кешу.
3. Гнучкість . Він повинен мати можливість відображати спрайти, моделі та томи (вокселі).
4. Розв’язаний . Графік сцени може бути відновлений до основної архітектури ECS після того, як я напишу рендерінг.
5. Модульний . Було б непогано мати можливість міняти місцями різні рендери, не змінюючи графіку моєї сцени.
6. Референтна прозорість , що означає, що в будь-який момент часу я можу надати їй будь-яку дійсну сцену, і вона завжди відображатиме однакове зображення для цієї сцени. Зокрема, ця мета не обов'язково необхідна. Я думав, що це допоможе спростити серіалізацію сцен (мені потрібно буде вміти зберігати та завантажувати сцени) та надасть мені можливість змінювати місцями на різних сценах під час виконання для тестування / експериментальних цілей.

Проблема та ідеї:

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

1. Централізований кеш. Кожен вузол сцени має ідентифікатор, а візуалізатор має кеш, який відображає ідентифікатори для візуалізації вузлів. Кожен вузол візуалізації містить VAO та VBO, пов'язані з геометрією. Пропуск кеша набуває ресурсів і відображає геометрію до вузла візуалізації в кеші. При зміні геометрії встановлюється брудний прапор. Якщо візуалізатор бачить брудний прапор геометрії під час ітерації через вузли сцени, він відтворює дані за допомогою вузла візуалізації. Коли видаляється вузол сцени, подія транслюється, а візуалізатор видаляє пов'язаний вузол візуалізації з кешу, вивільняючи ресурси. Крім того, вузол позначений для видалення, а рендер відповідає за його видалення. Я думаю, що цей підхід найбільш близько досягає мети 6, одночасно враховуючи 4 і 5. 2 страждає від додаткової складності та втрати локальності даних із пошуковими картами замість доступу до масиву.
2. Розподілений кеш . Аналогічно вище, крім кожного вузла сцени є вузол візуалізації. Це обходить пошук карти. Для адреси локалізації даних вузли візуалізації можуть бути збережені в рендері. Тоді вузли сцени можуть замість цього мати покажчики для візуалізації вузлів, і рендерір встановлює вказівник на пропуск кеша. Я думаю, що цей вид імітує підхід до компонентної сутності, тому він би відповідав решті архітектури. Проблема тут полягає в тому, що тепер вузли сцени містять дані, що стосуються реалізації рендерера. Якщо я зміню спосіб відображення рендерінгу (наприклад, спрайти візуалізації проти томів), тепер мені потрібно змінити вузол візуалізації або додати більше «компонентів» до вузла сцени (що означає змінити графік сцени). З іншого боку, це здається найпростішим способом підключити моє рендеринг за першою ітерацією.
3. Поширені метадані . Компонент метаданих кеша рендерера зберігається у кожному вузлі сцени. Ці дані не залежать від реалізації, але містять ідентифікатор, тип та будь-які інші відповідні дані, необхідні кешу. Тоді пошук кешу можна виконати безпосередньо в масиві, використовуючи ідентифікатор, а тип може вказати, який тип підходу до використання (наприклад, спрайти проти томів).
4. Відвідувач + розподілене відображення . Візуалізація - відвідувач, а вузли сцени - елементи в шаблоні відвідувачів. Кожен вузол сцени містить ключ кешу (як метадані, але лише ідентифікатор), яким маніпулює лише рендер. Ідентифікатор можна використовувати для масиву замість узагальненого пошуку карти. Візуалізатор може дозволити вузлу сцени відправляти іншу функцію візуалізації на основі типу вузла сцени, а ідентифікатор може використовуватися будь-яким кешем. Ідентифікатор за замовчуванням або поза діапазоном вказуватиме на пропуск кешу.

Як би ви вирішили цю проблему? Або у вас є якісь пропозиції? Дякуємо, що прочитали мою стінку тексту!

Перечитавши ваше запитання, я сильно відчуваю, що ви надмірно ускладнюєте проблему. Ось чому:

1. Існує лише два типи системи візуалізації: "Вперед" і "Відкладено", жоден з яких не залежить від графіка сцени.

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

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

Це сказав:

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

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

Тоді ви зможете прийняти зважене рішення.