TinyGPU v2.0 funciona en silicio, pero su afirmación de ser la GPU más pequeña afronta una prueba mayor

Tom Hardware informa que TinyGPU v2.0 ya funciona en silicio físico, convirtiendo aproximadamente 240.000 transistores en un procesador gráfico 3D operativo. El diseñador Pongsagon Vichit mostró el chip generando gráficos tras su proceso de fabricación con Tiny Tapeout. Esto transforma el proyecto de un experimento con FPGA en un circuito integrado específico de aplicación fabricado, o ASIC.

El resultado importa porque la fabricación revela problemas que la simulación por software y las pruebas con FPGA pueden ocultar. El comportamiento del reloj, la temporización de señales, el acceso a memoria y la integración a nivel de placa deben resistir el contacto con hardware físico. El video de Vichit indica que la canalización esencial funciona, aunque la demostración disponible no responde a todas las preguntas sobre rendimiento o fiabilidad.

No se trata de un rival en miniatura para Nvidia, AMD o Intel. TinyGPU v2.0 renderiza escenas deliberadamente modestas, a baja resolución y con profundidad de color limitada. Su verdadero oponente es la distancia entre un interesante prototipo de FPGA y silicio funcional reproducible. Superar esa distancia otorga al proyecto un valor técnico que va mucho más allá de su tasa de fotogramas.

La siguiente cuestión se refiere a TinyGPU v3.0. Vichit está desarrollando un diseño más programable, con funciones de pixel shader y correcciones para limitaciones conocidas de v2.0. Esa hoja de ruta eleva lo que está en juego porque cada capacidad añadida consume lógica, ancho de banda de memoria y esfuerzo de verificación.

Tom Hardware afirma que TinyGPU superó su prueba de silicio

El cambio importante no es que TinyGPU muestre gráficos 3D simples. Es que el chip fabricado supuestamente hace lo que prometía su diseño digital.

Vichit probó anteriormente TinyGPU v2.0 en una placa FPGA Basys3. Una FPGA es un chip configurable que permite a los diseñadores probar lógica de hardware antes de comprometerse con una disposición fija. Esa etapa mostró que la arquitectura podía renderizar modelos, aceptar entradas de un controlador y manejar una pantalla VGA.

Fabricar un ASIC elimina esa flexibilidad. La lógica se convierte en una disposición física de transistores y cables. Un fallo de diseño no puede corregirse cargando una nueva configuración en el mismo chip. Los errores importantes suelen requerir otro proceso de fabricación.

Según el informe de prueba de silicio del 4 de agosto, el silicio TinyGPU v2.0 recibido produjo gráficos reales durante las pruebas. El informe describe el resultado como una demostración exitosa en condiciones reales tras el proceso de producción de Tiny Tapeout.

Esa evidencia respalda una afirmación más limitada que una calificación completa de producto. Un video puede mostrar que las funciones principales operan en una configuración probada. No establece el rendimiento de fabricación, la tolerancia de voltaje, la estabilidad durante largos periodos ni el desempeño en múltiples muestras.

Estas distinciones importan en la cobertura de semiconductores. Los ingenieros suelen llamar silicio A0 a la primera versión recibida. Obtener resultados útiles de A0 es significativo porque muchos errores de hardware se vuelven costosos después del tapeout. El tapeout es el momento en que un diseño de chip terminado entra en fabricación.

La canalización demostrada supuestamente gestiona transformación, iluminación, rasterización y salida de pantalla. La transformación convierte las coordenadas del modelo en posiciones para la pantalla. La rasterización determina qué píxeles pertenecen a cada triángulo. La iluminación ajusta el color visible de una superficie mediante la dirección de luz seleccionada.

La documentación del proyecto del diseñador describe una arquitectura de 25 MHz que utiliza unos 240.000 transistores en su forma fabricada. Admite modelos de hasta 1.000 triángulos, aunque la velocidad real depende de la complejidad de la escena y de las funciones activadas.

El objetivo de pantalla documentado es de 320 por 240 píxeles con color de 4 bits. El color de cuatro bits ofrece 16 valores de color posibles dentro del esquema de paleta correspondiente. Es una limitación extrema frente a los gráficos modernos, pero suficiente para mostrar objetos sombreados o texturizados reconocibles.

El proyecto también depende de memoria QSPI externa. QSPI es una interfaz serie que transfiere datos a través de varias líneas de señal. TinyGPU utiliza ese hardware externo para datos de modelos, almacenamiento de fotogramas e información de profundidad que consumirían demasiado espacio en el chip.

La configuración de Vichit incluye un módulo de salida VGA, hardware QSPI, una interfaz de gamepad y un controlador SNES. Los usuarios pueden rotar modelos, cambiar su escala o ajustar la luz direccional. Estos controles hacen que la demostración sea interactiva, en lugar de una animación fija grabada en el circuito.

Tom Hardware cubrió anteriormente el diseño antes de su fabricación, cuando la estimación de transistores reportada se acercaba más a los 200.000. La cifra actual de 240.000 refleja la implementación fabricada descrita por Vichit. Las estimaciones pueden cambiar a medida que la síntesis y el diseño físico traducen la lógica fuente en celdas estándar reales.

Por tanto, el resultado despeja una incertidumbre mientras deja varias otras abiertas. TinyGPU v2.0 ya no es solo una afirmación basada en simulación o FPGA. Supuestamente es silicio funcional, pero sigue siendo un chip experimental, no una GPU comercial cualificada.

Una GPU de 240.000 transistores es en realidad un estudio de restricciones

TinyGPU se vuelve interesante cuando sus limitaciones se tratan como requisitos de diseño, no como comparaciones incómodas con tarjetas gráficas de escritorio.

Una GPU discreta moderna contiene miles de millones de transistores, caché extensa, bloques de cómputo especializados, motores de video e interfaces de memoria de gran tamaño. TinyGPU v2.0 no tiene nada de esa escala. Comparar su rendimiento principal revelaría poco sobre el problema de ingeniería que Vichit decidió resolver.

Su problema es la compresión. La arquitectura debe conservar suficiente de una canalización gráfica convencional para transformar y dibujar geometría 3D dentro de un presupuesto lógico diminuto. Cada registro, multiplicador, búfer y estado de control compite por la misma área limitada de silicio.

La aritmética de punto fijo ayuda a controlar ese presupuesto. Los números de punto fijo reservan bits predeterminados para sus partes enteras y fraccionarias. Requieren menos circuitería que las operaciones generales de punto flotante, pero los diseñadores deben gestionar cuidadosamente el rango y la precisión.

La canalización también utiliza sombreado plano con una luz direccional dinámica. El sombreado plano asigna un valor de iluminación uniforme a un triángulo, en lugar de calcular cambios suaves para cada vértice o píxel. Esa elección reduce el cómputo y conserva una forma 3D visible.

La eliminación de caras traseras descarta los triángulos orientados en dirección opuesta a la cámara. Normalmente esas superficies no pueden verse, por lo que omitirlas ahorra trabajo de rasterización. Es una técnica gráfica estándar cuyo beneficio resulta especialmente importante con un presupuesto reducido de transistores y reloj.

Un búfer de profundidad de 8 bits registra qué superficie debe aparecer delante en cada posición. Sin pruebas de profundidad, los triángulos dibujados posteriormente podrían cubrir de forma incorrecta la geometría más cercana. La precisión limitada se adapta a estas escenas compactas, aunque sería inadecuada para muchos entornos mayores.

El doble búfer de 4 bits mantiene superficies separadas para el dibujo y la visualización. Se puede mostrar un búfer mientras se prepara el siguiente fotograma. Intercambiarlos reduce el tearing visible, donde partes de dos fotogramas aparecen juntas durante una actualización.

Estas funciones hacen que TinyGPU v2.0 sea más que un generador de patrones cableado. El chip acepta datos de modelos y procesa geometría a través de etapas reconocibles. Sin embargo, sigue siendo un diseño de función fija, con límites estrictos sobre el tamaño de las escenas, la calidad de salida y los efectos admitidos.

El rango de tasa de fotogramas reportado alcanza aproximadamente entre 7,5 y 15 fotogramas por segundo en escenas adecuadas. El repositorio también documenta un ejemplo texturizado de 1.000 triángulos a 6,5 FPS. Estas cifras describen cargas de trabajo diferentes, por lo que no deben tratarse como referencias universales contradictorias.

La tasa de fotogramas depende del número de triángulos, el área visible, el trabajo de texturas, los retrasos de memoria y otros detalles de la escena. Un objeto pequeño puede requerir menos procesamiento de píxeles que una geometría que cubre la mayor parte de la pantalla. Cualquier comparación seria necesita modelos, ajustes, relojes y condiciones de salida idénticos.

