1 puntos por GN⁺ 2024-03-28 | 1 comentarios | Compartir por WhatsApp
  • 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

 
GN⁺ 2024-03-28
Opiniones en Hacker News
  • Soy el creador de este proyecto. Esperaba que se difundiera después de que el sitio tuviera un poco más de contenido, pero así salieron las cosas :)
    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.
    • He venido siguiendo actualizaciones semirregulares en Discord, y es genial que el proyecto haya llegado hasta aquí. También me frustró un poco que mi propio proyecto con FPGA avanzara relativamente poco en el mismo periodo, y estaba esperando que se publicara algo por escrito.
    • Busqué Xilinx Zynq UltraScale+ y parece bastante caro. Mucha gente gasta miles de dólares o más en sus hobbies, así que si tienes el dinero no es problema, pero me da curiosidad si este es el hardware objetivo final del proyecto o si estás pensando en algo más allá.
    • Me da curiosidad cuánto depende de bloques hard IP. ¿Se puede portar a FPGAs de otros proveedores, como Lattice ECP5? También me gustaría saber si implementaste PCIe directamente en HDL o si usaste un bloque IP específico del proveedor. Sería bueno que compartieras también estadísticas de uso de recursos.
    • En el artículo sobre la Texture Unit, la tabla ROM para los offsets de dirección de los niveles mip parece ocupar bastante espacio. Me pregunto si consideraste incluir la dirección base de cada mip como parte de la especificación de la textura.
    • Si quisiera intentar algo parecido, ¿qué libros recomendarías? Por ejemplo, necesito material para aprender diseño de placas PCB para hardware que se conecta por PCIe.
  • El impacto de la serie de la computadora en protoboard de Ben Eater en la electrónica hobbyista es sorprendente. A mí también me motivó de forma parecida a intentar diseñar mi propio CPU “retro”.
    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.
    • Este proyecto también empezó exactamente ahí. Después de construir la computadora de 8 bits en protoboard de Ben Eater, empecé a investigar qué haría falta para construir algo más interesante.
      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.
    • Los registros se pueden esquivar usando la pila o la memoria, y la división se puede implementar como una función simple. Parte de la diversión de trabajar a ese nivel es eso.
      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
    • Iba a recomendar el Parallax Propeller, especialmente el primer modelo que viene en formato DIP, pero en realidad es mucho más complejo de programar y bastante más potente. A esa altura conviene mirar un ESP32, y al final termina siendo “usar simplemente un MCU” :)
      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.
    • No se me ocurren muchos otros casos tan populares como este. Estuvo un tiempo con poca actividad, pero recientemente volvió a publicar videos con cierta regularidad, y su audiencia está en los primeros cientos de miles.
      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.
    • Mientras investigaba gráficos en MCU, me decepcionó descubrir que la pequeña GPU NeoChrom incluida en componentes STM32 modernos no está completamente documentada. Históricamente, STM32 no solía meter cajas negras dentro del chip, así que probablemente sea un bloque IP licenciado a un tercero.
  • Genial. El blog de hello me ayudó a entender la intención del creador: https://www.furygpu.com/blog/hello
    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.
    • Agregar las funciones necesarias para soporte básico de D3D requiere bastante esfuerzo, y estoy evaluando qué es realmente posible en términos de rendimiento. Lamentablemente, las perspectivas no parecen buenas.
      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.
  • Es el proyecto de mis sueñ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

  • Probablemente ya lo sepas, pero para otras personas que tengan curiosidad por este camino: para este tipo de uso definitivamente vale la pena limitarse a FPGA que tengan transceptores dedicados de alto ancho de banda
    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
  • El pipeline parece retro, pero es muchísimo mejor que no tener nada
    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
    • También existe una GPU de un tipo parecido
      https://github.com/asicguy/gplgpu
    • Claro, depende de la definición de “abierto”. Hasta donde sé, no hay un toolchain open source para FPGA relativamente recientes, así que para hacer modificaciones reales sigues atado a herramientas propietarias, probablemente de pago. Si necesitas algo más grande que un iCE40 UP5k, casi no hay alternativa
    • Ticket2Ride Number9 fue una GPU de función fija de fines de los 90, y fue liberada completamente como open source bajo GPL
    • Depende de qué consideres una “GPU”
      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
    • También está Nyuzi, que se enfoca más en una GPU de propósito general: https://github.com/jbush001/NyuziProcessor. Aunque su creador también experimentó con ejecutar gráficos 3D
  • No puedo creer que esto sea lo más cercano que tenemos a una GPU pequeña e independiente. No hay algo como una GPU en formato M.2
    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...
    • Existe al menos una GPU M.2 de Asrock Rack basada en el controlador Silicon Motion SM750. También hay productos parecidos en formato mPCIe
      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
    • ¿Qué tal las GPU MXM que antes se usaban en laptops gamer? Sé que el estándar es muy de nicho y caro. En eBay una 3080M usada ronda los 400 dólares, pero existen y pueden convertirse a PCIe y luego conectarse también a M.2
    • Quizá tenga muy poca potencia, pero también existe esto: https://www.matrixorbital.com/ftdi-eve
  • Es un proyecto muy genial, y me alegra ver más trabajo en este campo
    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/
  • Parece un logro realmente impresionante. Me gustaría ver fotos del dispositivo real. También me confunde un poco qué módulo FPGA usa
    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

  • No es elegir entre un SoC ARM y un FPGA Xilinx: es un chip híbrido. Es una estructura que combina un FPGA con un SoC tradicional, así que no hace falta meter un MCU de softcore que consuma valiosos recursos del FPGA solo para tareas básicas de administración
  • Xilinx no revela el número de parte exacto del FPGA usado en el SoM Kria. Sin embargo, según las especificaciones públicas parece coincidir con los dispositivos ZU3EG-UBVA530-2L y ZU5EV-SFVC784-2L[1], y solo este último tiene soporte PCIe.
    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-...
  • Dijeron que soporta funciones de hardware equivalentes a las de una tarjeta gráfica de gama alta de mediados de los 90, y como parece que nadie hizo todavía esta pregunta, quiero hacerla: ¿qué tan buena es la compatibilidad VGA? Por ejemplo, ¿se podría enchufar en cualquier PC con ranura PCIe, arrancar DOS y jugar DOOM?
  • Me gustaría que el creador explique en detalle la implementación de la interfaz PCIe. Probablemente nunca haga hardware de ese nivel, pero creo que vale la pena mirar por dentro PCIe como cultura general
    • La próxima entrada del blog tratará exactamente ese tema. Parece que será una serie de varias partes: la primera sobre el esquemático/layout del PCB, la siguiente sobre la interfaz del FPGA y las pruebas, y luego el driver de Windows
    • El FPGA que se está usando tiene PCIe nativo, así que normalmente en esta parte solo se obtiene una interfaz hacia un bloque IP propietario del proveedor. El estado de las interfaces abiertas en el mundo FPGA es desastroso. Lo mejor que vi completamente open source fue algo del nivel de una MAC gigabit
    • Uso https://github.com/alexforencich/verilog-pcie sobre el core de IP hard PCIe de Xilinx. Ese core proporciona todo lo que está por debajo de la capa de transacción