Blog Personal.

Uncategorized

PS5 Uncovered (DF): La retrocompatibilidad

Eurogamer lanzo hace unos dias un artículo titulado «PlayStation Uncovered» para intentar arrojar luz sobre lo confusas que son ciertas cosas respecto a la información que dio Mark Cerny acerca de la inminente PlayStation 5, pero el artículo es tan denso y tiene tanta información que lo dividiré en varias entradas distintas.

En primer lugar, Cerny ha confirmado lo que os comente en la entrada «Feedback sobre Retrocompatibilidad» donde yo dije:

Ahora bien… ¿Cual es el problema añadido? Pues que puedes tener un sistema que sea binariamente compatible pero que de problemas con los algoritmos de ciertos juegos que dependen del timing y de la sincronización, no solo por las velocidades de reloj dispares sino también por los ciclos por instrucción que pueden ser distintos y que las instrucciones tarden más o menos de una variante a otra. El truco para conseguir la compatibilidad no se basa unicamente en el hecho de igualar la velocidad de reloj sino los ciclos por instrucción, lo que lleva a tener que colocar la CPU del sistema anterior para tener 100% de compatibilidad hacia atrás. El otro mecanismo es añadir ciclos de instrucción adicionales para emular el sistema menos potente en su timing exacto cuando ejecuta en modo retrocompatible de tal manera que no se den problemas en esos escenarios.

Tomemos por ejemplo un hardware concreto con con compatibilidad hacía atrás, por ejemplo 3DS…

El sistema de video de 3DS es diferente al de DSi por tanto se ha de implementar el de DSi al completo dentro del nuevo SoC. También se han de tener en cuenta las velocidades de reloj anteriores que son 66Mhz para DS y 133Mhz para DSi por lo que la velocidad de reloj de todos los componentes tiene que ser un múltiple de todas ellas. El problema viene cuando miramos la CPU, tenemos un ARM11, tecnicamente es un conjunto de registros e instrucciones ARM pero resuta que el CPI es distinto en cuanto a estas instrucciones y Nintendo opto por colocar el ARM9 de DSi para el modo de compatibilidad hacía atrás por el hecho que Nintendo no quiso realizar los cambios pertinentes al ARM11 para asegurarse un timing exacto y tener el 100% de compatibilidad hacía atrás.

Os he marcado la parte importante en negrita.

La idea aplicada a las consolas next gen es que Zen2 tiene un CPI mucho más corto que Jaguar, es decir, que los tiempos por instrucción no son lo mismo y eso da problemas en algunos escenarios en concreto. No es un problema específico de PlayStation 5 sino un problema general, lo normal era siempre mantener la CPU del sistema anterior o evolucionar a partir de esta.

¿Cual es lo que ha hecho AMD para dar compatibilidad hacía atrás con Jaguar? Veamos lo que dice Mark en el artículo de Digital Foundry.

«Toda la lógica del juego creada para las CPU Jaguar funciona correctamente en las CPU Zen 2, pero el tiempo de ejecución de las instrucciones puede ser sustancialmente diferente», nos dice Mark Cerny. «Trabajamos con AMD para personalizar nuestros núcleos Zen 2 a medida; tienen modos en los que pueden aproximarse más estrechamente a los tiempos de Jaguar.»

No creo que sea algo a medida para ellos desde que Microsoft tiene que tener el mismo problema debido a la misma transición y AMD les debe haber vendido la misma solución de añadir ciclos muertos para igualar el timing y no dar problemas de compatibilidad en algunos casos concretos con los juegos pensados para la anterior generación.

Esto es todo, tenéis el Discord y los comentarios de esta entrada para comentarla.