Ese contexto de referencia sigue incompleto. El video de silicio confirma un funcionamiento visible, pero no proporciona un conjunto amplio de pruebas de rendimiento. Tampoco establece si cada función documentada se ejercitó durante la prueba grabada.

Aquí es donde la etiqueta de GPU más pequeña exige cautela. «GPU» no tiene un único umbral de transistores, y los proyectos independientes de aficionados implementan distintos subconjuntos de funcionalidad gráfica. Algunos dibujan solo primitivas básicas, mientras que otros incluyen transformación, texturas, iluminación o etapas programables.

Por tanto, el título es una abreviatura útil, no un premio estandarizado. La distinción más defendible de TinyGPU es su combinación de silicio fabricado y una canalización 3D compacta y autónoma. Los lectores deberían evaluar las funciones documentadas en lugar de depender únicamente del superlativo.

Esa combinación también crea valor educativo. El código fuente expone la canalización en Verilog, un lenguaje de descripción de hardware utilizado para definir circuitos digitales. Los desarrolladores pueden examinar cómo los conceptos gráficos se convierten en máquinas de estados, unidades aritméticas y transacciones de memoria.

Para los estudiantes, esto convierte una salida visual familiar en una puerta de entrada al diseño de chips. Un modelo giratorio es más fácil de interpretar que una forma de onda abstracta. Sin embargo, cada fotograma visible sigue dependiendo de las mismas disciplinas de temporización, verificación y diseño físico utilizadas en chips más grandes.

Tiny Tapeout convierte la brecha de los prototipos en la competencia principal

La victoria central de TinyGPU es sobre la barrera de costes y coordinación que normalmente mantiene a los pequeños proyectos de hardware alejados del silicio fabricado.

La fabricación de chips suele favorecer a organizaciones que pueden llenar un troquel grande y gestionar flujos de ingeniería especializados. Un diseñador individual rara vez necesita una oblea completa. Incluso un circuito experimental diminuto implica requisitos de preparación, encapsulado, validación y fabricación.

El programa de obleas compartidas cambia esa ecuación al colocar muchos diseños pequeños en el mismo chip fabricado. Cada participante recibe un área de bloque definida. La infraestructura compartida gestiona las interfaces comunes, la lógica de selección y el acceso mediante una placa de demostración.

Este modelo se parece al transporte compartido. Cada diseño ocupa solo una parte del vehículo disponible, de modo que ningún participante debe financiar el viaje completo. La analogía es imperfecta, pero explica por qué las obleas con múltiples proyectos se han vuelto valiosas para la educación y la experimentación.

TinyGPU v2.0 utiliza una asignación de 4 por 4, equivalente a 16 bloques de Tiny Tapeout. Es un proyecto grande dentro del modelo compacto de diseño de la plataforma. La asignación sigue obligando a Vichit a tomar decisiones que un equipo de GPU de escritorio resolvería con muchísimo más silicio.

El programa también impone límites de interfaz. La memoria externa, la salida de video y la entrada del controlador deben pasar por los pines disponibles y las placas complementarias admitidas. Estas restricciones dan forma a la arquitectura tan directamente como el número de transistores.

El proceso comienza mucho antes de la fabricación. Vichit debe describir el circuito en Verilog sintetizable, es decir, código que las herramientas pueden convertir en lógica real. Las comprobaciones automatizadas verifican después las interfaces, las hipótesis de temporización y los requisitos de diseño físico.

La síntesis convierte el diseño en una biblioteca de celdas estándar. La colocación asigna ubicaciones físicas a esas celdas. El enrutamiento las conecta con trazas metálicas respetando las reglas de fabricación. El diseño completado se une después a otros proyectos en el tapeout compartido.

La simulación sigue siendo esencial durante todo ese flujo. Un banco de pruebas proporciona entradas y verifica las salidas esperadas antes de la fabricación. El prototipado con FPGA añade otra capa al ejecutar una lógica similar en hardware reconfigurable con periféricos reales.

Ninguno de los dos pasos predice perfectamente el silicio. El enrutamiento, los bloques de memoria y la temporización de una FPGA difieren de los de un proceso ASIC. Los chips físicos también introducen comportamientos de reloj, reinicio, alimentación e integridad de señal que las pruebas simplificadas pueden pasar por alto.

