¿Puede estar Sony haciendo una nueva portátil? Esto es una afirmación que para algunos es imposible mientras que para otros si que es posible. Os voy a dejar los dos puntos que para mi la hacen posible, el primero de los puntos es la situación del mercado actual y como ha cambiado con Switch, la segunda es la posibilidad técnica de tener la portátil y como puede ser.

#1 Situación actual del mercado

El otro día mirando el blog de Sean Malstrom me encontré con la siguiente afirmación por su parte, la cual es completamente cierta:

Pongamos-lo de la siguiente manera: Los juegos venden consolas. ¿Que juegos tiene Switch? Aparte de las secuela de Nintendo, estos son una gran cantidad de ports que se pueden encontrar en cualquier lado. Todo lo que necesita un competidor es hacer una portátil y ese competidor tendrá los mismos ports exactos. Estoy intentando remarcar que la Swich no tiene una ventaja competitiva en el mercado… simplemente no tiene competición en el mercado en este momento.

Y en otra entrada dice:

Pero nunca desestimaría a Sony invadiendo el mercado de las portátiles.

Nintendo Switch no es realmente una consola de videojuegos. Es una Consola Vampiro, todo lo que hace es comer juegos de otras librerías de juegos. Switch es la Capital del Port. Puedo ver fácilmente otra pieza de hardware comiendose a Switch en el mercado actual.

Todo se traduce en que Switch no tiene innovación en el valor que se traduce en un producto único que la competencia no puede copiar. Es decir, no es un producto de Océano Azul…

Es decir, Switch tiene un mercado único porque es el único pez en el mar…

Pero se puede llegar a encontrar el mar con competencia…

Toda empresa tiene un RPV que la define, precisamente lo que asegura un océano azul es que los Procesos y Valores de la competencia sean lo suficientemente dispares como para que esta no haga un producto como el tuyo. Normalmente los océanos azules terminan tan rápido como la competencia es capaz de copiar la curva de valor del producto. Esto nos lleva a la falsedad cuando la gente habla de productos tipo Océano Azul por parte de Nintendo, mucha gente piensa que esto…

Fue un producto de Océano Azul, pero su curva de valor que venía de la inclusión del Wii Remote era fácilmente copiable. En realidad el concepto Océano Azul no asegura el éxito y paradojicamente Wii U es más océano azul porque con los años nadie de la competencia ha copiado su curva de valor.

¿Otros ejemplos de producto tipo Océano Azul en Nintendo?

Toda la gama DS, tanto las DS originales como 3DS y… Uno que os va a sorprender pero tiene que ver con la elección del formato que hizo que la oferta de juegos fuese dispar respecto a la competencia y tuviese su propia curva de valor.

Lo único que defiende el concepto de Switch es que Sony parece no tener la motivación de ir a hacer portátiles en estos momentos por el fiasco de Vita, pero Sony entiende PlayStation de la forma en que paradojicamente el fallecido Satoru Iwata hablo del futuro de las plataformas en ese sentido:

Apple es capaz de lanzar dispositivos inteligentes con varios factores forma uno después de otro porque hay una sola manera de programación adoptada por todas las plataformas. Apple tiene una plataforma común llamada iOS. Otro ejemplo es Android, pese a que hay varios modelos Android no tiene sequías de software porque hay una forma en común de programar en la plataforma Android que funciona con varios modelos El punto es: las plataformas de Nintendo deberían ser como esos dos ejemplos.

Y bueno, precisamente hemos visto como ha cambiado el paradigma con PS4 Pro y Xbox One X, y sabemos que tanto Scarlett como PS5 serán completamente compatibles hacía atrás.

#2 Hardware

Las plataformas de consolas pese a ser únicas para cada fabricante se han vuelto no dependientes de un hardware específico, pero hay un problema enorme, dado que PS4 es x86-64 en estos momentos y no hay presencia en ese sentido en el mercado de sistemas de bajo consumo y por tanto no existe un núcleo de CPU que podamos utilizar para crear una PS4 portátil en estos momentos que corra los juegos de manera nativa.

Tenemos tres caminos:

  • Crear un interprete por software o por hardware que traduzca a tiempo real las instruciones x86-64 a ARM64, esto significa que la CPU dado el tiempo necesario para el interprete tendrá que ser más potente que el AMD Jaguar en PS4.
  • Recompilar y lanzar los juegos pensados para PS4 para la arquitectura ARM64 que utilice la nueva portátil.

Personalmente me decanto por la segunda opción, el motivo de ello es mantener las cosas lo más simple posibles y sin sobre-complicaciones. La idea es que los desarrolladores puedan tener dos versiones de sus juegos en la tienda y que dependiendo de la versión de PlayStation que tengamos podamos descargar una versión u otra.

