Esta entrada es MUY TÉCNICA, se trata de una explicación no solo del funcionamiento interno del SoC en el interior de la Nintendo Switch…

nintendo-switch-interior-2

… sino también una explicación del como y por qué Nintendo puede adoptar el Tegra X2 como sustituto en futuras iteraciones de la consola sin romper compatibilidad de ningún tipo y sin necesidad de parches por el medio.

#1 Diagrama del Tegra X1 y del Tegra «Parker» X2

Si comparamos los dos SoC de la serie Tegra Xn a simple vista parecen iguales con algunos cambios menores y mejoras leves.

NVIDIA-Tegra-Parker-SOC_Specs-1

Directo de la documentacion de Nvidia donde podemos ver claramente cual es la organizacion de cada uno de los dos SoC y como están organizados los diferentes elementos del Tegra X1:

TegraX1CompleteDiagram

Por el momento estáis viendo un complejo anagrama de siglas en recuadros conectados entre si, no os preocupéis que lo ire desgranando punto por punto los que son más importantes de todos, dado que la entrada se basará especialmente en el Tegra X1 que es el SoC utilizado en la Nintendo Switch.

¿En cuanto al Tegra X2? Su diagrama es algo diferente y se pueden ver cosas que no coinciden en la organización.

ParkerDiagram.PNG

En el Tegra «Parker» ciertos componentes han sido sustituidos por otros y los caminos a memoria tienen ciertas variaciones, los tratare en cada sección y subsección correspondiente.

#1.1 PLL y Master Clock

Los PLL (Phase Locked-Loop) en Inglés o Circuitos de Bucle de Enganche de Fase en Español son componentes indispensables en todo procesador ya que son imprescindibles para coordinar la comunicacion entre sus diferentes componentes dentro del chip. No son algo exclusivo del Tegra X1 ¿Y que es lo que hacen? Simplemente son los que se encargan que los envios se hagán a frecuencias de reloj exactas múltiples de una velocidad de reloj concreta dentro del SoC.

¿Y cual es esa velocidad de reloj en el Tegra X1? Unos 38.4 Mhz de serie por lo que los buses de comunicación e incluso algunos procesadores del sistema iran a un múltiplo de dicha velocidad de reloj.  Aunque en realidad hay una serie de velocidades de reloj estándar en el Tegra X1 para la intercomunicación que se pueden utilizar colocando ciertos valores en los registros del chip…

  • Valor 1100: Oscilador a 26 Mhz, en las frecuencias en las que es necesario que este vaya a la mitad de frecuencia este se pone en valor (0000) y funciona a 13Mhz para dichos envios.
  • Valor 0101: Es el que se encuentra configurado de serie y por eso la velocidad de reloj de muchos componentes es un múltiple de 38.4 Mhz, en las en las frecuencias en las que es necesario que este vaya a la mitad de frecuencia este se pone en valor (0100) y funciona a 19.2Mhz para dichos envios.
  • Valor 1001: La velocidad del Oscilador se coloca a 48 Mhz, pero como contrapartida su velocidad reducida (valor 1000) no se coloca a 24 Mhz sino a 12 Mhz, es decir 1/4 parte.

En la Nintendo Switch el valor siempre se mantiene en los 38.4 Mhz de serie. ¿Las únicas areas donde esto no se cumple? A nivel externo del chip los controladores SATA, USB y PCI-Express toman velocidades de reloj acorde con sus estándares, pero son interaces externas. A nivel interno tanto la CPU como la GPU tienen su propio reloj, en Switch la velocidad de reloj de la CPU es de 1020 Mhz como veremos más adelante, pero la GPU funciona a un múltiple de esos 38.4 Mhz pero podría funcionar a otras velocidades de reloj, pero digamos que Nintendo no ha tocado esa parte tampoco. Pero eso ya lo comentaré cuando entremos en la GPU.

#2 Interfaz de Memoria

La Interfaz de Memoria se basa en una interconexión en anillo para comunicar los diferentes procesadores que tienen acceso a la memoria RAM y a los componentes de E/S. Para la comunicación directa entre los diferentes procesadores del sistema se utiliza en en el Tegra X1 el componente llamado MSelect que en el caso del Tegra X2 es bautizado como Control Fabric, quedando la Interfaz de Memoria unica y llanamente para que los diferentes procesadores tengan acceso a la RAM.

Su funcionalidad es coordinar las entradas y salidas de de datos desde y hacía la memoria y desde y hacía los diferentes componentes. Solo tiene una excepción que es el bus de lectura del CCPLEX (CPUs) que tiene acceso directo cuando lee los datos (y por tanto no los modifica) ya que en ese caso concreto accede directamente al controlador de memoria, esto no se ve en el diagrama principal pero si en el diagrama de acceso donde el controlador de memoria es llamado EMC y la interfaz de memoria como MC.

TegraX1RAMAccess

En cambio el CCPLEX (CPUs) cuando escribe datos y por tanto modifica el resultado final si que los datos pasan por la interfaz de memoria. ¿Y como funciona la interfaz de memoria exatamente? Lo voy a explicar con un simil muy simple, imaginaos una autopista urbana circular.

autopista-urbana-sur--619x348.jpg

Y digo circular porque sería completamente cerrada sobre si misma, donde los coches/datos no paran de dar vueltas a través de la misma y al ser una camino de alta velocidad los datos van mucho más rápidos en esta sección del chip.

form-cerosuperr2

Obviamente cada barrio de la ciudad tiene asignada un salida que es un canal DMA, cada uno de los componentes que tienen acceso directo a la RAM tienen una unidad DMA que envía y recibe desde y hacía el anillo. A nivel interno el anillo sabe cual es el origen y el destino de cada dato (pueden ser tanto datos como instrucciones) por el hecho de que esta marcado en el completo de la dirección de memoria así como su nivel de prioridad. Esto claro esta no es único de los Tegra y lo tienen todos los SoC pero aprovecho para explicarlo.

