BoTWPhysics

Es una pregunta muy buena, técnicamente depende de la parte del hardware en la que se estén ejecutando las físicas del juego. Tenemos dos opciones solamente:

  • En el Espresso (la CPU).
  • Utilizando Compute Shaders (en la GPU).

En el primer caso dado que la CPU de Wii U es muy inferior a las CPUs de PS3 y 360 pues las dos últimas podrían ejecutar un motor de físicas de este tipo sin problemas. En el segundo caso, aquí es algo bastante más complicado porque sabemos que la GPU de Wii U al ser de arquitectura R700 soporta una versión altamente limitada de los Compute Shaders que se utilizan para el cálculo de las físicas. Los Compute Shaders son algo que se empezó a utilizar a partir de DX11/OGL 3 por el hecho de que las GPUs antes no podían trabajar con el contexto gráfico y el de computación al mismo tiempo.

03.jpgEs decir, pueden conmutar ambos y esto significa que si en Wii U se utiliza el contexto de computación a priori o posteriori entonces el contexto gráfico tiene menos tiempo disponible a una tasa de tiempo fija o añade una latencia en el resto del pipeline. Aunque realmente la GPU no soporta Compute Shaders al uso sino que lo que soporta son Fragment/Pixel Shaders utilizados como Compute Shaders.

captura-de-pantalla-2016-04-29-a-las-14-11-25

Los Fragment/Pixel Shaders trabajan en grupos de 2×2 operandos por lo que un Wavefront de 64 elementos tendrá en realidad hasta 16 instrucciones para 4 elementos cada una (haciendo el total de 64), los Compute Shaders permiten colocar unas 64 instrucciones distintas para un elemento cada una. El motivo de que esto ocurre es porque las GPUs trabajan con 4 operandos siempre en el pipeline gráfico. Es por ello que el pipeline de computación pre-DX11 en realidad es un pipeline gráfico acortado, es decir, sin las etapas de geometría y rasterización previas al texturizado. Y aquí es donde llegamos a lo que es interesante:

GX2Multicore1

Al igual que ocurre en DX11 en Wii U podemos crear listas de comandos con diferentes núcleos de la CPU y no solo con un núcleo.

GX2Multicore2Lo que ocurre es que a nivel de GPU la arquitectura no tiene múltiples procesadores de comandos que permitan el hecho de poder procesar de manera asíncrona la parte de computación. AMD no empezó a añadir los procesadores de comandos para computación (los llamados ACE en los diagramas de AMD) hasta los primeros chips de la arquitectura GCN 1.0 (HD 7000) en adelante. Incluso la serie HD 5000 (VLIW5 como las anteriores y Wii U pero con soporte DX11) solo tiene un solo procesador de comandos como se puede ver en el siguiente diagrama de la HD 5870.

slide22-archdiagram.jpgPor lo que al final aunque aliviemos la carga de la CPU pudiendo crear varias listas de comandos a nivel de GPU solo funciona con una. ¿Y que ocurre a nivel de hardware con Switch? Bueno, la forma de gestionar las listas de comandos no dependen de la naturaleza de la GPU sino de la API misma y si la API esta pensada para no invocar los procesadores de comandos para computación entonces… no los invoca.

Bueno, una vez hecha la presentación toca saber si Xbox 360 y PS4 podría ejecutar el motor de físicas de Breath of the Wild si este funcionase en la GPU si se podría ejecutar en 360 y en PS3. Pues bien, hay una ventaja que tiene Wii U respecto a 360 de cara a estas cosas que es la memoria embebida y se que ambas tienen memoria embebida, lo que ocurre en 360 es que tiene la latencia enorme porque las operaciones realizadas sobre la memoria embebida no se pueden leer de vuelta, se vuelcan sobre la RAM principal y luego se recuperan, una RAM principal a la que acceden todos los componentes y tiene una enorme contención. En Wii U la memoria embebida tiene acceso directo de lectura y escritura y una latencia mucho más baja por su cercanía con la GPU al estar en el mismo chip por lo que resulta una ventaja en el procesamiento de las instrucciones. Poder, se podría en 360 hacerlo pero no se si lo haría mejor o peor.

En cuanto a PS3, se pueden renderizar la escena en el RSX y calcular las físicas de la escena en el CBEA y en este caso la consola de Sony sería muy superior a la de Nintendo porque esto permite tener un pipeline de computación de manera asíncrona que se puede dedicar a cosas como esta dejando el trabajo libre a la GPU para renderizar la escena.

CELL_BE_processor_PS3_board.jpg

Los SPE del CBEA están altamente pensados para este tipo de trabajos, el núcleo PowerPC no lo utilizaríamos para las físicas pero si los SPE que acelerarían el trabajo de mala manera. Pero para ello haría falta adaptar el código del juego al hardware de la consola, en 360 no haría falta porque su configuración es muy parecida a la de Wii U pero en PS3 si que se tendría que re-escribir el código. Si no se hiciese entonces los SPE del CBEA no entran en juego y el resultado sería peor en rendimiento al de las otras dos consolas.

us__en_us__ibm100__cell_broadband__spe__620x350Con esto respondo a la primera pregunta.

En cuanto a la segunda, básicamente la respuesta es porque no quieren y por el hecho que aplicar esto en sus AAA significa tener que sobrecomplicar las cosas y los costes al llegar a un nivel de emergencia superior. Recuerdo a principios de la generación pasada como con PS3 y con todo el mundo acabando de alucinar con el Half-Life 2 en PC y su motor de físicas nos mostraron cosas como esta:

El problema es que en la mayoría de juegos se ha utilizado el CBEA como se utilizan los Compute Shaders en gráficos, para efectos de post-procesado en muchos casos y en otros para calcular la etapa de iluminación durante el renderizado en diferido. Pero en general PS3 debería tener una enorme ventaja sobre las otras dos en ese aspecto, otra cosa es que se aplique el mínimo común múltiple y el tema de las físicas se haya sacrificado muchas veces en favor de la calidad visual.

Legend-of-Zelda-Breath-of-the-Wild-E3-2016-07

En el caso de BoTW es un juego que sacrifica ciertos elementos en comparación con un sandbox como por ejemplo GTA, en el caso de un GTA la CPU  tiene que estar calculando decenas por no decir centenares de iteraciones de lo que se mueve por la ciudad tanto de los vehículos como de la gente… Una situación tipo GTA V mata el rendimiento de la Wii U por completo. Pero en especial BoTW lo que sacrifica es un nivel visual complejo con tal de conseguir tener el motor de físicas que esperaban tener con el juego y forma parte integral del diseño del mismo, lo ideal como ya he contado seria la capacidad de poder procesar desde la GPU gráficos y físicas (a través de computación) al mismo tiempo pero no se puede por lo que la carga gráfica se ha recortar enormemente con tal de dar tiempo al procesamiento de las físicas en la escena por lo que las preferencias en el diseño técnico del juego han sido completamente distintas.

Con esto termino, espero haber resuelto las dudas planteadas.