GLES2.0 glVertexAttribPointer: снижение производительности за использование нечетных значений шага и смещения?

У меня есть некоторые упакованные данные вершин, которые работают до 6 байтов на вершину:

glVertexAttribPointer Shader.pos3d_loc, 3, GL_UNSIGNED_BYTE, True, 6, 0
glVertexAttribPointer Shader.norm_loc, 3, GL_UNSIGNED_BYTE, True, 6, 3

Существуют ли какие-либо потери производительности (например, скрытые копии памяти), вызванные использованием шагов и смещений, которые не кратны 4 байтам?


performance stride opengl-es-2.0
person Peeling    schedule 22.03.2017    source источник
comment
На этом этапе копирование не производится. Вы либо копируете данные в буфер вершин, либо значения доступны одно за другим по мере необходимости. Эти значения здесь только для того, чтобы сообщить openGL, как интерпретировать ваш буфер. Например, normal[i].x = (float)((ubyte)(((void*)ptr)[stride*i])) где ubyte получен из параметра GL_UNSIGNED_BYTE.   -  person Matic Oblak    schedule 22.03.2017
comment
Спасибо :) Я понимаю, что делает эта функция, но я знаю, что есть несколько ошибок, связанных с выравниванием и форматированием, когда GL будет молча преобразовывать данные внутри при существенном снижении производительности. Я задавался вопросом, не спровоцирует ли указание нечетного шага и выравнивания GL внутреннюю повторную буферизацию данных, когда происходит окончательный вызов рендеринга.   -  person Peeling    schedule 24.03.2017

Ответы (1)


arrow_upward
0
arrow_downward

Краткий ответ: «это зависит»:

На ПК и (по крайней мере, на некоторых) устройствах Android нет заметного штрафа за плотную упаковку трехкомпонентных атрибутов таким образом.

В IOS (во всяком случае, на момент написания этого) существует большое снижение производительности. Реализация IOS GL внутренне распаковывает и выравнивает все атрибуты, которые не выровнены по 4 байтам, вызывая нагрузку как на память, так и на ЦП. Нагрузка на ЦП может быть незаметной, если только вы не работаете с динамическими VBO.

person Peeling    schedule 04.04.2017