¿Por dónde empezar al considerar hacer una GPU?

Vi este video el otro día y me hizo pensar en cómo diseñar algo como la GPU. ¿Por dónde empezarías? Estoy más interesado en leer sobre cómo funcionan y no en hacer uno con TTL (todavía de todos modos).

Sé que esto suena como una pregunta de 'cómo se hace un lenguaje de programación', pero cualquier punto de partida sería bueno ya que no tengo idea de por dónde empezar a buscar.

¿Está interesado en "gráficos 3D de alta velocidad" o "cómo manejar un CRT/LCD"?
@Joby atm solo muestra algo en una pantalla. Un cuadrado de color estaría bien.
¿Alguien puede explicarme por qué obtuve un voto negativo? Entonces puedo resolver cualquier problema con la pregunta.
La dificultad que veo con esta pregunta es que hay MUCHO terreno entre generar solo una pantalla monocromática de 80x25 caracteres, lo que alguna vez se podría haber llamado un generador de pantalla de video, y lo que se entiende por 'GPU'. La sugerencia de que es posible que desee hacer uno 'fuera de TTL' lo acerca mucho más al antiguo final del generador de pantalla de 80x25.
@JustJeff, Ok, no sabía de qué otra manera se llamaban, ¿por qué son tan diferentes si hacen un trabajo similar?
Además, ¿por qué obtuve otro voto negativo? ¿Podría explicar por qué votaste negativo?

Respuestas (6)

Eso es como ir a tu examen final de collage para la clase de ciencias y tener esta como tu pregunta: describe el universo. Sea breve, pero conciso. No hay forma posible de responder a eso de manera práctica, así que responderé una pregunta diferente.

¿Cuáles son los tipos de cosas que necesito saber antes de intentar diseñar una GPU?

En un orden cronológico aproximado, son:

  1. Ya sea VHDL o Verilog.
  2. FPGA's (área útil para jugar con la escritura de lógica digital).
  3. Cosas básicas de ruta de datos, como FIFO.
  4. Interfaces de bus, como interfaz PCIe y DDR2/3
  5. Implementaciones binarias de funciones matemáticas, incluido el punto flotante, etc.
  6. Diseño de CPU.
  7. Estándares de interfaz de video.
  8. Cosas analógicas de alta velocidad (el lado analógico de la digital de alta velocidad)
  9. PLL's y otras cosas de relojería semi-avanzadas.
  10. Diseño de PCB de circuitos de alta velocidad.
  11. Diseño de convertidor CC/CC de baja tensión y alta corriente.
  12. Montones y montones de cosas de software.
  13. Y, por último, ASIC u otro diseño de tipo de chip personalizado.

También me atrevería a decir que no harás este tipo de cosas con chips lógicos TTL. Dudo que pueda obtener una interfaz de memoria DDR2/3 razonable que funcione con chips TTL normales. Usar un FPGA grande sería mucho más fácil (pero no fácil).

Subir al paso 6 probablemente sea "lo suficientemente bueno para saciar su sed intelectual". Eso también podría hacerse dentro de un período de tiempo razonable, alrededor de un año, para establecer una meta a corto plazo.

EDITAR: si todo lo que quiere hacer es escupir una señal de video, entonces es relativamente fácil. Es, en esencia, una parte de la memoria que se desplaza a una pantalla a 60 Hz. El diablo está en los detalles, pero aquí hay un bosquejo de cómo hacer esto:

Comience con un poco de RAM de doble puerto. No tiene que ser un verdadero puerto dual ram, solo un poco de RAM que una CPU pueda leer/escribir y que su circuito de video pueda leer. El tamaño y la velocidad de esta RAM dependerán del tipo de pantalla que estés manejando. Yo personalmente usaría SDRAM DDR2 conectada a la interfaz de memoria de un FPGA Xilinx Spartan-6. Su núcleo de "generador de interfaz de memoria" (MIG) facilita convertir esto en una RAM de doble puerto.

