Здесь есть (по крайней мере) два фактора. Графические процессоры могут использовать кэш вершин после преобразования при визуализации индексированных примитивов. Размер этого кэша варьируется, и он используется во время отдельного вызова отрисовки (насколько я знаю, не для нескольких вызовов, поэтому не имеет значения, как часто вы меняете данные буфера в этом контексте).
Если вы упорядочите свои данные, чтобы использовать преимущества этого кэша (пример алгоритма здесь ), вы можете увидеть улучшения производительности. Однако эта организация больше связана с упорядочением ваших индексов, чтобы каждый тройной индекс повторно использовал как можно больше недавно просмотренных вершин. Это, вероятно, не имеет никакого отношения к вашему конкретному сценарию, если только ваши треугольники через буфер индекса также случайно не разбросаны по буферу ... в этом случае вы, вероятно, часто продуваете кэш. В вашем вопросе мне не было ясно, так ли это, поэтому я подумал, что стоит упомянуть.
Проблема, скорее всего, заключается в том, что графические процессоры также кэшируют доступ к памяти для данных вершин во время рисования. Размер этого кеша также довольно ненадежен, и вполне возможно, что вы можете получить высокую частоту промаха в этом кеше на отдельных ядрах, обрабатывающих эти индексы в очень плохо локализованные данные вершин.
Что касается или нет, это приведет к тому, что достаточно проблем с производительностью, чтобы быть красным флагом в вашем приложении, и, в частности, (это звучит так), чтобы перестроить ваш алгоритм, чтобы лучше организовать данные за счет читабельности алгоритма ... это не то, что я могу ответить, вам придется профилировать некоторые сценарии и посмотреть.
Я бы лично допустил ошибку в отношении читабельного, обслуживаемого кода, хотя, как мне кажется, любой отсутствующий кеш, который вы собираетесь вызвать, не будет достаточно значительным для пользователей, чтобы это заметить.