Pourquoi les graphiques vectoriels à accélération matérielle n'ont-ils pas décollé?

Je travaille sur une application qui implique une manipulation en temps réel des tracés vectoriels à 60 ips, et je suis très étonnée du peu d'informations disponibles sur le sujet. Au début, j'ai essayé d'implémenter mon idée en utilisant CoreGraphics, mais cela ne fonctionnait pas correctement pour mes besoins . J'ai ensuite découvert qu'il existait un standard Khronos pour les graphiques vectoriels à accélération matérielle appelé OpenVG et, heureusement, une âme bienveillante avait écrit une semi-implémentation OpenGL ES appelée MonkVG .

Malgré le fait qu’OpenVG soit une API très utile, elle semble plus ou moins abandonnée par Khronos. Selon Wikipedia, depuis 2011, le groupe de travail "a décidé de ... ne pas se réunir [sic] régulièrement pour poursuivre la normalisation". La documentation, la meilleure que je puisse trouver, consiste en une seule carte de référence. De plus, il n’ya pratiquement aucun exemple d’OpenVG sur l’Internet. Je peux trouver des centaines de didacticiels OpenGL en un clin d'œil, mais OpenVG semble faire clairement défaut.

On pourrait penser que les vecteurs à accélération matérielle seraient plus importants dans le monde actuel où les résolutions augmentent rapidement, et il semblerait que de nombreuses entreprises mettent en œuvre leurs propres méthodes. Par exemple, Qt et Flash ont des schémas pour les vecteurs à accélération matérielle, et de nombreux outils d'Adobe ont l'accélération matérielle en option. Mais il semble que la roue se réinvente alors qu’une norme existe déjà!

Y at-il quelque chose qui me manque dans OpenVG qui le rend impropre à une utilisation réelle? Ou est-ce simplement que la norme n'a pas été intégrée dans le temps et qu'elle est maintenant vouée à l'obscurité? Pensez-vous qu’il soit possible d’avoir une API normalisée pour les graphiques vectoriels à accélération matérielle à l’avenir ou sera-t-il plus facile d’utiliser des techniques raster traditionnelles? Ou les vecteurs sont-ils simplement en voie de disparition, avant même qu'ils ne soient jamais entrés?

mise à jour: voir le bas de la réponse

Cette réponse arrive un peu trop tard, mais j'espère éclairer d'autres (en particulier maintenant que le comité de standard C ++ souhaite incorporer Cairo dans std):

La raison pour laquelle personne ne se soucie vraiment des "graphiques vectoriels accélérés" est à cause du fonctionnement des GPU. Les GPU utilisent la parallélisation massive et les capacités SIMD pour colorer chaque pixel. AMD fonctionne généralement par blocs de 64x64 8x8 pixels alors que les cartes NVIDIA fonctionnent généralement en 32x32 4x4 pixels [Voir la mise à jour en bas]

Même s'ils rendent un triangle 3D, le GPU fonctionne sur des quadruples entiers couverts par ce triangle. Donc, si un triangle ne couvre pas tous les 8x8 pixels du bloc (ou 4x4 dans le cas de nvidia), le processeur graphique calcule la couleur des pixels non couverts, puis supprime le résultat. En d'autres termes, la puissance de traitement des pixels non couverts est gaspillée. Bien que cela semble inutile, cela fonctionne incroyablement bien pour le rendu de grands triangles 3D lorsqu'il est associé à un nombre considérable de cœurs de processeur graphique (informations plus détaillées ici: Optimisation du rastériseur de base ).

Ainsi, lorsque nous examinons la rastérisation à base de vecteurs, vous remarquerez que lorsque vous tracez des lignes, même si elles sont épaisses, il existe un espace blanc énorme. Beaucoup de puissance de traitement gaspillée et, plus important encore, de bande passante (principale cause de consommation d'énergie et souvent de goulot d'étranglement). Donc, à moins de tracer une ligne horizontale ou verticale avec une épaisseur multiple de 8, et de l' aligner parfaitement 8 limites de pixels, beaucoup de puissance de traitement et de bande passante seront gaspillés.

La quantité de "déchets" peut être réduite en calculant la coque à restituer (comme le fait NV_path_rendering), mais le GPU est toujours contraint à des blocs de 8x8 / 4x4 (le rapport pixels_covered / pixels_wasted est probablement meilleur aussi. est beaucoup plus bas).

C'est pourquoi beaucoup de gens ne se soucient même pas de "l'accélération vectorielle élevée". Les GPU ne sont tout simplement pas bien adaptés à la tâche.