Luego, diseñe un circuito que controlará cómo se lee esta RAM y escupirá estos datos en un bus simple. Normalmente solo lee la RAM secuencialmente. El "autobús simple" realmente es solo eso. Son algunos bits con el valor del píxel, y eso es todo. Este circuito tendrá que hacer dos cosas más: tendrá que volver al principio de la RAM en cada cuadro de video y tendrá que "pausar" la salida durante los períodos de retroceso horizontal/vertical.

En tercer lugar: haga un circuito que emita las señales de control de video (HSync, Vsync, etc.) y le diga al circuito anterior cuándo pausar y reiniciar. Estos circuitos son bastante fáciles de hacer. Encontrar el estándar de video apropiado es más difícil, en mi humilde opinión.

Y finalmente: conecte las señales de control y el bus de datos de píxeles de video a "algo". Eso podría ser una pequeña pantalla LCD a color. Podría ser a un DAC de video para generar una señal compatible con VGA. Hay codificadores NTSC/PAL que tomarían estas señales. Etc.

Si la resolución es realmente pequeña, puede usar la RAM interna de la FPGA en lugar de una SDRAM DDR2 externa. Debo advertirle que si se usa DDR2 SDRAM, probablemente necesitará un FIFO y algunas otras cosas, pero eso tampoco es terriblemente difícil. Pero con DDR2 SDRAM puede admitir pantallas de resolución bastante alta. También puede encontrar placas de desarrollo FPGA con VGA DAC integrados y otras formas de salidas de video.

Vaya, no es una tarea corta entonces. Entiendo que no hubo una respuesta concisa. Pero me ha dado un buen punto de partida y tendré que hacerlo en mi tiempo libre muy limitado. Pero debería ser una experiencia interesante.
@Dean Hmmm... Hay TRES cosas diferentes aquí: CPU, GPU y algo para escupir una señal de video. Es fácil hacer algo para escupir una señal de video. Una GPU es más como una CPU que está diseñada para hacer procesamiento relacionado con video/gráficos: gráficos 3-D, aceleración de gráficos 2-D, etc. Si solo desea que algo emita una señal de video, entonces está listo. Si desea gráficos en 3D o incluso 2D semiavanzado, deberá revisar mi lista.
¿Cómo es fácil escupir una señal de video? Creo que esto sería un mejor primer paso.
@Dean Edité mi respuesta para incluir cosas sobre cómo escupir una señal de video.
@David: Sí, creo que eso es todo lo que alguien puede esperar hacer en una placa de pruebas. Solía ​​diseñar controladores de pantalla para Raster Technologies, Apollo Computer y ayudé a ATI a entrar en 3D. Estas cosas han sido de silicona personalizadas o semipersonalizadas durante mucho tiempo. Algunas GPU modernas tienen más transistores que la CPU que los controla. La iluminación, el sombreado, el mapeo de texturas, la interpolación, la corrección de perspectiva y la rasterización requieren muchos cálculos.
@Olin "y ayudó a ATI a entrar en 3D" -----> =O Debe escribir un libro de texto de EE que lo abarque todo y que contenga todo lo que sabe. Haría cosas absurdas para tenerlo en mis manos.
Una vez escribí un libro sobre gráficos por computadora (ISBN 0-471-13040-0), pero es muy introductorio. En la década de 1990, cuando ATI solo tenía sus chips MACH64 y quería entrar en 3D, me contrataron como consultor para enseñarles algunos de los conceptos, ponerlos en marcha y ayudarlos con la arquitectura. El resultado fueron los primeros chips RAGE. Yo era un tipo de gráficos en ese entonces. Consulte la patente estadounidense 5097427 si no me cree. Sin embargo, creo que la patente de interpolación cuadrática (US 5109481) fue más importante pero menos llamativa. Es posible que reconozca algunos otros nombres en esos ;-)

Racing the Beam es una mirada detallada al diseño y funcionamiento del Atari VCS. Tiene un tratamiento completo del adaptador de interfaz de televisión.

La TIA es la GPU más sencilla y práctica.

Comprender un sistema de trabajo pequeño, pero completo, puede ser una buena manera de aprender un nuevo tema.

Los esquemas completos están disponibles, al igual que un manual técnico .

