Ускорение вычислений преобразования

Первое, что я бы сделал, это объединить ваше вращение и преобразовать матрицы в одну матрицу, прежде чем вы войдете в цикл for... таким образом вы не вычисляете два матричных умножения и вектор в каждом цикле for; вместо этого вы будете умножать только один вектор и матрицу. Во-вторых, вы можете захотеть развернуть свой цикл, а затем скомпилировать его с более высоким уровнем оптимизации (на g++ я бы использовал как минимум -O2, но я не знаком с MSVC, поэтому вам придется перевести этот уровень оптимизации самостоятельно) . Это позволит избежать любых накладных расходов, которые могут возникнуть в ответвлениях в коде, особенно при очистке кеша. Наконец, если вы еще не изучили это, попробуйте выполнить некоторые оптимизации SSE, поскольку вы имеете дело с векторами.

ОБНОВЛЕНИЕ: я собираюсь добавить последнюю идею, которая будет включать в себя многопоточность... в основном конвейер ваших вершин, когда вы выполняете свою многопоточность. Так, например, предположим, что у вас есть машина с восемью доступными потоками ЦП (т. е. четырехъядерная с гиперпоточностью). Настройте шесть потоков для обработки вершинного конвейера и используйте неблокирующие очереди с одним потребителем/производителем для передачи сообщений между этапами конвейера. Каждый этап преобразует один член вашего массива вершин из шести элементов. Я предполагаю, что существует множество этих массивов вершин с шестью элементами, поэтому установка в потоке, который проходит через конвейер, позволяет очень эффективно обрабатывать поток и избегать использования мьютексов и других блокирующих семафоров и т. д. Для больше информации о быстрой неблокирующей очереди одного производителя/потребителя, см. мой ответ здесь.

ОБНОВЛЕНИЕ 2: у вас есть только двухъядерный процессор... поэтому откажитесь от идеи конвейера, так как он столкнется с узкими местами, поскольку каждый поток будет бороться за ресурсы ЦП.

Я не могу сделать это в шейдере, потому что я объединяю все спрайты сразу. Это означает, что я должен использовать ЦП для вычисления преобразований.

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

Что вам нужно сделать, так это не иметь меньше партий. Вы должны иметь правильное количество партий. Вы понимаете, что зашли слишком далеко с пакетной обработкой, когда отказываетесь от преобразования вершин графического процессора в пользу преобразования ЦП.

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

Кроме того, GLM — прекрасная математическая библиотека, но она не рассчитана на максимальную производительность. Как правило, это не то, что я бы использовал, если бы мне нужно было преобразовывать 300 000 вершин на процессоре каждый кадр.

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

Редактировать:

Это больше похоже на то, о чем я думал.

// Apply Matrix
glm::vec4 transformed;
glm::mat4 translation = m_rotation * m_translation;
for ( int i=0; i<6; i++ )
{
    transformed.x = vertices[i].x;
    transformed.y = vertices[i].y;
    transformed.z = vertices[i].z;
    transformed.w = 1.f; // ?
    /* I can't find docs, but assume they have an in-place multiply
    transformed.mult(translation);
    // */
    vertices[i].x = transformed.x;
    vertices[i].y = transformed.y;
}

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

Вы можете попытаться продублировать какой-нибудь стек и сделать больше меньших циклов.

glm::vec4 transformed[6];
for (size_t i = 0; i < 6; i++) {
    transformed[i].x = vertices[i].x;
    transformed[i].y = vertices[i].y;
    transformed[i].z = vertices[i].z;
    transformed.w = 1.f; // ?
}
glm::mat4 translation = m_rotation * m_translation;
for (size_t i = 0; i < 6; i++) {
    /* I can't find docs, but assume they have an in-place multiply
    transformed.mult(translation);
    // */
}
for (size_t i = 0; i < 6; i++) {
    vertices[i].x = transformed[i].x;
    vertices[i].y = transformed[i].y;
}

Как упомянул Джейсон, раскручивание этих циклов вручную может быть интересным.

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

Я подозреваю, что вызов этой функции меньше важнее, чем ее ускорение. Тот факт, что у вас есть эта проверка needTransform внутри этой функции, заставляет меня думать, что это, вероятно, актуально.

Когда у вас есть проблемы высокого уровня, подобные этой, в низкоуровневом коде, вы в конечном итоге просто слепо вызываете этот метод снова и снова, думая, что он бесплатный. Независимо от того, верны ли ваши предположения о частоте потребностей в Transform, они могут быть совершенно неверными.

Реальность такова, что вы должны просто вызвать этот метод один раз. Вы должны применить Transform, когда хотите применить Transform. Вы не должны вызывать applyTransform, когда вам может понадобиться applyTransform. Интерфейсы должны быть контрактом, относитесь к ним как к таковым.

Если вы настаиваете на выполнении вычислений на процессоре, вам следует заняться математикой самостоятельно.

Прямо сейчас вы используете матрицы 4x4 в 2D-среде, где одной матрицы 2x2 для вращения и простого вектора для перемещения должно быть достаточно. Это 4 умножения и 4 сложения для поворота, а также два сложения для перевода.

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

По сравнению с операциями, выполняемыми этими матрицами 4x4 прямо сейчас, это намного меньше.