- Se propone un enfoque que utiliza la estructura de tiras dispersas (sparse strips) para mejorar la eficiencia en el renderizado de gráficos 2D basado en CPU
- Investigación centrada en las estructuras de datos y métodos de procesamiento para lograr renderizado de alto rendimiento en CPU en lugar de GPU
- Mediante una representación de datos dispersa, se reduce el uso de memoria y se asegura una velocidad de renderizado rápida incluso en escenas complejas
- Diseño que mejora la eficiencia del procesamiento en paralelo y el aprovechamiento de caché frente a los métodos tradicionales de renderizado en CPU
- Investigación que muestra la posibilidad de implementar gráficos 2D de alta calidad usando solo CPU
Resumen de la investigación
- Este artículo tiene como objetivo el renderizado de gráficos 2D de alto rendimiento en CPU y explora métodos para reducir la dependencia de la GPU
- El concepto central es una estructura de datos llamada tiras dispersas (sparse strips), que almacena de forma eficiente solo las partes necesarias en lugar de datos continuos a nivel de píxel
- Con esta estructura se logra reducir el costo de acceso a memoria y mejorar la velocidad de renderizado
Estructura de tiras dispersas
- Una tira (strip) representa un segmento continuo de píxeles de una imagen 2D, y en formato disperso (sparse) solo almacena las partes necesarias
- Este método es especialmente eficiente en imágenes con mucho espacio vacío o gráficos vectoriales complejos
- En comparación con el renderizado tradicional basado en búfer completo, ofrece menor uso de memoria y mejor eficiencia de caché
Rendimiento e implementación
- Aprovecha las instrucciones SIMD y el multihilo de la CPU para maximizar el rendimiento del procesamiento en paralelo
- Los resultados experimentales muestran que es posible procesar la misma escena con un rendimiento de nivel de renderizado en tiempo real incluso sin GPU
- La implementación fue escrita en C++ y se probó en diversas resoluciones y niveles de complejidad de escena
Posibles aplicaciones
- Puede aplicarse en entornos centrados en CPU como renderizado de UI, motores de gráficos vectoriales y pipelines 2D de motores de juego
- También puede ofrecer procesamiento de gráficos 2D de alto rendimiento en sistemas embebidos o entornos de servidor donde la GPU es limitada
Conclusión
- El enfoque basado en tiras dispersas demuestra que puede aliviar los cuellos de botella del renderizado en CPU y mejorar la eficiencia de memoria
- Presenta potencial como modelo alternativo frente a las estructuras de procesamiento gráfico dependientes de GPU
- Para consultar cifras adicionales o datos comparativos, es necesario revisar el contenido del PDF original
1 comentarios
Comentarios de Hacker News
La estructura
struct Stripdefinida en el paper parece tener un tamaño de 64 bits (8 bytes), pero en el texto dice que un strip ocupa 64 bytesHaciendo las cuentas, en realidad parece ser algo como 259×8 + 7296 ≈ 9KB. Da la impresión de que hay una unidad incorrecta
Puede que solo sea un typo, pero también es posible que hayan asignado cada strip por unidad de línea de caché (64 bytes).
Si fue así, habría sido para evitar false sharing, así que puede que el renderer lo hiciera a propósito
El paper se enfocó sobre todo en comparar tiempos de ejecución, y no trató comparaciones de almacenamiento
También vale la pena ver Blaze: Parallel Rasterization on CPU
El proyecto está interesante. En la sección 3.9 se ve que la salida es un bitmap, así que al final parece que habría que copiar la imagen al GPU
Como Skia se está moviendo a WebGPU, y WebGPU soporta compute shaders, da la impresión de que los gráficos 2D son cada vez más un problema resuelto en términos de portabilidad y rendimiento
Aun así, hay casos donde un renderer por CPU sigue siendo útil — por ejemplo, en la web hay que compilar shaders en tiempo de ejecución cuando carga la página
En teoría, algo como arrancar con un renderer de CPU, al estilo del JIT de JS, y cambiar al GPU cuando los shaders estén listos, podría ser viable
Otra ventaja es el tamaño del binario. WebGPU (basado en dawn) es bastante grande
Enlace de referencia
En un proyecto más grande también existe una versión llamada Vello Hybrid, que hace la geometría en CPU y el pintado de píxeles en GPU
También consideramos la idea de usar el renderer de CPU mientras se compilan los shaders, pero todavía no la hemos implementado
De hecho, renderizar en GPU sería menos eficiente porque después habría que volver a copiar la imagen
Hace poco escribí código para renderizar trayectorias N-body de alta precisión con varios millones de vértices,
y me pregunto si implementar en GPU la representación RLE propuesta en este paper funcionaría bien sin perder simplicidad
Video de demo
Interesante. Me gustaría ver el rendimiento por núcleo de los renderers comparados.
Creo que eso mostraría la eficiencia del código. Los renderers populares podrían ser más lentos en velocidad bruta, pero usar menos CPU
También se pueden ver resultados en el benchmark oficial de Blend2D o en
vello_chart, que hice incluyendo renderers adicionales
¿Por casualidad uno de los asesores, Raph Levien, es el autor de la antigua biblioteca Libart?
Un poco fuera de tema, pero me pregunto desde cuándo la vista previa de PDF en GitHub empezó a cargar solo algunas páginas
Me parecía mejor como antes, cuando cargaba el PDF completo de una vez y el navegador se encargaba de renderizarlo
Me pregunto si existe algún benchmark para validar la correctitud (correctness) del renderer
La idea era medir la radiosidad de una escena real y compararla con los resultados de la simulación
En rendering en tiempo real, también se suele comparar contra renderers offline como Arnold u Octane
Wiki de Cornell box
No existe un renderer que reproduzca la realidad a la perfección; todos aceptan algún tipo de trade-off