¿Y que configuración tendría la CPU? unos 8 núcleos ARM64 con la suficiente potencia como para suplir los AMD Jaguar, acompañados por unos 8GB de memoria RAM, pero aquí ya entramos en los problemas ya que la futura memoria LPDDR5 no alcanza el ancho de banda suficiente para igualar el ancho de banda de la GDDR5 de PlayStation 4 por lo que tenemos que buscar caminos alternativos para suplir la falta de ancho de banda.

La primera solución que nos viene a la mente es el uso de algún tipo de memoria 3D-DRAM, pero el estándar WideIO lleva años completamente abandonado, aunque es interesante un modelo de este tipo por tener menos Pj/bit y permitir alcanzar mayores anchos de banda. ¿El problema? PS4 es una configuración UMA a nivel físico aunque por otro lado actua como una arquitectura NUMA a nivel de direccionamiento donde CPU y GPU comparten espacios de memoria distintos.

Incluso en PS4 pese a que los 8GB están unificados existe un mecanismo DMA en la GPU para copiar los datos desde la parte coherente a la no-coherente y viceversa. Por lo que a efectos prácticos tener una memoria para la GPU no sería algo antinatural a simple vista pero esto no se podría aplicar porque pese a que CPU y GPU no sean coherentes en realidad no ven otra RAM, el acceso no-coherente no es otra cosa que un acceso sin que haya coherencia entre las caches. La memoria que ven es la misma realmente.

La coherencia de caché hace referencia a la integridad de los datos almacenados en las cachés locales de los recursos compartidos. La coherencia de la caché es un caso especial de la coherencia de memoria.

Cuando los clientes de un sistema, en particular las CPUs en un multiprocesador, mantienen cachés de una memoria compartida, los conflictos crecen. Haciendo referencia al dibujo, si el cliente de arriba tiene una copia de un bloque de memoria de una lectura previa y el cliente de abajo cambia ese bloque, el cliente de arriba podría estar trabajando con datos erróneos, sin tener conocimiento de ello. La coherencia de la caché intenta administrar estos conflictos y mantener consistencia entre las cachés y la memoria.

Pero CPU y GPU no comparten sus caches, excepto en el acceso coherente a la memoria a través de los buses Onion/Onion+, los cuales generan en GCN 1.0 a GCN 1.2 un problema de contención de memoria, AMD lo solvento a partir de los SoC Carrizo y de Polaris (RX 4×0, RX 5×0) en adelante añadiendo la Access Translation Cache de tal manera que la GPU ya no tenía que acceder a través del bus Onion al Northbridge/uncore de la CPU como antes para tener coherencia con las caches.

El problema de los GCN es la enorme contención de memoria entre Onion (Bus Coherente) y Garlic (Bus no-coherente), de los 176GB/s supuestamente la GPU a través de Onion (conmutado con la CPU) debería coger unos 25.6 GB/s (bus de 32 bytes*800Mhz) y dejar libres unos 150.4 GB/s pero eso no ocurre, sino que la contención es de 3X aproximadamente, esto deja un ancho de banda que da justo para una GPU a 800Mhz con 32 ROPS, y PS4 se equilibro para eso en cuanto a sus especificaciones.

¿La otra opción que había? Utilizar Onion+ que es de solo 10GB/s para acceder a la parte coherente, pero que reducia latencia al hacer bypass a las caches de la GPU.

Esto significa que una GPU que soporte ATC el ancho de banda necesario pasaría a ser de 130GB/s, demasiado ancho de banda por el momento para un dispositivo móvil, pero ya hemos conseguido reducir algo el ancho de banda.

La memoria que vamos a ver en los dispositivos de bolsillo es la LPDDR4X estee… La LPDDR5 que es una LPDDR4X a más velocidad, recordemos que la LPDDR4X funciona a un voltaje mucho menor que la LPDDR4.

Esto reduce el consumo dentro de las mismas especificaciones en un 20% respecto a la LPDDR4, el problema es que la LPDDR5 es algo más rápida y la cantidad de Mw/Gb o Pj/bit acaba siendo más alto, por lo que hay que buscar alternativas y de ahí lo que he comentado antes de la posibilidad de utilizar algún metodo de 3D-DRAM para el ancho de banda.

¿Y cual puede ser la solución? Pues utiizar un Tile Renderer, el truco del Tile Rendering necesita algunos cambios pero no vamos a tomar la arquitectura GCN sino una que es compatible hacía atrás y que ha salido recientemente.

