FP32 vs FP16

Uno de los temas que van a afectar a todas las consolas independientemente de si hablamos de PS4 Pro, Nintendo Switch o Xbox Scorpio es el tema de half-floats o FP16. Es decir, la capacididad de operar con números de coma flotante de 16 bits en vez de números de coma flotante de 32 bits.

Esto no es algo nuevo en las GPUs, lo que si que es nuevo y es algo que AMD ha tomado de Nvidia es el hecho de poder realizar dos operaciones distintas de una misma instrucción al mismo tiempo utilizando una misma ALU FP32. A nivel de marketing llamamos a esas ALUs bajo el nombre de Stream Processors o núcleos CUDA según el contexto.

De ahí sale el tema de los 8.4 «TFLOPS» de PS4, algo de lo que hablo Mark Cerny en la entrevista concedida a Eurogamer.

«Una de las carácteristicas que aparecen por primera vez es el manejo de variables de 16 bits. Es posible realizar dos operaciones de 16 bits en vez de una de 32 bits» dice, confirmando lo que aprendimos de nuestra visita a Voofoo Studios para ver Mantis Burn Racing. «En otras palabras, en floats completos tenemos unos 4.2 TFLOPS. Con medios floats, ahora es el doble de esto, es decir, unos 8.4 TFLOPS en computación de 16 bits. Esto tiene el potencial de aumentar radicalmente el rendimiento.»

Esto no es algo que haya colocado Sony porque si, es algo que AMD le ha tomado prestado a Nvidia como he comentado antes y lo ha colocado en las GPUs de la arquitectura Polaris en adelante y como colateral esta en PS4 Pro desde el momento en que su GPU es una AMD Polaris pero esto es algo que no se puede realizar en la PS4 estándar desde el momento en que esto no esta implementado en su GPU.

Dado que es algo implementado por AMD no tengáis dudas que Xbox Scorpio también lo va  a implementar y si esta tiene una potencia de 6 TFLOPS en FP32 Microsoft puede hablar de una potencia de 12 TFLOPS en FP16. ¿Pero que tienen de especial esas instruciones en FP16? En realidad nada, es como coger la máquina del tiempo e ir varios años hacía atras donde las GPUs no tenían ALUs FP32 completas con tal de poder colocar más núcleos en el limitado espacio que tenían.

¿Y en que se traduce esto? Los gráficos en FP16 operan con cifras mucha menor precisión por lo que la calidad de imagen acaba siendo peor por esa falta de precisión que es falta de información que con el formato FP32 por lo que hay informacion que no puede ser representada. Un número en FP32 tiene una precisión de 1 bit de signo, 8 bits del entero y 23 bits de los decimales. Un número en FP16 tiene una precisión de 1 bit de signo, 5 bits de entero y unos 10 bits de decimales por lo que el resultado final cuando los gráficos tienen una alta precisión de color es un degradado en la calidad de imagen de la escena final por lo que es una trampa para conseguir rendimiento a cambio de sacrificar la calidad de imagen.

Un caso famoso de esto es la Elemental Demo del Unreal Engine 4 corriendo en el Tegra X1.

La Elemental Demo tiene dos versiones, la primera de ellas utiliza el SVOGI y requiere unos 2.5 TFLOPS para funcionar, algo a lo que no llegan ni PS4 y mucho menos el Tegra X1 mientras que la segundo no lo utiliza. ¿En que se traduce esto? En que la versión de PC utiliza iluminación global dinámica.

