En una entrevista acerca del hardware de la PS4 Pro, tuvimos a Mark Cerny de SCEI realizando las siguientes afirmaciones en su día:

«Una de las carácteristicas que han aparecido por primera vez es el hecho de poder manejar variables de 16 bits, es posible realizar dos operaciones de 16 bits en vez de una de 32 bits» dice (Cerny), confirmando lo que aprendimos durante nuestra vista a VooFoo Studios para hacerle un vistazo a Mantis Burn Racing. «En otras palabras, en coma flotante de precisión completa (full floats), tenemos unos 4.2 TFLOPS. Con como flotante de media precisión (half-floats), ahora tenemos el doble de eso, por lo que son 8.4 TFLOPS en computación de 16 bits. Esto tiene el potencial de aumentar radicalmente el rendimiento.

Veamos como es Mantis Burn Racing en cuanto a calidad visual…

De un tiempo a esta parte estoy comentando como el tema de la precision en FP16 solamente se ajusta bien a ciertos aspectos visuales en concreto… Pero hay un problema con esto que afecta indirectamente a PS4 Pro y de la que Microsoft es participe, veamos:

  • En PC las únicas GPUs a nivel doméstico capaces de desacoplar una operacion de 32 bits en dos de 16 bits son los AMD Vega con el Rapid Packed Math, el motivo es el uso de un nuevo tipo de Compute Unit que permite hacer esto. ¿Que ocurre? Casi nadie tiene una AMD Vega, el resto de la gama de AMD no lo soporta y Nvidia no le da apoyo a nivel doméstico tampoco.
  • No entra dentro de la especificación mínima que han de tener las GPUs para PC dar soporte DirectX 12 por lo que los fabricantes no lo implementan.

¿Con que nos encontramos? Pues que la gran mayoría de juegos en PC no lo utilizan y es una función por el momento que esta de más. ¿Pero PS4 no es un PC verdad? El problema es que esto obliga a tocar todo el código del juego y… Ni la PS4 estándar ni tampoco toda la familia al completo de la Xbox One incluida la X lo soporta. En el caso de Microsoft tiene sentido porque no lo ven como algo importante y no esta en la especificación de su API.

El caso es que el pasado mes de Agosto apareció la noticia de que Wolfestein II: The New Colossus iba a utilizar el RPM. La noticia hablaba del PC obviamente, pero era de cara a las AMD Vega, recordemos que el juego utiliza el mismo motor gráfico que el Doom, en todo caso el otro hardware que lo utiliza es la PS4 Pro por lo que debería haber un modo que lo utilice. El problema es que en PC el Rapid Packed Math no se le ha dado soporte todavía a través de los drivers/controladores aún en PC…

Adrenalin esta especificamente enfocado a la amplia base de usuarios e AMD, no traer consigo ninguno de las mejoras de rendimiento específicas de Vega o los cambios documentados al comportamiento o capacidades especificas de hardware en Vega, Así como las mejoras dependientes del juego en juegos ya existentes como el Rapid Packed Math en Wolfestein II… Adrenalin no los lleva consigo.

Es decir, en PC… Nadie esta utilizando el RPM porque ni la propia AMD ha activado el apoyo al mismo, pero sabemos que esta activado en la PS4 Pro porque lo utiliza el Mantis Burn Racing, dado que PS4 es un ecosistema cerrado Sony no tiene que asegurarse la compatibilidad con nada fuera de las plataformas PS4 por lo que la especificación del DirectX 12 les es completamente igual. ¿Lo realmente extraño? Sony en todo el SDK de la consola no menciona el RPM por ningún lado ni como utilizarlo… ¿Entonces?

confusedgif

Bueno, en en el GCN4 (Correspondiente a Polaris) se añadio el soporte para operaciones de media precisión, pero no para el RPM. ¿Es posible que la gente del Mantis Burn Racing estuviese utilizando simplemente operaciones en coma flotante de 16 bits bajo la suposición de que corren a un ratio de 8.4 TFLOPS. Es muy posible y la cosa se confirma cuando tenemos en cuenta la version de Xbox One X del juego, la cual por no soportar el RPM debería ser peor que la de PS4 Pro, pero sabemos que soporta precisión de 16 bits.

¿Entonces? Bueno… Según los propios desarrolladores del Mantis Burn Racing:

Tuvimos que recortar unas pocas cosas en la PlayStation 4 Pro, como es el hecho de algunos detalles de las partículas y el uso de shading de menor precisión… Podemos tomar otro camino con la Xbox One X añadiendo detalles extras… Como extra añaddo vamos a añdir algo de Anti-Aliasing en la Xbox One X a 4K. Tuvimos que cancelar esto en la Playstation 4 Pro donde estabamos satisfechos porque los pixeles siendo muy pequeños un poco de aliasing no es un problema. Pero cuando lo añadimos le añade una capa adicional a la claridad y la frescura de la imagen.

¿Que me confirma esto? Simple… Si el juego funcionase en PS4 Pro a 8.4 TFLOPS en FP16 simplemente con los 6 TFLOPS en FP16 la Xbox One X tendría problemas para ejecutar una versión mejor. Es decir, no hay ningún juego en PS4 que utilice el RPM ergo los 8.4 TFLOPS son un bulo enorme, pero es que tampoco en PC y con ello tenemos que volver al tema del Wolfestein II como punto final, bueno al mismo motor gráfico que es el mismo que el del Doom.

