Скорость функции cos() и sin() в шейдерах GLSL?

Question

Меня интересует информация о скорости sin() и cos() в Open GL Shader Language.

GLSL Specification Document указывает, что:

Встроенные функции в основном делятся на три категории:

• ...
• ...
• Они представляют собой операции графического оборудования скорее всего, ускорится в какой-то момент. Функции тригонометрии относятся к категории .

EDIT:

Как уже отмечалось, подсчет тактовых циклов отдельных операций, таких как sin() и cos() на самом деле не рассказать всю историю производительности.

Так, чтобы уточнить мой вопрос, меня действительно интересует, стоит ли оптимизировать sin() и cos() призывает к общим случаям.

Например, в моем приложении для аргумента будет 0. Так что делает что-то вроде этого имеет смысла:

float sina, cosa; 

if (rotation == 0) 
{ 
    sina = 0; 
    cosa = 1; 
} 
else 
{ 
    sina = sin(rotation); 
    cosa = cos(rotation); 
} 

Или же GLSL компилятора или реализации sin() и cos() заботиться о оптимизациях, как это для меня?

Answer 1

Например, в моем приложении, это будет очень часто для аргумент равен 0. Таким образом, делает что-то вроде этого имеют смысл:

No.

Ваш компилятор будет делать один двух вещей.

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

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

Также обратите внимание, что эквивалентность с плавающей точкой вряд ли будет работать. Нет, если вы фактически не передаете шейдеру единый или вершинный атрибут, содержащий ровно 0,0. Даже интерполирование между 0 и отличным от нуля, вероятно, никогда не даст ровно 0 для любого фрагмента.

Answer 2

Не уверен, что это отвечает на ваш вопрос, но очень сложно рассказать вам, сколько часов/слотов требуется для обучения, поскольку это очень сильно зависит от GPU. Обычно это один цикл. Но даже если нет, компилятор может изменить порядок выполнения команд, чтобы скрыть истинную стоимость. Конечно, медленнее использовать поиск текстур для sin/cos, поскольку он должен выполнять инструкции.

Answer 3

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

Если вы хотите взглянуть на код сборки вашего шейдера для конкретной платформы, я бы порекомендовал AMD GPU ShaderAnalyzer.

Answer 4

Это хороший вопрос. Я тоже удивился этому.

Google'd linkscos и sin являются одноцилиндровыми на обычных картах с 2005 года или около того.

Answer 5

Посмотрите, сколько грехов вы можете получить в одном шейдере подряд, по сравнению с math.abs, frac, ect ... Я думаю, что gtx 470 может обрабатывать 200 функций sin для фрагмента без проблем, кадр будет 10 процентов медленнее, чем пустой шейдер. это очень быстро, вы можете отправить результаты. Это будет хорошим показателем вычислительной эффективности.

Answer 6

Компилятор оценивает обе ветви, что делает условия довольно дорогими. Если вы используете как sin, так и cos в вашем шейдере, вы можете рассчитать только sin (a) и cos (a) = sqrt (1.0 - sin (a)), так как sin (x) * sin (x) + cos (x) * cos (x) всегда 1.0