La GPU del Tegra X1 con sus 256 núcleos puede llegar por los pelos a ese TFLOP en FP16 de ahí a que la calidad de imagen sea peor que en los otros dos casos. Pero la perdida de precisión le hace ganar una potencia adicional que le permite correr la demo. Por otro lado y esto es algo que mucha gente desconoce PS3 en lo que a los Pixel/Fragment Shaders se refiere trabajaba en muchos juegos con una precisión de 16 bits en vez de una de 32 bits aunque se ha de aclarar una cosa muy importante, en PS3 no se trabajaba con color de 16 bits en absoluto ya que el formato de las texturas era y sigue siendo 24 bits color+8 bits para el canal alfa. Tampoco representan unos 16 bits para profundidad+stencil que continuaban siendo de 32 bits en enteros (24+8) sino que las operaciones hechas en coma flotante se operaban a 16 bits, esto se ve mirando el G-Buffer para el renderizado en diferido de Killzone 2 en dicha consola.

Fijaos como el Render Target donde se almacena el valor de la normal utiliza cifras en FP16, esto es porque en dicha consola los Pixel/Fragment Shaders no pueden trabajar en coma flotente con cifras mayores de 16 bits. Aunque hay casos donde una precisión de 32 bits no supone una mejora respecto a una de 16 bits hay otros casos en los que si y esto acaba afectando a la calidad de imagen final. En la actual generación se aprovecha la capacidad de las ALUs de los shaders de poder trabajar en FP32 para ganar más precisión en estos casos pero hay que tener que no todos los elementos de la imagen se generan utilizando coma flotante por lo que la tasa de 8.4 TFLOPS de potencia no ocurrira nada y lo más seguro es que será invocada cuando la precisión en FP32 hagá que la versión 4K nativa o en F4KE (ya sea utilizando cualquiera de los dos métodos de reescalado) se renderice más lentamente y esa potencia extra en FP16 ayude al renderizado.

Pero un caso donde se ve esto es en los mapas de sombras, la precisión de los Variance Shadow Maps es de  FP32, mientras que el de los mapas de sombras estándar es de FP16 y por tanto más baja ya  que existe una degradación visual cuando se trabaja en FP16.

La gracia es que los mapas de sombras son Fragment/Pixel Shaders muy dependientes de los ROPS y del ancho de banda y el truco del FP16 en estos casos es que necesitas mucho menos ancho de banda y es ideal en sistemas con poco ancho de banda disponible. Es otro ejemplo de lo que ocurre cuando se trabaja a menor precisión. Pero lo que hay que tener claro es que no toda la escena se renderiza en coma flotante y que en muchos casos el salto de una operación a FP32 a dos en FP16 no supone un aumento de velocidad igual a la hora de renderizar el fotograma sino las partes donde se trabaje en coma flotante y el coste por perder precisión va a ser una perdida en la calidad de imagen aunque hay casos donde una precisión mayor de 16 bits no resulta en una diferencia. Personalmente no tengo ninguna duda de que en el caso de renderizar los juegos a 4K en PS4 Pro los desarrolladores harán sacrificios en la calidad de imagen final utilizando parte de la información gráfica en FP16 y este degradado en la calidad de imagen será algo que la gente aceptará bajo el argumento de que es algo necesario para los 4K, ya sean nativos o F4KE.

¿En que se traduce todo esto? Pues que el soporte de dos operaciones en FP16 que tiene PS4 Pro puede ayudar a aumentar la velocidad y permitir resoluciones a 4K nativo en muchos casos pero a cambio de un recorte en la calidad de imagen. Pero no sería una calidad de imagen peor que en PS3 y por tanto es posible que gracias a esto algún que otro desarrollador se plantee versiones 4K en PS4 de algunos exitos de PS3 pero no mejorando la calidad de imagen como en los remasters que hemos visto hasta ahora sino tomando como referencia la calidad de imagen de las versiones de PS3 para ello. Un  buen ejemplo para ver la diferencia entre el uso de FP16 en ciertas partes del pipeline gráfico (PS3) y el uso de FP32 es el remaster de God of War 3, fijaos en que hay elementos que se representan con una menor calidad visual en PS3 y hay una serie de artefactos gráficos.