¿Que otra consola soporta el RPM? Pues la Nintendo Switch pero en su versión de Nvidia ya que el Tegra X1 tiene la misma funcionalidad. Ya existe un juego que sacrifica la calidad de los shaders a favor de conseguir el rendimiento necesario… Que es precisamente el Doom y Wolfestein II utiliza la misma precisión visual.

Obviamente nadie quiere perder calidad de imagen… Y por ello en PS4 Pro no tenemos una version FP16 del Doom… ¿Es eso o simplemente es algo que no funciona ni en PC (Vega) ni en PS4 Pro y que ha sido publicitao hasta la saciedad de manera erronea? No, la cosa es mucho más sencilla, no merece la pena sacrificar calidad de imagen por resolución. Si alguien pusiera el Doom de Switch a 4K en PS4 Pro manteniendo la calidad gráfica de la portátil de Nintendo automaticamente buena parte de la gente regresaría de nuevo a la versión con menor resolución pero con más calidad visual, pero de calle.

¿Entonces como es que Cerny hablo sacando pecho de la función en Digital Foundry? Quien se crea que Cerny ha diseñado lo que es la PS4 y la PS4 Pro va muy errado, Cerny no ha diseñado absolutamente nada y fue un mandato de Sony a AMD y esta última le informo de la aplicación del RPM en el hardware, cosa que Sony dio por hecho pero lo desconocen porque ellos han encargado el SoC pero no han trabajado directamente con el mismo. La implicación de Microsoft en Xbox One fue mucho más amplia, en realidad en todo el SoC de PS4 y PS4 Pro no hay nada realizado por Sony mientras que Microsoft si que ha trabajado codo con codo con AMD y lo sabemos por cambios en el hardware que realizaron como es el segundo procesador de comandos.

Pe… pero se necesita tener acceso al hardware para poder realizar la API gráfica de bajo nivel y Sony tiene una para PS4 llamada GNM.

Vamos a hablar de GNM… Sony hace uso de una especificación de shaders propia. ¿Esto significan cambios en el hardware? No, en OpenGL tenemos por ejemplo el GLSL y en DirectX el HLSL, son lenguajes de especificación de shaders distintos… Sony le ha dado por hacer el suyo que es el PSSL.

PSSL.PNG

GNM no es más que la API Mantle que AMD lanzo para PC pero en vez de con soporte HLSL con soporte PSSL… ¿Como es posible esto? La misma naturaleza de Mantle lo especifica:

La API Mantle no incluye ningún compilador de alto nivel para los shaders, la creación de los shaders toma forma binaria a partir de un lenguaje de shaders intermedio como entrada de datos.

Es decir, Mantle no soporta ni GLSL, ni HLSL, ni PSSL… Sino que soporta un lenguaje intermedio… ¿De que nos suena eso? Ah si, es lo que hemos visto en su evolución que es Vulkan con el soporte del SPIR-V… La documentación de Mantle es especifica sobre el lenguaje intermedio, puede ser cualquiera que se haya desarrollado.

Los controladores de Mantle pueden escoger varias elecciones de cara al Lenguaje Intermedio y la API debería ser por lo general considerada agnóstica en cuanto al Lenguaje Intermedio. Actualmente, un Lenguaje Intemedio esta basado en subset del AMD IL… Se pueden adoptar otras opciones en el futuro.

¿Las opciones de cara al futuro? La adoptación del SPIR-V como lenguaje intermedio para eliminar la dependencia de AMD en Vulkan (el cual deriva de Mantle) pero cuando PS4 salió al mercado no existía aún Vulkan y se tenian que hacer juegos para la consola, tampoco existía DirectX 12 aunque las consolas de Sony no lo utilizan, lo que había era Mantle, pero Mantle es el nombre de la API para PC y en PC no se utiliza el PSSL sino GLSL o HLSL según el caso… Pero si que se utilizo en juegos en concreto que si que utilizaban al menos uno de esos lenguajes intermedios.

4b90df70-a1f4-4804-b9fb-d9d53c331ab0.jpg

La respuesta es bien simple… Mantle utilizaba un conversor del HLSL a AMD IL en su día.

HLSLMantle.PNG

Sony tiene su propio conversor al AMD IL, el llamado PSSLC que son las siglas del PSSL Compiler. La suposición mía es que no compila sino que convierte el código al AMD IL. Sony no da soporte al HLSL pero si que lo da a su PSSL y sabemos que la conversión al AMD IL es posible. Pero esto solo afecta a la parte de los shaders, en el resto de componentes del pipeline la especificación es la misma… ¿Para que va Sony a realizar una API de bajo nivel desde cero si AMD ya le proporciona una que encima puede personalizar? Es un ahorro en personal, tiempo y en costes increible pero Sony no ha tocado nada del hardware ni de las APIs a bajo nivel fuera del PSSL.

¿Pero es necesario para dar soporte al RPM una programación especial? No, solo hace falta hacer trabajar el código en FP16 y ya esta, el RPM no necesita de ningún tipo de instrucción especial sino solamente bajar la precisión en la que trabajan los shaders de 32 bits en coma flotante a 16 bits en coma flotante. De ahí  a que la gente del Mantis Burn Racing en su día intepretará que el juego iba a 8.4 TFLOPS y Mark Cerny también.