¡Reglas de Atari 2600! La mayoría de los sistemas de juego usan hardware para generar la pantalla, pero el 2600 lo hace todo por arte de magia. Compara algo como Combat o incluso Asteroids con algo como Toyshop Trouble (Asteroids y Toyshop Trouble son ambos 8K). Combat muestra dos objetos de un solo color con resolución de 2 líneas; Toyshop Trouble muestra 16 objetos con resolución de una sola línea y coloración por línea (y sin parpadeo). No hay hardware adicional para Toyshop Trouble más allá de un conmutador de banco para permitir 8k de código. Solo un poco de codificación inteligente y algo de magia.
Por cierto, la programación 2600 puede ser oscura, pero un diseño de superposición de video basado en PSOC que hice para un cliente parecía más bien 2600. Configure el hardware en el chip para generar algunos de los tiempos y use el código para alimentar datos a un esclavo SPI para que pueda ser registrado como píxeles.
increíble que todo el código del juego tuviera que ejecutarse durante los tiempos de retroceso del haz

Si solo desea poner algunas cosas en la pantalla y cree que realmente podría disfrutar del cableado, podría aspirar a un sistema de gráficos de personajes de principios de 1980. Si puede alcanzar el tiempo para RS-170A, es posible que incluso pueda enviar la señal a una entrada AV de repuesto en un televisor de plasma de 50 "y volverse retro a lo grande.

Algunos de los primeros sistemas usaban sus CPU de 8 bits para generar directamente la pantalla, por ejemplo, el 6507 en el Atari 2600 y el Z-80 en el Timex Sinclair ZX-81. Incluso puedes hacer el mismo tipo de cosas con microcontroladores modernos. La ventaja de esta manera es que el hardware es simple, pero el software generalmente tiene que estar en ensamblador, y es muy exigente, y los resultados serán realmente decepcionantes. Podría decirse que el 2600 empleó hardware adicional, pero el TIA no tenía mucho FIFO, y el 6502 (bueno, 6507, en realidad) tuvo que descargar bytes en tiempo real. En este enfoque, no existe un modo de video estándar; cada aplicación que usa video tiene que estar íntimamente combinada con las necesidades de mantener el flujo de píxeles.

Si realmente desea crear algo a partir de TTL, el siguiente nivel de complejidad sería optar por la visualización de texto basada en ROM de caracteres. Esto le permite poner cualquiera de, digamos, 256 caracteres en cualquiera de, por ejemplo, 40 columnas y 25 posiciones de fila. Hay un par de maneras de hacer esto.

Una forma: haz lo que hice con el modelo TRS80. Un grupo de contadores 74161 con una variedad de puertas generó la dirección de video; tres 74157 multiplexaron 12 bits de la dirección de la CPU con la dirección de video, para alimentar una dirección a una RAM estática de 2K. Los datos de RAM se almacenaron en el búfer de regreso a la CPU, pero se alimentaron sin búfer como dirección a la ROM del conjunto de caracteres. No hubo arbitraje de autobuses; si la CPU quería RAM de video, se pisaba el sistema de video, lo que resultaba en el efecto 'nieve'. La dirección de video multiplexada se combinó con algunas líneas de la sección del mostrador para redondear las direcciones bajas; La salida de la ROM de caracteres se volcó en un registro de desplazamiento 74166. Todo corrió por divisiones de un cristal de 14.31818MHz. En este enfoque, tendría exactamente un modo de video completamente implementado en hardware, como 40x25 o 64x16, etc.,

Otra forma: desenterrar un llamado chip CRTC como un 6845. Estos combinaron la mayor parte de la lógica de contador y pegamento, y proporcionaron al procesador una interfaz de registro de control para que pudiera reprogramar parte del tiempo. Los sistemas como este podrían hacerse algo más flexibles, por ejemplo, podría obtener 40x25 y 80x25 del mismo hardware, bajo control de registro. Si se vuelve inteligente con las frecuencias de reloj, es posible que pueda permitir que su CPU tenga acceso libre a la RAM de video durante la mitad del reloj, y que el generador de direcciones de video acceda durante la otra mitad del reloj, evitando así la necesidad de arbitraje de bus. y eliminando el efecto nieve.