NV_path_rendering est plus l'exception que la norme, et ils ont introduit la nouvelle astuce consistant à utiliser le tampon de gabarit; qui prend en charge la compression et peut réduire considérablement l'utilisation de la bande passante.

Néanmoins, je reste sceptique quant à NV_path_rendering, et avec un peu de googging montre que Qt sous OpenGL (alias la méthode recommandée) est nettement plus rapide que celui de NVIDIA, NV_path_rendering: Rendu de chemin NV En d'autres termes, les diapositives de NVIDIA étaient "accidentellement" comparées à la version de XRender Qt. Ooops.

Au lieu de dire que "tout le dessin vectoriel avec accélération hw est plus rapide", les développeurs de Qt sont plus honnêtes, admettant que le dessin vectoriel avec accélération matérielle n'est pas toujours meilleur (voir comment leur rendu fonctionne bien: Qt Graphics and Performance - OpenGL )

Et nous n’avons pas touché à la partie «graphiques de montage en direct», qui nécessite la génération de bandes de triangle à la volée. Lors de l'édition de svgs complexes, cela pourrait en réalité ajouter une surcharge importante.

Que ce soit meilleur ou non, cela dépend fortement des applications; En ce qui concerne votre question initiale "Pourquoi ça n'a pas décollé", j'espère qu'on y répondra maintenant: il y a beaucoup d'inconvénients et de contraintes à prendre en compte, rendant souvent sceptiques beaucoup de personnes et pouvant même les pousser à ne pas en mettre en œuvre .

update: les chiffres sont complètement erronés, car les GPU mentionnés ne sont pas pixellisés en blocs 64x64 & 32x32 mais plutôt en 8x8 = 64 et 4x4 = 16. Cela annule les conclusions du message. Je mettrai bientôt à jour ce post plus tard avec des informations plus à jour.

Je ne pense pas qu'il soit vraiment vrai que personne ne se soucie vraiment des "graphiques vectoriels accélérés" tels qu'ils sont écrits dans cette réponse .

Nvidia semble se soucier un peu. Outre Kilgard, qui est le responsable technique principal de NV_path_rendering (désormais NVpr pour sauver mes doigts), le président de Khronos, Neil Trevett, également vice-président de Nvidia, a promu NVpr autant que possible ces dernières années. voir son talk1 , talk2 ou talk3 . Et cela semble avoir payé un peu. Au moment de la rédaction de cet article, NVpr est maintenant utilisé dans Google Skia (qui à son tour est utilisé dans Google Chrome) et indépendamment [de Skia] dans une version bêta d’Adobe Illustrator CC (version bêta), selon les diapositives de Kilgard à la CG14 ; il y a aussi quelques vidéos des conférences données ici: Kilgard et Adobe. Un développeur du Caire (qui travaille pour Intel) semble également intéressé par NVpr. Les développeurs Mozilla / Firefox ont également expérimenté NVpr. Ils s’intéressent en fait au graphisme vectoriel accéléré par GPU en général, comme le montre ce talk FOSDEM14 .

Microsoft s’intéresse également beaucoup au fait qu’ils ont créé Direct2D , qui est utilisé assez largement [si vous croyez que la version de Mozilla est tirée du discours susmentionné].

Passons maintenant à la question initiale: il existe en effet des raisons techniques pour lesquelles l’utilisation de GPU pour le rendu de chemin n’est pas simple. Si vous voulez savoir en quoi le rendu de chemin diffère de la géométrie de sommet 3D standard et ce qui rend l'accélération GPU du rendu de chemin non triviale, alors Kilgard a un très bon article de type FAQ , malheureusement enfoui quelque part sur le forum OpenGL.

Pour plus de détails sur la façon dont Direct2D, NVpr et ce type de travail, vous pouvez lire le document de Kilgard Siggraph 2012 , qui est bien sûr axé sur NVpr, mais qui fait également un bon travail en examinant les approches antérieures. Il suffit de dire que les piratages rapides ne fonctionnent pas très bien ... (comme le souligne le texte de la question sur les PSE). Il existe des différences de performances significatives entre ces approches décrites dans ce document et montrées dans certaines des premières démos de Kilgard, par exemple dans cette vidéo . Je dois également noter que le document d'extension NVpr officiel détaille plusieurs réglages de performances effectués au cours des années.

