Pourquoi les graphiques vectoriels accélérés par matériel n'ont-ils pas décollé?
Je travaille sur une application qui implique une manipulation en temps réel des chemins vectoriels à 60 images par seconde, et je suis très surpris par le peu d'informations disponibles sur le sujet. Au début, j'ai essayé de mettre en œuvre mon idée en utilisant CoreGraphics, mais cela n'a pas fonctionné correctement pour mes besoins . J'ai ensuite découvert qu'il existait une norme Khronos pour les graphiques vectoriels accélérés par le matériel appelée OpenVG , et heureusement, une bonne âme avait écrit une semi-implémentation OpenGL ES appelée MonkVG .
Mais malgré le fait qu'OpenVG soit une API très pratique, elle semble plus ou moins abandonnée par Khronos. Selon Wikipédia, depuis 2011, le groupe de travail "a décidé de ... ne pas se réunir régulièrement [sic] pour poursuivre la normalisation". La documentation, du mieux que je puisse trouver, se compose d'une seule carte de référence. De plus, il n'y a pratiquement aucun exemple d'OpenVG sur Internet. Je peux trouver des centaines de tutoriels OpenGL en un clin d'œil, mais OpenVG semble visiblement manquant.
On pourrait penser que les vecteurs accélérés par le matériel seraient plus importants dans le monde d'aujourd'hui où les résolutions augmentent rapidement, et il semble que de nombreuses entreprises mettent en œuvre leurs propres moyens de le faire. Par exemple, Qt et Flash ont des schémas pour les vecteurs à accélération matérielle, et de nombreux outils d'Adobe ont une accélération matérielle en option. Mais il semble que la roue se réinvente alors qu'une norme existe déjà!
Y a-t-il quelque chose qui me manque dans OpenVG qui le rend impropre à une utilisation dans le monde réel? Ou est-ce juste que la norme n'a pas pris son temps et qu'elle est désormais destinée à l'obscurité? Pensez-vous qu'il y ait de la place pour une API standardisée pour les graphiques vectoriels accélérés par le matériel à l'avenir, ou sera-t-il simplement plus facile d'utiliser des techniques traditionnelles basées sur des trames? Ou les vecteurs sont-ils simplement sur le point de sortir, avant 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 les autres (en particulier maintenant que le comité standard C++ veut incorporer Le Caire 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 fonctionnent en utilisant une parallélisation massive et des capacités SIMD pour colorer chaque pixel. AMD fonctionne généralement en 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 quads entiers que ce triangle couvre. Donc, si un triangle ne couvre pas tous les 8x8 pixels du bloc (ou 4x4 dans le cas de nvidia), le GPU calculera la couleur des pixels non couverts, puis ignorera 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 grand triangles 3D lorsqu'ils sont associés à un grand nombre de cœurs GPU (informations plus détaillées ici: Optimisation du rasterizer de base ).
Donc, lorsque nous regardons en arrière la rastérisation vectorielle, vous remarquerez que lorsque vous dessinez des lignes, même si elles sont épaisses, il y a un espace vide massif. Beaucoup de puissance de traitement gaspillée, et surtout de la bande passante (qui est la principale cause de consommation d'énergie, et souvent un goulot d'étranglement) Donc, à moins que vous ne dessiniez une ligne horizontale ou verticale avec un multiple d'épaisseur de 8, et il s'aligne parfaitement aux limites de 8 pixels, beaucoup de puissance de traitement et de bande passante seront gaspillées.
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 limité à des blocs 8x8/4x4 (également probablement les benchmarks GPU de NVIDIA évoluent mieux avec des résolutions plus élevées, le ratio pixels_covered/pixels_wasted est beaucoup plus faible).
C'est pourquoi beaucoup de gens ne se soucient même pas de "l'accélération vectorielle hw". 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 d'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 vis-à-vis de NV_path_rendering, et avec un peu de recherche sur Google, Qt lors de l'utilisation d'OpenGL (alias la méthode recommandée) est nettement plus rapide que NV_path_rendering de NVIDIA: rendu de chemin NV En d'autres termes, les diapositives de NVIDIA étaient "accidentellement" en comparant la version de Qt de XRender. Oups.
Au lieu de faire valoir que "tout dessin vectoriel avec accélération hw est plus rapide", les développeurs de Qt sont plus honnêtes admettant que le dessin vectoriel accéléré HW n'est pas toujours meilleur (voir comment leur rendu fonctionne expliqué: Qt Graphics and Performance - OpenGL )
Et nous n'avons pas touché à la partie des graphiques vectoriels "édition en direct", qui nécessite la génération de bandes triangulaires à la volée. Lors de l'édition de fichiers SVG complexes, cela pourrait en fait ajouter de sérieux frais généraux.
Que ce soit meilleur ou non, cela dépend fortement des applications; quant à votre question initiale "pourquoi elle n'a pas décollé", j'espère qu'il est maintenant répondu: il y a beaucoup d'inconvénients et de contraintes à prendre en compte, ce qui rend souvent beaucoup de gens sceptiques et peut même les pousser à ne pas en appliquer un .
mise à jour: On m'a fait remarquer que les chiffres sont complètement hors de base, car les GPU mentionnés ne trament pas en blocs 64x64 et 32x32 mais plutôt 8x8 = 64 et 4x4 = 16. Cela annule à peu près les conclusions de l'article. 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" comme écrit en cette réponse .
Nvidia semble s'en soucier un peu. Outre Kilgard, qui est le responsable technique sur NV_path_rendering (désormais NVpr pour sauver mes doigts), le président de Khronos, Neil Trevett, qui est également vice-président de Nvidia, a promu NVpr autant qu'il le pouvait ces dernières années; voir son talk1 , talk2 ou talk . Et cela semble avoir payé un peu. Au moment d'écrire ces lignes, NVpr est maintenant utilisé dans Skia de Google (qui à son tour est utilisé dans Google Chrome) et indépendamment [de Skia] dans une version bêta d'Adobe Illustrator CC (bêta), selon les diapositives de Kilgard à GTC14 ; il y a aussi quelques vidéos des conférences qui y sont données: Kilgard's et Adobe's . Un développeur du Caire (qui travaille pour Intel) a également semble intéressé dans NVpr. Les développeurs de Mozilla/Firefox ont également expérimenté NVpr et ils se soucient en fait des graphiques vectoriels accélérés par GPU en général comme ceci FOSDEM14 talk-shows.
Microsoft se soucie également beaucoup car ils ont créé Direct2D , qui est utilisé assez largement [si vous croyez le développeur Mozilla de la discussion susmentionnée].
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 souhaitez en savoir plus sur la façon dont le rendu de chemin diffère de la géométrie de sommet 3D standard et sur ce qui rend l'accélération GPU du rendu de chemin non triviale, alors Kilgard a une très bonne publication de type FAQ , ce qui est malheureusement enterré quelque part dans le forum OpenGL.
Pour plus de détails sur la façon dont Direct2D, NVpr et de tels travaux, vous pouvez lire Kilgard's Siggraph 2012 paper , qui est bien sûr axé sur NVpr, mais fait également un bon travail en examinant les approches antérieures. Il suffit de dire que les hacks rapides ne fonctionnent pas trop bien ... (comme l'a noté le texte de la question PSE.) Il existe des différences de performances significatives entre ces approches, comme discuté dans cet article et montré dans certaines des premières démos de Kilgard, par ex. dans cette vidéo . Je dois également noter que document d'extension officiel de NVpr détaille plusieurs réglages de performances au fil des ans.
Tout simplement parce que NVpr n'était pas si génial sous Linux en 2011 (dans sa première implémentation publiée), comme cela 2011 blog post de Zack Rusin de Qt, cela ne signifie pas que l'accélération GPU des vecteurs/chemins est sans espoir, car la réponse de M. Goldberg semble en avoir déduit. Kilgard a en fait a répondu à la fin de ce 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 après cela.
Valve Corp se soucie également du rendu vectoriel accéléré par GPU, mais d'une manière plus limitée, en ce qui concerne le rendu des polices/glyphes. Ils ont eu une implémentation agréable et rapide du lissage des grandes polices en utilisant des champs de distance signée accélérés par le GPU (SDF) présenté au Siggraph 2007 , qui est utilisé 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 quelques améliorations par l'un des développeurs de Cairo & pango sous la forme de GLyphy; son auteur a donné ne conférence à linux.conf.au 2014 . La version trop longue et non surveillée est qu'il fait une approximation arc-spline des courbes de Bézier afin de rendre le calcul SDF plus traitable dans l'espace vectoriel (plutôt que dans le raster) (Valve a fait ce dernier). Mais même avec l'approximation arc-spline, le calcul était encore lent; il a dit que sa première version tournait à 3 fps. Donc, il fait maintenant une sélection basée sur la grille pour les choses qui sont "trop loin", qui ressemble à une forme de LOD (niveau de détail) mais dans l'espace SDF. Avec cette optimisation, ses démos ont couru à 60 ips (et c'était probablement Vsync limité). Cependant, ses shaders sont incroyablement complexes et repoussent les limites du matériel et des pilotes. a également trouvé des bugs importants dans les compilateurs de shader, dont certains ont ensuite été corrigés par leurs développeurs respectifs. Cela ressemble donc beaucoup au développement de titres de jeu AAA ...
Dans un autre ordre d'idées, il semble que Microsoft ait commandé/spécifié un peu de nouveau matériel GPU pour améliorer leur implémentation Direct2D avec, matériel utilisé par Windows 8, si disponible . Cela s'appelle rastérisation indépendante de la cible ( [~ # ~] tir [~ # ~] ), un nom ce qui est un peu trompeur quant à ce que les choses semblent réellement faire, ce qui est expliqué dans la demande de brevet de Microsoft . AMD a affirmé que TIR a amélioré les performances des graphiques vectoriels 2D d'environ 500% . 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 basés sur GCN d'AMD. Nvidia a confirmé qu'il s'agit bien d'un nouveau matériel, pas simplement d'une mise à jour de pilote. Article de blog de Sinofsky a quelques détails supplémentaires, y compris quelques repères réels de TIR. Je ne cite que les bits de l'idée générale:
pour améliorer les performances lors du rendu d'une géométrie irrégulière (par exemple, les frontières géographiques sur une carte), nous utilisons une nouvelle fonctionnalité matérielle graphique appelée Target Independent Rasterization, ou TIR.
TIR permet à Direct2D de passer moins de cycles CPU 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 qui prend en charge DirectX 11.1.
Ci-dessous est un graphique montrant l'amélioration des performances pour le rendu de la géométrie anti-crénelée à partir d'une variété de fichiers SVG sur un GPU DirectX 11.1 prenant en charge TIR: [graphique coupé]
Nous avons travaillé en étroite collaboration avec nos partenaires matériels graphiques [lire AMD] pour concevoir 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 c'était l'une des belles choses que Win 8 a ajouté et qui a été perdue pour la plupart dans le monde dans le fiasco Metro UI ...
Probablement parce que ses avantages ne l'emportent pas sur les coûts.