Comentario Original:

Hay algo que no me encaja: ¿1542 millones de transistores para solo 115 Gflops?
Xenos tiene 337 millones de transistores y procesa 240 Gflops.
¿A donde van esos transistores (cachés, paginación, lógica, …)?

Hay un detalle que en la entrada original pase por alto que es el siguiente:

2A610EsL5Umee9wL

Es el hecho de que la cantidad de EUs por SSN se puede activar o desactivar en dicho diseño, es una cosa muy importante que hasta ahora no se ha visto en ninguna GPU existente en el mercado incluyendo las más nuevas. ¿El que? El concepto de la ola de tamaño variable.

Thefuck-random-30688791-407-393

En Nvidia las olas son siempre de 32 componentes, en AMD de 64 componentes. Es decir, el planificador tanto en el pipeline gráfico como en el pipeline de computación envia de manera encapsulada siempre bloques de x elementos fijos a procesar. Cuando la AMD Vega aún no había sido presentada se hablo mucho de que esto sería adaptado por la GPU de AMD y llama poderosamente la atención que Intel parece que lo va a adoptar para su GPU dedicada y hace pensar que forma parte de la especificación de una futura versión o subversión de una API.

AMD-Vega-architecture-840x429.jpg

El concepto es sencillo, se basa en que en vez de tener una unidad SIMD de n componentes capaces de procesar todos la misma instrucción lo que pasaríamos a poder dividirla para aumentar la cantidad de instrucciones a procesar a cambio de reducir la cantidad de componentes por instrucción para aprovechar el resto de componentes para otra instrucción o simplemente dejarlos inactivos.

Por ejemplo si yo tengo una unidad SIMD16 con la vieja configuracion tendre que alimentarla con unos 16 componentes/operandos con los que realizar la operación, si lo alimento con menos entonces su rendimiento solo será del 50%. En cambio con el nuevo paradigma la unidad SIMD16 se convierte en 2 unidades SIMD8 capaces cada una procesar una instrucción diferente. Esto arquitecturalmente es un gran cambio en todo el procesador, no solo en las unidades de ejecución sino también en el planificador global de la GPU y el planificador de lo que es la Compute Unit (AMD)/SM (Nvidia)/Subslice System (Intel).

IntelEU

kaveri-14b

PascalSM

La unidad modificada sería el Local Thread Dispatcher en Intel, el Scheduler en la Compute Unit de AMD y el Warp Scheduler en Nvidia. En realidad son diferentes nombres para el mismo tipo de unidad y no voy a especificar técnicamente los cambios en este caso porque entraríamos a un nivel técnico que a mi me supera sinceramente, simplemente con tener una abstracción tenemos suficiente.

¿El siguiente cambio? Obviamente el planificador de la GPU en global, el cual se compone por el Procesador de Comandos y los alternos, en el prototipo de la GPU de Intel esto se ha realizado a través de un FPGA pero en su implementación como GPU en un bloque nos encontramos con que su tamaño es enorme con un poco más de 1500 millones de transistores.

ANrpDHxvRGsFcEPw

El tema es que esto no es el sistema gráfico al completo…

5XbJsTftZHT84khQkfyVSi-650-80

El recuadro amarillo es la diapositiva de arriba, lo que sería el nuevo planificador esta en el prototipo en otro chip. Teniendo en cuenta que Intel pronto sacará sus 10nm lo más seguro es que ambas partes se unifique en una sola en el futuro. ¿pero como es que el prototipo tiene tantos transistores? Mi hipotesis es que el recuadro amarillo no es que hayan cogido un chip ya existente sino que tienen que haber cambios importantes a nivel de SSn con tal de aplicar lo que he comentado más arriba y también otro cambio importante que es la capacidad de funcionar a diferentes velocidades que tiene cada uno de los componentes de la EU y por tanto no solo en diferentes configuraciones.

04_l

