Новичок OpenGL ES 2.0 Математический вопрос - PullRequest
1 голос
/ 01 июня 2011

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

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

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

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

Ответы [ 2 ]

1 голос
/ 01 июня 2011

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

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

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

1 голос
/ 01 июня 2011

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

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

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

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

...