Индексное рисование быстрее, чем неиндексное

8

Мне нужно нарисовать много полигонов, состоящих из 6 вершин (два треугольника).

Без каких-либо текстурных координат, нормалей и т. Д. Оба подхода дают 72 байта. В будущем мне, безусловно, понадобятся координаты текстур и нормали, из-за которых индексное рисование будет занимать меньше памяти. Не много, хотя.

Итак, мой вопрос: для ВАО с небольшим перекрытием вершин, какой подход быстрее? Меня не волнует дополнительная память, потребляемая неиндексным рисованием, только скорость.

Изменить: чтобы было понятно.

Неиндексный подход:

float[18] vertices = {
//Triangle 1
1,1,0,
1,0,0,
0,0,0,

//Triangle 2
1,0,0,
0,1,0,
0,0,0,
};

Индексный подход:

float[12] vertices = {
1,1,0,
1,0,0,
0,0,0,
0,1,0,
};

int[6] indices = {
//Triangle 1
0,1,2,

//Triangle 2
0,3,2
};
KaareZ
источник
1
... почему бы просто не измерить оба подхода для вашего конкретного приложения на целевом оборудовании и выяснить это окончательно?
Шон Миддледич

Ответы:

4

Я пытаюсь ответить на вопрос. Я думаю, что вы должны идти с индексами по нескольким причинам:

1) В любом случае, индексирование является бесплатной операцией на стороне GPU, вы не берете штрафы там. (добавлено) Конечно, индексы являются операциями произвольного доступа и могут снизить производительность кэша памяти GPU.

2) Индексирование может позволить кеш вершин графического процессора выполнять те немногие оптимизации для перекрывающихся вершин.

3) Меньший объем памяти на стороне графического процессора много раз означает лучшую производительность, поскольку пропускная способность памяти является одним из узких мест, а также потому, что операции извлечения (например, 10_10_10_2 -> 4 x float) во многих случаях не требуют затрат.

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


Смотрите также это:

/programming/17503787/buffers-indexed-or-direct-interlaced-or-separate

Мако
источник
1
ре 1) как насчет оптимизации порядка индексов для производительности кеша? Есть алгоритмы для этого даже. как переупорядочение кеша. 3) как насчет издержек самого буфера индекса? иногда трип-удаление приводит к меньшему количеству данных для загрузки ... хотя это не распространенный случай.
Джерико
1

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

#version 330 core

const vec3 data[4] = vec3[]
(
//Triangle 1
vec3(1,1,0),
vec3(1,0,0),
vec3(0,0,0),

//Triangle 2
vec3(1,0,0),
vec3(0,1,0),
vec3(0,0,0)
);

void main()
{
  gl_Position = vec4( data[ gl_VertexID ], 1.0);
}
чокнутый урод
источник
А при рендеринге с использованием экземпляров вы можете установить точку, поворот и масштаб для каждого экземпляра.
Лассе
@ratchet freak Позиции не всегда будут одинаковыми, так как это для ландшафта (и я не могу использовать triangle_strips, так как это будет очень трудно реализовать должным образом, потому что оно основано на вокселях). Мне просто нужно знать, должен ли я использовать индексное или неиндексное рисование. Или даже старые списки отображения, если это будет быстрее.
KaareZ
@KaareZ Вы все еще можете использовать форму, чтобы изменить положение. Или используйте инстансинг для передачи данных по каждому лицу.
чокнутый урод
0

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

это будет варьироваться в зависимости от аппаратного обеспечения и очень многих сложных факторов. измерение с помощью профилирования автоматически рассмотрит все эти вещи для вас без необходимости что-либо знать о них.

jheriko
источник
-1

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

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

Но...

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

72 байта настолько малы, что, вероятно, было бы недостаточно эффективно использовать память, чтобы не индексировать их.

Несколько практических правил: индексирование более эффективно использует память. Индексирование теряет цветовую точность. Не индексируется быстрее.

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

Индекс работает так, что когда он рисует пиксель, ему присваивается индекс, и он должен искать цвет в таблице заранее определенного размера. (Допустим, 256 байтов, поэтому вы ограничены 256 цветами). Затем он рисует этот пиксель. При индексировании данные пикселей не хранятся напрямую, поэтому нет ограничения по цвету 256. Но в изображении размером 100x100 ваше 400-байтовое изображение теперь составляет 10000 байтов.

Отказ от ответственности, я вытаскиваю эти цифры из своей шляпы.

Evorlor
источник
Я не спрашивал о цветовом сжатии.
KaareZ
Супер короткий ответ: индексация всегда медленнее. Я спрятал свой ответ там, но добавил его в первую строку, теперь я пошел в сжатие цветов, потому что это то, что индексирование.
Evorlor
Я говорю об индексировании вершин, а не о сжатии текстур. Как, например, у вас есть v0, v1, v2 и v, 3. Чтобы нарисовать два треугольника, вы указываете следующие индексы: 0, 2, 3, 0, 2, 4
KaareZ
О, моя ошибка. В этом случае я не знаю, но я предполагаю, что применимы те же практические правила (минус потеря разрешения)
Evorlor