Comentario Original:

Que opinas de esto urian:

tx1custom

Opino que es cierto que se basa en el Tegra X1 sin ser un Tegra X1 al uso, por eso realice la entrada en modo negativo por el hecho que el TX1 sin cambios tiene horrendos problemas de ancho de banda con la memoria que afectan al rendimiento gráfico, algo que se puede solventar ampliando el ancho del bus de memoria de 64 bits LPDDR4 a 128 bits LPDDR4 o en su defecto añadiendo memoria embebida en el chip para que ciertas operacione se realicen dentro de la memoria interna del procesador.

Pero antes de ir a la pregunta de la memoria… ¿A que viene el uso de los 20nm en vez de los 16nm? Esto supongo que os lo resolverá:

20nmtsmc

La diferencia entre los 20nm y los 16nm de TSMC es nula, esto es debido a que el proceso «16FF» en realidad no es un proceso de 16nm real sino que es uno de 18-19nm realmente y la enorme ventaja de ir a FinFet es poder alcanzar velocidades de reloj altas para un entorno que lo permita. Pero en densidad el salto de los 2onm a los 16nm, es nulo, la propia TSMC compara ambos procesos con el de 28nm y afirma que el de 20nm tiene una densidad de 1.9 veces y el de 16nm de 2 veces por lo que no estamos hablando de un modo de 16nm real y paradojicamente en ciertos lugares se le bautiza como 20nmFinFet por el hecho que su ventaja es en consumo pero no en densidad y si el chip va a ir a ciertas velocidades de reloj es posible que el uso del proceso de 16nm no les resulte una ventaja.

Lo otro que tenemos es el tema de la memoria, la propia Emily sigue hablando de unos 4GB de memoria.

rogersspecs

Esto es importante por un motivo muy simple, si la modificación es la anchura del bus de memoria colocando uno de 128 bits LPDDR4 como el Tegra Parker entonces el número de chips de memoria que podría colocar sería el doble y por tanto soportaría unos 8GB para el SoC pero las especificaciones son de 4GB por lo que el bus es de 64 bits en el caso del SoC de Nintendo Switch.

nvidia-drive-px-29-638

Tras esta pequeña deducción y teniendo en cuenta la historia de Nintendo con sus sistemas lo único que nos queda deducir es que el sistema al igual que sus predecesoras a nivel sobremesa (Gamecube, Wii y Wii U) y como su predecesora a nivel portátil (3DS) la nueva consola de Nintendo tiene memoria embebida en su interior, dicha memoria embebida se utilizaría en principio para almacenar los búfers de imagen de los juegos y sería un factor limitante para colocar los juegos a una resolución mayor que los 720P. Antes de nada no creo que Nintendo utilice gráficos de más de 8 bits por componente y hemos de tener en cuenta que la imagen al televisor se transmitirá a través del dock pero el dock estará conectado a un puerto USB-C que hay abajo en la consola por el que el SoC transmite directamente la imagen y el sonido tanto a la pantalla si esta en modo portátil o al USB-C hacía el dock.

switchinternals

dockinternal

Si existe un método de re-escalado estará dentro del Dock pero no olvidemos que el re-escalado añade una latencia adicional. En todo caso no pienso que la consola pueda renderizar a 1080P porque entonces el coste de la memoria embebida sería prohibitivo. Recordemos que hay dos formas base de renderizar las escenas en los juegos, uno es el renderizado frontal o directo, el otro es el renderizado por diferido. Ambos tienen exigencias de memoria completamente distintas y hemos de tener en cuenta que si miramos el diagrama de la consola el búfer frontal de almacena en la misma memoria. El búfer frontal es el que lee el controlador de pantalla sea cual sea para enviar los datos al televisor o a la pantalla, su formula es:

Resolución*RGB

Si la imagen es a 1280x720P a unos 8 bits por componente entonces:

1280 * 720 * (8+8+8)= 2.764.800 bytes = 2.7 MB.

El búfer delantero esta independientemente de cual sea la forma de renderizar, en algunas arquitecturas con memoria embebida este es escrito en una parte de la memoria principal pero si el diagama es fidedigno entonces ya tenemos unos 2.7 MB de entrada ocupados pero existe una trampa y es que muchas veces para efectos de post-procesado via computación el búfer frontal es rescatado para realizar dichos efectos sobre la imagen final, es rescatado como si fuese una imagen 2D a procesar y de ahí la ventaja de tenerlo cerca del SoC pero hay otra ventaja que es el hecho de poder utilizar la compresión de texturas. Nintendo desde la Gamecube lleva utilizando el método de S3TC que también fue licenciado por Microsoft y es llamado DXTC o BCn, algo que la GPU de Nvidia en Switch ha de soportar desde el momento en que parte de una arquitectura de PC. Dichos métodos de compresión de texturas comprimen la información en un ratio de 4:1 por lo que el búfer frontal pasaría a ser de:

[1280 * 720 * (8+8+8)]/= 691.200 bytes = 0.66 MB.

