Mirando en las presentaciones de AMD para la GDC me encuentro con el tema del Raytracing Audio pero ejecutado por computación como es obvio dado que AMD no ha integrado aún las unidades de función fija encargadas de calcular la intersección de los rayos con los elementos de la escena en sus GPUs de PC.

He de aclarar que soy muy ignorante en cuanto a harware para el audio y es algo que paralelamente estoy aprendiendo por lo que no suelo hacer entradas de este tipo, pero es interesante tratarlo porque es la forma con la que harán avanzar el audio de los juegos de cara a la siguiente generación en comparación con la actual y lo sabemos por las palabras de Mark Cerny a Wired respecto a la novedades que llevarán las consolas de la siguiente generación y aunque esto ya lo trate por encima en una entrada reciente, esta presentación nos confirma ciertas cosas que comente y que contradicen la «opinión» general de los «informados medios».

Aunque aparezca el logo Steam Audio en la presentación, esta va sobre el uso de la Real Time Queues (Colas a tiempo real) en las GPU de AMD en PC que sirven tanto para el Raytracing Audio como para el llamado TrueAudio Next, lo cuales en PC utilizan GPUs a partir de la gama GCN4 (GCN 1.3) que ven de la AMD Fiji (28nm) y luego las posteriores Polaris (14nm Finfet), Vega (GCN 1.4 aka GCN5) y las futuras Navi. ¿La particularidad de estas? Como ya comente, la eliminación de los aceleradores para el True Audio Next del uncore privado de la GPU que se encontraban en GCN 1.0 y GCN 1.1.

En GCN 1.2 este desaparecio por completo al no ser muy utilizado en el hardware pero acabo en consolas siendo el encargado de audio de al menos una de las dos plataformas (PlayStation 4).

En el caso del PC, AMD integro a partir de GCN 1.3 la capacidad para reservar parte de la potencia de la GPU para lo que AMD llama RTQs (Colas a tiempo real) y aquí hemos de tener en cuenta que las colas no son más que las múltiples listas de comandos que le enviamos a la GPU. Una cola es una lista FIFO (First in- First Out) y en el caso de las GPUs se trata de colas circulares, es decir… Cuando los contadores de programa de las unidades ACE o del Procesador de Comandos leen las listas de comandos en un lugar reservado de la misma en la RAM principal (parte coherente) lo que hacen es ir rotando una lista de direcciones de memoria concretas.

El Procesador de Comandos Gráficos puede gestionar una sola cola y no puede conmutar entre otras. Cada una de las unidades ACE pueden gestionar hasta 8 colas pero no simultaneamente y las ha de ir conmutando, tanto las unidades ACE como el Procesador de Comandos Gráficos son los que gestionan y envian las diferentes listas de comandos a los diferentes elemento de la GPU y los hacen circular según la etapa del pipeline en que se encuentren, excepto en la parte del pipeline donde dichas listas se encuentran en las Compute Units.

Esta diagrama es de la GPU de Playstation 4 pero va en consonancia con lo que estoy comentando. ¿Y que tiene que ver con el tema del Audio? Pues que podemos gestionar colas a tiempo real o mejor dicho, reservar parte de la potencia de la GPU para ese tipo de colas via computación.

¿Que entendemos como tiempo real?

Un sistema de tiempo real es un sistema informático que interacciona con su entorno físico y responde a los estímulos del entorno dentro de un plazo de tiempo determinado. No basta con que las acciones del sistema sean correctas, sino que, además, tienen que ejecutarse dentro de un intervalo de tiempo determinado

Las Compute Units de la GPU pueden hacer creer que funcionan a tiempo real porque están pensadas para que la longitud de las instrucciones sea fija, si una instrucción no tiene sus datos en los registros y esta se atrasa o depende de una instrucción anterior entonces es movida hacía atrás en la lista. Pero las RTQs no funcionan así, funcionan en paralelo y de manera completamente aislada al pipeline gráfico y de computación habitual hasta el punto de tener sus propio recursos reservados en forma de CUs privadas.

Podemos asignar varios RTQs a diferentes tareas en la GPU que funcionan de manera completamente aislada al pipeline gráfico y de computación. E decir, no pueden comunicarse de ninguna manera. No podemos asignar más de 25% del total de Compute Units de la GPU en ello y no podemos asignar más de un RTQ por Shader Engine por lo que el limite son 4. El ejemplo que dan es el de una AMD Vega 64 donde se utilizan unas 4 CUs para un RTQ (Tangent Convolution) y para el otro RTQ (que es el calculo del Raytracing de la escena) unos 8 CUs, quitandole para ello a la GPU unos 12 CUs para los gráficos y dejandola en unos 52 CUs, un recorte que es significativo.

¿Va a ser así en consolas next gen? En principio no, el motivo de ello es porque para la compatibilidad hacía atrás los sub-sistemas de audio de PS4 y Xbox One han de estar intactos y como ya os comente en la serie de entradas especulatorias de PS5 (y hay cosas que veréis en Xbox «Scarlett») si algo tienen los DSP de Cadence de la gama Tensilica es que son compatibles hacía atrás por lo que los van a integrar de mejores y su integración va a ser importante para no tener que depender de parte de las CUs para ciertas funciones del audio, pero el tema del RTQ1 que corresponde a cual es la generación del sonido según la posición de los objetos depende de los resultados de calcular la intersección y esto lo trataremos más adelante porque las cosas se han de hacer por orden.

La otra parte es el uso del Raytracing para trazar como van rebotando los «rayos» de sonido por la escena y aquí se ha de tener en cuenta que como he dicho al principio la implementación en PC adolece de la falta de una unidad encargada de recorrer la estructura de datos que es el BVH que se ha construido a partir de la geometria de la escena.

Hay que tener en cuenta que el BVH no limita la subdivisión según el espacio ocupado por cada objeto en pantalla como ocurre con el KD-Tree sino que el espacio en pantalla es dividido de manera regular y especificamos que objetos se encuentran en cada espacio.

El orden es colocado en forma de arbol binario.

La construcción del BVH se hace desde su elemento más simple y luego se van agrupando por areas según su posición en pantalla. La precisión del nodo más inferior del arbol binario puede ser a nivel de vertice, poligono, objeto o grupo de objetos. Cuanto más preciso sea el arbol más lento será el procesador en recorrerlo. El caso es que para el Raytracing audio no necesitamos un nivel de precisión tan grande como en gráficos. En realidad es más bien «Cone Tracing Audio».

Ya he comentado muchas veces que la implementación del Raytracing a tiempo real supone el añadido de unidades traversales en las Compute Units como ocurre en el caso de las Nvidia Turing. El añadido de estas unidades es algo que personalmente doy por hecho en las CUs de las GPUs de la consolas de la siguiente generación y son la llamada «Secret Sauce» de la que habla Lisa Su por no decir el ingrediente principal por lo que el cálculo del RTQ2 en el ejemplo no se haría tampoco en las CUs de la GPU como ya comente recientemente, permitiendo así que su uso se dirija hacia otras tareas, principalmente los gráficos.

Por otro lado se puede utilizar el mismo BVH generado para el Raytracing de los gráficos para lo que es el Raytracing Audio, construir otra de menor precisión sería una redundancia y una perdida absoluta de tiempo. Pero se ha de tener en cuenta que las unidades traversales solo informan si el rayo ha impactado con el objeto y de que manera (sin impacto, total o parcialmente) y con ello se ejecuta el shader correspondiente dentro de la propia Compute Unit, por lo que es posible crear Sound/Audio Shaders como un tipo de shader asignado a la etapa de Raytracing. Es decir, me estoy refiriendo a la forma en al que el sonido interactua con cada objeto que va a depender de la naturaleza del mismo, la distancia respecto al jugador, etc.

Por lo el RTQ1 no se ejecutaría en las unidades especializadas porque están demasiado lejos respecto a las unidades traversales. Ya que dichas unidades no se encuentran en la Compute Unit, tampoco en el Shader Engine, ni tan siquiera en lo que es todo el conjunto GFX sino más allá y la latencia sería horrible por lo que la única manera es hacerlo a través de un shader y de la misma manera que ocurre con el raytracing gráfico se ha de tener una información de las caracteristicas de cada material de cara a representar el comportamiento del sonido con cada objeto por lo que la generación del sonido se hará durante el pipeline gráfico y a través de los mismos shaders para el raytracing híbrido que se utilizan para solventar cierto problemas de la iluminación indirecta y por tanto al contrario de lo que comente hace unos días entonces la generación de audio si que afectará al rendimiento gráfico pero a cambio de conseguir un mayor realismo del mismo.

Personalmente es la parte que más me fascina porque puede cambiar la jugabilidad de muchos juegos y por tanto la forma de jugarlos. Sobretodo a la hora de crear ambientes completamente inmersivos.

Esto es todo, como siempre tenéis el Discord y los comentarios de la misma entrada para comentar el contenido de la misma.