Это, вероятно, задавали снова и снова, но я не мог найти ничего полезного, поэтому здесь все повторяется ...
В моем приложении мне нужно визуализировать довольно большую сетку (пару миллионов треугольников).или больше) и у меня возникают некоторые проблемы с получением приличной частоты кадров.Процессор в основном работает на холостом ходу, поэтому я определенно привязан к GPU.Изменение разрешения не влияет на производительность, поэтому оно не привязано ни к фрагменту, ни к растру.
Сетка динамическая (но локально статическая), поэтому я не могу сохранить все это на видеокарте и отрендерить его однимвызов.По причинам, связанным с применением, данные хранятся в виде дерева с вокселями в листьях, что означает, что я выбираю усеченный в основном бесплатно.Данные вершин состоят из координат, нормалей и цветов - текстуры и шейдеры не используются.
Мой первый подход состоял в том, чтобы просто визуализировать все из памяти, используя одно большое STREAM_DRAW VBO, которое оказалось слишком медленным.Первоначально я думал, что, возможно, я перегружал шину (выдавая ~ 150 МБ на кадр), поэтому я реализовал схему кэширования, которая хранит геометрию, недавно использованную для визуализации объекта в статических VBO на графической карте, при этом каждый VBO хранит паруОт 100 КиБ до пары МБ данных (хранение большего количества данных на VBO приводит к большему перерасходу кэша, поэтому здесь есть компромисс).На рисунке ниже приведен пример того, как выглядят данные, где все окрашенное в красный цвет рисуется из кэшированных VBO.
Пример визуализированных данных http://gimaker.users.sourceforge.net/0010.png
Как показывают цифры ниже, яне вижу впечатляющего увеличения производительности при использовании кеша.Для полностью статической сетки около 1 миллиона треугольников я получаю следующие частоты кадров:
- Без кэширования: 1,95 Гц
- Кэширование с использованием массивов вершин: 2,0 Гц (> 75% отсетка кэшируется)
- Кэширование с использованием
STATIC_DRAW VBO: 2,4 Гц
Итак, мои вопросы, как мне это ускорить?Т.е.:
- Какой рекомендуемый формат вершин для получения достойной производительности?Я использую чередованное хранилище с позициями и нормалями, такими как
GL_FLOAT и GL_UNSIGNED_BYTE для цветов, с одним байтом заполнения, чтобы получить 4-байтовое выравнивание (всего 28 байт / общее количество вершин). - Использует ли тот же буфер для нормалейдля всех моих блоков может помочь (все блоки выровнены по оси, поэтому я могу выделить обычный буфер размером с наибольшую запись в кэше и использовать его для них всех).
- Как узнать, какая часть конвейераявляется узким местом?У меня нет впечатляющей видеокарты (Intel GM965 с драйверами Linux с открытым исходным кодом), поэтому возможно, что я достиг своего предела.Какую пропускную способность можно ожидать от типичного аппаратного обеспечения (встроенная графика 2-3 года, современная интегрированная графика, современная дискретная графика)?
- Любые другие советы о том, как вы справитесь с этим, подводные камни и т. Д.
Меня не интересуют ответы, в которых предлагается LOD (я уже проверял это), советы от конкретного поставщика или использование функций OpenGL из чего-либо более 1,5.