Sin embargo, si desea optar por modos de gráficos reales, descubrirá rápidamente que rodar el suyo propio es problemático. El Apple 2 original lo logró, pero ese sistema tenía algo así como 110 chips MSI TTL, y aun así hubo algunas cosas divertidas con las que lidiar, como el mapeo no lineal del búfer de video a la pantalla y paletas de colores extremadamente limitadas. , por nombrar dos. Y Woz es generalmente reconocido por haber tenido una pista. Cuando apareció el '2e', Apple ya estaba colocando el sistema de video en un chip personalizado. El C-64, que salió casi al mismo tiempo, debía sus capacidades gráficas a chips personalizados.

Así que... Yo diría que hay dos formas de hacerlo. Una forma: saque su cubo de TTL antiguo y aspire a una pantalla de texto de un color de 80x25; al revés: consígase una buena placa de evaluación de FPGA, hágalo todo en VHDL y comience con una pantalla de texto de 80x25.

Debería comenzar con algunos fundamentos de la arquitectura de la computadora y, en paralelo, comenzar con el diseño básico de ASIC utilizando VHDL u otro lenguaje de descripción.

Una vez que haya aprendido los conceptos básicos de la arquitectura de la computadora, le recomendaría aventurarse en los gráficos por computadora, tal vez comenzando con algunos proyectos simples de OpenGL. Lo principal aquí sería tener una idea de la arquitectura de representación de la canalización de gráficos .

El siguiente paso sería pensar en formas en que esta canalización de renderizado podría lograrse con hardware dedicado en lugar de software.

En términos de construir una GPU y conectarla a su computadora, no creo que esto sea factible de hacer con el presupuesto de un entusiasta, pero tal vez haya algo muy básico que pueda probar con una plataforma ARM-linux integrada (que expone un bus del sistema) y una FPGA (la FPGA en este caso es su GPU escrita en VHDL) que emite a una pantalla VGA de baja resolución como un proyecto integral. Esto requeriría escribir controladores también. Si puedes hacerlo, sería genial en un currículum.

Mire los diagramas de bloques de alto nivel de las GPU de AMD y NVidia. Probablemente encontrará bastante información de la gente de opengraphics, que está diseñando hardware de gráficos de código abierto, con controladores de código abierto.

Entonces tienes que mirar lo que quieres.

  • Salida, HDMI, DVI o VGA?
  • ¿Transformaciones de vértices?
  • Texturizado?
  • ¿Sombreado de píxeles?
  • ¿Recorte de triángulos y rasterización?
  • ¿Alguna textura?
  • ¿Operaciones de trama?

Si no ha realizado ninguna programación utilizando funciones de GPU, también podría ser bueno saberlo.

Creo que Leon también lo tiene clavado. Usaría Verilog si hiciera esto.

Si solo desea un video compuesto, como en el video que publicó. Hay muchos ejemplos por ahí. Diablos, mira la implementación de Woz del Apple II. :)

¿@Leon ha dejado un comentario? Si es así no puedo verlo.
Lo borré. Sugerí usar un FPGA para implementar una CPU simple. Lo hice hace algunos años con un diseño de un libro, escrito en VHDL, que modifiqué para mi hardware.
Ahh ok, entonces es por eso que puedo verlo.

Parece que no está buscando hacer una GPU (en el sentido de 3D y sombreado y todo eso) tanto como un generador de video. Muchas placas de evaluación de FPGA tienen un conector para un monitor VGA u otro tipo y proyectos de muestra del fabricante o de otros usuarios para mostrar cosas en ese monitor. También hay algunas placas con pantallas LCD incorporadas, pero tienden a estar en la clase de $ 300 y más, mientras que las básicas que pueden controlar un monitor estándar cuestan $ 60-120.

La mayoría de los FGPA no tienen suficiente memoria interna para hacer más que una pequeña pantalla, pero muchas de las placas tienen memorias externas con más capacidad. Muchos de ellos manejan monitores VGA analógicos digitalmente, es decir, RG y B están completamente encendidos o apagados, aunque algunos le brindan dos niveles y probablemente pueda encontrar uno con un DAC de video o un conector para una interfaz de monitor digital.