Ce n'est pas parce que NVpr n'était pas si performant sous Linux en 2011 (dans sa première mise en service publiée), comme le disait dans l'article de Zt Rusin de Qt en 2011 , que l'accélération GPU des vecteurs / chemins est sans espoir, a répondu M. Goldberg. semble avoir déduit de cela. Kilgard a en fait répondu à la fin de ce billet de blog avec des pilotes mis à jour montrant une amélioration 2x-4x par rapport au code plus rapide de Qt et Rusin n'a rien dit par la suite.

Valve Corp. s'intéresse également au rendu vectoriel accéléré par le GPU, mais de manière plus limitée, en ce qui concerne le rendu des polices / glyphes. Ils ont eu une bonne et rapide implémentation du lissage des grosses polices avec les champs de distance signés (SDF) accélérés par le GPU présentés à Siggraph 2007 , qui sont utilisés dans leurs jeux comme TF; il y a une démonstration vidéo de la technique publiée sur YouTube (mais je ne sais pas qui a fait ça).

L’approche SDF a vu certains des perfectionnements apportés par l’un des développeurs du Caire & pango sous la forme de GLyphy ; son auteur a donné une conférence à linux.conf.au 2014. La version trop longue-regardée est qu’il effectue une approximation arc-spline des courbes de Bézier afin de rendre le calcul SDF plus facile à manipuler dans l’espace vectoriel (plutôt que dans l’affichage raster) (ce dernier est fait par Valve). Mais même avec l'approximation arc-spline, le calcul était toujours lent; il a dit que sa première version a fonctionné à 3 fps. Donc, il effectue maintenant une sélection basée sur la grille pour des éléments "trop ​​éloignés", qui ressemblent à une forme de LOD (niveau de détail) mais dans l'espace SDF. Avec cette optimisation, ses démos ont fonctionné à 60 fps (et il était probablement limité à Vsync). Cependant, ses shaders sont incroyablement complexes et repoussent les limites du matériel et des pilotes. Il a dit quelque chose du genre: "pour chaque combinaison pilote / système d'exploitation, nous devions changer les choses". Il a également trouvé des bugs importants dans les compilateurs de shader, certains d'entre eux ont ensuite été fixés par leurs développeurs respectifs. Cela ressemble donc beaucoup au développement de titres de jeux AAA ...

Sur un autre plan, il semble que Microsoft ait commandé / spécifié un peu de nouveau matériel de processeur graphique afin d’améliorer leur implémentation de Direct2D avec le matériel utilisé par Windows 8, le cas échéant . C'est ce qu'on appelle la rastérisation TIR ( Target-Independent Rasterization ), nom trompeur quant à ce que semble réellement faire le travail, qui est décrit dans la demande de brevet de Microsoft . AMD a affirmé que le TIR améliorait les performances graphiques vectorielles 2D de 500% environ . Et il y avait un peu de "guerre des mots" entre eux et Nvidia parce que les GPU Kepler ne l'ont pas, contrairement aux GPU d'AMD basés sur GCN. Nvidia a confirméqu’il s’agit bien d’un nouveau matériel, et pas simplement d’une mise à jour de pilote. Le blog de Sinofsky contient quelques détails supplémentaires, y compris quelques points de repère réels du TIR. Je ne cite que les idées générales:

Pour améliorer les performances lors du rendu d'une géométrie irrégulière (par exemple, des bordures géographiques sur une carte), nous utilisons une nouvelle fonctionnalité matérielle graphique appelée Rasterisation Indépendante, ou TIR.

TIR permet à Direct2D de passer moins de cycles de processeur sur la tessellation, ce qui lui permet de donner des instructions de dessin au GPU plus rapidement et plus efficacement, sans sacrifier la qualité visuelle. TIR est disponible dans le nouveau matériel GPU conçu pour Windows 8 et prenant en charge DirectX 11.1.

Vous trouverez ci-dessous un graphique illustrant l'amélioration des performances de rendu de la géométrie anti-aliasée à partir de divers fichiers SVG sur un processeur graphique DirectX 11.1 prenant en charge le format TIR: [chart snipped]

Nous avons travaillé en étroite collaboration avec nos partenaires de matériel graphique [lire AMD] pour concevoir le TIR. Des améliorations spectaculaires ont été rendues possibles grâce à ce partenariat. Le matériel DirectX 11.1 est déjà sur le marché aujourd'hui et nous travaillons avec nos partenaires pour nous assurer que davantage de produits compatibles TIR seront largement disponibles.

Je suppose que Win 8 a ajouté que c’était une des bonnes choses qui avait été perdue pour la plupart dans le fiasco de l’interface utilisateur de Metro ...

Probablement parce que ses avantages ne dépassent pas ses coûts.