- Es una unidad de procesamiento gráfico personalizada, creada directamente desde el hardware hasta los drivers, para usarse como una GPU real en PCs modernas
- La implementación principal se realizó sobre un FPGA Xilinx Zynq UltraScale+ y está montada en una PCB personalizada
- Se conecta a la computadora host mediante PCIe, por lo que no funciona como un experimento de software, sino como una GPU de hardware real
- Sus funciones compatibles están ajustadas al nivel de las tarjetas gráficas avanzadas de mediados de la década de 1990, con el objetivo de renderizar juegos de esa época
- Incluye incluso una pila moderna de drivers para Windows, lo que permite renderizar juegos reales de esa época a tasas de cuadros superiores al tiempo real
Configuración de hardware
- FuryGpu es una GPU completamente personalizada, creada desde cero para usarse en computadoras modernas
- La lógica de procesamiento gráfico está implementada sobre un FPGA Xilinx Zynq UltraScale+
- Está montada en una PCB personalizada y se conecta a la computadora host mediante PCIe
Funciones gráficas y drivers
- Las funciones de hardware admiten un nivel equivalente al de las tarjetas gráficas avanzadas de mediados de la década de 1990
- Se ofrece junto con una pila moderna de drivers de software para Windows, lo que permite usarla como GPU en un entorno real
Tareas que puede ejecutar
- FuryGpu puede renderizar juegos reales de esa época
- Su rendimiento de renderizado puede alcanzar tasas de cuadros superiores al tiempo real
1 comentarios
Opiniones en Hacker News
Para responder la pregunta que recibo con más frecuencia: en algún momento pienso publicar todo el stack como open source. Eso incluye esquemáticos/layout de la PCB, todo el HDL, el driver WDDM para Windows, el driver de runtime de la API, e incluso Quake portado para usar esa API.
Pero primero tengo que resolver temas legales relacionados con mi trabajo y decidir detalles como la licencia. No es mi empleo principal, pero es un campo lo bastante cercano como para tener cuidado.
El primer commit de este proyecto fue el 22 de agosto de 2021, y llevo trabajando en él poco más de dos años y medio. No escribí durante el proceso, pero en la playlist de FuryGpu en YouTube (https://www.youtube.com/playlist?list=PL4FPA1MeZF440A9CFfMJ7...) hay bastantes videos donde se puede ver, a grandes rasgos, el avance.
Las próximas entradas del blog tratarán sobre la interfaz PCIe, y probablemente será una serie de varias partes que empiece con el esquemático/layout de la PCB y continúe con el diseño en FPGA y el driver para Windows. Con solo escribir el artículo sobre la Texture Unit, terminé respetando aún más a quienes escriben este tipo de artículos técnicos con una cadencia constante.
Anhelo algo que sea fácil de conectar y usar como un 6502, pero con unos cuantos registros más y algunas funciones adicionales como división por hardware; aun así, es una tarea realmente nada sencilla.
Al final uno vuelve a “mejor uso un MCU y listo”, y luego se topa con el problema de generar gráficos.
Como con compuertas lógicas discretas es difícil hacer mucho procesamiento de alta velocidad, pensé que sería mucho más interesante aprender qué se puede hacer con una FPGA.
Para los gráficos, al principio se puede empezar con salida serial. Es una forma de abstraer el problema hasta que estés listo para abordarlo. Si exprimes al máximo un Arduino, puedes convertirlo en una tarjeta gráfica VGA muy básica [1]. ESP32 to VGA es más fácil y también ofrece teclado y mouse [2].
[1] https://www.instructables.com/Arduino-Basic-PC-With-VGA-Outp...
[2] https://www.aliexpress.us/item/1005006222846299.html
La salida de video es un gran problema por el ancho de banda necesario para la salida digital. Con salida compuesta o VGA quizá todavía se pueda lograr usando chips fáciles de conseguir. El Commander X16 reciente eligió una FPGA para resolver este problema.
Supongo que en realidad menos de 100 mil personas ven los videos hasta el final, y de ellas aún menos intentan hacer algo por su cuenta. Para la época actual, la electrónica hobbyista se siente sorprendentemente pequeña.
Por lo que leí, ante todo es un proyecto hobby hecho por diversión, y parece que piensa escribir mucho sobre cómo lo construyó.
Me impresiona especialmente que funcione todo el stack. El driver de Windows implementa una API gráfica personalizada, y Quake corre sobre ella. Es una lástima que no haya soporte para DX/GL, pero se entiende perfectamente por qué eligió el camino de una API personalizada.
Me pregunto si publicará el diseño como open source.
No es simplemente un problema de “shaders”: incluso el administrador de ventanas del sistema operativo tiene muchos requisitos para poder funcionar. Los actores habituales de este campo, es decir, AMD, Nvidia, Intel, Imagination, etc., han construido esto de forma incremental sobre tecnologías desarrolladas durante más de 20 años.
Durante el último año estuve trabajando en una GPU centrada en 2D para microcontroladores con fuertes restricciones de entrada/salida (https://github.com/KallDrexx/microgpu). Hice que pudiera renderizar interfaces de usuario en pantallas grandes incluso con dispositivos SPI lentos, y el trabajo fue muy interesante
Pero al ver las limitaciones del pipeline del procesador, venía pensando que con un FPGA podría hacerlo más rápido. Hace poco conseguí algunos FPGA de bajo costo y empecé a aprender para intentar convertir el microgpu basado en ESP32 a uno basado en FPGA
No sé si, por las limitaciones de tiempo libre y por mis hijos, podré llegar a este nivel, pero me gustaría lograr aunque sea una centésima parte de esto
Incluso una señal RGB 1080p 60Hz “básica” requiere procesamiento de señales de alta frecuencia que es muy difícil de manejar solo con lógica FPGA pura
Casi no hay GPU de hardware abierto de las que valga la pena hablar. Dependerá de la licencia, pero no pude encontrar información, y esto podría ser el primer caso y el punto de partida para mucho más trabajo
https://github.com/asicguy/gplgpu
https://github.com/schlae/graphics-gremlin es un adaptador compatible con MDA/CGA
https://github.com/OmarMongy/VGA es un núcleo VGA
https://github.com/archlabo/Frix es un SoC completo compatible con IBM PC que incluye VGA
Lo único que quiero es una GPU M.2 independiente. Puede tener un rendimiento modesto, con que esté al nivel de una GPU integrada como Intel UHD Graphics, AMD Radeon o Qualcomm Adreno alcanza
Tengo una idea para un producto embebido pequeño que necesita mucha computación y redes, pero muy poca capacidad gráfica. El NXP Layerscape LX2160A [1] habría sido casi perfecto, pero tuve que descartarlo porque no tiene GPU integrada. Solo necesito una GPU pequeña
[1]: https://www.nxp.com/products/processors-and-microcontrollers...
Su rendimiento no se acerca para nada al de una GPU integrada moderna. Una GPU integrada puede aprovechar la memoria del sistema, cachés y el presupuesto de energía, mientras que un dispositivo M.2 simple no tiene nada de eso. Incluso una GPU PCIe de gama baja, es decir, una tarjeta de una sola ranura de media longitud/media altura, difícilmente supere a una buena GPU integrada, y solo tiene sentido cuando realmente necesitas funciones básicas de pantalla
Algo relacionado para mirar es el proyecto Vortex de Georgia Tech[1]. Parece un enfoque orientado al futuro, en vez de repetir el pasado de función fija del diseño de GPU. En esencia es una computadora altamente paralelizada basada en RISC-V, con extensiones para manejar mejor cargas de trabajo de GPU
Las placas para ejecutarlo cuestan miles de dólares, así que no es muy amigable para hobbistas, pero sin duda es más accesible que un desarrollo cerrado y propietario. También salió la versión 2.0 hace unos meses
[1]: https://vortex.cc.gatech.edu/
En el blog habla de un Xilinx Kria SoM, pero si sigo el enlace y miro las especificaciones del módulo, parece que trae un SoC ARM, no un FPGA Xilinx. Quizá me estoy perdiendo algo porque no estoy familiarizado con el mundo FPGA
https://www.amd.com/en/products/system-on-modules/kria/k26/k...
Como dije en otra parte de este hilo, el SoM Kria tiene una estructura que combina la lógica FPGA y un núcleo ARM hard encargado del control. Además de que en ese momento se podía conseguir y de que la placa de desarrollo Kria era realmente barata, unos 350 dólares, estos dispositivos incluyen cosas como IP hard de DisplayPort conectada al núcleo ARM, lo que permite delegar al firmware tareas como la salida de video y el audio.
La versión anterior de este proyecto corría en un Zynq 7020, y en ese caso había que escribir directamente la parte relacionada con HDMI. No es extremadamente complejo, pero ocupa bastante lógica, y si se lo hace configurable se vuelve mucho más complicado
Diseñar y hacer el bring-up de una placa FPGA, como en la entrada del blog, ya es una barrera bastante alta. Ojalá algún día se publiquen los esquemáticos y el código fuente.
[1] https://docs.amd.com/v/u/en-US/zynq-ultrascale-plus-product-...