Os contamos al detalle que es el Rapid Packet Math, como afecta y porque no ayudará acortar la brecha entre PS4 Pro y Xbox One X.

Más historias en la categoría Editorial

• ¿Necesitamos más juegos de Transformers? Rotundamente, sí
• Los Remakes y Remasters se han posicionado en la industria ¿son realmente necesarios?
• 343 Industries estaba destruyendo Halo y no lo sabíamos

No te pierdas nada y ¡Síguenos en Google News!

---

Hace ya bastante que no escribía un artículo pero llevo tiempo viendo la necesidad de hablar sobre un tema que está confundiendo a mucha gente. Me encuentro aquí intentado explicaros de una manera sencilla y lo más fácil posible de asimilar, algo que está circulando por la red como la pólvora. Así que permitidme comenzar con esta ardua tarea que tengo por delante y espero que no os perdáis con mis explicaciones. Así pues, “Allé voy“.

Hace poco AMD anunciaba que las GPU que incorporan arquitectura Polaris en adelante como VEGA, integraran una función llamada Rapid Packet Math, quedaros con el nombre porque lo vais a leer mucho en la red de aquí a noviembre. Entre las GPU elegidas para beneficiarse de esto se encuentra PS4 Pro y por ello Marck Cerny, arquitecto de Playstation 4 y PS4 Pro, dijo hace un tiempo que con esta función la consola premium de los japoneses era una consola que podía rendir hasta 8,4 teraflops en lugar de 4,2 teraflops. Una subida que supondría el doble de potencia, simplemente activando una función de una arquitectura gráfica. Por desgracia el argumento de Cerny tenía trampa y estamos leyendo como se desvirtúa todo en un mar de datos técnicos en los que se asegura que la brecha entre Xbox One X y la consola de Sony va a reducirse.

Seguro que muchos recordarán las promesas de DirectX12, una API que aumentaría la eficiencia de Xbox y PC. Este caso es similar, la potencia de PS4 no se va a duplicar, ni sacará flops del aire. Pero si hará que la consola de Sony sea más eficiente al igual que DX12 ha conseguido mejorar Xbox. Pero las diferencias entre maquinas están ahí, y seguirán igual de grandes en el tiempo.

Entendiendo el Rapid Packet Math

Para poder seguir hablando de esta supuesta potencia aumentada y descifrar la ecuación, necesito hablaros un poco de la tecnología que hace esto posible. No quiero pecar de dar demasiados tecnicismos así que nos quedaremos en lo superficial. Ante todo, me gustaría que usáramos este artículo para poder debatir sobre posibles beneficios o detalles más técnicos.

Para quien no entienda de CPUs y GPUs, podemos decir que estos elementos son el cerebro pensante de cada sistema, y lo que hacen es mandar instrucciones para realizar las tareas pertinentes según requiera dicho sistema. Dependiendo de la instrucción, ésta tiene un tamaño en bits. Los PC y las actuales consolas de sobremesa funcionan prácticamente con instrucciones de 32 bits (FP32) y en móviles, íntegramente en 16 bits (FP16). En función de las instrucciones de datos requeridas, se suelen alternar entre mandar instrucciones de 32 y 16 bits y en consolas cuando se manda una instrucción FP32, ésta ocupa toda la cola de la instrucción, y una vez enviada queda el hueco libre para otra, así todo el tiempo. Cuando mandas una instrucción en FP16 ocupa el espacio entero de una FP32, con lo cual pierdes un valioso espacio de información que podrías aprovechar, porque una FP16 ocupa la mitad que una FP32.

Cuando Nvidia lanzó el chip Tegra X1 (el mismo que incluye Nintendo Switch) anunció que era el primer chip móvil que llegaba a 1 teraflop de potencia, pero obviamente esto tenía trampa ya que el truco reside en que Nvidia lanzó una tecnología que lo que hace es meter dos instrucciones al mismo tiempo FP16 dentro del hueco de una FP32 para aprovechar los huecos vacíos y ganar rendimiento con ello, doblando la potencia frente a un desarrollo en FP32, ya que recordamos que una instrucción en FP32 equivale a 2 de FP16.

