Con la complejidad de los GPU incrementándose año a  año, la cantidad de tiempo que se tarda en diseñar una GPU se incrementa en igual medida. Debido a ésto, no es algo que los fabricantes quieran realizar todos los años.

Para NVIDIA, Kepler es la encarnación de ese concepto. Kepler trae consigo algunos cambios arquitectónicos muy importantes en comparación con Fermi, pero al mismo tiempo, sus orígenes pueden rastrearse al mismo. Desde una vista general de alto nivel, Kepler es idéntico a Fermi: aún está organizada en núcleos CUDA, SMS, y GPC, y cómo son ejecutados los warps no ha cambiado significativamente. Tampoco hubo grandes cambios en el motor de renderizado, con la representación aún siendo manejada de manera distribuida a través de raster engines, polymorph engines y ROPs.

Análisis de los cambios en la arquitectura

En GF114 cada SM contenía 48 núcleos CUDA, organizados en 3 grupos de 16. Junto a los 3 grupos de 16 núcleos CUDA se encontraban 16 unidades de carga/almacenamiento, 16 SFUs de interpolación, 8 SFUs de funciones especiales, y 8 unidades de textura. Alimentado con datos a todos esos bloques se encontraban un par de warp schedulers, cada uno de ellos capaz de emitir hasta 2 instrucciones por ciclo de reloj del núcleo, para un total de hasta 4 instrucciones por ciclo para el SM.

Dentro de la SM en sí diferentes unidades operan en diferentes relojes, con los warp schedulers y unidades de textura operando en el reloj del núcleo y los núcleos CUDA, las unidades de carga/almacenamiento y SFUs corriendo en el reloj de shader, cuya frecuencia igual al doble de la frecuencia del reloj del núcleo. Como los warps de NVIDIA son de 32 threads, salta a la vista que los mismos son dos veces más grandes que cualquiera de los bloques de unidades de ejecución. Aquí es donde el reloj de shader entra en juego: con Fermi, un warp es separado y ejecutado en 2 ciclos del reloj de shader, con 16 threads ingresando primero y 16 continuando en el siguiente ciclo. El reloj de shader es lo que permitió a NVIDIA la ejecución de un warp completo durante un ciclo de reloj de gráficos utilizando sólo la mitad del hardware.

Entonces, ¿cómo cambia ésto en GK104? El aspecto más importante de GK104, lo que a su vez dicta el diseño de todo lo demás, es que NVIDIA ha dejado de lado el reloj de shader. Ahora todo el chip corre bajo el reloj del  núcleo. Como consecuencia de ello, en lugar de la ejecución de dos mitades de warp en rápida sucesión, GK104 está diseñado para ejecutar un warp completo a la vez, y el hardware GK104 ha cambiado dramáticamente como resultado.

Debido a que NVIDIA ha cambiado en esencia un menor número de unidades corriendo a mayor velocidad de reloj por un mayor número de unidades con menor velocidad de reloj, era necesario doblar el tamaño de cada unidad funcional dentro de su SM. Mientras que un grupo de 16 núcleos CUDA eran suficientes cuando había un reloj de shader, ahora son necesarios un total de 32 núcleos CUDA. Lo mismo ocurre con las unidades de carga/almacenamiento y las unidades de función especial, que han sido duplicadas en tamaño con el fin de compensar la falta de un reloj de shader. Pero, por supuesto, NVIDIA no se detuvo allí, ya que cambiar el reloj de shader por las mayores unidades funcionales sólo otorgaba el mismo rendimiento final. Después de doblar el tamaño de las unidades funcionales en una SM, a continuación, NVIDIA duplica el número de unidades funcionales en cada SM con el fin de hacer crecer el rendimiento de la propia SM. 3 grupos de núcleos CUDA pasaron a ser 6 grupos de núcleos CUDA, 2 grupos de unidades de carga/almacenamiento, 16 unidades de textura, etc. Al mismo tiempo, con el doble de unidades funcionales también se duplicaron los otros recursos de ejecución, con 2 warp schedulers pasando a ser 4 warp schedulers y los registros pasando de 32768 a 65536 entradas.