La idea es que la velocidad de reloj depende del voltaje y podemos tener diferentes areas del SSN a diferente velocidad si es necesario. Por descarte y por lógica en el diagrama tenemos que las FF (Fixed Function) serían las unidades de texturas (Sampler) que hay en cada SSN, siendo el recuadro no marcado el Data Port del que hablamos en la entrada anterior. ¿Que serían las llamadas Media Units? Uno podría pensar que serían los codificadores/descodificadores de video a tiempo real pero estos van normalmente en el Northbridge privado de la GPU o en el caso de que haya uno solo en el del sistema, no es normal ponerlos en este tipo de unidades, no sabemos que podría ser esta Media Unit… ¿Se trataría de la Delta Color Compressión? No tendría sentido porque esto sería una variación en los ROPS pero si somos estrictos nos encontraremos con que las GPUs de Intel no tienen ROPS propiamente dicho sino unidades que envían y reciben datos con la Cache L3… ¿Que nos queda? Si el diagrama es representativo de la organización esto significaría que Intel habría por fin añadido los ROPS con toda su funcionalidad como Dios Manda a su diseño y que estos ROPS estarían conectados a la cache global (la de más nivel de la GPU) como ocurre con las Nvidia desde Maxwell y las AMD de Vega en adelante.

La otra parte es el recuadro que pone… FF, CMD Streamer, Cache L3… No se trata d euna sola unidad sino de las unidades conectadas a los shaders tipicas de una GPU. En la Funcion Fija tenemos lo que es el rasterizador y unidades como la de teselación. el Command Streamer se trataría de la unidad de Dispatch encargada de enviar los comandos a las unidades de ejecución disponibles de la GPU o las adecuadas para cada tarea en concreto (función fija)… ¿Que otro cambio a futuro nos quedaría? La adopción de un rasterizador por tiles como el que tiene Nvidia en sus GPUs a partir de Maxwell…

tiledcaching2tiledcaching3

La Cache L3 en el diseño de Intel haría el trabajo de la Cache L2 en otras GPUs y aquí se le llama Cache L3 porque al contrario de las unidades de texturas de AMD e Intel donde estas tienen un solo nivel en Intel tienen dos niveles. Esto permite que la GPU pueda dividir la escena por Tiles… ¿Es un Tile Renderer? No, porque el Tile Renderer funciona de manera distinta, un Tile Renderer calcula la geometría de la escena y antes de rasterizarla en conjunto tiene en cuenta la posición en pantalla de la geometría y crea una lista de pantalla que rasteriza a continuación. Para ello necesita ordenar la geometría de la escena según su posición en pantalla y la de calcular toda al completo previamente para ello en vez de ir calculando componente por componente para ordenarlo al final.

sortmiddle

La Rasterización por Tiles es distinta, se puede aplicar en una GPU convencional porque… y esto es una correccion mía porque sinceramente lo supe hace muy poco es que no hay ordenación previa, es decir, la arquitectura sigue siendo una Last Sort por lo que el ordenación de la escena se hace al final por lo general.

sortlast

¿Entonces? Digamos que lo que ocurre es que cuando el rasterizador rasteriza por Tiles lo que hace es almacenar el resultado en la Cache más alta para ser procesador después por las CUs/SMs no lo envia de manera directa sino que lo copia directamente en la Cache L2. Si además tenemos la suerte de que las texturas para el fragmento estén copiadas en la Cache L2 nos ahorramos el viaje a la memoria externa de la GPU en la etapa de texturización, la que es la más lejana. ¿Por qué tiene importancia esto? Para los profanos tiene que ver con la logistica de lo datos, cuanto más lejos esta una memoria de un procesador más lenta es una instrucción.

cpu_cache_structure

Los Shaders están pensados para funcionar con direccionamiento inmediato, esto significa que los datos se encuentran en sus registros y operan desde allí, normalmente las GPU dividen sus instrucciones en dos tipos:

  • Simples: Se suelen poder ejecutar en un ciclo por instrucción.
  • Complejas: Necesitan unos 4 ciclos por instrucción.

Pero con las texturas es distinto, se encuentran en la Cache de texturas que esta a un nivel por debajo, eso es una latencia adicional, si los datos no se encuentran en dicha cache entonces ha de mirar en la Cache L2 e ir bajando hasta la memoria más lejana a la que tenga acceso. Obviamente con el tema de las texturas no ocurre eso porque ya se encarga el mecanismo automatizado de tener en la cache de texturas los datos correspondientes. En realidad el problema viene con el pipeline de computación y es aquí donde Intel tiene problemas en comparación con AMD y graves además. ¿Cuales? La unidad de Intel no tiene un camino alternativo para la computación.

gs4106-the-amd-gcn-architecture-a-crash-course-by-layla-mah-38-1024.jpg

En las GPUs de AMD (y en las de Nvidia, pero me centrare en las de AMD) los datos pueden seguir dos caminos distintos, uno para gráficos y otro para computación. El de gráficos tiene una Cache de texturas pero el de Computación tiene la Local Data Share que se podría considerar como una especie de Cache L0 ya que la Cache L1 no asignada a las unidades de texturas se encuentra englobada por CU.