Por eso, una salida funcional después de la fabricación tiene más peso que otro vídeo de FPGA. El resultado indica que el flujo de herramientas, la plataforma compartida, la conexión de la placa, la memoria externa y la lógica gráfica funcionaron conjuntamente. Un fallo en cualquiera de los enlaces críticos podría haber impedido mostrar un fotograma visible.

Los resultados históricos de Tiny Tapeout aportan un contexto útil. Ejecuciones anteriores han integrado procesadores, generadores de señales, pantallas, aceleradores y circuitos analógicos experimentales en silicio compartido. La plataforma no está dedicada a los gráficos, lo que convierte a TinyGPU en una prueba de esfuerzo para su modelo de diseño general.

Una canalización gráfica combina aritmética, secuenciación, tráfico de memoria y una temporización de pantalla estricta. Perder la sincronización puede corromper una imagen completa. Coordinar con éxito estas piezas convierte al proyecto en una demostración más rica que un simple contador o una luz parpadeante.

Aun así, el tapeout compartido no elimina el riesgo de ingeniería. Redistribuye la infraestructura y reduce la barrera de entrada. Los diseñadores siguen siendo responsables de la corrección funcional, la temporización, el uso de recursos y el comportamiento de su hardware circundante.

La plataforma tampoco puede hacer que un circuito limitado se comporte como uno más grande. La resolución, profundidad de color, frecuencia de reloj y presupuesto de escena de TinyGPU siguen siendo consecuencias directas de sus decisiones de diseño. La accesibilidad no elimina la relación entre área y capacidad.

Por tanto, la presión recae sobre las suposiciones tradicionales acerca de quién puede fabricar un procesador interesante. TinyGPU no presiona la hoja de ruta de productos de Nvidia. Presiona la creencia de que el silicio gráfico personalizado pertenece únicamente a grandes empresas o laboratorios universitarios.

Ese cambio tiene implicaciones más allá de las GPU. Los chips pequeños y abiertos permiten a los desarrolladores probar aceleradores, interfaces y procesadores educativos inusuales en su medio físico final. Algunas ideas fracasarán, pero sus fallos pueden convertirse en evidencia de ingeniería visible y reproducible.

Lo que la demostración de TinyGPU v2.0 no demuestra

Una salida funcional establece la funcionalidad básica, pero no demuestra un benchmark completo, preparación para producción ni un récord mundial indiscutible.

La primera incertidumbre se refiere al alcance de las pruebas. Las imágenes públicas pueden mostrar un modelo apareciendo en un monitor y respondiendo a la entrada. No pueden revelar si todas las rutas aritméticas, condiciones de memoria, orientaciones de triángulos o estados de control se comportan correctamente.

Una validación exhaustiva requeriría múltiples escenas de prueba y mediciones repetibles. Los revisores también necesitarían información sobre muestras de silicio, estabilidad del reloj, voltaje, temperatura, reinicios y funcionamiento prolongado. Esos resultados no han acompañado al informe inicial.

La segunda incertidumbre se refiere al rendimiento. El rango citado de 7,5 a 15 FPS parece coherente con las expectativas previas de FPGA, pero las cargas de trabajo influyen notablemente en el resultado. Un benchmark necesita un modelo, cámara, textura, viewport y método de medición fijos.

La dependencia del chip de la memoria QSPI externa complica aún más la interpretación. La latencia de memoria puede detener o marcar el ritmo de distintas etapas de la canalización. El repositorio incluso documenta ajustes de latencia configurables para el módulo de memoria conectado.

Eso no debilita el proyecto. La memoria externa es una elección arquitectónica legítima, especialmente cuando el almacenamiento en chip dominaría el área. Simplemente significa que la expresión "GPU independiente" no debe confundirse con un único componente que no requiere hardware de apoyo.

La GPU sigue necesitando memoria, un reloj, alimentación, conexiones de vídeo y hardware de entrada. Los procesadores comerciales también dependen de sistemas circundantes. Aquí, "independiente" significa que la canalización gráfica se ejecuta en lógica fabricada, en lugar de dentro de una FPGA o un microcontrolador.

La tercera incertidumbre es el fallo de viewport documentado por Vichit. En v2.0, la geometría que se extiende más allá del viewport visible puede congelar la GPU y obligar a un reinicio. Un viewport define el área rectangular de pantalla donde debería aparecer la escena.

Es una limitación considerable para el renderizado 3D general. Las cámaras desplazan habitualmente objetos parcialmente fuera de la pantalla. Un procesador gráfico debería recortar o rechazar la geometría relevante sin bloquear su canalización.

Vichit afirma que TinyGPU v3.0 resuelve el problema. Hasta que esa versión se publique y pruebe, la solución sigue formando parte de la hoja de ruta. La limitación también ilustra por qué el hardware programable o flexible aumenta las exigencias de verificación.

Una cuarta preocupación afecta a la descripción de "la más pequeña del mundo". El anterior primer diseño de GPU de Vichit utilizaba unas 16.000 puertas y renderizaba solo dos triángulos texturizados. Otros circuitos gráficos diminutos adoptan compromisos distintos, lo que dificulta una clasificación directa.

El chip anterior apuntaba a una salida de 640 por 480 a 60 FPS, lo que suena más rápido que v2.0. Sin embargo, manejaba una escena radicalmente más pequeña y carecía de la capacidad de v2.0 para archivos de modelos con hasta 1.000 triángulos.

Esta aparente inversión muestra por qué las comparaciones unidimensionales fallan. Una mayor resolución o tasa de fotogramas no implica automáticamente una arquitectura más capaz. TinyGPU v2.0 acepta una geometría mucho más rica mientras opera a una frecuencia de visualización menor.

Las GPU modernas representan el extremo opuesto. Sus miles de millones de transistores admiten aritmética masivamente paralela, planificación compleja, shaders programables, jerarquías de caché y memoria de alto ancho de banda. TinyGPU elimina intencionadamente la mayor parte de esos sistemas.

La GeForce 256 de Nvidia ofrece una referencia histórica más pertinente que una tarjeta de juegos actual. Presentada en 1999, ayudó a popularizar la transformación y la iluminación por hardware como una función definitoria de las GPU. TinyGPU reproduce conceptos relacionados a escala experimental.

Sin embargo, la terminología compartida no implica una amplitud comparable. El hardware de clase GeForce se orientaba a juegos comerciales, compatibilidad de software y cargas de trabajo sostenidas de clientes. TinyGPU es un proyecto abierto de aprendizaje que ilustra mecanismos seleccionados.

Tom Hardware enmarca acertadamente el dispositivo como un logro de entusiastas, no como una alternativa de compra. La interpretación más útil sigue esa distinción. Su importancia reside en el silicio visible y la economía arquitectónica, no en el rendimiento para consumidores.

El proyecto obtendría evidencias más sólidas con archivos de prueba reproducibles, condiciones de reloj registradas y resultados de varios chips. Los constructores independientes podrían entonces comparar el comportamiento del hardware con la simulación y la salida de FPGA.

El código abierto hace posible ese proceso, pero la publicación por sí sola no lo completa. El código fuente permite la inspección. Las pruebas de hardware repetibles convierten la inspección en una verificación más sólida.

TinyGPU v3.0 pondrá a prueba si la programabilidad cabe en el mismo diminuto formato

La próxima versión debe añadir flexibilidad sin perder la simplicidad disciplinada que permitió a v2.0 alcanzar silicio funcional.

La hoja de ruta pública de Vichit describe TinyGPU v3.0 como un paso de una canalización fija hacia el procesamiento programable de píxeles. Un pixel shader es un pequeño programa que calcula el color de salida de los píxeles. Permite efectos que las reglas fijas de iluminación y texturas no pueden expresar.

Las publicaciones públicas atribuidas a Vichit describen un diseño inspirado en los primeros pixel shaders de DirectX 8. El núcleo propuesto procesa cuatro píxeles en paralelo mediante ejecución de una sola instrucción y múltiples datos. SIMD aplica una instrucción a varios elementos de datos simultáneamente.

El diseño reportado utiliza un conjunto de instrucciones compacto y un número limitado de registros temporales. La ejecución enmascarada proporciona un método restringido para manejar comportamientos condicionales. Estas decisiones buscan preservar la programabilidad sin incorporar la complejidad de una arquitectura de shaders moderna.

Ese es el mecanismo que vale la pena observar. La programabilidad puede reemplazar varios circuitos fijos por lógica aritmética y de control reutilizable. También puede requerir almacenamiento de instrucciones, decodificación, registros, planificación y pruebas de riesgos más exhaustivas.

V3.0 también debe resolver el problema del viewport. Vichit ha hablado del rechazo de planos cercano y lejano junto con el recorte mediante guard bands. El recorte mediante guard bands permite coordenadas más allá del área visible antes de que las etapas posteriores restrinjan los píxeles a la pantalla.

Si ese mecanismo funciona, los objetos parcialmente visibles deberían dejar de congelar el procesador. La mejora haría más prácticos el movimiento de cámara y las escenas generales. También abordaría una debilidad claramente documentada de v2.0, en lugar de añadir funciones por sí mismas.

Ahora importan sobre todo tres señales.

Primero, Vichit debe publicar una arquitectura v3.0 estable y una implementación sintetizable. Las descripciones de funciones pueden cambiar mientras se optimiza la lógica. Un repositorio público expondría el formato real de instrucciones, la canalización y el uso de recursos.

Segundo, el diseño necesita resultados reproducibles en FPGA con escenas que sometan a estrés conjuntamente el recorte y la ejecución de shaders. Mantener la tasa de fotogramas durante un efecto simple no es suficiente. Las pruebas deberían situar geometría a través de los límites de pantalla mientras ejercitan la profundidad y la memoria externa.

Tercero, v3.0 necesitará finalmente otro resultado en silicio. El éxito en FPGA validaría buena parte de la lógica, pero la lección central de v2.0 es que la fabricación representa un umbral independiente. El silicio A0 funcional reforzaría las afirmaciones de la nueva arquitectura.

Un fallo en cualquier etapa seguiría produciendo información útil. Superar el presupuesto de la baldosa revelaría el coste de área de la programabilidad. Los problemas de temporización identificarían rutas lentas. Los errores visuales podrían exponer supuestos sobre precisión u ordenamiento de memoria.

Por tanto, la hoja de ruta importa incluso si v3.0 no cumple una ventana de lanzamiento prevista para 2026. Los calendarios de chips dependen de la madurez del diseño y de oportunidades de fabricación compartida. Un retraso sería menos informativo que la razón que lo explique.

Los lectores también deberían evitar tratar v3.0 como una línea de productos inevitable. No hay un mercado de consumo anunciado, un ecosistema de controladores ni una pila de software comercial. Actualmente, el proyecto funciona como desarrollo de hardware abierto y experimentación pública.

Ese enfoque permite a Vichit tomar decisiones que los proveedores comerciales de GPU no pueden. La compatibilidad con juegos existentes es innecesaria. El soporte de controladores puede seguir siendo limitado. El diseño puede privilegiar la transparencia y la educación visual sobre el rendimiento de propósito general.

Al mismo tiempo, la programabilidad invitará a comparaciones más exigentes. Una vez que un procesador ejecuta instrucciones de shader, los desarrolladores preguntarán por los límites de instrucciones, el comportamiento de ramificación, el acceso a texturas, la precisión y el rendimiento. Cada respuesta crea otra obligación de verificación.

El logro de v2.0 da credibilidad a esa hoja de ruta porque su predecesor llegó al silicio y, según se informa, produjo gráficos. No garantiza que v3.0 vaya a caber, funcionar o fabricarse con éxito. El progreso del hardware sigue siendo acumulativo, pero implacable.

Para los desarrolladores que siguen la cobertura de Tom Hardware, el mejor siguiente paso es examinar el diseño abierto en lugar de centrarse en el superlativo. Comparen la especificación del repositorio con futuros benchmarks, escenas de prueba y grabaciones de silicio.

El valor duradero de TinyGPU dependerá de si otros pueden reproducir, estudiar y ampliar sus técnicas. Una única demostración exitosa genera atención. La verificación documentada convierte esa atención en conocimiento de ingeniería reutilizable.

Habrá que observar si v3.0 mantiene una relación clara entre cada función y su coste de hardware. Si la flexibilidad de los shaders, el recorte y el trabajo paralelo de píxeles siguen siendo comprensibles, el proyecto conservará su mayor ventaja.

La GPU útil más pequeña no es necesariamente la que tiene menos transistores. Es aquella cuyas limitaciones revelan cómo funciona realmente el hardware gráfico. TinyGPU v2.0 ha llegado a ese punto en silicio.

Ahora v3.0 debe demostrar si esa misma claridad sobrevive en una canalización más programable. Esa prueba, más que una competencia con las GPU de escritorio, determinará el próximo capítulo del proyecto.