Blog Personal.

Conceptos Básicos, PlayStation 5, PS5

PS5: SmartShift Re-Explicado

El Smartshift es una de los elementos de la GPU de PlayStation 5 que muy poca gente entiende bien, a simple vista se trata de una fluctuación de la velocidad de reloj de la GPU pero… ¿En que se basa dicha fluctuación? Para empezar no se basa en la fluctuación del voltaje por lo que el único elemento de la formula de consumo energético que es variable es la velocidad de reloj. ¿Pero cual es la condición para el cambio?

Pues bien, os lo voy a aclarar de una manera mucho más fácil que como lo hice hace unos meses en esta entrada, la velocidad de reloj varía por completo según la instrucción que se este ejecutando en ese momento. El motivo de ello es que diferentes instrucciones tienen diferentes consumos energéticos y esto permite aumentar la velocidad de reloj en instrucciones muy simples en lo que a su consumo energético se refiere.

Pe… pero Urian, una GPU tiene decenas de unidades trabajando en paralelo en instrucciones distintas al mismo tiempo, no una sola.

¿Que es lo que ocurre? Internamente cada una de los 36 CUs ejecutan 2 (modo Wave32) u 5 instrucciones (Wave64) al mismo tiempo por lo que la velocidad de reloj que alcance la Compute Unit en teoría debería ser la más alta que permita la instrucción que más consuma que en ese momento se este ejecutando. Esto significa que internamente con el Smartshift encendido la GPU esta pensada para un consumo energético máximo pero que va variando las velocidades de reloj de cada CU.

¿Y a que viene hablar de ello? En la entrevista a Jason Ronald (uno de los arquitectos de la Xbox Series X) en Xataka el zasca ha sido monumental y he de adelantar que tiene razón.

«Podríamos haber usado relojes forzados, podríamos haber usado tasas de reloj variables: la realidad es que eso hace más difícil a los desarrolladores optimizar sus juegos aunque nos hubiera permitido por ejemplo presumir de TFLOPS más altos de los que ya teníamos. Pero sabes, eso no es lo importante. Lo importante son las experiencias de juego que los desarrolladores pueden construir».

Pues en esto tiene razón, en realidad el Smartshift rompe por completo el uso de herramientas como el Razor de Sony y el PIX de Microsoft. Dichas herramientas de rendimiento monitorizan a tiempo real el uso de cada elemento del sistema e indican lo sobresaturados o infrasaturados que están de carga de trabajo pudiendo optimizar los juegos al hardware aprovechando al máximo y de manera eficiente cada parta optimizando cada tipo de carga de trabajo el hardware pero para ello el hardware ha de tener un rendimiento base constante, si este se vuelve variable entonces la herramienta que depende de unos valores fijos de rendimiento de cada una de las partes.

Es decir. la herramienta deja de funcionar por completo. En cuanto a los TFLOPS hay que tener en cuenta que los TFLOPS que se dan son en realidad la cantidad de instrucciones FMADD (Floating point Multiply ADD) por ciclo de reloj que se pueden realizar. Debido a que es un tipo de instrucción que consume poco es posible colocar la GPU a una mayor velocidad que la normalizada. En cambio Microsoft al descartar el Smartshift tiene que colocar la velocidad de reloj a la que sea aceptable para la instrucción que más energía consume, si tuviesen el Smartshift implementado podrían hacer que la cantidad de TFLOPS realizando instrucciones FMADD exclusivamente fuese más alto que esos 12 TFLOPS.

Y una cosa, se ha de tener en cuenta que la tasa de TFLOPS es variable al tipo de instrucción utilizada, y en el código de un juego no vamos a ver como la GPU va realizando instrucciones FMADD todo el rato. Pero esto solo es una parte de la historia. Jason Ronald tiene razón en lo que dice pero no es el escenario completo.

El otro elemento son las unidades de función fija, estas siempre funcionan al mismo ratio y siempre realizan el mismo trabajo, no son susceptibles a ir cambiando la velocidad de reloj y es fija. Es muy posible que Sony haya colocado las unidades de función fija fuera de las Compute Units que son:

  • Unidades de Rasterizado.
  • Unidades RBE.
  • Teselador (Primitive Engine)
  • Unidad de Culling (Geometry Engine)

A una velocidad de funcionamiento fija y la velocidad variable sea solo para las Compute Units, las dos únicas unidad de función fija afectadas por el SmartShift serían la unidad de intersección para el trazado de rayos y la de filtrado de texturas.

Pe… pero Urian… Si hablastes de carga de trabajo hace unos meses.

Las instrucciones son la carga de trabajo, el Smartshift permite variar la velocidad de reloj según cada instrucción. No son una ventaja a la hora de ejecutar instruccioens complejas pero en instrucciones más simples esa velocidad de reloj adicional se agradece. Lo malo es que no puedes optimizar los juegos al 100% dado que la potencia total no es constante, lo bueno es que te permite sacar más rendimiento de la GPU para ciertas cargas de trabajo a cambio de perder la capacidad de optimización.

¿Y que hay de la CPU?

Ah si, con la CPU se aplica lo mismo, la velocidad de cada uno de los núcleos es variable según el tipo de instrucción que estén ejecutando. Por ejemplo las instruciones AVX de 256 bits tienen un consumo energético enorme que hacen bajar la velocidad de reloj del núcleo durante la ejecución de esa instrucción. Por lo que el funcionamiento es en general como en la GPU y no, no es un overclock clásico basado en variaciones continuas de voltaje.

Esto es todo, tenéis los comentarios de esta misma entrada para comentar y no olvideis que tenemos Discord.

4.5 2 votes
Article Rating
8 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Tokra_Kree

Hola Urian. No acabo de entender este tema de la frecuencia variable.

Creo que Cerny destacó su beneficio precisamente en las unidades de función fija, como las unidades de rasterizado, command buffer, cache L2, etc.

¿O es que habrá una frecuencia variable para toda la GPU? y además frecuencias variables e independientes para las CU’s?

Pepelepew

Hola Urian, en el kit de desarrollo se hablo que las frecuencias eran fijas, para que los desarrolladores no tengan que batallar a la hora de batallar y podes sacarle provecho al software que estan desarrollando, lo que iban hacer es que el SOC final de PS5 se encargaría de varias las frecuencias de forma «automatica» como explico cerny en road to PS5, donde abra muchos hardware dedicado y sensores que se encargaran de administrar el consumo energetico.

Tokra_Kree

Se supone que hay una unidad Power Control, que recibe información de CPU y GPU.

ps5powercontrol.jpg
Ger

Si razor y pix son herramientas que dependen de frecuencias constantes, supongo que para smartshift tendrán una herramienta homóloga para frecuencias variables, no creo que metan una tecnología sin pensar en lo que ello conlleva. También me uno al compañero Tokra_Kree con respecto a que Cerny hablaba del beneficio en rasterizado y demás…

Last edited 2 months ago by Ger
nolgan

opino igual.. no van a dejar a los dev si razor…. me imagino que habra una nueva version actualizada… que tendra esto en cuenta.. seria lo logico

otra cosa..es que se pueda hacer.. o no… un razor que tenga estyo en cuenta… o la dificultad de crearlo y usarlo y que optimiza bien …

veremos.. poco a poco se vera y ira saliendo cosas segun pasen los meses…

nolgan

mmm

salvo que sony haya creado un RAZOR que use y tenga encuenta esto… que TB es posible

Steven

Hola tiene capacidad de apagar o desativar partes de la gpu?

[…] PS5: SmartShift Re-Explicado […]