Estoy trabajando en una aplicación que involucra la manipulación en tiempo real de rutas de vectores a 60 fps, y estoy muy sorprendido por la poca información que hay sobre el tema. Al principio, traté de implementar mi idea usando CoreGraphics, pero no funcionó adecuadamente para mis propósitos . Luego descubrí que había un estándar Khronos para gráficos vectoriales acelerados por hardware llamado OpenVG , y afortunadamente un alma amable había escrito una semi-implementación de OpenGL ES llamada MonkVG .
Pero a pesar del hecho de que OpenVG es una API muy práctica, parece más o menos abandonada por Khronos. Según Wikipedia, desde 2011, el grupo de trabajo "decidió ... no hacer ninguna reunión regular [sic] para una mayor estandarización". La documentación, lo mejor que puedo encontrar, consiste en una sola tarjeta de referencia. Y lo que es más, apenas hay ejemplos de OpenVG en cualquier parte de Internet. Puedo encontrar cientos de tutoriales de OpenGL en un abrir y cerrar de ojos, pero OpenVG parece notablemente perdido.
Se podría pensar que los vectores acelerados por hardware serían más importantes en el mundo actual de resoluciones que aumentan rápidamente, y parece que muchas compañías están implementando sus propias formas de hacerlo. Por ejemplo, Qt y Flash tienen esquemas para vectores acelerados por hardware, y muchas de las herramientas de Adobe tienen como opción la aceleración por hardware. ¡Pero parece que la rueda se reinventa cuando ya existe un estándar!
¿Hay algo que me falta de OpenVG que lo hace inadecuado para el uso en el mundo real? ¿O es solo que el estándar no se dio cuenta a tiempo y ahora está destinado a la oscuridad? ¿Crees que hay espacio para una API estandarizada para gráficos vectoriales acelerados por hardware en el futuro, o será más fácil usar técnicas tradicionales basadas en raster? ¿O los vectores simplemente están saliendo antes de que entraran?
Respuestas:
actualización: ver la parte inferior de la respuesta
Esta respuesta llega un poco tarde, pero espero dar luz a los demás (particularmente ahora que el comité estándar de C ++ quiere incorporar a Cairo en std):
La razón por la que a nadie realmente le importan los "gráficos vectoriales acelerados" es por cómo funcionan las GPU. Las GPU funcionan usando paralelización masiva y capacidades SIMD para colorear cada píxel. AMD generalmente funciona en bloques de
64x648x8 píxeles, mientras que las tarjetas NVIDIA generalmente funcionan en32x324x4 píxeles [Ver actualización en la parte inferior]Incluso si están renderizando un triángulo 3D, la GPU funciona en quads completos que cubre este triángulo. Entonces, si un triángulo no cubre todos los píxeles de 8x8 en el bloque (o 4x4 en el caso de nvidia), la GPU calculará el color de los píxeles descubiertos y luego descartará el resultado. En otras palabras, se desperdicia la potencia de procesamiento para píxeles descubiertos. Si bien esto parece un desperdicio, funciona increíblemente bien para renderizar triángulos 3D grandes cuando se combina con una gran cantidad de núcleos de GPU (información más detallada aquí: Optimización del rasterizador básico ).
Entonces, cuando miramos hacia atrás en la rasterización basada en vectores, notará que al dibujar líneas, incluso si son gruesas, hay un espacio en blanco masivo. Se desperdicia mucha potencia de procesamiento y, lo que es más importante, ancho de banda (que es la principal causa del consumo de energía y, a menudo, un cuello de botella) Entonces, a menos que esté dibujando una línea horizontal o vertical con un grosor múltiplo de 8, y se alinea perfectamente con Límites de 8 píxeles, se desperdiciará mucha potencia de procesamiento y ancho de banda.
La cantidad de "desperdicio" se puede reducir calculando el casco para renderizar (como lo hace NV_path_rendering), pero la GPU todavía está restringida a bloques de 8x8 / 4x4 (también es probable que los puntos de referencia de GPU de NVIDIA escalen mejor con resoluciones más altas, la relación píxeles_cubiertos / píxeles_desgastados es mucho más bajo)
Es por eso que muchas personas ni siquiera se preocupan por la "aceleración vectorial hw". Las GPU simplemente no son adecuadas para la tarea.
NV_path_rendering es más la excepción que la norma, y han introducido el nuevo truco de usar el búfer de plantilla; que admite compresión y puede reducir significativamente el uso de ancho de banda.
No obstante, sigo siendo escéptico de NV_path_rendering, y con un poco de búsqueda en Google muestra que Qt cuando uso OpenGL (también conocido como la forma recomendada) es significativamente más rápido que NV_path_rendering: NV Path rendering En otras palabras, las diapositivas de NVIDIA estaban "accidentalmente" comparando la versión de XRender de Qt. Ooops
En lugar de argumentar que "todo el dibujo vectorial con aceleración hw es más rápido", los desarrolladores de Qt son más honestos al admitir que el dibujo vectorial acelerado HW no siempre es mejor (vea cómo se explica su representación: Gráficos Qt y rendimiento - OpenGL )
Y no hemos tocado la parte de los gráficos vectoriales de "edición en vivo", que requieren la generación de franjas triangulares sobre la marcha. Al editar svgs complejos, esto podría agregar una sobrecarga seria.
Si es mejor o no, depende en gran medida de las aplicaciones; en cuanto a su pregunta original "por qué no ha despegado", espero que ahora se responda: hay muchas desventajas y limitaciones a tener en cuenta, a menudo haciendo que muchas personas se muestren escépticas e incluso pueden sesgarlas para que no implementen una .
Actualización: me han señalado que los números están completamente fuera de la base, ya que las GPU mencionadas no se rasterizan en bloques de 64x64 y 32x32, sino más bien 8x8 = 64 y 4x4 = 16. Esto prácticamente anula las conclusiones de la publicación. Pronto actualizaré esta publicación más tarde con información más actualizada.
fuente
No creo que sea realmente cierto que a nadie realmente le importen los "gráficos vectoriales acelerados" tal como están escritos en esta respuesta .
A Nvidia parece importarle un poco. Además de Kilgard, que es el técnico principal en NV_path_rendering (en adelante NVpr para salvar mis dedos), el presidente de Khronos, Neil Trevett, quien también es vicepresidente de Nvidia, ha promovido NVpr tanto como pudo en los últimos años; ver su talk1 , talk2 o talk3 . Y eso parece haber valido la pena un poco. Al momento de escribir esto, NVpr ahora se usa en Skia de Google (que a su vez se usa en Google Chrome) y de forma independiente [de Skia] en una versión beta de Adobe Illustrator CC (beta), según las diapositivas de Kilgard en GTC14 ; También hay algunos videos de las charlas ofrecidas allí: Kilgard y Adobe. Un desarrollador de Cairo (que trabaja para Intel) también parece interesado en NVpr. Los desarrolladores de Mozilla / Firefox también experimentaron con NVpr y, de hecho, se preocupan por los gráficos vectoriales acelerados por GPU en general, como muestra esta charla FOSDEM14 .
A Microsoft también le importa un poco porque crearon Direct2D , que se usa bastante ampliamente [si cree en el desarrollador de Mozilla de la charla antes mencionada].
Ahora, para llegar al punto de la pregunta original: de hecho, hay algunas razones técnicas por las que el uso de GPU para la representación de rutas no es sencillo. Si desea leer acerca de cómo la representación de ruta difiere de la geometría de vértice 3D estándar de pantano y qué hace que la aceleración de GPU de la representación de ruta no sea trivial, entonces Kilgard tiene una muy buena publicación de preguntas frecuentes , que desafortunadamente está enterrada en algún lugar del foro OpenGL.
Para obtener más detalles sobre cómo Direct2D, NVpr y ese tipo de trabajo, puede leer el documento Siggraph 2012 de Kilgard , que, por supuesto, se centra en NVpr, pero también hace un buen trabajo al examinar enfoques anteriores. Baste decir que los hacks rápidos no funcionan demasiado bien ... (como se señala en el texto de la pregunta del PSE). Existen diferencias de rendimiento significativas entre estos enfoques, tal como se discutió en ese documento y se mostró en algunas de las primeras demostraciones de Kilgard, por ejemplo, en este video . También debo tener en cuenta que el documento oficial de extensión NVpr detalla varios ajustes de rendimiento a lo largo de los años.
El hecho de que NVpr no fuera tan bueno en Linux en 2011 (en su primera implementación lanzada), como dijo esa publicación de blog de 2011 de Qt's Zack Rusin, no significa que la aceleración de vectores / rutas de GPU sea inútil como la respuesta del Sr. Goldberg parece haber inferido de eso. De hecho, Kilgard respondió al final de esa publicación de blog con controladores actualizados que muestran una mejora de 2x-4x sobre el código más rápido de Qt y Rusin no ha dicho nada después de eso.
Valve Corp. también se preocupa por la representación vectorial acelerada por GPU, pero de manera más limitada, en relación con la representación de fuente / glifo. Han tenido una implementación agradable y rápida de suavizado de fuentes grandes utilizando campos de distancia con signo acelerados por GPU (SDF) presentados en Siggraph 2007 , que se utiliza en sus juegos como TF; Hay una demostración en video de la técnica publicada en YouTube (pero no estoy seguro de quién lo hizo).
El enfoque SDF ha visto algunos refinamientos por parte de uno de los desarrolladores de El Cairo y pango en forma de GLyphy ; su autor dio una charla en linux.conf.au 2014. La versión demasiado larga no observada es que hace una aproximación de arco-spline de las curvas de Bezier para hacer que el cálculo de SDF sea más manejable en el espacio vectorial (en lugar de en la trama) (Valve hizo lo último). Pero incluso con la aproximación de arco-spline, el cálculo seguía siendo lento; Dijo que su primera versión corrió a 3 fps. Así que ahora hace algunos sacrificios basados en la cuadrícula para cosas que están "demasiado lejos", lo que parece una forma de LOD (nivel de detalle) pero en el espacio SDF. Con esta optimización, sus demos corrieron a 60 fps (y probablemente era Vsync limitado). Sin embargo, sus sombreadores son increíblemente complejos y superan los límites del hardware y los controladores. Dijo algo como: "para cada combinación de controlador / sistema operativo tuvimos que cambiar las cosas". También encontró errores significativos en los compiladores de sombreadores, algunos de los cuales fueron arreglados por sus respectivos desarrolladores. Así que se parece mucho al desarrollo de títulos de juegos AAA ...
En otra táctica, parece que Microsoft ha encargado / especificado un poco de nuevo hardware de GPU para mejorar su implementación de Direct2D, hardware que utiliza Windows 8, si está disponible . Esto se llama rasterización independiente del objetivo ( TIR ), un nombre que es un poco engañoso en cuanto a lo que realmente parece hacer, que se explica en la solicitud de patente de Microsoft . AMD afirmó que TIR mejoró el rendimiento en gráficos vectoriales 2D en un 500% . Y hubo un poco de "guerra de palabras" entre ellos y Nvidia porque las GPU Kepler no lo tienen, mientras que las GPU basadas en GCN de AMD sí. Nvidia ha confirmadoque esto es de hecho un poco de hardware nuevo, no simplemente algo que puede proporcionar una actualización de controlador. La publicación del blog de Sinofsky tiene algunos detalles más, incluidos algunos puntos de referencia reales de TIR. Cito solo los bits de idea general:
Supongo que esta fue una de las cosas buenas que agregó Win 8 que se perdió principalmente en el mundo en el fiasco de la interfaz de usuario de Metro ...
fuente
Probablemente porque sus beneficios no superan los costos.
fuente