Esta es la pregunta del millon, los rumores apuntan a una portátil con pantalla 720P con los controles desmontables que se podrá utilizar también como consola de sobremesa se dice que el hardware que va a llevar es un Tegra X2 como SoC principal del sistema.

NVIDIA-Tegra-Parker-SOC_Features

TegraX2 Specs

La pregunta es si sería posible construir una consola de sobremesa con capacidad de mover los mismos juegos a 1080P, la respuesta es un si pero para ello necesatamos antes que nada ver como funciona la arquitectura «Pascal» de Nvidia y cual es su organización interna, es decir, necesitamos desmontar las piezas para luego montar la GPU que queremos montar, para ello voy a tomar como referencia la GeForce «Pascal» 1080.

geforce_gtx_1080_block_diagram

Veamos los diferentes elementos:

#1 Gigathread Engine

Es el planificador de la GPU y por tanto donde además se encuentra el procesador de comandos, es el encargado de gestionar y distribuir las tareas entre los GPC que hay en el sistema.

#2 Cache L2, ROPS y Controlador de Memoria

Los ROPS se encuentran conectados a la cache L2 y están fuera de las unidades GPC, lo cual es una diferencia sustancial respecto a AMD que tienen los ROPS en los Shader Engines. El número de ROPS es equivalente a la cantidad de controladores de memoria existentes en el sistema siendo de 8 por cada controlador de memoria del tipo GDDR5/GDDR5X en las GPUs dedicadas. En el caso concreto de la GeForce «Pascal» 1080 tenemos una configuración de 8 controladores de memoria conectados a 8 canales GDDR5X con un ancho de banda de 320GB/seg, esto son unos 40GB/seg por cada uno de los controladores pero dichos controladores también sirven para la memoria GDDR5. La GeForce «Pascal» 1070 tiene también un bus de 256 bits pero a 256GB/seg lo que corresponde a memoria GDDR5 y son 32GB/seg por controlador de memoria pero lo que quiero que os quede claro es que cada 8 ROPS pueden alimentar y alimentarse de hasta unos 40GB/seg.

La conexion de memoria LPDDR4 en el caso del Nvidia Parker/Tegra X2 es a través una interfaz de 128 bits LPDDR4 con un ancho de banda de 51.2GB/seg. Como supera los 40GB/seg de máximo esto significa que tenemos 16 ROPS en total, pero cada bloque de 8 comunicandose solo a 25.6 GB/seg por lo que el Tegra X2 tiene un cuello de botella en ancho de banda respecto a las versiones dedicadas. También hemo de tener en cuenta que los controladores de memoria LPDDR4 son de 32 bits, por lo que estamos hablando de que el ratio en ese caso es de 4 ROPS por controlador de memoria en vez de 8 como ocurre con la GDDR5/GDDR5X.

Si Nintendo utiliza el Tegra X2 sin cambios en la organización de la memoria entonces estaríamos hablando de una densidad de 8GB y aquí es donde un servidor es bastante… Bueno, conociendo a Nintendo es posible que tengamos una mala sorpresa que yo descartaría por el momento. Shigeru Miyamoto ya dijo que con la potencia de Wii U para NX es suficiente y Wii U tiene un ancho de banda con su memoria de 12.8GB/seg, justo lo que tiene un solo chip de memoria LPDDR4 que para colmo tiene una densidad de 2GB, me veo a Nintendo racaneando en la memoria y colocando una GPU con solo 4 ROPS….

PanicPanic

… Bueno, no os pongáis así… ¡Era una broma! El caso es que los Tegra tienen severos problemas con los efectos de post-procesado debido a la falta de ancho de banda con la memoria, una de las mejoras del Tegra X1 al Tegra X2 ha sido mantener la cantidad de ROPS mientras se duplica el ancho de banda para que estos puedan tener suficiente ancho de banda para trabajar sin problemas. Es más, en el caso concreto de Wii U los ROPS estaban conectados a la MEM1, la cual les daba el suficiente ancho de banda… ¿Supone esto el retorno de la memoria embebida? Lo dudo, más bien pienso que Nintendo esta vez no va a racanear en cuanto al ancho de banda de la memoria externa aunque luego comentare una hipotesis que tengo que tiene que ver con Pascal pero eso cuando lleguemos al uncore (y no creo que lleguemos en esta entrada) pero de momento dejemos eso en el aire.

El paso de los 720P a los 1080P supone que la cantidad de pixeles que se dibujan en el búfer de imagen es de 2.25 veces más, como no podemos hablar de fracciones podemos decir que sería de 3 veces más por lo que pasaríamos de los 16 ROPS a los 48 ROPS. Esto serían unos 6 controladores de memoria por lo que la cantidad de RAM en la versión de sobremesa (la cual se cambiaría por memoria GDDR5 o GDDR5X) sería la siguiente:

  • 6GB de memoria GDDR5 o 12GB de la misma memroia (Clamshell)
  • 6GB de memoria GDDR5X, podrían ser 12GB sin Clamshell desde el momento en que en 2017 veremos memoria con esa densidad.