En el Tegra X1 tenemos dos anillos funcionando en paralelo, por lo que podemos decir que es una pequeña autopista de dos carriles y hemos de tener en cuenta que hay tanto un carril de envio como uno de recepción. ¿Y con que coinciden los carriles? Pues con el hecho de que tenemos 2 controladores de memoria LPDDR4 (32 bits cada uno) mientras que en el Tegra X2 la configuración puede ser de unos 2 o 4 carriles dado que soporta un bu de 128 bits por lo que el anillo interno es mucho más rapido. Cada anillo tiene un bus de 256 bits por dirección por lo que tenemos un total de 1024 bits y con la memoria funcionando a 800 Mhz esto supone que el anillo de manera interna funciona a 102.4 GB/s, la interfaz de memoria se comunica con los controladores de memoria con los buses reducidos a la mitad por lo que el ancho de banda pasa a ser de 51.2GB/s y por último el propio controlador de memoria se comunica con la memoria con un ancho de banda de 25.6 GB/s por lo que a medida que nos acercamos a la RAM el canal se va estrechando. En el caso del Tegra X2 las cifras se duplican en el caso de utilizar los 4 carriles pero se reducen a la mitad si tenemos un sistema con LPDDR4 de 64 bits.

Los diferentes componentes internos del SoC se conectan al anillo utilizando un múltiple de 38.4 Mhz pero la velocidad interna del mismo es distinta y esta alineada con la velocidad de la memoria RAM que es de unos 800 Mhz, de ahí salen los anchos de banda antes especificados.

En cuanto a los componentes externos de E/S estos se comunican con la Interfaz de Memoria cada uno con su interfaz correspondiente y su velocida correspondiente dado que la velocidad de reloj maestra es solo para los . La única excepción es el puerto PCI-Express que comentare más adelante que no permite el acceso por lo que en el caso de un sistema con Tegra X1 dual cada chip tiene su memoria privada y no puede acceder a la memoria del otro, esto es diferente en el caso del Tegra X2, pero no es algo que dependa de la interfaz de memoria

#2 CCPLEX

El CCPLEX varia en ambos procesadores, en el caso del Tegra X1:

X1CCPLEX

La composición de este componente es muy estandar ya que no tiene ningún procesador que haya sido modificado por Nvidia, se trata de un dispositivo Big-Little compuesto por 4 núcleos Cortex A57 de alto rendimiento y  núcleos Cortex A53 de bajo rendimiento pero de bajo consumo. En el caso de la Nintendo Switch el A53 no aparece por ningún momento y esta desactivado por lo que no vamos a perder el tiempo con él. Si hacemos caso de la informacion filtrada via Digital Foundry la velocidad de reloj del A57 independientemente del modo de uso de la consola es siempre de unos 1020 Mhz, por lo que es una velocidad de reloj que en teoría no se ve afectada por el ahogamiento termal ya que el X1 tiene un mecanismo que recorta la velocidad de reloj a la mitad de la CPU cuando el calor del chip aumenta por encima de lo permitido. En dispositivos como el Jetson TX1 y la Nvidia Shield TV se sacrifica la velocidad de reloj de la GPU con tal de mantener la velocidad de reloj de la CPU cercana a los 2 Ghz.

JetsonTX1CPUSpecs

El VGIC-400 va en conjunto al CoreSight 400 y se trata del controlador de interrupciones, es decir, es el que envia una interrupción para que la CPU pare la ejecución actual del programa y atienda la interrupción mientras que la CPUIF es el mecanismo de petición a memoria de los datos que explicare luego porque es sumamente importante. Las interacciones de la CPU con la Interfaz de Memoria las tratare en su sub-sección correspondiente.

En cuanto al Tegra «Parker» X2 vemos algunos cambios de entrada en la composición interna del CCPLEX.

CCPLEXTX2.PNG

Los 4 Cortex-A53 han sido sustituidos por dos núcleos Denver2 de Nvidia, este chip propietario es compatible también con el set de registros e instrucciones ARM-V8, por lo que puede ejecutar el mismo código que el A57 pero tiene una capacidad monohilo mucho más alta que los A57.

En el Tegra X2 tenemos cinco modos de funcionamiento distinto para el CCPLEX.

Id Modo Modo Denver 2 Ghz ARM A57 Ghz
0 Max-N 2 2.0 GHz 4 2.0 GHz
1 Max-Q 0 4 1.2 Ghz
2 Max-P Core-All 2 1.4 GHz 4 1.4 GHz
3 Max-P ARM 0 4 2.0 GHz
4 Max-P Denver 2 2.0 GHz 0

En el caso de una eventual Switch basada en el Tegra X2 se puede utilizar el modo Max-Q sin problemas desactivando el Nvidia Denver, en todo caso una versión de la Switch basada en el X2 tendría ciertos problemas no en el aspecto de la ejecución del código en el X2 a no ser que Nintendo haga algunos cambios en el Sistema Operativo de la consola.

En cuanto al CPUCIF este esta pensado para funcionar en un sistema de memoria completamente coherente, en el diagrama del Tegra X2 no lo veis porque ahora es llamado CPU Switch Fabric y su trabajo es que tanto los núcleos Denver como los núcleos A57 tengán una coherencia en el acceso a la memoria para que puedan trabajar de manera coherente.

Parker4

El CPU Switch Fabric  esta conectado al Control Faric, que comentare en su sección correspondiente.

#3 CoreSight SoC-400

Se trata de otro componente estándar de los procesadores ARM, encargado de gestionar las interrupciones que van hacía y desde la CPU y otros componentes.

Tanto en el X2 como en el X1 el CoreSight es exactamente igual, lo que es diferente son los componentes conectados al CoreSight SoC-400 que hace que el sistema tenga ciertas incompatibilidades de entrada y Nintendo tenga que hacer ciertos cambios.

#3.1 BPMP-Lite (Solo X1)

Conectado al CoreSight 400 se encuentra un ARM7TDMI cuyo único trabajo es la gestión de encendido y de ser el director de orquestra de unas serie de microcontroladores y sensores encargados de controlar la temperatura y el consumo del sistema. Las siglas BPMP significan Boot and Power Management Processor. 

¿Que es lo que hace exactamente? Se encarga de encender y apagar los diferentes componentes del SoC a medida que son necesarios o no con tal de ahorrar energía y reducir el ahogamiento térmico. No es una pieza que se encuentre en manos

#3.2 Cortex R5 (X2)

El Tegra X2 es un SoC pensado para automoviles inteligentes, es por ello que su funcionamiento es diferente al del X1 y tiene ciertos elementos exclusivos. En el caso que nos ocupa el BPMP-Lite ha sido sustituido por un Cortex-R5 que es un procesador mucho más potente para realizar dicha tarea. Por lo que el mecanismo de arranque y la seguridad del mismo es completamente dispar.

En realidad tenemos dos R5 distintos, el segundo es el SCE (Safety Cluster Engine) que solo sirve para la automoción por lo que para la consola sería completamente inutil y en realidad junto al R5-BPMP se podrían sustituir en una eventual revisión de la Switch a 16FF o bajo un mejor proceso por el mecanismo del BPMP-Lite del X1 y eliminar por completo el resto de componentes basados en el Cortex R5 que poco o nada tienen que ver con las funciones de una consola de videojuegos.

Ya que estamos con los R5 en el X2, el último es el (SPE) Sensor Processing Engine, se trata de otros de los elementos pensados para automoción. Esta siempre encendido pero funcionando a muy baja velocidad, es el encargado de controlar que solo la llave adecuada o la huella dactilar del propietario abra el coche, es al que los sensores del mismo coche s encuentran conectados así como la conectividad online del mismo. Como entenderéis no es algo que sea esencial en una consola de videojuegos y es uno de los motivos por los cuales colocar un X2 sin cambios sería una tontería porque una parte importante del SoC no sería de utilidad alguna en la consola.

#3.2 APE 

El APE es el Audio Processor Engine y por tanto el Procesor de Sonido, se encuentra conectado tanto a la Interfaz de Memoria del sistema como al CoreSight SoC 400 para comunicarse directamente con la CPU, por lo que el camino de datos APE<->CPU es completamente distinto al de GPU<->CPU.

En realidad se trata de un SoC dentro del propio SoC ya que esta compuesto principalmente por dos componentes.

APEX1Diagram

El ADSP es un Cortex-A9 estandar que en el caso del Tegra X1 es el encargado de generar  el audio, las siglas de ADSP significan Advanced DSP y se trata por tanto de un procesador de señal encargado de generar las señales de audio. Gracias a su conexión con el CoreSight SoC 400 funciona de manera coordenada en cuanto al acceso a memoria con la CPU y esta dentro de su mismo espacio de memoria aparte de poder enviarle las interrupciones pertinentes cuando es necesario. El AHUB en cambio es por un lado una colección de máquinas de estado pensadas para acelerar ciertas funcione del procesamiento de audio que suelen ser comunes y repetitivas para liberar de su tediosa ejecución al ADSP como es la compresión/descompresión de ciertos codecs de audio y por el otro tiene una serie de interfaces externas del tipo I2S, S/PDIF, y DMIC (Microfono Digital) para el envió y recepción de datos de audio por lo que en Switch es el encargado de enviar la señal de audio a los altavoces de la consola o la pantalla según el caso, en el X1 tiene la capacidad de enviar el audio via Bluetooth por lo que en Switch no debería haber problemas para envió de audio a través de Bluetooth.

En cuanto al microfono y como puntualización, pese a que el Tegra X1 tiene una interfaz para microfono digital carece por si mismo de un microfono digital así como de un altavoz digital integrado de serie. El Tegra X2

En Switch el altavoz ha sido obviamente integrado por Nintendo pero no el microfono, como curiosidad, el Tegra X2 que utiliza el mismo sistema de audio que el X1 si que los integra de serie al expandir el sistema de audio pero mantiendo la compatibilidad hacía atrás con el del Tegra X1, por lo que el sistema de audio no debería presentar problemas de compatilidad alguno

#4.1 MSelect (X1)

El MSelect se trata de un interconectador Crossbar que comunica la CPU con varios componentes entre si pero no comunica a estos con la interfaz de memoria, su velocidad de reloj no esta especificada en ningún momento en la documentación oficial.

Sus interconexiones son:

  • La CCPLEX se comunica a a través del MSelect a través de un bus de 128 bits que va desde la CPU hasta el MSelect.
  • El propio MSelect por otro lado se comunica con tres dispositivos distintos:
    • El BPMP-Lite a través de un bus de 32 bits, es la única manera en que la CPU se puede comunicar con este componente sin pasar por el CoreSight-400 y viceversa por lo que es un camino alternativo.
    • Se comunica directamente con la GPU a través de un bus AXI de 64 bits, este bus es utilizado entre CPU y GPU cuando la segunda funciona en modo co-procesador de la primera. Dado que el MSelect no tiene acceso directo a la RAM del sistema tenemos que la GPU en el Tegra X1 no tiene acceso al espacio de memoria de la CPU de manera directa.
    • El Tegra X1 tiene una interfaz PCI Express 3.0 de 4 nodos y de doble canal, en el caso de la Nintendo Switch no tiene utilidad alguna en apariencia, en el Drive PX sirve para comunicar entre si a los dos Tegra X1.nvidia-chip-inline
  • El CoreSight-400 tiene un acceso directo al MSelect. ¿El motivo? Lo útiliza para enviar peticiones de interrupción a la GPU por un lado y tambien al Tegra X1 secundario si este se encuentra en el sistema.