Claro esta qe dichas versiones 4K serían solo para PS4 Pro y dado que el acceso a esas nuevas funciones de la GPU necesitan el uso de una extensiones adicionales sobre la API gráfica (ya sea GNM o GNMX) el código de ese modo de renderizado no sería compatible con la PS4 estándar pero ni falta que haría por el hecho que su presencia es por velocidad de cada al renderizado en 4K sea nativo o escalado.

Pero hay otra consola que han presentado hace poco que también va a utilizar esto que es la Nintendo Switch por el simple hecho que va a tener una GPU de Nvidia como mínimo de arquitectura Maxwell por lo que esto lo va a soportar y dado que es un hardware portátil el FP16 va a ser utilizado muy a menudo por lo que si ciertos juegos desde PS4/Xbox One son portados a Nintendo Switch estos tendrán ciertos recortes a nivel visual por el hecho que algunas partes de la imagen se procesaran a menor información pero al mismo tiempo si hablamos de tomar como base juegos de PS3 para ser directamente portados entonces el problema es menor, aunque obviamente dependerá de la naturaleza de cada juego y de como los desarrolladores ajusten la versión de Switch de sus juegos. En todo caso este tipo de optimizaciones ocurren en todas las plataformas.

 

En lo que a Switch se refiere entra el tema de la estética, muchos de los juegos de la propia Nintendo no pretenden un estilo realista por lo que una menor precisión en el renderizado no va a afectar la calidad de imagen y es en estos casos donde la mayor potencia en FP16 se puede utilizar para aplicar una mayor cantidad de operaciones por pixel consiguiendo paradojicamente una mayor calidad de imagen o en su defecto una tasa de fotogramas más alta de lo que se puede conseguir en su antecesora (Wii U).

¿Pero que ocurre en casos donde la estética es más realista como es el caso de Skyrim que vimos en el video de presentación de la Nintendo Switch? Hay que tener en cuenta que lo que vimos fue un montaje pero el caso es interesante desde el momento en que es un juego que utiliza el Forward Rendering. El video en la presentación era el de la versión remaster pensada para al hardware de PS4 y Xbox One y no es que Switch no pueda mover Skyrim porque puede y de sobras pero tendría que tener algunos recortes en la calidad de imagen porque lo más seguro es que quienes hagan el port utilizen el FP16 en algunas partes del renderizado como… ¡La versión de PS3!

En pocas palabras, si el juego se confirma al final preparaos para ver un cierto downgrade visual respecto a lo visto en el anuncio por el uso de precisión de 16 bits en alguna que otra parte de la imagen con tal de mejorar el rendimiento del juego aunque por otro lado la GPU es más potente incluso en FP32 que las de la anterior generación por lo que podría ejecutar sin problemas y sin recortes de ningún tipo al menos a nivel teórico los juegos a la calidad de la anterior generación y colocarse además un poco por encima ya que si tomandos la GPU del Tegra X1 o del Tegra X2 este tiene la potencia suficiente para mover los juegos con mayor soltura.

¿Entonces porque se utilizaría en algunos casos el FP16 a la hora de renderizar la escena? El motivo sería el ancho de banda, no sabemos cual será el ancho de banda disponible en Nintendo Switch pero hay que tener en cuenta que el RSX con 8 ROPS y 22.4 GB/seg en muchos casos con tal de paliar el cuello de botella por la velocidad de la memoria y la limitada tasa de relleno ciertas partes del pipeline gráfico se procesaban con un precisión de 16 bits y es muy probable que los desarrolladores hagan lo mismo en Nintendo Switch si al final se confirma un muy limitado ancho de banda en la memoria aunque dudo mucho que tomen un Tegra X1 tal cual y más existiendo el Tegra x2 como base que tiene el doble de ancho de banda ya que un ancho de banda de 51.2 GB/seg no es un mal ancho de banda para renderizar dichas escenas a 720P sin problema alguno.

En todo caso espero haber resuelto la duda sobre el tema del FP16 de la que se que algunos me habéis preguntado tanto por comentarios como por correo.