¿El problema de la GDDR5? Nintendo anda obsesionada con el consumo de mala manera. ¿Entonces que otra solución habría? Pues una interfaz de 256 bits LPDDR4, lo que aumentaría el número de ROPS a 32 y los anchos de banda a 102.8GB/seg o 136GB/seg según el tipo de memoria utilizada. Para no tener varios proveedores el hecho de utilizar memoria LPDDR4 tiene sentido ya que podría ir dirigida a la versión portátil o la hipotética versión de sobremesa.

En cuanto a la Cache L2, su funcionamiento es igual al de la arquitectura GCN y en realidad su tamaño e interconexión crece al aumentar el número de ROPS. La GeForce «Pascal» 1080 tiene unos 4MB de Cache L2 en total, por lo que cada bloque de 8 ROPS se lleva unos 512KB de memoria y cada ROP unos 64KB.  No olvidemos que en modo computación los ROPS no se utilizan y se accede directamente a la Cache L2 y ahí viene la gran diferencia respecto a los RBs de AMD que son más complejos porque llevan cache interna en la que realizar sus operaciones, en el caso de la arquitectura de Nvidia los ROPS escriben y leen sobre la cache L2 y no tienen cache propia. Esto va a provocar que en el caso de NX si se confirma que lleva Nvidia muchos de los desarrolladores para ciertas operaciones de post-procesado con tal de ahorrar tiempo acaben haciendo bypass a los ROPS y hagán que los shaders escriban directamente sobre la Cache L2, aunque vuelvo a decir que tengo una hipotesis sobre una optimización que podría hacer Nintendo en NX y tendría mucho sentido pero como he dicho antes la vamos a dejar para otra entrada.

#3 GPC

En el diagrama de la GeForce «Pascal» 1080 tenemos unos 4 GPC en total, la cantidad de GPCs es escalable según las necesidades del cliente de la misma manera que la cantidad de TPCs dentro de cada uno de los GPC. La unidad en común es el Raster Engine, el cual es al rasterizador del sistema por lo que la «Pascal» al igual que GCN puede generar varios fragmentos a texturizar por ciclo de reloj. Si entramos ya dentro de cada TPC veremos que esta compuesto por 2 SMs y el Polymorph Engine, es lo mismo que el Geometry Engine de la arquitectura GCN, es decir… La unidad encargada de la subdivisión de vertices o más conocida como teselación.

En cuanto a los SMs funcionan exactamente igual que las Compute Unit de la arquitectura GCN, la diferencia es que en vez de tener unos 4 bloques SIMD-16 aquí tenemos unos 2 bloques SIMD-32 pero el número de Stream Processors es el mismo. Tiene un planificador fuera de orden dentro del SM (como ocurre en la arquitectura GCN) y sus 4 unidades de texturas correspondientes con su Cache L1 correspondiente.

nvidiasm

 

Si Parker/Tegra X2 es la base para la NX portátil y esta ira a 720P para el salto a 1080P hace falta un salto de 2.25 veces y aquí tenemos dos soluciones distintas:

  • Duplicar el número de SMs de 4 (2 TPCs) a 8 (4 TPCs) y realizar una subida de vueltas al sistema, por lo que tendríamos una configuración de 512 Stream Processors.
  • Pasar de 4 SMs (2 TPCs) a 10 SMs (5 TPCs) por lo que la configuración pasaría a ser de 640 Stream Processors.

El hecho de que el sistema estaria conectado a la corriente le daría una mejora en cuanto a la potencia en coma flotante, no sabemos cual es la velocidad del Tegra X2 en lo que a su GPU se refiere pero en el caso del Tegra X1 con un proceso de 20nm es de 1Ghz, con el salto a los 16nmFinFet tiene que existir un subida de vueltas, aunque en ambos casos estaríamos hablando de 1 TFLOP en FP32 (2 TFLOPS en FP16) y de 1.3 TFLOPS en FP32 (2.6 TFLOPS en FP16) por lo que la potencia de nuestra NX de sobremesa estaría a la par de la Xbox One y no llegaría al nivel de la de PS4 a no ser que hubiese una subida de vueltas importante en lo que a la velocidad de reloj se refiere en la versión de sobremesa.

Teniendo en cuenta que tenemos GPUs de la serie Pascal a 1.5 Ghz en sobremesa no sería descartable una versión así:

(1.5*10^9)*512 CUDA Cores*2 (FMADD)= 1.5 TFLOPS.

(1.5*10^9)*640 CUDA Cores*2 (FMADD)= 1.92 TFLOPS

Por lo que en la segunda configuración superaría por poco a PS4 aunque no me veo a Nintendo apuntando más alto que PS4. Más bien me veo a Nintendo pidiendo que los juegos que funcionan a 1080P en PS4 funcionen a 720P en la NX portátil con algunos recortes, en especial en postprocesado ya que el Tegra X2 tiene potencia para ello. Aunque vuelvo a repetir que desconocemos la velocidad de reloj del Tegra X2 y es dificil escalar desde ahí.

#4 CPU y Uncore

Curiosamente ayer Nvidia presento el sucesor del Parker, el cual no va a ir para el mercado de las tablets sino el de los smartcars, se que no es para una consola.