¿La naturaleza del MSelect? Nvidia no especifica su naturaleza, pero mi hipotesis es que no es una propietario sino completamente estandar, el CoreLink NIC-400, esto tiene sentido si tenemos en cuenta que los protocolos utilizados en el diagrama son del tipo ARM y vemos en el diagrama otros elementos complementarios como son el CoreSight SoC-400 y el vGIC-400. Pero como ya he dicho no esta especificado en ningún momento en la documentación del Tegra X1 pero si que lo esta en el Tegra X2 como tal.

¿Su velocidad de reloj? pero desde el momento en que es utilizado también por la GPU para comunicarse con la CPU se deduce que funciona a la misma velocidad de reloj que la GPU para poderse pasar los datos de la forma más rapida posible. La única excepcion sería el controlador PCI Express que diría que de manera externa no funciona a un múltiple de 38.4 Mhz pero el controlador si se comunica a una velocidad múltiple de 38.4 Mhz con el MSelect y diría que la interfaz a memoria del CCPLEX así como el CoreSight también funcionan a una frecuencia multiple de 38.4Mhz, pero la desconozco.

Pero claro, el MSelect ha de proveer con datos a varias interfaces al mismo tiempo y no solo a la comunicación CPU-GPU, en todo caso si mi hipotesis fuese cierta el ancho de banda del MSelect sería variable según el modo de uso de la Switch.

Modo (Mhz) CPU GPU CoreSight PCIE BPMP
307,2 4.58 GB/s 2,29 GB/s 2,29 GB/s 2,29 GB/s 1,145 GB/s
384 5,72 GB/s 2,86 GB/s 2,86 GB/s 2,86 GB/s 1,43 GB/s
768 11,44 GB/s 5,72 GB/s 5,72 GB/s 5,72 GB/s 2,86 GB/s

¿Como es que lo he tachado? Pues porque una velocidad de comunicación de solo 5.72 GB/s para una consola del calibre técnico de Switch es insuficiente.

Por otro lado, ai nos fijamos bien en el diagrama veremos que el bus del MSelect a la GPU es el mismo bus que luego va del MSelect a la interfaz de memoria y aunque tanto CPU como GPU tienen sus propios canales de acceso a memoria para poder acceder la GPU al espacio de memoria de la CPU necesita «acceder» a través del MSelect. Bueno, en realidad lo único que hace es que la cache de segundo nivel de la GPU sea coherente con la de la CPU para operaciones de proposito general, ya que al contrario de lo que ocurre con el X2 el sistema no tiene un direccionamiento de memoria completamente coherente.

¿Entonces cual sería el trabajo del MSelect? Pues sería muy parecido al del mecanismo Fusion Compute Link/Onion en los SoC de AMD pero en este caso hablariamos de un sistema que no soporta coherencia al completo. Pongo esto de manera orientativa ya que los SoC de Nvidia no cumplen el estandar HSA pero el concepto es exactamente el mismo.

NonFullHSA

#4.2 Control Fabric (X2)

Estamos ante una versión más avanzada del MSelect que hay en el Tegra X1. ¿El motivo? Ahora tenemos el espacio de memoria siendo completamente coherente.

FullHSA

nvidia_p100_um

¿Como afecta esto al sistema? Pues esto cambia por completo la forma en la que la CPU accede a la memoria, en el caso del X1 el conjunto de instrucciones del X1 diferencia tanto el acceso al espacio coherente como al espacio no-coherent. Si se utiliza una API de alto nivel y por tanto con un controlador por software gestionado por la CPU por el medio esa diferencia no tiene importancia, pero no es el caso de la API NVN de la Nintendo Switch que es una API de bajo nivel donde el desarrollador tiene control absoluto sobre que bus de memoria utilizar en cada momento aunque hemos de tener en cuenta que la GPU no accede a la RAM a través del Control Fabric sino que este existe para que haya una coherencia a nivel de las caches de lo diferentes procesadores.

¿Es una complicación para los juegos? Pues si, porque de entrada no serían compatibles a no ser que se bajara un parche que cambiara algunos archivos de los juegos para hacerlos compatibles . Ahora estamos viendo como Nintendo permite parches de «primer día» a los editores independientes por lo que sería posible pero esto limitaría el catálogo disponible para una eventual Switch con el X2 como procesador de entrada en teoría. ¿Cierto? Pues no, porque luego vais a ver como esto no tiene porque ser así y no se rompe la compatibilidad, en la sección de la GPU para ser más exactos.

¿Una de las funcionalidades no especificadas del Control Fabric? El hecho de darle a la CPU y a la GPU la comunicación con una GPU externa conectada a través de un bus interno no especificado, las hipotesis es que ese bus interno es un bus NVLink pero Nvidia no especifico la naturaleza del bus cuando presento el Drive PX2.

Pascal-Drive-PX2-4GB-GDDR5-1

Las GPUs no se encuentran en ningún momento en una especificación aparte sino en el reverso del Drive PX2.

nvidia-drive-px-2-board-100654615-orig

Por lo que no hablamos de un bus externo sino uno interno, de ahí a que se piense que esto utilice el NVLink para comunicarse.

NVLink

¿Es posible que veamos una Switch con un dock avanzado conteniendo una GPU en el interior del mismo y en la máquina principal tengamos el puerto USB-C evolucionado a funcionar con un Thunderbolt 3? No, porque dicho puerto no da el suficiente ancho de banda para el renderizado de gráficos a tiempo real. Lo único que podríamos ver como mucho sería una versión de sobremesa con el SoC y la GPU integrados pero en ese caso lo más lógico en cuanto a costes sería integrarlo todo en un mismo SoC con tal de reducir costes pero dudo mucho teniendo en cuenta la estrategía de Nintendo de que veamos una Switch puramente de sobremesa.