En última instancia, la duplicación del tamaño de las unidades funcionales permite a NVIDIA dejar de lado el reloj de shader. Sin embargo, es la segunda duplicación de recursos la que hace de GK104 mucho más poderoso que GF114. El SMX cuenta con el doble de potencia en casi todos los aspectos significativos que el SM de GF114. En total, cada SMX cuenta ahora con 15 unidades funcionales a la que los warp schedulers pueden acudir. Cada uno de los 4 schedulers puede, a su vez, emitir hasta 2 instrucciones por ciclo de reloj (si sus warps poseen Paralelismo de Nivel de Instrucciones, ILP), permitiendo a los schedulers en su conjunto pasar instrucciones a un máximo de 8 de las 15 unidades funcionales en cualquier ciclo de reloj.

El núcleo de la GTX 670 

En un movimiento inusual de parte de NVIDIA, para la GTX 670 están desactivando uno de los ocho SMXs de GK104 y bajando el reloj de núcleo, y eso es todo. GTX 670 se comercializará con 7 SMXes activos, los 32 ROPs de  GK104 y los 4 controladores de memoria GDDR5. Normalmente, NVIDIA recortaría todos los aspectos de la GPU a la vez con el fin de crear una mayor brecha en el desempeño y maximizar el número de GPUs que pueden utilizar de cada waffer, como sucede en la GTX 570, con sus 15 SMs y 40 ROPs, pero éste no es parece ser ese caso.

Por otro lado, las velocidades de reloj son igualmente interesantes. Oficialmente, tanto el reloj de base como el reloj de boost son un poco más bajo que los de la GTX 680. La GTX 670 vendrá a 915MHz para el reloj de base y a 980MHz cuando se activa el reloj de boost, lo que la ubica 91MHz (9%) y 78MHz (7%) más abajo que la GTX 680, respectivamente.

El subsistema de memorias tampoco ha sido cambiado en absoluto. Las GTX 670 contarán con misma memoria de 6.008GHz de la GTX 680 con el bus de memoria de 256-bit de su hermana mayor, dándole el mismo ancho de banda de memoria de 192GB/segundo. Esto es particularmente interesante ya que NVIDIA siempre ha bajado sus relojes de memoria en el pasado, y también quitaba normalmente un controlador de memoria/ROP.

En conjunto, esto significa que corriendo en los relojes de base la GTX 670 cuenta con el 100% del ancho de banda de memoria, el 91% del rendimiento de ROPs y el 80% del rendimiento de shaders de la GTX 680. Esto coloca a la GTX 670 mucho más cerca de la GTX 680 de lo que estaba la GTX 570 de la GTX 580.

En lo que refiere a consumo de energía, la brecha entre las dos tarjetas va a ser casi la misma que vimos entre las GTX 580 y GTX 570. El TDP oficial de la GTX 670 es de 170 W, 25 W menos que la GTX 680.

 La tarjeta gráfica en cuestión

Aquí veremos algunas imágenes de la GeForce 670 GTX, con un diseño de referencia de NVIDIA. La tarjeta mide 25 centímetros de largo, pero una peculiaridad es que el PCB sólo alcanza 17 de éstos centímetros, con el resto del largo siendo ocupado por la carcaza del fan, de tipo blower.

En la parte superior de la tarjeta se encuentran los conectores de alimentación PCI Express y SLI. Dado que NVIDIA no está luchando para ahorrar espacio como lo hizo con la GTX 680, las tomas de corriente PCI Express están dispuestas de forma tradicional, lado a lado. En cuanto a los conectores SLI, ya que esta es una tarjeta de alta gama, NVIDIA proporciona 2 conectores, permitiendo a la tarjeta ser utilizada en 3-way SLI.

Rendimiento, temperatura, ruido y consumo

Como vemos, la GTX 670 se posiciona muy bien en todas las pruebas, superando a tarjetas incluso más caras que ella. Es de notar el consumo de energía, más que excelente para un GPU de este nivel de prestaciones.

Palabras finales

NVIDIA lo ha hecho de nuevo. Mediante un ingenioso rediseño de su excelente núcleo Gf104 ha conseguido arrebatar nuevamente la corona de rendimiento en juegos a AMD. Sin embargo, con cada generación los GPUs AMD se han ido centrando cada vez más en el mercado High Performance Computing (HPC), relegando el rendimiento en juegos, por lo que éstos aún mantienen el primer lugar en las tablas de velocidad de cómputo.

Con una gran relación precio-producto, un consumo acotado, un nivel de ruido más que bueno y un rendimiento increíble en juegos, la GTX 670 se posiciona como la tarjeta ganadora en la guerra que siempre se desata al lanzarse una nueva generación de GPUs, al menos para el mercado gamer.