Source: https://josepjroca.wordpress.com/2016/01/31/el-hardware-de-nx-sobremesa-especulacion-puesta-al-dia/
Timestamp: 2018-01-19 17:09:04+00:00

Document:
El hardware de NX sobremesa (Especulación puesta al día) | Disruptive Sketchbook
Urian 3:30 PM el 31 January, 2016
El hardware de NX sobremesa (Especulación puesta al día)
La entrada que hare a continuación es puramente especulativa con tal de explicar como podemos montar la NX de sobremesa bajo especificaciones mínimas teniendo en cuenta los últimos rumores y noticias que han aparecido, tened en cuenta que esto es pura especulación fudamentada. Algunas cosas serán un Deja Vu y antes de empezar recordar que esto de lo que voy a hablar es una especulación sobre la potencia de la NX de sobremesa.
#1 Compute Units en Wii U (R700) y Compute Units en arquitectura GCN
En cualquier juego si queremos aumentar la resolución y/o la tasa de fotogramas tenemos que aumentar la potencia de la GPU en el mismo grado. Pero en especial lo que tenemos que hacer es aumentar la tasa de hilos de ejecución-kernels dentro de cada GPU. Esto es general entre todas las GPUs contemporáneas y ya lo explique en su día con el simil del cine, el cual volveré a rescatar porque es necesario entender todo el esquema completo.
Una Compute Unit de una GPU es una sala de cine, donde los programas-kernels son los espectadores que se sientan en las butacas que son lo stream processors, cuando terminan de ver la película se levantan y entran los siguientes de la cola. En las GPUs de AMD lo que existen son unos elementos llamados Wavefronts compuestos por 64 elementos cada uno de ellos, pero dichos wavefronts se dividen en 4 grupos de 16 cada uno que son enviados a la GPU como mínimo en cada ciclo de reloj aunque es posible que si una instrucción requiere varios ciclos de reloj que el cambio no se haga de un ciclo para otro pero lo habitual es que un Wavefront entero se vea resuelto en solo unos cuatro ciclos de reloj.
Ahora bien, la arquitectura GCN tiene una Compute Unit compuesta por cuatro unidades SIMD de 16 elementos:
Uno puede pensar que un Wavefront se resuelve en de golpe en cada uno de los Compute Units, pero no es así. En la Compute Unit entran cuatro Wavefronts distintos y ejecuta en paralelo la primera etapa de los cuatro wavefronts, luego la segunda etapa, luego la tercera y para terminar la cuarta. Es decir, una Compute Unit de la arquitectura GCN puede ejecutar hasta 4 Wavefronts simultáneos al mismo tiempo. Al mismo tiempo si os fijáis tenemos cuatro unidades de texturizado en la Compute Unit por lo que el ratio en dicha arquitectura es de una TMU por unidad SIMD, siendo el ratio por Stream Processor/SP con cada TMU de 16:1.
Ahora vayamos a la que utiliza Wii U, su GPU es de la familia R700 por lo que la configuración de sus Compute Units es distinta a la de la arquitecturaGCN. Si miramos la configuración de la arquitectura R700:
Cada “núcleo” tiene 80 unidades, lo pongo entre comillas porque aquí núcleo no corresponde a Compute Unit y se puede confundir. El caso es que las 80 unidades están compuestas en unidades de 16 de estas:
Que son lo que la diapositiva de arriba llama ALUs. ¿Verdad que antes he dicho que los Wavefronts entran en grupos de 16? La diapositiva no es muy clara cuando habla del ratio 4:1 pero se refiere a que cada grupo de 5 Stream Processors (ALU) le toca una TMU, es decir… el ratio en la arquitectura R700 es de 20 ALUs por TMU, pero esto tiene una pequeña desventaja, dado que la gran mayoría de operaciones gráficas se hacen con cuatro componentes la mayoría de veces el quinto stream processor quedaba completamente en desuso por lo que AMD en arquitecturas posteriores decidió pasar al ratio 16:1 para las TMUs, tal y como se ve en la Compute Unit de la arquitectura GCN.
En Wii U tenemos 8 unidades compuestas cada una de ellas por una TMU y sus respectivas ALUs. Marcadas con la letra N en el Latte que es donde se encuentran las Compute Units de su GPU:
Cada N corresponde a una TMU distinta, por lo que en realidad tenemos 2 unidades SIMD por tanto 160 Stream Processors. Supongamos en primer lugar que lo que queremos es hacer una consola que lo que haga es mover los juegos de Wii U que van a 720P a 1080P, luego ya iremos escalando hacía arriba.
(1920*1080)/(1280*720)=2.25.
8 TMUs* 2,25 = 18 TMUs
Dado que cada unidad SIMD es de 16 ALUs (80 Stream Processors) y con 4 TMUs entonces la cifra no cuadra mucho por lo que tendríamos que subir a las 20 TMUs, lo que darían unos 400 Stream Processors. Pero no nos interesa reciclar la GPU de Wii U por estar desfasada y haber otras opciones mejores en el mercado. Es decir, lo que nos interesa es tener en cuenta la arquitectura GCN. En la arquitectura R700 cada unidad SIMD esta compuesta por 16 ALUs, que al mismo tiempo esta compuesta por 5 Stream Processors. La GPU de Wii U tiene 2 unidades SIMD en total, cada unidad SIMD equivale a una Compute Unit de la arquitectura GCN ya que opera con cuatro Wavefronts al mismo tiempo y dispone de 4 TMUs. ¿La diferencia? El ratio de la unidad SIMD es de 16:1 en ves de 20:1, por lo que con unas 20 ALUs bajo arquitectura GCN la potencia de a GPU quedaría en los 320 Stream Processors, una cifra que de entrada esta claro que es insuficiente.
Pero supongamos que lo que queremos es una consola que no solo sea un aumento en la resolución sino también un aumento en la tasa de fotogramas en ciertos juegos. Un aumento de casi el doble. Y es aquí donde entramos en un elemento peliagudo y al mismo tiempo algo que me “preocupa” sobre el hardware de la consola, hay juegos que no es que funcionen solo a 720P sino que además lo que hacen es funcionar a 30fps e incluso con bajones que los colocan cerca de los 20fps. Un escalado solo en resolución sería una auténtico suicidio desde el punto de vista técnico… Un Game Over en toda regla y el fin de Nintendo ya que los editores independientes de entrada le darían con la puerta en las narices.
¿Que le parece el hardware de mi máquina?
Lo siento, no nos interesa… Vuelva otra generación por favor.
Pe… pero oiga…
Nintendo tendría que asegurarse al menos que los juegos que en Wii U funcionan a 720P30 de media funcionen a 1080P60 en la siguiente generación.
El salto de 720p30 a los 1080p30 supone unos 320 Stream Processors, esto manteniendo la calidad de imagen y la velocidad de reloj de la GPU de Wii U. El paso a 1080p60 tienen que significar unos 640 Stream Processors. Por lo que el las 8 TMUs de Wii U se convertirán automaticamente en 40 TMUs y dada la configuración de la arquitectura GCN esto son 10 Compute Units o mejor dicho unos 640 Stream Processors en total. En lo que a potencia se refiere este salto sin tocar la velocidad de reloj de la GPU respecto a Wii U sería de unos 0.704 TFLOPS, muy por debajo de lo que pueden ofrecer tanto Xbox One como PS4. Por lo que nos encontraríamos de nuevo en la misma situación que Wii U, con ports recibiendo recortes visuales por la falta de potencia de procesamiento de la GPU respecto a PS4 y Xbox One.
¿Entonces cual sería la potencia ideal para una NX que compitiese de tu a tu con Xbox One y PS4?
En una de las sesiones de preguntas y respuestas entre la directiva de Nintendo y los accionistas e inversores hubo una frase de Takeda que me llamo mucho la atención, algo que supone un giro de 180º respecto a lo que Nintendo realiza normalmente. La frase puede que la este malinterpretando yo pero es la siguiente:
Entiendo que, gracias a la evolucion de la tecnología de las computadoras, apuntar a un entorno se desarrollo de software que no dependa de un hardware específico se esta convirtiendo en la norma de hoy en día.
Esto me llama la atención porque actualmente en el desarrollo de juegos tenemos dos entornos de desarrollo de software que son agnósticos de plataforma y por tanto del hardware y altamente utilizados para la producción de juegos.
La colaboración de Nintendo con Unity ya se ha dado en Wii U, por lo que una versión del motor podría aparecer sin problemas en la nueva consola.
No conozco cuales son las exigencias de Unity, pero hay altos rumores de que el Unreal Engine 4 podría ejecutarse en la consola. Dichos rumores vienen de cuando Dragon Quest XI fue presentado se comento que iba a tener una versión para NX. Oficialmente el juego sale para PS4 y 3DS porque NX aún no ha sido anunciada como plataforma oficial. ¿Que tiene que ver la versión de NX en esto? Pues que Dragon Quest XI utiliza el Unreal Engine 4. Pero la pregunta clave es…. ¿Cual es la potencia que pide el Unreal Engine 4 para funcionar?
En palabras del propio Tim Sweeney, arquitecto del Unreal Engine 4 cuando este fue presentado:
El Unreal Engine 4 esta pensado para una GPU DX11 y empieza a ser realmente interesante en un hardware con más de 1 TFLOP de potencia gráfica, donde entrega unas capacidades realmente sin precedentes. Sin embargo el UE4 también incluye un renderizador para los dispositivos del mercado de masas con una colección de carácteristicas más apropiada para estos.
Dicho TFLOP de marras es en el entorno de las GPUs de Nvidia, no podemos compararlo de forma directa por lo que voy a hacer ahora es un poco generalista y simplificado. Lo digo porque he escuchado alguna que otro comentario por ahí. Tampoco Sweeney nos hablo de cual era la resolución objetivo pero hay una parte de la promo-entrevista que resulta interesante y nos ayudará junto a otra información sacar las condiciones de dicha cifra:
La Iluminación Global a tiempo real en el Unreal Engine 4 es el mayor progreso en iluminación desde que el Unreal Engine 1 introdujera la Iluminación Directa en 1995.
Por lo visto el UE4 tiene dos motores de renderizado… ¿En que se diferencian?
Por lo visto en el tipo de iluminación utilizada… ¿Donde he oído yo eso de los 2.5 TFLOPS para iluminación global? Ah si, de la demo del Samaritan:
Por lo que es posible que el renderizador para “productos del mercado de masas” este pensado para un 1 TFLOP a 1080P30 realmente, es decir… Sin utilizar la iluminación global. ¿Como se aplicaría esto a NX en el esquema que estamos hablando? Pues tendríamos que subir la velocidad de reloj de la GPU hasta estar por la cifra de 1 TFLOP para los 1080P30. Esto significa que para llegar a esas condiciones necesitaremos un aumento en la velocidad de reloj de la GPU para poder llegar a dicha cifra, es decir… NX ha de superar la cifra de 1 TFLOP, romper la barrera.
Si tomamos como referencia el Unreal Engine 3 y Xbox 360 como referencia según la diapositiva nos salen unas 9.000 operaciones por pixel, el UE4 en su versión sin GI da unas 16000 operaciones por pixel. Wii U resulto impotente incluso para el UE3 estándar porque su GPU solo podía ejecutar unas 6400 operaciones por pixel de media, llevando a que muchos juegos con ese motor tuviesen recortes en Wii U respecto a la versión de Xbox 360. Es decir, Nintendo no puede repetir el error y como mínimo se ha de colocar en el mínimo del Unreal Engine 4 que son las 16.000 operaciones por pixel, el ideal serían las 40.000 pero no me veo a Nintendo compitiendo en la gama alta, pero 16.000 es el mínimo que deberíamos esperar en lo que al rendimiento gráfico se refiere para el UE4.
¿Pero a que resolución? Lo que voy a decir ahora no lo voy a sostener con nada fiable pero es una posibilidad, se que la encuesta no fue muy fiable y fue bastante fake y mal hecha pero no entiendo como la gente se pone las manos sobre la cabeza ante una resolución HD+ aka 900p y a 60fps, más que nada porque es una resolución mucho mejor que los 1080p30.
El hecho de que la GPU pueda reproducir video a 4K/60 no es una contradicción a renderizar a 900p60, en todo caso teniendo en cuenta las 16.000 operaciones por pixel del UE4 básico entonces:
(1600*900*60*16000)/ 10^12= 1.38 TFLOPS.
Que gracioso, es una cifra muy cercana a la de Xbox One aka la consola 900p, no creo que sea una coincidencia esto.
En el caso de una configuración 720p60 entonces:
(1280*720*60*16000)/10^12 = 0.88 TFLOPS aprox
Luego tenemos la más alocada de todas, la capacidad de reproducir a 1080p60 por lo que la potencia necesaria acabaría siendo de:
(1920*1080*60*16000)/10^12= 2 TFLOPS
En la última instancia la consola estaría un poco por debajo de PlayStation 4. Ahora bien, hemos tomado como referencia una GPU con 640 Stream Processors, 10 CUs, estos tres escenarios plantean un problema con la configuración que hemos escogido.
0.88 * 10^12/ 640 Stream Processors*2 (FMADD)= 687.5 Mhz.
1.38 * 10^12/ 640 Stream Processors*2 (FMADD)= 1078 Mhz.
1.99 * 10^12/ 640 Stream Processors*2 (FMADD)= 1.55 Ghz.
Dado que las GPUs de la arquitectura GCN se mueven habitualmente entre 800Mhz y 1Ghz las dos primeras cifras son posibles mientras que la segunda esta en el mundo de lo imposible a no ser que aumentemos el número de Compute Units de la configuración de la que estamos hablando.
Ahora vamos a darle una vuelta más a la maquinaría.
¿El retorno de Electronic Arts?
No es algo oficialmente confirmado, pero hace unos días pudimos leer que Star Wars Imperial Commando podría aparecer en la Nintendo NX así como en el resto de plataformas.
Lo cual es una sorpresa positiva después del abandono de EA a las consolas de sobremesa de Nintendo por el fiasco técnico de Wii U. ¿Pero que tiene de especial en el contexto del que estamos hablando? En primer lugar tenemos que tener en cuenta hecho de que el Frostbite en PS4 funciona a 900p60 por lo que podemos saber cual es la tasa de operaciones por pixel bajo dicho motor. Haciendo una simple operación.
(1.84*10^12)/1600*900= 22.000 operaciones por pixel aproximadamente.
Es un salto importante respecto a los 16.000 y pienso que Nintendo haría un golpe de efecto muy grande de cara al apoyo de terceros si consiguieran convencer a Electronic Arts a volver de nuevo independientemente de lo bien o mal que caiga la compañía su influencia es muy importante. Incluso si la consola fuese inferior a PS4 el hecho de poder reproducir el Frostbite a 720P60 requeriría una potencia de:
(1280*720*60*22000)/10^12= 1.21 TFLOPS.
Por lo que de las tres configuraciones ante mencionadas la que tendría más números sería la segunda:
1.38 * 10^12/ 640 Stream Processors*2 (FMADD)= 1.55 Ghz.
Hay que tener en cuenta que en este caso estoy siendo muy conservador en lo que a las especificaciones técnicas se refiere. También es posible que la GPU sea tan potencia como la de PS4 y puede reproducir los juegos a 900p60 o incluso más potente y los pueda reproducir a 1080p60. El problema es que en ambos casos la velocidad de reloj de la GPU aumentaría considerablemente y lejos del entorno de los 800Mhz-1 Ghz, el que pienso que va a tener la GPU de la consola.
1.84*10^12/640 Stream Processors*2 (FMADD)= 1.4375 Ghz.
2.73*10^12/640 Stream Processors*2 (FMADD)=2.133 Ghz
Como veis son cifras completamente imposibles por lo que tenemos que buscar una configuración con un mayor número de Compute Units con tal de poder ir bajando la velocidad de reloj hasta unos niveles que podríamos considerar estables. Nintendo no tiene porque seguir esta configuración pero tanto en Xbox One como en PS4 el ratio de la velocidad de reloj CPU-GPU es de 2:1. Dado que la consola aparecerá a finales de este año o durante el 2017 hemos de tener en cuenta que es muy probable que el chip principal este fabricado utilizando el nodo de 14 o 16nm Finfet y por tanto estemos hablando de una APU/SoC con Polaris+Zen acompañado de memoria HBM.
De esta diapositiva PS4 utiliza el bus Onion+, y la APU/SoC más moderno hecho por AMD y que se encuentra en el mercado, bajo el nombre en clave Carrizo, unifica los buses Garlic (el que permite el acceso directo a la memoria desde la GPU) y el Onion (que comunica a la GPU con el Northbridge de la GPU) en un solo componente que hace el trabajo de los dos al que han llamado Onion3, por lo que la configuración pasaría a ser de esto:
En el caso del bus coherente nos sirve para saber la velocidad de reloj de la CPU a través de la velocidad de reloj de la cache más lejana.
En el caso del Jaguar de PS4 la cache más alejada es la L2 que es la compartida por los cuatro núcleos de cada módulo y funciona a la mitad de la velocidad de reloj de la CPU, que en el caso de PS4 es de unos 800Mhz. El bus Onion es de 256 bits por lo que coge los unos 25.6 GB/seg de ancho de banda. Pero lo que nos interesa es el Zen y si miramos la configuración del Zen veremos que su cache más alejada es la L3 que cumple la misma función que la L2 del Jaguar.
Si se mantiene el bus de 256 bits eso significa que la velocidad de reloj de la CPU con el bus coherente de 50GB/seg sería de unos 3.125 Ghz, mientras que con el bus de 40GB entonces su velocidad de reloj sería de 40GB/seg, obviamente bajo estas velocidades de reloj el ratio 2:1 de la GPU deja de tener sentido porque son demasiado altas por lo que tenemos que buscar otra forma de adivinar cual puede ser dicha velocidad de reloj de la GPU.
Dado que el bus no-coherente seguiría existiendo y como antes nos permitiría el acceso completo al ancho de banda desde la GPU, podemos deducir el número de ROPS de la misma, dado que estamos en una configuración de 10 CUs por el momento y la configuración de las GPUs de AMD es:
4 ROPS por RB
3 o 4 CUs por RB
La configuración más posible sería de 4+3+3 y por tanto 3 RBE, por lo que estaríamos hablando de 12 ROPS en total. Lo cual es una cifra un poco rara de entrada, ya que lo habitual son los 8, 16 o 32 ROPS en las GPUs, 8 ROPs sería demasiado bajo pero 16 tienen más sentido en una configuración con un solo chip HBM2, por lo que la configuración pasaría a ser de 12 CUs en vez de 10.
Dado que antes hemos hablado del Frostbite como referencia entonces tenemos que volver a reformular por el uso de las 12 CUs:
1.38 * 10^12/ 768 Stream Processors*2 (FMADD)= 0.9 aprox (720p60 Frostbite/ 900p60 UE4)
1.84*10^12/768 Stream Processors*2 (FMADD)= 1.120 Ghz. (900p60 Frostbite)
1.99 * 10^12/768 Stream Processors*2 (FMADD)= 1.295 Ghz. (1080p60 UE4/900p 60 Frostbite)
2.73*10^12/768 Stream Processors*2 (FMADD)=1.777 Ghz (1080p60 Frostbite)
La otra configuracion posible son los 16 CU:
1.38 * 10^12/1024 Stream Processors*2 (FMADD)= 675 Mhz aprox (720p60 Frostbite/ 900p60 UE4)
1.84*10^12/1024 Stream Processors*2 (FMADD)= 0.9 Ghz. (900p60 Frostbite)
1.99 * 10^12/1024 Stream Processors*2 (FMADD)= 0.975 Ghz. (1080p60 UE4/900p 60 Frostbite)
2.73*10^12/1024 Stream Processors*2 (FMADD)=1.33 Ghz (1080p60 Frostbite)
La configuración con 16 CUs parece ser la mas adecuada de todas ellas de cara a que la consola sea competitiva tecnicamente hablando. Ahora bien, nos hemos dejado lo de la memoria HBM2, la cual va a salir con tres velocidades de reloj distintas:
Debido a la relación existente entre los ROPS y el ancho de banda de la memoria podemos deducir rápidamente las potenciales velocidades de reloj, la formula sería la siguiente:
Numero de ROPS*Precision por pixel*(Color+Z)Lectura+Escritura*Velocidad de reloj de la GPU= Ancho de banda ideal para la memoria gráfica.
Por desgracia no tenemos todos los datos:
En cuanto a la memoria HBM2 tenemos tres configuraciones distintas en lo que a velocidad de reloj se refiere que son las siguientes:
16 ROPS*8 bytes por pixel*2*N=Ancho de banda de la memoria HBM2
Por lo que la formula quedaría de la siguiente manera:
N =Ancho de banda de la memoria HBM2/16 ROPS*8 bytes por pixel*2
Ahora veamos con las tres velocidades de la memoria HBM que pueden acabar en la consola:
256*10^9/256= 0.5 Ghz.
204*10^9/256= 0.8 Ghz aprox.
256*10^9/256= 1 Ghz.
Veamos como quedaría la cosa en cuanto a potencia gráfica:
0.5*1024 Stream Processors*2 (FMADD)= 1 TFLOP
0.8*1024 Stream Processors*2 (FMADD)= 1.7 TFLOPS aprox.
1*10^12*1024 Stream Processors*2 (FMADD)= 2 TFLOPS
Seamos sinceros, el escenario ideal sería el de 2 TFLOPS de potencia y teniendo en cuenta las exigencias técnicas del Frostbite el primer escenario no lo veo posible. Los 1.7 TFLOPS tendrían su gracia desde el momento en que estaríamos hablando de un salto de una orden de magnitud respecto a Wii U y la consola se colocaría casi a la par de PS4 en lo que a potencia técnica se refiere. Es más, el tema del consumo es importante y hemos de tener en cuenta que un SoC con una GPU a 800Mhz consume mucha menos energía que uno con un SoC con una GPU a 1Ghz.
El tema del consumo, la obsesión de Nintendo
Nintendo lo que busca es una mayor potencia/consumo que la competencia, lo que se llama… rendimiento por vatio. Si comparamos en potencia Wii U con el resto veremos que es un poco menos potente que PS4 y Xbox One, pero su rendimiento por vatio es superior. En el caso de la NX de sobremesa el hecho de aparecer bajo un nodo de fabricación más avanzado supone una reducción importante no solo en el tamaño sino también en el consumo energético.
Una de las cosas que permite el uso de un nodo más avanzado es el hecho que se pueden alcanzar velocidades de reloj con un voltaje mucho más bajo:
Esto es una perogrullada, pero el uso de un proceso FinFet significará una reducción enorme en lo que al consumo del chip principal se refiere y Nintendo podrá lanzar una consola con un consumo energético mucho menor que el de PS4 y Xbox One al mercado. En todo caso hay un elemento que me parece cuanto menos un error enorme en el caso de Nintendo y supongo que tras la confusión Wii con Wii U no lo van a volver a repetir, me refiero al poco espacio que tiene la placa lógica donde se encuentran los chips y la memoria en el caso de Wii U:
Esto por no contar las similitudes en forma entre Wii y Wii U, lo que ha llevado a la confusión del mercado de masas entre ambas consolas.
Por lo que Nintendo necesita un diseño industrial nuevo que permita unas especificaciones de consumo y calor mucho mejores, el modelo Wii y Wii U no puede continuar si quieren tener una consola competitiva. El uso de la memoria HBM2 junto a un SoC fabricado bajo el proceso FinFet debería ser suficiente como para poder sacar una consola con un consumo y por tanto con un factor forma mucho menor que PS4.
Obviamente todo esto es una especulación pura y dura, pero como he dicho antes dadas la últimas noticias he decidido ponerlo todo en su sitió y no hacerlo en varias entradas consecutivas.
Esto es todo, dada la cercanía de información sobre NX voy a dejar el tema de NX de sobremesa clausurado en esta entrada. Si me equivoco al 100% no pasa nada, si la acierto total o parcialmente tampoco.
dieselo (@dieselo) 6:55 PM el 31 enero, 2016
Urian, quizás no venga a cuento pero como controlas tanto el hardware me gustaría saber, ¿es posible ponerle unas antenas para ampliar el rango de señal del gamepad de WiiU?
Bob the Buffalo 9:19 PM el 31 enero, 2016
wow que entradota! pero muy bien explicada.
quien sabe si hasta E3 veremos mas sobre esto o antes…espero que antes. tengo mucha curiosidad
← NX no tan portátil
NX no tan portátil (II) →

References: resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución