¿Existe un proyecto de tarjeta gráfica vectorial basada en FPGA?

He estado jugando con proyectos VGA como mi último interés. Tengo un FPGA Xilinx Spartan 3E 250K , que tiene muy poca memoria RAM para un búfer de cuadro completo de 640x480. Entonces, estoy buscando hacer las cosas más "interesantes". Es decir, optando por un enfoque vectorial en lugar de un mapa de bits. Sin embargo, es un poco alucinante en cuanto a cómo hacerlo. ¿Existen tarjetas gráficas VGA conocidas y de código abierto basadas en vectores?

No voy a usar esto en ningún tipo de escenario de "producción", por lo que realmente no me importa si solo puede renderizar de manera efectiva a 1 fps o algo así. Estoy viendo una idea de proyecto interesante.

Si no los conoce, vale la pena buscar ideas en fpgaarcade.com y opencores.org . Creo que necesitas registrarte para el segundo, pero no envían spam ni nada.

Respuestas (1)

Por favor, por favor, no tomes lo que voy a decir como algo personal. Creo que su pregunta es una que muchas personas probablemente se han preguntado en un momento u otro. Incluso voté a favor de la pregunta. Desafortunadamente, la respuesta es "no funciona de esa manera". Y no hay una buena manera de responder a su pregunta sin posiblemente hacerlo sentir mal por hacerla, lo cual es una pena porque creo que hay información útil en la respuesta. Así que tengan paciencia conmigo y entiendan que mi motivación es explicar cómo funciona esto y no hacerles sentir mal.

Las pantallas modernas (televisores, LCD, plasma, la mayoría de los CRT) son dispositivos basados ​​en tramas. Es decir, vuelven a dibujar la pantalla una línea de escaneo a la vez. Las interfaces de video utilizadas para hablar con estas pantallas se basan en una interfaz de trama. NTSC, VGA, HDMI, etc. son todas tecnologías de visualización de trama.

Hace años, principalmente en los años 70 y principios de los 80, había algunas pantallas de vectores reales. En lugar de dibujar las cosas una línea de escaneo a la vez, en realidad trazaron la forma de los objetos. Los mejores ejemplos de esto son los o-scopios analógicos y los juegos de arcade Asteroids y Battlezone. Se utilizaron muy pocas pantallas de vectores de color, y el mejor ejemplo de ello es el juego de arcade Tempest. Una forma diferente de visualización de vectores son los sistemas utilizados para espectáculos de luz láser.

La interfaz eléctrica de una pantalla vectorial tiene señales para la ubicación X e Y del haz, la intensidad y, a veces, el color. Esto es muy diferente a la interfaz de una pantalla de trama.

La tecnología CRT más antigua podría usarse para pantallas vectoriales o de trama, pero las pantallas LCD, de plasma, OLED, etc. están todas fundamentalmente basadas en tramas y no se pueden usar fácilmente en un modo de tipo vectorial.

El problema con su pregunta es que está preguntando acerca de una "tarjeta gráfica VGA basada en vectores". "Basado en vectores" no va con VGA. VGA es un estándar de visualización y una interfaz basados ​​en ráster, mientras que el vector no lo es. No se pueden mezclar los dos, ya que son sistemas diferentes.

Es posible hacer una tarjeta de gráficos vectoriales basada en un FPGA, pero no puede conectarla a un monitor de tipo VGA sin hacer una conversión de vector a ráster en el FPGA, y eso requiere tanta RAM o más que un ráster estándar. tarjeta grafica. Podría obtener una pantalla vectorial, pero casi se han ido con la desaparición del CRT.

La forma más fácil de obtener una pantalla vectorial en estos días es obtener un o-scopio que tenga un modo X/Y. De hecho, hay muchos proyectos en la web que usan un viejo oscopio con tubo CRT como pantalla para algo. Aquí hay un proyecto que usa uno para hacer un reloj . Y aquí hay otro . Hay docenas de otros proyectos similares en la web.

Si bien son interesantes, estos proyectos son poco más que novedades. Son novedades geniales, pero solo novedades. Y ninguno de ellos se acerca a la calidad de visualización de una tarjeta VGA normal.

Una solución alternativa es simplemente obtener un FPGA con algo de RAM externa. Hay muchas maneras de hacer esto, pero la forma más fácil y sencilla es usar una placa basada en Xilinx Spartan-6 con SDRAM DDR2 externa. Hay varias placas de desarrollo FPGA en el mercado que tienen ambos chips que funcionarán. Algunos de ellos incluso tienen interfaces VGA también.

No usaría SRAM externa. La SRAM, especialmente la SRAM asíncrona, también tendrá una interfaz lenta y el tamaño de la memoria será limitado. No es imposible usar SRAM, pero no es más fácil usar SRAM que DDR2 SDRAM en un Spartan-6.

