Hasta ahora, he podido descubrir que ha habido un movimiento desde un circuito muy especializado que implementa las diversas etapas de la tubería gráfica a un enfoque más general. Esta transformación se ha reflejado parcialmente en las API 3D en forma de sombreadores programables. La mayoría de los transistores parecen estar dedicados a unidades SIMD masivamente paralelas que ejecutan las instrucciones reales del sombreador.
Correcto. Básicamente, debido al tamaño de característica relativamente grande en las GPU más antiguas, la única forma de implementar eficientemente cosas como iluminación básica, antialiasing, mapeo de texturas, geometría, etc. era usar una tubería de "función fija". Sacrificaron la flexibilidad en aras del rendimiento porque no tenían suficiente densidad de chip para poder implementarla utilizando una arquitectura SIMD masivamente paralela más genérica como las GPU actuales.
Es una GPU moderna (piense en Nvidia Fermi), básicamente, un conjunto de matrices SIMD "estúpidas" que se alimentan con instrucciones y datos de la CPU y varios cachés, y toda la lógica real que asigna la tubería de gráficos a esas instrucciones ocurre en el controlador de gráficos ?
Ciertas cosas todavía se hacen en hardware; otros no lo son. Por ejemplo, los ROP todavía se usan en la etapa final para insertar datos de píxeles en el conjunto de chips VGA. Tenga en cuenta que estoy usando "chipset VGA" aquí como un término genérico para referirme al mecanismo que transmite una señal de video a su monitor, independientemente de si es realmente "VGA" en algún aspecto.
Es cierto, en general, que las arquitecturas actuales de GPU como Nvidia Fermi y AMD Southern Islands son, en su mayor parte, CPU masivamente paralelas donde tienen un conjunto de instrucciones personalizado, y cada "núcleo" individual es extremadamente débil, pero hay una gran cantidad de núcleos (a veces varios miles). Pero todavía hay hardware específico para gráficos allí:
La decodificación de video de hardware a menudo se realiza, en gran parte, utilizando chips de función fija. Esto es particularmente cierto cuando DRM (gestión de restricciones digitales) está involucrado. A veces, la decodificación de video "hardware" realmente significa un conjunto de instrucciones guiadas por firmware que solo se presentan como tareas antiguas habituales para los núcleos SIMD. Realmente depende
Con la excepción de unas pocas tarjetas Nvidia (Tesla) específicas de cómputo, casi todas las tarjetas gráficas "SIMD genéricas" tienen una gama completa de hardware dedicado a la salida de video. La salida de video no es lo mismo que renderizar; Los elementos de salida de función fija incluyen códecs LVDS / TMDS / HDMI / DisplayPort, HDCP e incluso procesamiento de audio (básicamente un pequeño DSP), ya que HDMI admite audio.
La "memoria de gráficos" todavía se almacena a bordo con las GPU, para que no tengan que atravesar el bus PCIe hablador y de latencia relativamente alta para llegar a la RAM del sistema, que es más lento y tarda más en responder que el más costoso, mayor calidad, memoria gráfica más rápida (por ejemplo, GDDR5) que viene en capacidades más pequeñas pero velocidades más altas que la memoria del sistema. El proceso de almacenar cosas en la memoria gráfica y recuperarlas desde allí a la GPU o la CPU sigue siendo una operación de función fija. Algunas GPU tienen su propio tipo de "IOMMU", pero esta unidad de administración de memoria es distinta (separada) de la CPU. Sin embargo, esto no es cierto para las recientes GPU Intel integradas en sus procesadores (Sandy e Ivy Bridge), donde la arquitectura de la memoria es casi completamente "coherente" memoria del sistema) y las lecturas de la memoria de gráficos son tan baratas para la CPU como lo son para la GPU.
¿O hay algunas unidades de control en algún lugar de la GPU que traducen la instrucción de alto nivel entrante y los flujos de datos (programas de sombreado compilados, datos y atributos de vértices y texturas) en instrucciones SIMD reales y se encargan de la sincronización, la asignación de memoria, etc.?
El idioma "nativo" de los SIMD casi siempre es generado por el controlador en el software, y no por el firmware de la GPU. Esto es especialmente cierto para las funciones de nivel DirectX 9 / OpenGL 2.x. Los sombreadores escritos en lenguajes de alto nivel como HLSL, GLSL o el ensamblador de sombreadores OpenGL ARB son eventualmente traducidos, por el controlador, a las instrucciones de la GPU al golpear ciertos registros y hacer los aros PCIe necesarios para enviar más buffers por lotes de cómputo y / o render comandos
Algunas cosas, como la teselación de hardware (DirectX 11 / OpenGL 4.0) vuelven a introducirse en el hardware de forma fija, similar a como solían hacer casi todo en los viejos tiempos. Esto se debe a que, nuevamente, las restricciones de rendimiento requieren que la forma más eficiente de hacer estos cálculos es tener un circuito dedicado para ello, en lugar de tener firmware o el controlador "programe" los SIMD para hacerlo.
Sospecho que la realidad está en algún punto entre esos dos extremos, y la respuesta sería bastante larga y se basaría en mucha especulación (tiene que haber una razón para que ciertos proveedores de GPU se nieguen a publicar cualquier documentación sobre sus productos, y mucho menos el controlador código fuente ...), pero cualquier sugerencia en la dirección correcta y recursos útiles serían muy apreciados.
AMD e Intel tienen a la vista una documentación muy sólida sobre sus GPU recientes, así como controladores de gráficos de código abierto para Linux (ver los proyectos Mesa y Direct Rendering Manager). Si observa algunos de los códigos en estos controladores, se reirá, porque los escritores de controladores gráficos en realidad tienen que implementar la geometría de cosas como dibujar varias formas o patrones, en "software" (pero usando comandos de hardware para enviar el verdadero trabajo preliminar para el hardware para el procesamiento), porque ni el firmware de la GPU ni el material de la función fija ya están presentes para procesarlo completamente en el hardware :) Es un poco curioso lo que tienen que hacer para admitir OpenGL 1.x / 2.x en los nuevos hardware.
La evolución se ha ido así:
- Hace mucho tiempo (antes de que se considerara posible la representación 3D en tiempo real): el trazado de rayos en la CPU era normal para la representación en tiempo no real. Para gráficos simples como se ve en las primeras versiones de Windows, la CPU fue lo suficientemente rápida como para dibujar formas simples (rectángulos, caracteres de una fuente, patrones de sombreado, etc.) sin hardware de función fija, pero no podía dibujar cosas demasiado complejas.
- Hace mucho tiempo (OpenGL 1.x): casi todo lo implementado por hardware de estado sólido; las funciones fijas "eléctricamente" eran la norma incluso para operaciones básicas
- Hace un tiempo (OpenGL 2.x): había comenzado una transición para hacer que las GPU fueran más programables. "Fragment shaders" (también conocido como sombreadores de píxeles) en el hardware de 5 años pueden casi realizar cálculos arbitrarios como una CPU, pero está limitada por la arquitectura, que sigue siendo muy orientado a gráficos. Por lo tanto, OpenCL / DirectCompute no están disponibles en este hardware.
- Recientemente (OpenGL 3.x): la transición a las GPU de propósito general se ha completado en su mayoría, pero, por supuesto, están optimizadas para cargas de trabajo que involucran grandes matrices de datos (piense en álgebra lineal) que se envían en lotes, en lugar de CPU que pueden operar eficientemente en secuencias largas de datos muy pequeños (1 + 1, 2 * 4, 5 * 6 en secuencia, etc.) La informática de propósito general está disponible a través de OpenCL, CUDA, etc. pero el hardware todavía no es un "coprocesador SIMD" completo porque (a) todavía tiene que forzar registros específicos de hardware para acceder a la funcionalidad de la GPU; (b) la lectura desde la GPU VRAM es muy lenta debido a la sobrecarga del bus PCIe (la lectura desde la GPU no está muy optimizada en la arquitectura actual); (c) la arquitectura de memoria y caché no es coherente con la CPU; todavía hay mucho hardware heredado de funciones fijas.
- Presente (OpenGL 4.x): eliminó gran parte del hardware de funciones fijas heredado. Se mejoró un poco la latencia de lectura de la GPU. Las IOMMU permiten un mapeo asistido por hardware (traducido) entre VRAM y la memoria del sistema. También introdujo la teselación de hardware, recuperando elementos de función fija.
- Futuro ( HSA): La GPU es básicamente un coprocesador. Está completamente integrado con la CPU con muy poca impedancia (para lecturas / escrituras) entre la GPU y la CPU, incluso para GPU dedicadas en el bus PCIe. Arquitectura de memoria totalmente coherente: "mi memoria es su memoria". Los programas de espacio de usuario pueden leer desde "VRAM" al igual que lo hacen desde la memoria del sistema sin shim de controlador, y el hardware se encarga de ello. Tiene la CPU para el procesamiento "en serie" (haga esto, luego haga eso, luego haga esto, luego haga eso) para cantidades modestas de datos, y la GPU para el procesamiento "paralelo" (realice esta operación en este enorme conjunto de datos y divídalo arriba como mejor te parezca). La placa en la que se encuentra la GPU aún puede tener ROP, códec HDMI, etc., pero esto es necesario para la salida de la pantalla,
