Блог

После некоторого сопротивления могучей силе ES 2.0 я, наконец, сдаюсь и пытаюсь проглотить столько, сколько может откусить мой рот. Вот мои вопросы. Согласно нескольким хорошим книгам и примерам, мой вершинный шейдер не может видеть связь между вершинами, но фрагментный шейдер видит.

Затем

1) можно ли с уверенностью сказать, что я могу выполнить всю математику OpenGL (например, вычисление матрицы, манипулирование векторами и т.д.) Во фрагментном шейдере, Чтобы быть привязанным к графическому процессору? (Мне кажется, что все примеры по-прежнему выполняют 3D-математику на стороне процессора непосредственно перед отправкой данных вершин в шейдер. )

2.a) Если да, должен ли я просто сбросить всю мою математическую библиотеку ES 1.1 и написать новую в GLSL?

2.б) Если да, будет ли фрагментный шейдер обрабатывать анимацию костей?

2.c) Если да, то куда мне следует поместить отбраковки? Допустим, я хотел бы применить AABB и Frustum. На мой взгляд, наиболее логичным местом для размещения таких отбраковок по-прежнему было бы на стороне процессора b / c, что в конечном итоге уменьшит количество вершин, перемещаемых в шейдер. Нет?

Золотое правило гласит: не выполняйте ненужных операций! Вот почему вы вычисляете свою матрицу преобразования на процессоре (поскольку она не изменяется для каждого фрагмента или даже для каждой вершины). Итак, вам нужно только умножить каждую вершину на одну матрицу (одна матричная операция на CPU часто все еще лучше, чем тысячи на GPU). Просто перемещать все в фрагментный шейдер, чтобы ограничить графический процессор приложения, — плохая идея. Конечно, если вы выполняете много ненужных операций для каждого фрагмента, вы, вероятно, будете ограничены графическим процессором, но для чего, если избегание этих вычислений повышает общую производительность при тех же результатах?

Имейте в виду, что простые операции с матрицей 4×4 также имеют незначительные затраты на процессор, поскольку они выполняются в худшем случае один раз на объект. Анимация костей (путем смешивания вершин) — это другое дело. Обычно это делается в вершинном шейдере, поскольку преобразование изменяется для каждой вершины. Но опять же, перемещение этих вычислений во фрагментный шейдер ничего не дает, кроме, вероятно, более низкой производительности.

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

1) Это безопасно и работает? ДА.

2a) Вы должны это сделать? Возможно, производительность GPU зависит от баланса между нагрузкой CPU и GPU, поэтому перемещение всего в GPU может все замедлить. Выполнение некоторых вычислений на CPU снижает нагрузку на GPU. Сбалансируйте его и профилируйте, прежде чем принимать такие важные решения. Из-за этого в большинстве игр есть математическая библиотека процессора.

2b) Нет, обычно это обрабатывается вершинным шейдером.

2c) Зависит от типа отбраковки, OpenGL уже выполняет отбраковку в виде усечения, вы можете выполнять отбраковку на CPU, но, опять же, сбалансируйте нагрузку между CPU и GPU. Отбраковка по пикселям должна выполняться в шейдере фрагментов.