L1CacheDiagram

La nomenclatura es confusa porque tenemos dos caches L1, pero las que están marcadas en azul no corresponden a la Compute Unit y en el caso de las AMD pre-Vega pueden estar asignadas a 3 CUs…

3CU2

o a 4 CUs…

4CU2

En el caso de Vega el ratio de la Cache L1 se ha disminuido de 4:1 o de 3:1 a 2:1 realmente. En el caso de la GPUs de Intel tenemos que la Cache del Sampler funcionaría tanto para computación como para gráficos y ya se sabe lo que ocurre en el rendimiento cuando se comparte el ancho de banda de una memoria por lo que es posible que si las Media Units son los ROPS entonces la unidad no marcada sea una especie de Local Data Share, la cual es habitualmente utilizada para computación pero la Local Data Share tiene un secreto.

prt1

La idea de las texturas parcialmente residentes es subdividir las texturas en bloques de 64KB… ¿Por qué de 64KB? Pues por qué es el tamaño de la Local Data Share… Pero no solo podemos cargar texturas en la Local Data Share sino también otro tipo de datos y si… Las unidades de texturas no solo pueden leer e interpolar utilizando los datos de la Cache de texturas sino también del Local Data Share aunque no lo normal y esto más bien se utiliza para el pipeline de computación. En todo caso lo importante es que por lo general es un camino de dato distinto al de la Cache de texturas por lo que si estamos ejecutando en una Compute Unit una ola que requiere acceder a la Local Data Share y no a la cache de texturas no entra en conflicto con el que utilice el otro tipo de memoria.

Cuando la GPU rasteriza por tiles no recibe las primitivas gráficas de manera ordenadas sino de manera desordenada… no se encarga de rasterizar toda la escena de golpe sino a medida que los triangulos a rasterizar le ven llegando.

Graphics3D_Rasterization

Lo normal es rasterizar cada primitiva en un tile de 8×8 pixeles que se va a enviar a las unidades shader para ser directamente texturizado o si no hay textura para dibujarlo directamente en el búfer de imagen después de la ordenación posterior. Pero en el nuevo paradigma puede tener otro camino de datos y es que se vea copiado en la Cache L2.  ¿Para que? El fragmento representa un espacio X,Y que almacena todos los triangulos del tile y todos y cada uno de los triangulos del Tile incluso si son visibles o no se acaban renderizando, a esto se le llama overdraw.

siggraph_vega_architecture_41

En la diapositiva tenemos un tile de 10×8 pixeles en total, tenemos que hay primitivas que en ciertos pixeles son visibles y en otros no son visibles. El concepto aquí es poder almacenar el tile para procesarlo y eliminar los pixeles no visibles para que los Fragment/Pixel Shader no los texturice y el resto no los dibuje. Para ello es necesario que el rasterizador este conectado a la Cache más alta de la GPU. De ahí a que en el diagrama Intel lo haya unificado respecto a la anterior generación, es un cambio obligatorio porque es exigencia de las nuevas APIs y si Intel no lo soporta entonces mal para Intel por lo que lo tiene que soportar si o si. ¿Hay una ordenación de la escena? No, esta sigue siendo Last-Sort y no es necesaria hacer una ordenación Middle-Sort para este proceso que tecnicamente sirve para eliminar el overdraw pero no es renderización por Tiles.

¿El otro cambio importante? La unidad de Dispatch, las cuales con el tamaño variable de las olas pues cambía por completo su naturaleza, cuando tienes una ola de tamaño fijo realizar el Dispatch es muy fácil… Pero cuando tenemos olas de tamaño variable entonces se complica un poco más, de la misma manera que el procesados de comandos, pero hemos quedado que es el llamado System Agent y que seria el otro chip.

¿Y como justificamos los 1500 millones de transistores entonces? FPGA, estos a cambio de ser programables tienen una mayor cantidad de transistores como es obvió. ¿Significa esto que Intel podría distribuir su GPU configurado en un FPGA? ¿Que sentido tiene? En el 2016 Intel compro Altera… ¿Es posible que Intel se este planteando SoCs y sistemas con FPGAs en un futuro? Altera ya tenía experiencia en ese aspecto precisamente y sería un factor diferencial de Intel respecto a AMD. Pero claro, esto es una suposición mia.

PD: Perdón por el rollo.