Velocidad de las funciones cos() y sin() en sombreadores GLSL?

Question

Estoy interesado en información sobre la velocidad de sin() y cos() en Open GL Shader Language.

El GLSL Specification Document indica que:

Las funciones integradas básicamente se dividen en tres categorías:

• ...
• ...
• representan un hardware de gráficos de operación es probable que acelere en algún momento. Las funciones de trigonometría se incluyen en esta categoría .

EDIT:

Como se ha señalado, contar ciclos de reloj de las operaciones individuales como sin() y cos() en realidad no cuentan toda la historia rendimiento.

Para aclarar mi pregunta, lo que realmente me interesa es si vale la pena optimizar sin() y cos() llamadas para casos comunes.

Por ejemplo, en mi aplicación, será muy común que el argumento sea 0. Lo mismo ocurre algo como esto sentido:

float sina, cosa; 

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

O el GLSL compilador o las sin() y cos() implementaciones cuidar de optimizaciones así para mí?

Answer 1

Por ejemplo, en mi aplicación que va a ser muy común que el argumento sea 0. Por lo tanto hace algo como esto sentido:

Nº

su compilador hará una de dos cosas

1. Emitirá una rama condicional real. En el mejor de los casos posibles, si 0 es un valor que es coherente a nivel local (de modo que los grupos de sombreadores a menudo lleguen a 0 o que no sean cero juntos), entonces podría obtener un mejor rendimiento.
2. Evaluará ambos lados de la condición, y solo almacene el resultado para el correcto de ellos. En ese caso, no has ganado nada.

En general, no es una buena idea usar la lógica condicional para bailar con un rendimiento tan pequeño como este. Tiene que ser realmente grande para que valga la pena, como un discard o algo así.

Además, tenga en cuenta que no es probable que la equivalencia de coma flotante funcione. No, a menos que realmente pase un atributo uniforme o de vértice que contenga exactamente 0.0 para el sombreador. Incluso la interpolación entre 0 y distinto de cero probablemente nunca producirá exactamente 0 para ningún fragmento.

Answer 2

No estoy seguro de si esto responde a su pregunta, pero es muy difícil decirle cuántos relojes/ranuras toma una instrucción, ya que depende mucho de la GPU. Por lo general, es un solo ciclo. Pero incluso si no, el compilador puede reorganizar el orden de ejecución de la instrucción para ocultar el costo real. Ciertamente, es más lento usar búsquedas de textura para sin/cos que para ejecutar las instrucciones.

Answer 3

Tendría que probar esto usted mismo, pero estoy bastante seguro de que la bifurcación en un sombreador es mucho más costosa que un cálculo sin o cos. Los compiladores GLSL son bastante buenos para optimizar los sombreadores, preocupándose por una optimización prematura. Si más tarde descubre que, a través de todo su programa, sus sombreadores son el cuello de botella, entonces puede preocuparse por optimizar esto.

Si desea ver un código de ensamblado de su sombreador para una plataforma específica, le recomiendo AMD GPU ShaderAnalyzer.

Answer 4

Esta es una buena pregunta. Yo también me preguntaba esto.

Google'd links dicen cos y sin son de un solo ciclo en las tarjetas convencionales desde 2005 más o menos.

Answer 5

ver cuántos pecados se pueden obtener en un sombreado en una fila, en comparación con math.abs, frac, ect ... creo que un gtx 470 puede manejar 200 funciones de pecado por fragmento sin problemas, el marco será de 10 por ciento más lento que un sombreador vacío. es muy rápido, puede enviar resultados. Será un buen indicador de eficiencia computacional.

Answer 6

El compilador evalúa ambas ramas, lo que hace que las condiciones sean bastante caras. Si usa tanto sen como cos en su sombreador, puede calcular solamente sin (a) y cos (a) = sqrt (1.0 - sin (a)) desde sin (x) * sin (x) + cos (x) * cos (x) siempre es 1.0