Рекомендации по OpenGL ES для условных обозначений

Question

Apple говорит в своих лучших практиках для шейдеров avoid branching, если это возможно, и особенно разветвляется на значения, вычисленные в шейдере. Поэтому я заменил некоторые операторы if встроенной функцией clamp(). Мой вопрос: clamp(), min() и max() могут быть более эффективными или это просто удобство (то есть макро), которые просто расширяются до if блоков?

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

Answer 1

Исторически говорящие графические процессоры поддерживали команды на фрагмент, такие как MIN и MAX намного дольше, чем они поддерживали произвольное условное ветвление. Одним из примеров этого в настольном OpenGL является расширение GL_ARB_fragment_program (теперь оно заменено GLSL), в котором явно указано, что он не поддерживает ветвление, но он предоставляет инструкции для MIN и MAX, а также некоторые другие условные инструкции.

Я был бы уверен, что все графические процессоры будут иметь выделенное оборудование для этих операций, учитывая, насколько распространены min(), max() и clamp() в шейдерах. Это не гарантируется спецификацией, потому что реализация может оптимизировать код, но он считает нужным, но в реальном мире вы должны использовать встроенные функции GLSL, а не сворачивать свои собственные.

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

void main() { 
    vec3 N = ...; 
    vec3 L = ...; 
    float NDotL = dot(N, L); 
    if (NDotL > 0.0) 
    { 
     // Lots of very intensive code for an awesome shadowing algorithm that we 
     // want to avoid wasting time on if the fragment is facing away from the light 
    } 
} 

Просто пережатие NDotL до 0-1, а затем всегда обработки теневой код на каждом фрагменте только умножаться через последний срок теневым NDotL будет много затраченных усилий, если NDotL было первоначально < = 0, и теоретически мы можем избежать этих накладных расходов с помощью ветки. Причиной такого рода не всегда является выигрыш в производительности, так это то, что он очень зависит от того, как оборудование реализует ветвление шейдеров.