Tampoco usaría un Spartan-3. La interfaz DDR SDRAM del S3 no es muy buena y es difícil lograr que la sincronización de la señal funcione de manera confiable. El Spartan-6 tiene una "macro dura" para la interfaz DDR2, lo que hace que todo sea mucho más fácil. El S6 también tiene más RAM interna para búferes, FIFO, etc. Xilinx tiene un buen núcleo de "Generador de interfaz de memoria" que hace que la interfaz de varios fragmentos diferentes de lógica con la SDRAM DDR2 sea mucho más fácil (con múltiples puertos de lectura/escritura también).

En cuanto a un núcleo de gráficos vectoriales de código abierto, no conozco ninguno. Eso no quiere decir que no haya uno, solo que no he visto uno. Pero también dudo que veas uno que sea muy bueno. Simplemente no hay mucha necesidad de uno ya que las pantallas son algo raras y limitadas. Si encuentra uno, es probable que sea bastante especializado (solo muestra un reloj).

Consiga una placa FPGA con Spartan-6, DDR2 SDRAM y un puerto VGA y será mucho más feliz.

¿No era Tempest una pantalla en blanco y negro con una calcomanía translúcida en la pantalla para que pareciera multicolor?
@ThePhoton No. Hubo algunas versiones de Battlezone así, pero no Tempest. Si miras las fotos de Tempest, verás que había "enemigos" multicolores moviéndose en la pantalla de formas que posiblemente no funcionarían con una calcomanía translúcida fija.
Algunas notas: 1. Spartan 3 es justo lo que tengo a mano. No actualizaré por un tiempo. 2. No tengo SDRAM, así que estoy limitado a BRAM :( 3. Mi punto sobre una pantalla "vectorial" es dibujar directamente como "barridos de haz", por así decirlo, y no tener un búfer de cuadros. Sé que no es una pantalla vectorial real, pero parece algo interesante de intentar
@Earlz No tendrá suficiente velocidad de procesamiento para manejar básicamente dibujar cosas mientras el rayo está escaneando. Si lo piensa, tiene un número limitado de relojes por píxel y un número variable de líneas en la memoria. Para cada píxel, debe verificar cada vector en busca de una intersección. El número máximo de vectores será el número de relojes por píxel. VGA tiene un reloj de píxeles de unos 25 MHz. Si su reloj principal es de 125 MHz, entonces tiene 5 relojes/píxel. Entonces puede tener 5 vectores en su búfer en cualquier momento. Eso no es muy interesante de ver.
@David Kessner, ¿es eso cierto con un FPGA? Presumiblemente, construiría un "circuito" para escanear cada píxel en la pantalla y luego un "circuito" para contener cada vector y que luego cada vector decidiría en paralelo si el píxel actualmente escaneado debe iluminarse. Entonces, el límite es la cantidad de comparadores de ubicación de vectores que puede colocar en el fpga, nada que ver con los ciclos de reloj.
@JohnBurton Aquí está el problema: no puede colocar suficientes de estos circuitos en un Spartan-3 para hacer una cantidad útil de vectores. Si tiene suerte, obtendrá el número total de vectores hasta alrededor de cien. Los dígitos 0-9, en promedio, requieren 5 vectores para dibujarse. Así que podrías poner quizás 20 dígitos en la pantalla en cualquier momento. Eso no es útil.
Vale, eso tiene sentido. Habría esperado que pudieras haber obtenido más que eso, pero supongo que son bastante "anchos" en términos de número de bits, por lo que tienes razón.
Buenos puntos. No esperaba que fuera capaz de grandes hazañas, pero eso es bastante limitado.
@DavidKessner: Estás pensando de una manera muy bruta. No todos los vectores intersecarán cada línea de escaneo, por lo que si realiza un seguimiento de los cuadros delimitadores de vectores, debería poder manejar "alrededor de cien" vectores por línea de escaneo . Y hay muchas formas de colocar mucha información en una pantalla VGA sin un búfer de cuadro de gráficos completo... con una arquitectura de memoria de dos niveles, podría hacer un generador de caracteres básico para (mucho) texto, o un sprite -sistema de gráficos basado.
@DaveTweed Hay muchas formas de optimizar las cosas, pero siempre habrá limitaciones. Para realizar un seguimiento adecuado de los cuadros delimitadores de vectores, debe organizar la memoria de vectores de tal manera que sepa a priori qué vectores se cruzan con la línea de exploración actual. En el peor de los casos, esta memoria es en realidad más grande que el búfer de cuadro VGA normal equivalente. En mi opinión, la mejor manera de minimizar los requisitos de BRAM es usar un generador de personajes + Sprites. El Char RAM+ROM requiere 32kbits, dejando suficiente espacio para los sprites.
Una vez miré el uso de un búfer de marco codificado de longitud de ejecución para una pequeña afición que nunca llegó a ninguna parte. Para las pantallas que quería calculé que podía almacenar suficientes píxeles. El problema era que era MUY difícil actualizar la pantalla, especialmente en un sistema FPGA sin una CPU que yo quería, por lo que no es práctico, pero podría haber algún esquema de compresión que pudiera usar.