Skip to main content
Nvidia GPU

¿Por qué kepler ha envejecido mal?

Con la nueva hornada de juegos que han salido recientemente, los poseedores de kepler han tenido la sensación de que sus tarjetas gráficas no rinden como deberían. Viendo que gráficas de AMD de la misma generación todavía son capaces de sacar resultados bastante satisfactorios no es raro que mucha gente empiece a hacerse preguntas. Y empiezan las teorías y los intentos de dar explicaciones al asunto.

Sobre este tema queda claro que no va a haber una explicación oficial por parte de Nvidia. Sería ridículo por parte de ellos reconocer públicamente que ya no les interesa, por las razones que sean, seguir dedicando recursos a la generación de gráficas kepler. Hace un tiempo hablé de un truco que tenía Nvidia con gameworks para desviar el rendimiento de algunos videojuegos en base a sus intereses pero en este caso con kepler hay algo más: El paralelismo a nivel de instrucción o ILP

Un procesador gráfico se compone en su unidad más básica de procesamiento de shaders. Estos shaders son en última instancia los que hacen los cálculos de texturas y pixels para que un videojuego se vea como se ve. Pero un shader por si mismo no hace un procesador gráfico. Ese shader necesita de componentes a su alrededor que le permitan hacer su trabajo. Decodificadores de instrucciones, dispatchers, schedulers, un sistema de cachés… Es por esto por lo que normalmente los shaders se incluyen en una estructura mayor en donde todo esto está incluído. En el caso de Nvidia esa estructura la llaman SM o Streaming Multiprocessor. Esta estructura también facilita las cosas a la hora de diseñar diferentes gamas de procesadores gráficos. Si quieres una gráfica barata y poco potente, metes por ejemplo un solo SM. Si quieres una más potente, metes 4, 8 o lo que consideres.

Kepler vs maxwell SM
Kepler vs maxwell SM

En esta imagen que acabo de poner se puede ver que kepler en un SM tiene 192 shaders divididos en grupos de 32 (aunque en la imagen lo hayan representado de otra forma) y 4 warp schedulers. Me interesaba poner una imagen en la que también se viera maxwell por algo que explicaré más adelante. Citando documentación de nvidia correspondiente a kepler nos encontramos con esto:

Also note that Kepler GPUs can utilize ILP in place of thread/warp-level parallelism (TLP) more readily than Fermi GPUs can. Furthermore, some degree of ILP in conjunction with TLP is required by Kepler GPUs in order to approach peak single-precision performance, since SMX’s warp scheduler issues one or two independent instructions from each of four warps per clock. ILP can be increased by means of, for example, processing several data items concurrently per thread or unrolling loops in the device code, though note that either of these approaches may also increase register pressure.

En condiciones normales un warp scheduler puede trabajar con una instrucción por cada ciclo de reloj, pudiendo los 4 warp schedulers dar servicio a 4 grupos de 32 shaders (128 shaders, quédate con este número que luego cobrará importancia) dentro de ese SM. En el caso de que se necesiten sacar el ideal de 6 instrucciones por ciclo de reloj de esos 4 warp schedulers hay que meter optimizaciones de forma activa, ya sea en el videojuego o en los drivers y así se daría servicio a los 6 grupos de 32 shaders llegando al total de 192 shaders servidos. Se alcanzaría por lo tanto, el 100% de utilización del SM.

Cuando kepler pasó a ser una arquitectura legacy, las optimizaciones dejaron de llegar. Los warp scheduler al no tener las optimizaciones necesarias para esos nuevos juegos, solo pueden sacar una instrucción por ciclo de reloj haciendo que 64 de los 192 shaders que componen un SM estén infrautilizados.

No es casualidad que en arquitecturas posteriores como maxwell Nvidia haya cambiado el diseño de los SM y ahora sean de 128 shaders y 4 warp schedulers, como se puede ver en la imagen de arriba. De hecho, si nos volvemos a remitir a la documentación de Nvidia nos encontramos con esto:

Each warp scheduler still has the flexibility to dual-issue (such as issuing a math operation to a CUDA Core in the same cycle as a memory operation to a load/store unit), but single-issue is now sufficient to fully utilize all CUDA Cores.

Nvidia comenta que los warp schedulers podrían seguir recibiendo optimizaciones para sacar dos instrucciones por ciclo de reloj en caso de ser necesario, pero que ya no hace falta porque con una instrucción por ciclo de reloj y 4 warp schedulers ya sería suficiente para tener funcionando los 4 grupos de 32 shaders del SM de 128 shaders de maxwell y pascal. Por esto el número 128 cobra la importancia que he comentado antes.

Esas optimizaciones que kepler requería para funcionar ya no son necesarias en los nuevos diseños de Nvidia y esto habrá favorecido la decisión de dejar de meter optimizaciones específicas para kepler en las nuevas actualizaciones de drivers. Por eso, en juegos que salen al mercado en estas fechas se ve que kepler tiene como una especie de regresión de rendimiento. Y es que en ese juego puede que la gráfica kepler tenga hardware infrautilizado, un poco como AMD y sus gráficas en directx 11 y los ACE. En este caso en concreto yo no creo que se pudiera decir que Nvidia esté activamente saboteando una arquitectura antigua como kepler, como podía ser el caso de la teselación en gameworks. Aquí simplemente el haber abandonado el soporte ha hecho que las peculiaridades de esa arquitectura ahora estén jugando en su contra. Lo ideal hubiera sido que kepler tuviese de inicio 6 warp schedulers por SM o 128 shaders por SM como maxwell o pascal pero, es lo que hay.

Un comentario en “¿Por qué kepler ha envejecido mal?

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *