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.
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.
Buen artículo
Totalmente verdad de ahí la prueba que una 1050ti rivaliza y supera en algunos juegos a la, en su momento, ultrapoderosa gtx 680. Una placa de gama baja-media ganándole a una de gama alta (si ya se que son generaciones distintas pero miremos la teoría:
gtx 680: 1536 cores + 128 tmu + 32 rops (1006 mhz gpu) + 28 nm + memoria a 6000 mhz (256 bits)
gtx 1050ti: 768 cores + 48 tmu + 32 rops (1290 mhz gpu) + 14 nm + memoria a 7000 mhz (128 bits)
La velocidad del nucleo es base. la 1050ti tiene tbc 3.0 y va casi a 1900 mhz en esa condición por cierto (la 680 solo llega en boost a 1110) con lo cual compensa con creces la mitad de cuda cores. rops están igualadas así que en «fuerza bruta» de juegos más viejos no hay ventaja, y solo en los tmu se sacan una diferencia notable que puede ayudar con algunas situaciones aunque los shaders hoy en día pesan mucho más que las tmu y de vuelta la velocidad de la gpu compensa las menores tmu.
La única situación que puede sacar ventaja la 680 es el AA y las altísimas resoluciones que por sus 256 bits de interfaz de memoria se va a notar apreciablemente…pero, el que tiene una 680 en un equipo del 2012 tiene un monitor a lo sumo full hd con suerte, así que la resolución no va a ser más que esa y solo le queda esgrimir el AA (muy al estilo de la voodoo 5 que todos sabemos como terminó…)
En cambio con maxwell la cosa cambia y mucho, la 1050ti le gana a veces a la 960 y por poco. Esa aquitectura envejecerá mucho mejor sin duda alguna (sin desmerecer pascal que claramente tiene cosas muy buenas por cierto)
Saludos
Controlas del tema una barbaridad, enhorabuena. Quizás me puedas dar tu opinión sobre un tema que aún no he leído en ningún foro de hardware, ni siquiera lo he expuesto antes porque doy por hecho que nadie me va a responder con algo de idea. En fin, me refiero al Raytracing. Yo vengo del mundo del 3D, y a la hora de renderizar reflejos si que es cierto que se precisa más tiempo de cálculo, pero nunca he visto que un motor de render me dijera: «Error, tu tarjeta gráfica no está preparada para renderizar reflejos, actualicela» o que renderice la luz por un lado y los reflejos por otro.
A lo que voy, sin ser un experto apostaría a que cualquier gráfica puede calcular reflejos, oclusión ambiental o lo que sea.. solo es cuestión de potencia. Entonces, ¿Todo ese rollo de los tensor cores? ¿Es todo marketing o tiene algún sentido?
Realmente por software se puede hacer cualquier efecto. El problema llega cuando ese efecto se vuelve demasiado complejo o pesado y hacerlo solamente por software se vuelve muy lento. En estos casos, suele ser conveniente tener algún tipo de hardware especializado que te acelere esa tarea.
En base a esto, los tensor cores tienen su parte de marketing y su parte de sentido. Las gráficas actuales tienen una potencia de computación bastante alta. Es totalmente posible que las gráficas actuales también puedan tener ray tracing a tiempo real, de igual manera que lo que vende Nvidia con su nueva generación de gráficas.
El problema viene cuando quieres más rendimiento. Las gráficas que lo tengan que hacer por software y fuerza bruta a base de computación no te sacarán los mismos FPS o ese efecto no tendrá la misma calidad si lo quieres ver a tiempo real.
Igual en un renderizado 3D que comentas no te importaría tanto. Si la escena es dificil de renderizar, vas a dejar el ordenador por la noche trabajando de ambas maneras ya que los tensor cores de Nvidia tampoco son tan extremadamente potentes como para que la diferencia sea abismal comparado con lo que ya hay. Al fin y al cabo estos tensor cores tienen pinta de ser poco más de aceleradores de cálculo de intersecciones. Si antes tenías que hacer por software la intersección entre un rayo y un polígono, ahora lo puedes hacer por hardware. Pero actualmente no parece haber una distancia tan grande entre las soluciones por software y la versión hardware con los tensor cores de Nvidia.
Quizás dentro de unos años, cuando la parte hardware haya avanzado mucho más, empecemos a ver que hacer ray tracing por software ya no merezca la pena.
Espero que esto haya respondido a la duda que planteabas.
Muchísimas gracias por tu respuesta
Muy buen articulo,
tengo una pregunta que me llevo haciendo bastante tiempo, cual crees que fue la razon por la que NVIDIA ha decido reducir el numero de «cores» por SM de Pascal (128) a Volta/Turing (64)?
Saludos!
En volta y turing se redujeron los warp schedulers a la mitad, con lo que no tendría sentido mantener 128 shaders por SM.
Estas dos arquitecturas están principalmente enfocadas a la computación y no a los videojuegos. En este caso es probable que nvidia haya optado por esto para que estas arquitecturas dejasen de ser superescalares. Esto mejora la capacidad de estas arquitecturas en paralelismo a nivel de hilos de ejecución a costa de empeorar el paralelismo a nivel de instrucción. Nvidia habrá pensado que para tareas de computación no compensaría meter hardware extra para intentar extraer paralelismo a nivel de instrucción.
Las tareas 3D como videojuegos son increíblemente paralelizables, con lo que meter más hardware para extraer más paralelismo como por ejemplo a nivel de instrucción tiene sentido. En otras tareas que se alejan de los videojuegos extraer paralelismo cuesta más.