#5 GPU

El Tegra X1 tiene una GPU basada en la arquitectura Nvidia Maxwell, concretamente una GM208/GM20B, no nos vamos a centrar en su arquitectura interna en esta entrada porque se alargaría hasta el fin de los tiempos y es de todos conocida.

X1-GPU

En cambio el X2 tiene una GPU con las mismas especificaciones técnicas pero utilizando el conjunto de registros e instrucciones Pascal. El problema es que no sabemos si la GPU Pascal en el X2 es una Maxwell++o no. ¿El motivo? Aquí entramos en un tema ya más delicado pero que merece la pena comentar y es que existe una enorme diferencia arquitectural entre la GP104 (GeForce 1080 y 1070) y la GP106 (GeForce 1060 y 1050) en comparación con la GP100 (Tesla P100) que hace que estemos hablando de dos chips completamente distintos pese a ser aparentemente ambos de la misma arquitectura.

¿Cual? Esto es la unidad SM del GP100:

gp100_sm_diagram-624x452

Lo normal sería que la unidad SM para el mercado doméstico descartase las unidades de doble precisión (en amarillo) porque no son útiles fuera del mercado de la computación de alto rendimiento y no lo utilizan los juegos. ¿Pero con que no encontramos cuando miramos la unidad de los GP104 y GP106? Pues con lo siguiente:

PascalSM

¿Que ha ocurrido aquí? No se trata de la misma unidad

  • GP100 tiene 64 núcleos con precisión en coma flotante de 32 bits, el GP104/GP106 en cambio tiene 128.
  • GP100 tiene dos bloques de procesamiento por SM, el GP104 tiene cuatro bloques de procesamiento. 2 processing blocks per SM, GP104 has 4 processing blocks per SM
  • GP100 tiene 32.768 registros por bloque de procesamiento, GP104/106 tiene 16.384 registros por bloque de proceamiento.
  • La memoria compartida interna en cada SM es de 64KB en el GP100, en el GP104/106 es de 96KB.

Si lo comparamos con la unidad SMM (propia de las GPU Maxwell) a simple vista nos parece una versión avanzada de Maxwell las GP104/106 utilizada en los sistemas domésticos del que derivaría la GPU Pascal dentro del X2.

SMM

Hostía tú, si tecnicamente parece la misma unidad. Nvidia para las unidades CUDA 5.X y las CUDA 6.1 y 6.2 especifica las siguientes especificaciones técnicas para una SM.

  • 32 (128) CUDA Cores.
  • 8 (32) Special function units.
  • 1 (4) Double-precision FP units.
  • 8 (32) Load / Store Units.

Que son las especificaciones que coinciden con la unidad SMM de Maxwell y la SM de la Pascal doméstica (GP104/106) mientras que las núcleos CUDA 6.0 tienen las siguientes especificaciones:

  • 32 (64) CUDA Cores.
  • 8 (16) Special function units.
  • 16 (32) Double-precision FP units.
  • 8 (16) Load / Store Units

Por lo que la deducción termina siendo a simple vista que Pascal en los sistemas domésticos y de rebote en el Tegra X2 es una Maxwell++ en teoría. Pero la cosa no es así de simple porque una GPU es mucho más que sus SM/CUs correspondientes y los cambios de Maxwell a Pascal están precisamente en una serie de lugares que no son las unidades SM.

PascalVenn.png

Y es aquí donde entramos en una serie de elementos importantes que son «Pascal» a nivel de escritorio pero que se encuentran ya en el X1.

  • La posibilidad de hacer dos operaciones de 16 bits bajo una misma instruccion subdividiendo la ALU  de 32 bits y el Registro correspondiente. FP16Op_575px
  • Soporte para codificar video en H.265/HEVC (aunque esto es trabajo del NVENC).

Por lo que podemos deducir que la GPU es casi igual en ambos casos a excepción de dos puntos concretos, pero antes de tocar esos dos puntos me gustaría hacer un inciso en lo que es el texturizado.

#5.1 Texturizado

Ambas GPUs tienen unas 16 unidades de texturas por lo que no van a poder trabajar con una mayor cantidad de texeles, suponiendo igualdad en la velocidad de reloj y que las texturas están comprimidas en formato BC/DXT/S3TC esto son:

768 Mhz*1 byte por texel*16 unidades= 12 GB/S

El problema viene en que la GPU tiene que acceder a través de la interfaz de memoria a la RAM que tiene un montón de clientes para la lectura y no solo la CPU. Aunque el anillo que es la interfaz de memoria es muy rápido no lo es la RAM que solo tiene un ancho de banda de 25.6 GB/S en ambas direcciones y por tanto unos 12.8 GB/ de lectura. Por lo que si Nintendo hubiese querido ir más allá en cuanto a velocidad de reloj se hubiese encontrado de entrada con un rendimiento decreciente pasados los 768 Mhz.

¿Es un problema en modo portátil? No, desde el momento en que el ancho de banda necesario se reduce a un 40% y a un 50% respectivamente.

307,2 Mhz*1 byte por texel*16 unidades= 4.8 GB/S

384 Mhz*1 byte por texel*16 unidades= 6 GB/S

En el Tegra X2 la interfaz de memoria puede ser de hasta 128 bits y por tanto duplicar el ancho de banda, en un sistema con el X2 Nintendo se podría permitir el lujo de subir levemente la velocidad de la GPU en modo dock aprovechando el mayor ancho de banda sin tener que hacer cambios arquitecturales en la GPU.

#5.2 Computación