La compresión de texturas es utilizada a la hora de trabajar en sistemas con memoria embebida para almacenar el búfer de imagen por el hecho que la memoria es cara y escasa pero nos queda en el caso del Forward Rendering el búfer trasero que es donde realmente se renderiza la escena y es más complejo al entrar una mayor cantidad de elementos en juego. El primero de ellos es el Antialiasing, hay dos tipos de AA, el primero es el de la fuerza bruta basado en renderizar la imagen a mayor resolución o con mayor cantidad de muestras. En el caso del segundo no es compatible con el renderizado en diferido mientras que el primero si. El segundo es utilizar algoritmos de computación de proposito general, lo que pide mucha más potencia pero es más laxo en la memoria, en todo caso la formula sería:

Precisión del AntiAliasing*[(Resolución*RGBA)+(Resolución*(Z+Stencil))]

Esto nos daría la siguiente tabla:

AA Sin compresión (en MB) Con compresión (en MB)
1 7,03 1,76
2 14,06 3,52
4 28,13 7,03
8 56,25 14,06

Con compresión con unos 16MB nos bastaría para ambos búfers pero nos falta mirar el renderizado por diferido donde la formula es más compleja.

deferred_overview

Necesitamos un total de 5 Render Targets aparte del Z+Stencil por lo que la tabla se complica de sobremanera ya que en total necesitamos unos 24 bytes por pixel de almacenamiento.

AA Sin compresión (en MB) Con compresión (en MB)
1 21,09 5,27
2 42,19 10,55
4 84,38 21,09
8 168,75 42,19

Nintendo esta portando sus juegos desde Wii U a Switch manteniendo la resolución de renderizado interno a 720P y hay que tener en cuenta que Wii U tenía 32MB de memoria embebida por lo que he marcado en rojo las resoluciones que considero que son inviables teniendo en cuenta lo que ocuparía el bufer frontal y en verde las que realmente lo son, empezando por escenarios con el Forward Rendering:

AA BackBuffer sin Compresión Frontbuffer sin Compresión Total
1 7,03 2,64 9,67
2 14,06 2,64 16,70
4 28,13 2,64 30,76
8 56,25 2,64 58,89

AA BackBuffer con compresión Frontbuffer con compresión Total
1 1,76 0,66 2,42
2 3,52 0,66 4,17
4 7,03 0,66 7,69
8 14,06 0,66 14,72

Veamos ahora los escenarios con el Deferred:

AA BackBuffer sin compresión Frontbuffer sin compresión Total
1 21,09 2,64 23,73
2 42,19 2,64 44,82
4 84,38 2,64 87,01
8 168,75 2,64 171,39

AA BackBuffer con compresión Frontbuffer con compresión Total
1 5,27 0,66 5,93
2 10,55 0,66 11,21
4 21,09 0,66 21,75
8 42,19 0,66 42,85

La otra cara de la moneda es el tema del texturizado, en las consolas con memoria embebida es posible texturizar directamente desde la memoria embebida pero hay dos técnicas para ello:

  1. Trasladar en cada fotograma desde la memoria principal las texturas necesarias para dicha tarea y almacenarlas en la memoria embebida. La memoria ocupada corresponde
  2. Utilizar un mapa de texturas de la escena en forma de una textura gigante, en este caso se almacenan estas en una megatextura en forma de página de texturas gigante que bien puede tener los datos de la textura para acceso inmediato o la dirección de memoria donde se encuentra la textura para su acceso inmediato, en segundo caso funciona de la siguiente manera: vt

Pero en en el caso que nos ocupa nos interesa que el atlas almacene las texturas tal cual en la escena actual, dicha tabla se va cambiando en cada fotograma de la escena sustituyendo las texturas no utilizadas por otras de nuevas y manteniendo las del fotograma anterior y es que en un escenario concreto no van a cambiar las texturas utilizadas en la escena. Si tomamos la resolución de 1280×720 pixeles esto son unos 921k pixeles por lo que esto es menos que una textura de 1024×1024 pixeles con 32 bits de memoria que ocuparía unos 4MB en total sin compresión y con la compresión se iría a 1MB, el hecho de poder texturizar desde la memoria es una ventaja enorme y es como supuestamente se tenía que hacer en Wii U pero casi nadie lo hizo de esta manera por vagancia, pero hay que tener en cuenta que de cada textura hemos de almacenar sus versiones más pequeñas que serían los MIPMAPS.

mipmap

Por lo que la resolución sería del atlas sería de 2048*1024 pixeles y ocuparía 8MB sin compresión y 2MB con esta, tomando como referencia las tablas de antes obtenemos en el caso del El Forward Rendering sin compresión:

AA Framebuffer con compresión VT con compresión Total
1 23,73 2,00 25,73
2 44,82 2,00 46,82
4 87,01 2,00 89,01

Forward Rendering con compresión:

AA Framebuffer con compresión VT sin compresión Total
1 2,42 2,00 4,42
2 6,15 2,00 8,15
4 9,67 2,00 11,67

Deferred Rendering sin compresión:

AA Framebuffer sin compresión VT sin compresión Total
1 23,73 8,00 31,73
2 44,82 8,00 52,82
4 87,01 8,00 95,01

Deferred Rendering con compresión:

AA Framebuffer sin compresión VT sin compresión Total
1 7,91 2,00 9,91
2 13,18 2,00 15,18
4 23,73 2,00 25,73

Si el búfer de imagen tiene suficiente capacidad de almacenamiento entonces se texturiza desde la memoria embebida, si no la tiene entonces se hace desde la memoria principal. Para poder trasladar los datos de una memoria a otra suele haber una unidad DMA, en Wii U era llamada DMAE y su trabajo era hacer copias de información de la RAM a la eDRAM. La unidad DMA se utiliza para no saturar el controlador de memoria de la GPU con demandas adicionales pero su ancho de banda no puede ser más grande que el ancho de banda de la memoria más lenta en la transferencia que en este caso sería de 25.6 GB/seg, En el caso que nos ocupa estaríamos hablando de 2MB u 8MB por fotograma por lo que a simple vista y a 60fps el ancho de banda de la unidad DMA debería ser de:

8MB *60*2 (envio y recepción)= 0.96GB/seg.

Pero en el caso del renderizado por diferido cada textura tiene varias muestras y no una sola, no solo en el renderizado por diferido sino también en el frontal por lo que lo normal es que una sola textura este compuesta por 10 sub-texturas con cosas como el mapa de normales, el color, albedo… Habitualmente se utilizan 10 subtexturas para una textura por lo que el ancho de banda de la unidad DMA puede ser de 9.6 GB/seg de media (en esto es especulación total).

El tercer tema relacionado con la memoria embebida es el de los mapas de sombras, estos se ven altamente beneficiados por la memoria embebida pero tienen el problema de necesitar unas cantidades de memoria ingentes para su calidad, se necesita un mapa de sombras de 4096×4096 pixeles en memoria para que las sombras sean lo suficientemente buenas a 720P, esto son unos 64MB de memoria sin comprimir y 16MB comprimidos por lo que no caben en la memoria embebida y el bajo ancho de banda de la RAM principal hace que el rendimiento de estas sea mortal, de ahí que muchos juegos de Wii U carezcan de mapas de sombras o los tengan ultra-simplificados. Esto sería un problema de Wii U que no solventaría Switch y lo heredaría.

Ahora bien, volviendo al tema de la fabricacion del chip la memoria embebida tiene un coste por el hecho que hace que el chip sea más grande, esto hace que el tiempo de circulación de los electrones por el chip aumente y la consecuencia sea que la velocidad de reloj sea menor que con el chip sin ella. La gente esta especulando con velocidades de reloj de 1 Ghz pero estas se dan en un entorno en el que no hay memoria embebida y por el momento Nintendo ha mostrado juegos de calidad Wii U a nivel visual para la consola.

the_legend_of_zelda_breath_of_the_wild_e3_2016_new-19 splatoonswitch mario_heart mario-kart-nintendo-switch

Con tal de echar mierda sobre Switch, ciertos contaminadores han aumentado la tasa de FLOPS de Wii U al doble con tal de que parezca que no hay tanta diferencia. La falsedad de dicha afirmación ya la comente en este blog en su día por lo que si queréis un informe pormenorizado lo podéis leer aquí. Volviendo al tema Switch lo que esta claro es que la memoria embebida hará que la GPU no funcione a 1Ghz, en todo caso hemos visto memoria embebida en Xbox One a 853 Mhz por lo que una velocidad de 850 Mhz para la GPU tampoco sería una velocidad mala por lo que la cosa comparativamente quedaría de la siguiente manera:

flopsenperspectiva

Pero tampoco olvidemos el hecho de que Switch es principalmente una consola portátil, ¿como se compara con la consola más potende la anterior generación en ese aspecto que es PS Vita?

flopsenperpectiva2

Sobran las palabras…

tobey-maguire-crying

Eres un trilero Urian, has de compararla con PS4 y Xbox One, con PS4 y Xbox One…

¿Yo un trilero? La gente olvida lo que es Switch, una consola portátil de gama alta cuyo hardware esta en esto y ha de funcionar con una batería.

nintendo-switch_6

Es imposible ahora mismo una potencia como los unineuronales le van a exigir a la consola y por el momento han estado echando mierda sobre ella con una comparación realmente absurda y sin tener en cuenta que hablamos de algo que es imposible pero ellos el amarillismo lo acaban utilizando.

potensiaaa

Imaginaos que hubiese ocurrido si alguien dijese que PS Vita era menos potente que Xbox 360 o PS3 cuando salió, ah no, que no se podía, que por aquel entonces era dogma de fe creer que PS Vita era una PS3 portátil y se acabo. Solo hay que recordar la bilis cuando Yifan Lu revelo las velocidades de reloj o cuando se les recuerda la verdadera tasa de la GPU de PS Vita. Pero claro, hay que hacer volar el Sony Retarding  a toda castaña y de manera consensuada.

En todo caso el más que posible escenario de Nintendo Switch con memoria embebida queda con esto explicado al 100%.