Как кэшировать ресурсы в моей системе рендеринга homebrew

Справочная информация:

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

  1. Простота . Это для исследовательского проекта, и я хочу иметь возможность легко изменять и расширять свои системы (следовательно, подход ECS).
  2. Производительность . Моя сцена может иметь множество небольших моделей, а также большие объемы с большой геометрией. Недопустимо приобретать объекты из контекста OGL и геометрии буфера для каждого кадра рендеринга. Я нацелен на локальность данных, чтобы избежать промахов в кэше.
  3. Гибкость . Он должен иметь возможность отображать спрайты, модели и тома (вокселы).
  4. Decoupled . График сцены может быть реорганизован в основную архитектуру ECS после того, как я напишу свой рендерер.
  5. Модульное . Было бы неплохо иметь возможность обмениваться в разных рендерах без изменения графика сцены.
  6. Ссылочная прозрачность , что означает, что в любой момент времени я могу дать ей любую действительную сцену, и она всегда будет отображать одно и то же изображение для этой сцены. Эта цель, в частности, необязательно требуется. Я подумал, что это поможет упростить сериализацию сериала (мне нужно будет сохранять и загружать сцены) и дать мне возможность свопинга в разных сценах во время выполнения для тестирования /экспериментов.

Проблема и идеи:

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

  1. Централизованный кеш . Каждый узел сцены имеет идентификатор, а средство визуализации имеет кэш, который отображает идентификаторы для рендеринга узлов. Каждый узел рендеринга содержит VAO и VBOs, связанные с геометрией. Ошибка кэширования получает ресурсы и сопоставляет геометрию с узлом рендеринга в кеше. Когда геометрия изменяется, устанавливается грязный флаг. Если рендер видит флаг грязной геометрии во время итерации через узлы сцены, он отбрасывает данные с помощью узла рендеринга. Когда узел сцены удаляется, событие транслируется, и рендеринг удаляет связанный узел рендеринга из кеша при освобождении ресурсов. В качестве альтернативы, узел отмечен для удаления, и рендеринг отвечает за его удаление. Я думаю, что этот подход наиболее близко достигает цели 6, а также учитывая, что 4 и 5. 2 страдают от дополнительной сложности и потери местоположения данных с помощью поиска карт вместо доступа к массиву. 3 страдает от однородного кеша.
  2. Распределенный кеш . Аналогично выше, за исключением каждого узла сцены, есть узел рендеринга. Это обходит поиск карты. Чтобы определить местоположение данных, узлы рендеринга могут быть сохранены в рендерере. Тогда узлы сцены могут вместо этого иметь указатели для рендеринга узлов, а рендерер устанавливает указатель на пропущенную кэш. Я думаю, что этот тип имитирует подход к компонентам сущности, поэтому он будет соответствовать остальной архитектуре. Проблема здесь в том, что теперь узлы сцены содержат данные, связанные с реализацией приложения. Если я изменил способ отображения рендеринга в рендерере (например, рендеринг спрайтов и томов), теперь мне нужно изменить узел рендеринга или добавить еще «компоненты» к узлу сцены (что также означает изменение графика сцены). С положительной стороны это похоже на самый простой способ запустить и запустить мой первый итерационный рендеринг.
  3. Распределенные метаданные . Компонент метаданных кеша рендеринга хранится в каждом узле сцены. Эти данные не специфичны для реализации, а содержат идентификатор, тип и любые другие необходимые данные, необходимые для кеша. Затем просмотр кеша может выполняться непосредственно в массиве с использованием идентификатора, и тип может указывать, какой тип подхода к рендерингу использовать (например, спрайты и тома).
  4. Посетитель + распределенное сопоставление . Средство визуализации - это посетитель, а узлы сцены - это элементы в шаблоне посетителя. Каждый узел сцены содержит ключ кеша (например, метаданные, но только идентификатор), который обрабатывает только обработчик. Идентификатор может использоваться для массива вместо обобщенного отображения карты. Средство рендеринга может позволить узлу сцены отправлять другую функцию рендеринга на основе типа узла сцены, а идентификатор может использоваться любым кешем. Идентификатор по умолчанию или вне диапазона указывает на пропущенность кеша.

Как бы вы решили эту проблему? Или у вас есть предложения? Спасибо, что прочитали мою стену текста!

10 голосов | спросил Sean 24 AM00000030000001431 2015, 03:42:14

1 ответ


2

После повторного чтения вашего вопроса, я сильно чувствую, что вы преувеличиваете проблему. Вот почему:

  1. Существуют только два типа системы рендеринга: Forward и Deferred, ни одна из которых не зависит от графика сцены.

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

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

Это сказало:

Если вы используете сценарный сценарий доморощенного, вы уже должны использовать интерфейс «Renderer» (или базовый класс) для создания части рендеринга вашего сценария. Шаблон посетителя, использующий двойную отправку, является хорошим подходом к этому, так как вы можете использовать множество типов узлов графа, таких как цвет, текстура, сетка, преобразование и т. Д. Таким образом, во время цикла рендеринга весь рендеринг должен сделать пройдите по древовидной структуре дна сцены сначала, передав себя в качестве аргумента. Таким образом, рендеринг в основном представляет собой набор шейдеров и, возможно, фреймбуфер или два. Результатом этого является то, что код поиска /удаления больше не нужен для системы рендеринга, просто сам сценарий.

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

Тогда вы будете готовы принять взвешенное решение.

ответил Ian Young 7 WedEurope/Moscow2016-12-07T22:30:38+03:00Europe/Moscow12bEurope/MoscowWed, 07 Dec 2016 22:30:38 +0300 2016, 22:30:38

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132