En la generación actual se combina lo que son gráficos y computación de manera alternada para generar la escena. Aquí entramos en el único elemento puramente Pascal que podría estar (o no) en la GPU del X1 pero que debería estar si o si en la X2. ¿De que se trata? Basicamente que el tiempo de cambio de contexto de computación a gráficos se ha reducido enormemente haciendo que la ejecucion de los juegos en un entorno combinado sea un poco más rápida. No es el caso de la mayoría de juegos de Switch que apenas utilizan la computación para según que tareas al ser ports directos de Wii U o de la anterior generación. En realidad en una GPU de las especificaciones de las de Switch no hay mucho tiempo muerto que se pueda aprovechar para computación que en los juegos de PS4 y Xbox One se suelen utilizar para procesos de post-procesado.

¿La solución? Hacer que algunos render targets funcionen a menor resolución y/o menos precisión afectando la calidad visual respecto a las versiones en otras consolas mucho más potentes. Switch por potencia es ideal para hacer ports mejorados de la generación PS3/360, lo hemos visto con Skyrim que luce muy bien en Switch pero no es buena para portar directamente desde PS4/Xbox One ya que en ese caso se tiene que realizar una conversión y teniendo en cuenta las limitaciones del hardware pues… La computación no es muy útil en Switch no porque la consola no pueda hacerla bien, poder la puede hacer bien pero los tiempos muertos utilizados para computación son mucho más pequeños.

El hecho de que Pascal reduzca los tiempos de cambio de contexto ayuda enormemente a acelerar la ejecución de los juegos que las ejecutan. Nos podemos encontrar con una mejora leve respecto a la Switch estandar en una Switch con un SoC basado en el X2 por ello o simplemente una gran mejora. Dependerá del nivel de uso del pipeline de computación para cosas como los efectos de post-procesado, las físicas de la escena…

#5.3 Compresión de Color

La Compresión de Color es el hecho de comprimir el búfer de color de cara a la re-utilización del mismo como textura, el problema de renderizar sin compresión de color es que los Render Targets en el caso de efectos de post-procesado o del renderizado en diferido no son recuperados como texturas comprimidas sino que ocupan todo el ancho de banda que ocuparían sin comprimir afectando muy negativamente el rendimiento en casos donde el ancho de banda es crucial.Es aquí donde entra lo que es la Compresión de Color, pero tiene ciertas diferencias en el X1 respecto al X2.

¿En que punto se diferenciarían entonces? En la Compresión de Color que en el X2 es más avanzada que en el X1. La Compresión/Descompresión de color por lo general es de 2 tipos, la primera es del tipo aritmetica por lo que se descomprime al vuelo el valor de los pixeles utilizando un algoritmo de compresión y de descompresion,  el segundo tipo es por bloque y lo que hace es identificar areas de un mismo color y los agrupa en un mismo envio.

En el X1 la compresíón aritmética es de 2:1 y la compresión por bloque es de 8:1

ColorComp

Es por ello que en Switch los juegos que tienen un aspecto más «cartóon» tienen una ventaja en ancho de banda…

2565435-e314stage1demo_splatoon_20140612

NSwitch_SuperMarioOdyssey_09_mediaplayer_large

Repecto a los que tienen un aspecto más «realista» (colorido menos homogéneo)

the_legend_of_zelda_breath_of_the_wild_e3_2016_new-19

elder-scrolls-v-skyrim-switch_1.jpg

La Compresión de Color no sirve para generar el búfer final de imagen (Frontbuffer) pero es útil en el caso del renderizado en diferido porque la GPU puede leer el búfer comprimido sin problemas. Ahora bien, no se debe confundir la Color Compressión con lo que es la Compression de Texturas porque es un tema aparte, aunque también es cierto que los búfers de imagen recalculados son utilizados como texturas a lo que me refiero es que no se comprimen utilizando compresión S3TC/BC/DXTC.

En Pascal se han añadido dos métodos de compresión de color de manera aritmética además del primer tipo.

PascalEdDay_FINAL_NDA_1463156837-008.png

Como se puede ver aquí la compresión aritmética se ha mejorado, dado que el proceso es algo que hace la GPU de manera automática y se mantiene el primer tipo que coincide con Maxwell pero el nivel de mejora no esta en el nivel de compresión sino en el tiempo de compresión/descompresión (lo cual tratare cuando llegue a la unidad VIC).

Teniendo en cuenta la compresión DCC de los dos tipos podemos sacar más o menos cual es el ancho de banda necesario para el Backbuffer en un renderizado en diferido clásico con 4 Render Targets contando además el Z-Buffer+Stencil en la ecuación, por lo que lo que vamos a ver a continuación son los requisitos de ancho de banda

warning-banner

Voy a colocar un montón de tablas a continuacion para que veáis a diferentes resoluciones cuales son los anchos de banda necesarios teniendo en cuenta las distintas condiciones de renderizado, tanto con con el renderizado inmediato…

forward-v2

… como en diferido a un nivel de la anterior generación en sobremesa. es decir, un Color Buffer con 4 Render Targets.

deferred-v2

La GPU de Switch pese a soportar rasterizado por Tiles a la hora de formar los búfer de imagen finales no lo hace por Tiles, sino que genera los búfers de imagen completos y por tanto sobre la memoria LPDDR4, la cual tiene un bus de escritura de 12.8 GB/s

Renderizado Inmediato 1920x1080 y a 30 fps
Color Z+S AA BW (GB/s)
32 32 1 0,46
32 32 2 0,93
32 32 4 1,85
16 (32 en DCC 2:1) 32 1 0,35
16 (32 en DCC 2:1) 32 2 0,70
16 (32 en DCC 2:1) 32 4 1,39
Renderizado Inmediato 1920x1080 y a 60 fps
Color  Z+S AA BW (GB/s)
32 32 1 0,93
32 32 2 1,85
32 32 4 3,71
16 (32 en DCC 2:1) 16 1 0,70
16 (32 en DCC 2:1) 16 2 1,39
16 (32 en DCC 2:1) 16 4 2,78