La primera pieza que necesitamos es añadir una unidad de Tiling junto al rasterizador, la segunda pieza es permitir que los ROPS escriban en una memoria interna sus resultados. El segundo caso lo tenemos con la cache L1 pero en RDNA 1.0 tenemos un problema con la Cache L1, es de solo lectura pero con hacerla de lectura y escritura y colocando una unidad de Tiling ya solventamos el problema del ancho de banda porque las operaciones del búfer de imagen se harían en la cache L1 de la GPU, la otra opción es crear una memoria privada para los ROPS que les permita operar a nivel de Tile y que pueda volcar los datos una vez terminados.

Tened en cuenta que la formula general para el ancho de banda de una GPU es: B = Bc + Bz + Bt.

Donde:

  • B es el Ancho de Banda Total
  • Bc es el Ancho de Banda del búfer de color.
  • Bz es el ancho de banda del búfer de profundidad
  • Bt es el ancho de banda de acceso a las texturas.

Un renderizador por tiles lo que hace es: B = Bc + Bz + Bt.

Sumando esto a la aplicación del ATC (disponible en RDNA) esto nos permite reducir aún más el ancho de banda necesario ya que evitamos contenciones en la memoria en el acceso entre la CPU y la GPU. Por otro lado tenemos una buena noticia con el tema de la memoria, AMD ha integrado el soporte LPDDR4X en sus SoC en Renoir y posiblemente en el futuro con «Dali» veamos soporte LPDDR5. En realidad creo que estos cambios que he comentado, Tile Rendering y LPDDR5 los hará AMD de cara a la versión de RDNA 2.0 para dispositivos Post-PC Samsung, pero los pueden licenciar a otros como a Sony.

Sony puede hacer que el SoC de la posible PS4Portable lo fabrique Samsung bajo el nodo de 7nm EUV, la diferencia con la versión de PC sería el no-soporte de Raytracing y el añadido de la unidad de Tiling. La GPU sería 100% compatible con la de PS4 por lo que el código gráfico no debería cambiar apenas en los juegos y estos serían sumamente fáciles de portar de una consola a otra.

¿Y que configuración de GPU deberíamos ver? Pues una con 9 WGP/18 CUs, es decir, la mitad de la RX 5700 que coincidiría con la configuración de la PS4 original (18 CUs) y funcionando también a 800Mhz como en la consola original. Tened en cuenta que RDNA tiene un rendimiento/w mucho mayor que el de GCN y si encima bajamos la velocidad de reloj a los 800Mhz y lo acompañamos con los cambios necesario que he comentado más arriba entonces PS4 Portable se hace posible. Aparte que AMD ya ha declarado con RDNA al contrario que GCN esta pensada para escalar a dispositivos Post-PC y tenemos el pacto AMD-Samsung por el medio.

En cuanto a la cantidad de memoria no me veo a Sony tomando algún tipo de memoria exótica como ocurrió en PS Vita. La cosa es que creo que vamos a terminar viendo un SoC acompañado por 2 chips de memoria LPDDR5 llegado el momento.

¿Que nos queda dentro del hardware interno? El almacenamiento, este es un tema peliagudo pero la bajada de precio de la memoria NAND Flash permite que puedan haber tarjetas de memoria con una capacidad muy cercana al BluRay, pero muchos juegos necesitan instalarse… Pero la solución a esto la tenemos con los chips de memoria UFS que nos pueden dar unos pocos cientos de GB de almacenamiento en un pequeño chip, lo cual nos permita instalar los juegos.

¿La siguiente pieza importante? La pantalla… ¿Que pantalla podríamos utilizar para la portátil? Pues yo creo que una a 1080P sería lo idea, es decir, tener la experiencia de PlayStation 4 completa en un dispositivo portátil del tamaño de una Switch. Se que hay gente que pensará que es una exageración ir a los 1080P, pero yo pienso que no, que tiene sentido tener una pantalla a más resolución ya que la potencia de la consola debería permitirlo. Para mi lo ideal sería la pantalla de PS VR pero no pensada para la VR en este caso, 5.7 pulgadas a 1080P y con un refresco de 120hz.

¡Pe… pero Urian… Esas especificaciones son imposibles!

Esperad al año que viene cuando Apple presente un iPad con una GPU al nivel técnico de PS4 (aunque no la aproveche) y entonces me decís si lo que digo en esta entrada es imposible, la tecnología esta ahí a la vuelta de la esquina y Nintendo ha demostrado que puedes tener una portátil a base de llenarla de ports multiplataforma.

Esto es todo, como siempre tenéis el Discord y los comentarios de la misma entrada para comentar el contenido de la misma.