nvidia_xavier_gtc-europeQuedaos por el momento con los 512 núcleos de la GPU (los cuales continuarán siendo los clásicos núcleos CUDA de toda la vida y por tanto aumentara en potencia. Lo que llama la atención es que pasamos de una configuración 2xDenver (Custom ARM64 CPU) a 8x Denver en «Xavier»… ¿Como se explica esto? Sencillo, el uncore en Xavier se ha duplicado y ya no acepta solo 2 módulos de GPU donde cada módulo del Cortex A57 es de 4 núcleos y del Denver de 2 núcleos sino que ahora soporta unos 4 módulos en el uncore aparte de la GPU. ¿Y como es dicho uncore? Pues si tiene que evolucionar desde el de Pascal esta claro que estamos hablando de un sistema completamente coherente en todos sus componentes.

nvidia_p100_um

Esto significa que tenemos un sistema de memoria totalmente coherente y unificado para todos los componentes del sistema, en el caso de las GPUs dedicadas Nvidia pretende hacerlo haciendo uso del NVLink como elemento de comunicación con la CPU, en el caso de los SoC dicha intercomunicación es a través del uncore y por tanto estaríamos ante el equivalente de Nvidia al soporte HSA completo.

isca-2014-heterogeneous-system-architecture-hsa-architecture-and-algorithms-tutorial-12-638

Esto es un cambio muy importante en el modelo de programación en lo que a las consolas de Nintendo se refiere. Wii U tiene una configuración con dos pozos de memoria que utiliza un controlador DMA para ir pasando los datos entre ambas (como ocurre en Xbox One) y con espacios de memoria de los diferentes procesadores colocados de manera compartimentada pero sin ninguna coherencia. Esto significa que buena parte de los motores gráficos y de los juegos tendrán que reprogramarse para funcionar con un solo pozo de memoria. Por otro lado si Nintendo opta por una configuración de 2 módulos en cuanto a la CPU da igual si son dos núcleos Denver con cuatro núcleos A57, cuatro núcleos Denver u ocho núcleos Cortex A57 que barren el suelo con el AMD Jaguar de PS4 y Xbox One. ¿Motivo? A igualdad de velocidad de reloj el AMD Jaguar puede realizar 3 instrucciones por ciclo de reloj (Dhyrstone) mientras que que el Cortex A57 puede realizar 4.6 en las mismas condiciones, Denver non tengo la cifra pero tiene que ser más alta que la del A57, en todo caso la potencia resultante sería mayor a igualdad de velocidad de reloj que con el Jaguar de AMD.

Ahora bien, en el caso de haber una versión de sobremesa no creo que haya diferencias en lo que a la CPU se refiere porque el objetivo sería mover los mismos juegos no a una mayor tasa de fotogramas sino a una mayor resolución. El salto a unos 4 modulos de CPU en vez de 2 en una futura versión tendría sentido en el caso de que Nintendo quisiera hacer una versión VR de NX pero entonces tendríamos que escalar también la GPU de manera más exagerada y personalmente veo más a Nintendo hacer una NX 4K antes que una NX VR. Lo que si que veo yo posible es que viendo la tradición de Nintendo en sacar una portátil con hardware nuevo cada tres años en modo tick-tock que en el 2020 veamos una «New NX» al estilo New 3DS y DSi con una CPU mejorada pero Nintendo no tiene la tendencia de mejorar las GPUs en cada nueva iteración.

#5 La opción doble SoC

Nvidia ha incluido una interfaz de comunicación llamada NVLink en Pascal y los SoC con Pascal que en el caso concreto del Drive PX2 sirve para comunicar los dos chips Tegra X2 entre si y con las GPUs dedicadas pero quiero que os quedéis solo con el doble Tegra X2.

NVIDIA-DRIVE-PX2-self-driving-cars-computer

En dicha configuración el acceso a memoria de los SoC pasa a ser completamente coherente y trabajan ambos conjuntamente. Es decir, en vez de fabricar un chip gordo se utilizarían dos chips Tegra X2 para la versión de sobremesa siendo los mismos que los de la versión portátil para los 1080P.

#6 Viabilidad

Siento deciros que la entrada es una perdida de tiempo por un motivo, si Nintendo quisiese una NX de sobremesa no tendría sentido que la NX portátil se conectase al televisor y el hecho de que la primera tuviese más potencia dividiría al mercado porque haría posible juegos que por potencia no serían posibles en la versión de portátil. Creo que lo que va a intentar Nintendo es tener versiones a 720P de juegos de PS4 y Xbox One, lo cual no es malo si tenemos en cuenta que partimos de un hardware de portátil de gama alta y resulta un salto espectacular respeto al hardware de 3DS e incluso es espectacular desde el de Vita en lo que a hardware se refiere por lo que con el concepto actual de NX que se rumorea va a ser suficiente por el momento y de ahí que yo dude en una versión de sobremesa, la cual se podría construir pero no tiene sentido por lo que he dicho.

En fin, eso es todo… Era una entrada que tenía pendiente y se que alguno me pregunto por ella en algún email.