No voy a tocar las resoluciones más bajas porque no merece la pena hacerlo, como se puede ver en el renderizado inmediato no supone un problema en lo que a ancho de banda en la consola se refiere, pero el problema aparece tan pronto como hablamos del ampliamente utilizado renderizado en diferido donde el uso del ancho de banda se dispara enormemente por lo que es recomendable utilizar la Compresión de Color para que el ancho de banda no resulte en un problema.

Tomando como he dicho antes unos 4 Render Targets para el búfer de color…

Renderizado en Diferido a 1920x1080 a 30 fps
RT0 RT1 RT2 RT3 Z+S BW (GB/s)
32 32 32 32 32 9,27
16 (32 en DCC 2:1) 16 (32 en DCC 2:1) 16 (32 en DCC 2:1) 16 (32 en DCC 2:1)16 (32 en DCC 2:1) 32 5,56
Renderizado en Diferido a 1920x1080 a 60 fps
RT0 RT1 RT2 RT3 Z+S BW (GB/s)
16 (32 en DCC 2:1) 32 32 32 32 18,54
16 (32 en DCC 2:1) 16 16 16 32 11,12

Aqui ya vemos un cuello de botella en Switch por el hecho que carecemos de más de 12.8 GB/s de ancho de banda para escritura, incluso en modo comprimido teniendo en cuenta el resto de componentes existentes que escriben sobre la memoria es un cuello de botella el ancho de banda que tiene la consola para generar el bufer de imagen. No es un sistema pensado para funcionar 1080P realmente sino que esta diseñado para renderizar a 720P y en algunos casos incluso con sacrificios, el hecho de colocarle a la GPU un ancho de banda de 51.2 GB/s mejoraría el rendimiento porque la GPU no se vería con el ancho de banda tan limitado para poder trabajar, aunque personalmente pienso que no vamos a ver nada a mayor resolución de pantalla en una futura Switch pero si que pienso que vamos a una Switch HDR.

Creo que vamos a ver la interfaz de memoria evolucionando de LPDDR4-3200 a LPDDR4-4266 pero sin dejar de ser de 64 bits.. Por lo que la evolución ira a los 34.8 GB/s de ancho de banda, lo que no es suficiente para 1080P60 en un supuesto nuevo sistema. ¿Pero tiene sentido mantener la pantalla a 720P? Lo que no tiene sentido es aumentar la resolución si no existen los medios a largo o corto plazo para mantener dicho aumento de resolución junto a mantener estable el rendimiento de los juegos.

#5.4 Velocidad de Reloj

Antes os he explicado el motivo por el cual Switch funciona a unos 768 Mhz como mucho en modo dock y tiene que ver con el ancho de banda disponible, pero hay otro motivo  que tiene que ver con la naturaleza del Tegra X1.

El Tegra X1 solo puede alcanzar sus más altas velocidades de reloj haciendo que la CPU se mueva a una velocidad de 1 Ghz aproximadamente por el ahogamiento termal producida por esta a la GPU. En la Shield TV donde la GPU también utiliza una velocidad derivada de los 38.4 Mhz…

ss2017-01-09at08-09-13.png

Aquí vemos dos velocidades de reloj, unos 884.8 Mhz y unos 921.6 Mhz de velocidad de reloj. ¿Como es que Switch no los utiliza? Pues porque de cara a renderizar en modo portátil lo que hace es recortar el multiplicador respecto a la velocidad base del modo dock al 40% y no existen multiplicadores fraccionarios sino de números exactos. ¿Entonces? Con una tabla lo veréis mejor.

Mhz Multiplicador /2,5 Multiplicador
768 20 307,2 8
844,8 22 337,92 8,8
921,6 24 368,64 9,6

¿De donde salen esos 768 Mhz? Son la velocidad más alta viable como he dicho antes en los que el ancho de banda de la memoria no es un problema. Pero los 768 Mhz es otra de las velocidades de reloj para la GPU en el X1 de seríe y es la má alta de las que son permitibles sin ahogamiento térmico por el medio.

ss2017-01-09at08-08-31

¿Es posible que veamos una versión con una velocidad de reloj para la GPU un poco más rapida? Si, se escogen los 48 Mhz como velocidad de reloj estándar, pero sería un salto más bien leve.

Multiplicador Velocidad /2,5 Multiplicador
20 960 384 8
22 1056 422,4 8,8
24 1152 460,8 9,6

En realidad ya hay algunos juegos que funcionan a 384 Mhz en Switch, y en realidad también los 768 Mhz son un multiple de 48 Mhz por lo que sería también un modo de funcionamiento para ciertos juegos en modo dock, especialmente los más antiguos que no aprovecharían la velocidad de reloj extra, por lo que al final lo que tendríamos solamente sería un modo 960 Mhz en modo dock, lo cual tampoco es que sea un salto espectacular sino más bien leve, pero sería un modo adicional para el dock que tendría esta versión más avanzada.

¿Sería contraproducente el aumento de la velocidad de reloj? Si a Nintendo se le ocurre colocar el Tegra X2 en una eventual versión avanzada de la Switch tendrá una ventaja importante incluso si mantiene las mismas velocidades que el modelo original por el uso de los 16FF al reducir el consumo energético a casi la mitad, esto significa que con una batería del mismo tamaño y con las mismas velocidades de reloj puede duplicar sin problemas el tiempo de duración de la batería en un modelo más avanzado.

#5.5 GPU Host

Conectado a la GPU tenemos un Crossbar privado llamado HOST1X en el X1, aunque no esta especificado en el diagrama general, dicho Crossbar forma parte del entramado que es la GPU del sistema tanto en el X1 como en el X2 y tiene una serie de componentes conectados al mismo y estos se encuentran conectados a la interfaz de memoria del sistema.