Podríamos pensar que eso está genial pero sigue habiendo truco pues esta ganancia de potencia conlleva un sacrificio de calidad visual. Por ejemplo, las instrucciones en FP16 son menos precisas en información que las de FP32 pues obviamente incluyen menos información dentro. Así, la fidelidad visual baja a costa de ganar rendimiento. En el vídeo de la demo técnica del Unreal Engine 4 se ve la perdida de fidelidad gráfica de un Tegra X1 en FP16 frente a la demo en PS4 y PC:

Suscríbete al canal de GX en Youtube

---

Para un móvil esto está muy bien porque se trabaja en FP16 y no requieren de instrucciones tan complejas, simplemente no las necesitan. Pero hablamos de sistemas que trabajan en su mayoría con operaciones de 32 bits de datos, que para gráficos más complejos requieren más esfuerzo para renderizar, por ejemplo, efectos gráficos. De esta manera tenemos que las consolas utilizan instrucciones FP16 para algunos efectos visuales, por ejemplo en la iluminación, ya que estos efectos consumen mucho si los cargamos en FP32. Ni que decir tiene que esto es un alivio de recursos, pero gracias al avance de las nuevas GPU y componentes, el paso natural es pasarlo todo a FP32; la mejora visual es notoria.

Además  hay otro problema. Los actuales motores gráficos no están pensados ni optimizados para trabajar en FP16, ya que en la actualidad la mayoría de cálculos se realizan en FP32, quedando la mejora en algo mucho menor de lo que parece. AMD ha llegado a decir que esta mejora estaría entre un 10% y un 40% dependiendo de la complejidad de los cálculos en FP16.

La brecha es grande, y se verá desde lejos

Volvemos ahora al principio,  doblar la potencia de PS4 Pro a 8,4 teraflops no es un argumento real. La consola de Sony es una máquina que puede operar a 8,4 teraflops en FP16 pero como hemos visto, no todo se hace a FP16. Recordamos que los motores funcionan a FP32 mayoritariamente, habría que construir un engine gráfico enteramente para que trabaje sobre FP16 y no obstante la pérdida de calidad visual sería muy notoria. Eso tampoco interesa. Así que la solución pasa por modificar un motor que aproveche algunas instrucciones FP32 (no todas) para que el Rapid Packet Math introduzca dos FP16. Siempre sería en elementos que no sacrifiquen calidad gráfica.

Esta técnica va a ayudar a la consola de Sony a ser más eficiente, pero no “más potente”. El hardware es el que es y a los usuarios de Xbox esto ya no nos pilla de nuevas. Todo lo que sean mejoras, será bien recibido por los usuarios. Pero retorcer el lenguaje para confundir al usuario no es positivo para nadie, al final la realidad es un muro que acaba golpeando tarde o temprano. Para reforzar mi argumento, os pongo un dato real ya que esto no es nuevo y lo hemos vivido.

Y es que la primera Xbox One de 2013 ya maneja los FP de manera customizada, y no solo eso sino que puede trabajar en FP64, o lo que es lo mismo, puede enviar instrucciones de 64 bits para operaciones muy complejas sobre FP32+32 o en FP16+16+16+16. Además puede modificar los ciclos de instrucciones al vuelo según el tipo de instrucción, por eso no necesita la optimización de meter 2 instrucciones de 16bits en una de 32, porque ella se adapta al momento sin perder rendimiento en el camino. Esta posibilidad no hizo que Xbox One duplicara potencia o redujera la brecha con PS4; solo hemos visto mejora de ello gracias a DirectX 12.

Detalles como este hicieron que trabajar con Xbox One fuera difícil. Como One ya trabaja con esto, Xbox One X no va a ser menos y no necesita incluir esta función ya que  maneja estas operaciones de manera más compleja e integrada. Además, no olvidemos que Xbox One X a diferencia de Xbox One, lleva integrado DirectX 12 en el hardware para ser más eficiente, como las GPU modernas, algo que habrá que ver como funciona.

Esperamos que os haya sido de utilidad este humilde texto y os invito a compartir con nosotros todo aquello que creáis conveniente o se nos haya escapado.