El GPU Host tiene en su interior una unidad CDMA (Command DMA) que recibe datos e instrucciones de manera directa de la GPU dado que los componentes que se encuentran conectados al mismo son aceleradores de la GPU, procesadores por si mismos con una serie de funciones específicas que voy a describir a continuación.

VIC (Video Image Compositor): Se trata de la unidad de post-procesamiento de video y por tanto es el encargado de generar la composición de la imagen final, por lo que es el encargado de leer el backbuffer (en RGBA) y convertirlo en RGB por lo que acabará ocupando de ancho de banda siempre la resolucion*RGB en bruto.

  • Puede rotar o girar sobre el eje la imagen final resultante.
  • Puede convertir imagen entrelazada en imagen progresiva
  • En las imagenes capturadas por la cámara puede reducir el ruido temporalmente, tanto en fotos como en captura de video. Como Switch no tiene cámara integrada esta funcionalidad no se utiliza
  • Capacidad para escalar la imagen.
  • Tiene una unidad de Blending que permite hacer mezclas de pixeles así como operaciones booleanas sobre un mismo pixel, esta funciona como un Blitter tradicional y tiene acceso directo a la interfaz de memoria a través de una unidad DMA
  • El VIC es además el encargado de descomprimir al vuelo los pixeles generados por la Delta Color Compression generado por los ROPS de la GPU.
  • En el X2 soporta HDR. Esto significa que una eventual mejora de Switch podría llevar una pantalla HDR.

NVENC: Es el codificador de video en H.264 y HEVC, es utilizado en Switch y otros dispositivos para generar videos en dicho formato, la fuente de origen puede ser el búfer de imagen de los juegos (se almacenan varios frontbuffers como resultada para componer el video) y el resultado se almacena es almacenado memoria no-volatil (microSD, eMMC). Puede generar videos de hasta 2160P a 30fps, pero eso tiene poca importancia en Switch desde el momento en que la consola funciona a resoluciones menores. En el caso del X2 aprovecha el mayor ancho de banda de la interfaz de memoria para reproducir videos hast a 4K60, es una de las piezas que en una eventual revision de Switch se cambiaría solo por un motivo, la incapacidad del X1 de codificar videos en HDR a tiempo real.

TSEP: Son las siglas de Tegra Security co-processor, encargado de manejar las claves HDCP.

NVDEC: Descodificador de video en H.264 y HEVC, es el procesador utilizado durante la reproducción de video. Puede reproducir a 4K30 en el Tegra X1 y a 4K60 en el Tegra X2 pero dado que Switch no alcanza esas resoluciones poco. Es una de las piezas que en una eventual revision de Switch se cambiaría solo por un motivo, la incapacidad del X1 de codificar videos en HDR a tiempo real.

NVJPG: Es un codificador JPEG, cuando en Switch le damos a… capturar una instantanea de nuestra acción de juego crear una copia comprimida en JPEG. No solo puede leer imagenes generadas por el VIC sino también del Video Input para la creación de instantaneas.

VI: Se trata del Video Input, un modulo encargado de convertir la imagen capturada por la cámara del dispositivo (ya se que Switch no tiene cámara) y enviarla al ISP para procesarla. ¿Es posible que veamos una eventual versión de la Nintendo Switch con una cámara integrada? Quien sabe… ¿Pero para que?

ISP: Son las siglas de Image Signal Processor, es el procesador utilizado para procesar las imagenes capturadas por la cámara, es una pieza por tanto completamente inutil en la Nintendo Switch actual pero no lo sería en el caso de una eventual Switch con cámara.

Display: Controlador de Pantalla, encargado de coordinar el envio de datos a la pantalla a través de la interfaz mini DisplayPort en el caso de Switch. Lee la sección de memoria correspondiente al frontbuffer y envía la señal para generar la pantalla, se encuentra controlado por el VIC por lo que realmente es un co-procesador de este.

CSI (Camera System Interface):  Es donde se conecta la cámara del sistema para que interactue con la GPU , no útil en el caso de la Switch estándar al no haber cámara integrada de serie en el sistema, pero el SoC tiene dicha conexión.

#6 E/S

Nintendo Switch tiene una serie de interfaces de E/S que son conocidas por todos:

  • 801.11ac (WiFi)
  • Bluetooth
  • USB-C (mini Display Port integrado)
  • Interfaz microSD
  • Interfaz eMMC

No merecen ninguna discusión porque son interfaces completamente estándar.

#7 Viabilidad del X2 en Switch

Una version a corto plazo con el X2 como SoC principal debería funcionar de la siguiente manera:

  • Modo Max-Q como único modo, los dos núcleos Denver 2 desactivados. En todo caso en el Jetson TX2 con dicho modo las velocidades de reloj alcanzadas son más altas que las de Switch por lo que una versión que mantenga las velocidades de reloj de Switch no sería problema. FINAL JetsonTX2 PPT Deck-13
  • Tanto el X1 como el X2 son compatibles por Socket pero el orden de los pines esta cambiado por lo que Nintendo no podría re-aprovechar la placa lógica y tendría que re-diseñar una.
  • Es posible hacer funcionar el X2 con una interfaz de 64 bits en vez de una de 128 bits. ¿Un pequeño overclock en la memoria para un mejor rendimiento? Es posible pero el salto no sería que digamos espectacular sino más bien un aumento leve.
  • ¿Pantalla nueva con soporte HDR? Tendría cierto sentido
  • Dudo que Nintendo al nuevo modelo le metán una cámara aunque todo es posible, pero no tengo dudas que van a duplicar a 64GB la capacidad de almacenamiento interna.
  • La tecnología aún no esta lista para una Switch Consola Portátil que sea viable por el tema del consumo pero si para una pequeña revisión de la Switch actual.