Perché la grafica vettoriale con accelerazione hardware non è stata decollata?

Sto lavorando su un'app che prevede la manipolazione in tempo reale di percorsi vettoriali a 60 fps e sono molto sorpreso dalla poca informazione sull'argomento. All'inizio, ho cercato di attuare la mia idea utilizzando CoreGraphics, ma non ha funzionato adeguatamente per i miei scopi . Ho quindi scoperto che esisteva uno standard Khronos per la grafica vettoriale con accelerazione hardware chiamato OpenVG , e per fortuna un'anima gentile aveva scritto una semi-implementazione OpenGL ES chiamata MonkVG .

Ma nonostante il fatto che OpenVG sia un'API molto utile, sembra più o meno abbandonato da Khronos. Secondo Wikipedia, dal 2011, il gruppo di lavoro "ha deciso di ... non tenere incontri regolari [sic] per un'ulteriore standardizzazione". La documentazione, la migliore che posso trovare, consiste in una sola scheda di riferimento. Inoltre, a malapena ci sono esempi di OpenVG su Internet. Riesco a trovare centinaia di tutorial OpenGL in un batter d'occhio, ma OpenVG sembra evidentemente mancante.

Penseresti che i vettori con accelerazione hardware sarebbero più importanti nel mondo odierno di risoluzioni in rapido aumento, e sembra che molte aziende stiano implementando i propri modi per farlo. Ad esempio, Qt e Flash hanno schemi per i vettori con accelerazione hardware e molti degli strumenti di Adobe hanno come opzione l'accelerazione hardware. Ma sembra che la ruota si reinventi quando esiste già uno standard!

C'è qualcosa che mi manca in OpenVG che lo rende inadatto per l'uso nel mondo reale? O è solo che lo standard non ha attecchito in tempo e ora è destinato all'oscurità? Pensi che ci sia spazio per un'API standardizzata per la grafica vettoriale con accelerazione hardware in futuro o sarà più semplice utilizzare le tecniche tradizionali basate su raster? O i vettori stanno semplicemente uscendo, prima di entrare?

aggiornamento: vedere la parte inferiore della risposta

Questa risposta arriva un po 'troppo tardi, ma spero di far luce sugli altri (in particolare ora che il comitato standard C ++ vuole incorporare il Cairo in std):

Il motivo per cui a nessuno importa davvero della "grafica vettoriale accelerata" è a causa del funzionamento delle GPU. Le GPU funzionano utilizzando la massiccia parallelizzazione e le funzionalità SIMD per colorare ogni pixel. AMD funziona in genere in blocchi di 64x64 8x8 pixel mentre le schede NVIDIA funzionano in genere in 32x32 4x4 pixel [Vedi aggiornamento in fondo]

Anche se stanno eseguendo il rendering di un triangolo 3D, la GPU funziona su interi quad coperti da questo triangolo. Quindi se un triangolo non copre tutti i pixel 8x8 nel blocco (o 4x4 nel caso di nvidia) la GPU calcolerà il colore dei pixel scoperti e quindi scarterà il risultato. In altre parole, la potenza di elaborazione per i pixel scoperti viene sprecata. Anche se questo sembra dispendioso, funziona incredibilmente bene per il rendering di grandi triangoli 3D se abbinato a un numero enorme di core GPU (informazioni più dettagliate qui: Ottimizzazione del rasterizzatore di base ).

Quindi, quando guardiamo indietro alla rasterizzazione basata su vettori, noterai che quando si disegnano linee, anche se sono spesse, c'è un enorme spazio vuoto. Molta potenza di elaborazione sprecata e, soprattutto, larghezza di banda (che è la causa principale del consumo di energia e spesso un collo di bottiglia) Quindi, a meno che non si stia disegnando una linea orizzontale o verticale con uno spessore multiplo di 8 e si allinea perfettamente a Limiti di 8 pixel, molta potenza di elaborazione e larghezza di banda verranno sprecate.

La quantità di "rifiuti" può essere ridotta calcolando lo scafo da renderizzare (come fa NV_path_rendering), ma la GPU è ancora vincolata a blocchi 8x8 / 4x4 (anche probabilmente i benchmark GPU della NVIDIA si adattano meglio con risoluzioni più elevate, il rapporto pixel_covered / pixels_wasted è molto più basso).

Questo è il motivo per cui molte persone non si preoccupano nemmeno dell '"accelerazione vettoriale hw". Le GPU semplicemente non sono adatte all'attività.

NV_path_rendering è più un'eccezione che una norma e hanno introdotto il nuovo trucco dell'uso del buffer di stencil; che supporta la compressione e può ridurre significativamente l'utilizzo della larghezza di banda.

Tuttavia, rimango scettico su NV_path_rendering, e con un po 'di googling mostra che Qt quando si utilizza OpenGL (aka il modo consigliato) è significativamente più veloce di NV_IA_path_rendering di NVIDIA: rendering del percorso NV In altre parole, le diapositive di NVIDIA sono state "casualmente" confrontando la versione di XRender di Qt. Ooops.

Invece di sostenere che "tutto il disegno vettoriale con accelerazione hw è più veloce", gli sviluppatori di Qt sono più onesti ammettere che il disegno vettoriale accelerato HW non è sempre migliore (guarda come funziona il loro rendering: Qt Graphics and Performance - OpenGL )

E non abbiamo toccato la parte della grafica vettoriale di "live editing", che richiede al volo la generazione di strisce triangolari. Quando si modificano svg complessi, questo potrebbe effettivamente aggiungere un grave sovraccarico.

Che sia migliore o meno, dipende fortemente dalle applicazioni; per quanto riguarda la tua domanda originale "perché non è decollata", spero che ora abbia una risposta: ci sono molti svantaggi e vincoli da tenere in considerazione, che spesso rendono molte persone scettiche e potrebbero addirittura indurle a non implementarne una .

aggiornamento: sono stato sottolineato che i numeri sono completamente fuori base, poiché le GPU menzionate non si rasterizzano in blocchi 64x64 e 32x32 ma piuttosto 8x8 = 64 e 4x4 = 16. Questo praticamente annulla le conclusioni del post. Presto aggiornerò questo post in seguito con informazioni più aggiornate.

Non credo sia vero che a nessuno importa davvero della "grafica vettoriale accelerata" come scritto in questa risposta .

A Nvidia sembra importare un bel po '. Oltre a Kilgard, che è il capo tecnico di NV_path_rendering (d'ora in poi NVpr per salvarmi le dita), il presidente di Khronos, Neil Trevett, che è anche vicepresidente di Nvidia, ha promosso NVpr il più possibile negli ultimi due anni; vedere i suoi talk1 , talk2 o talk3 . E questo sembra aver pagato un po '. Al momento della stesura di questo articolo, NVpr è ora utilizzato in Google Skia (che a sua volta viene utilizzato in Google Chrome) e indipendentemente [di Skia] in una versione beta di Adobe Illustrator CC (beta), secondo le diapositive di Kilgard su GTC14 ; ci sono anche alcuni video dei discorsi tenuti lì: Kilgard e Adobe. Anche un dev del Cairo (che lavora per Intel) sembra interessato a NVpr. Gli sviluppatori di Mozilla / Firefox hanno anche sperimentato NVpr e in realtà si preoccupano della grafica vettoriale accelerata GPU in generale, come mostrano questi talk di FOSDEM14 .

Anche a Microsoft importa un bel po 'perché hanno creato Direct2D , che è usato abbastanza ampiamente [se credi allo sviluppatore Mozilla dal discorso di cui sopra].

Ora per arrivare al punto della domanda originale: ci sono davvero alcuni motivi tecnici per cui l'uso di GPU per il rendering del percorso non è semplice. Se vuoi leggere come il rendering del percorso differisce dalla geometria del vertice 3D standard di bog e cosa rende l'accelerazione GPU del rendering del percorso non banale, allora Kilgard ha un ottimo post simile a una FAQ , che purtroppo è sepolto da qualche parte nel forum OpenGL.

Per maggiori dettagli su come funzionano Direct2D, NVpr e simili, puoi leggere il documento Siggraph 2012 di Kilgard , che ovviamente si concentra su NVpr, ma fa anche un buon lavoro nel sondare approcci precedenti. Basti dire che gli hack rapidi non funzionano troppo bene ... (come ha notato il testo della domanda PSE). Esistono differenze di prestazioni significative tra questi approcci come discusso in quel documento e mostrato in alcune prime dimostrazioni di Kilgard, ad esempio in questo video . Dovrei anche notare che il documento ufficiale di estensione NVpr descrive dettagliatamente diverse ottimizzazioni delle prestazioni nel corso degli anni.

Solo perché NVpr non è stato così eccezionale su Linux nel 2011 (nella sua prima implementazione rilasciata), come ha detto quel post sul blog del 2011 di Zack Rusin di Qt, ciò non significa che l'accelerazione GPU di vettori / percorsi sia senza speranza come la risposta di Goldberg sembra aver dedotto da quello. Kilgard ha infatti risposto alla fine di quel post sul blog con driver aggiornati che mostrano miglioramenti 2x-4x rispetto al codice più veloce di Qt e Rusin non ha detto nulla dopo.

Valve Corp. si occupa anche del rendering vettoriale con accelerazione GPU, ma in modo più limitato, relativo al rendering di font / glifi. Hanno avuto un'implementazione piacevole e veloce del grande smussamento dei caratteri usando i campi a distanza segnata con accelerazione GPU (SDF) presentati a Siggraph 2007 , che viene utilizzato nei loro giochi come TF; c'è una dimostrazione video della tecnica pubblicata su YouTube (ma non sono sicuro di chi l'abbia fatto).

L'approccio SDF ha visto alcuni perfezionamenti di uno degli sviluppatori del Cairo e del pango sotto forma di GLyphy ; il suo autore ha tenuto un discorso su linux.conf.au 2014. La versione troppo lunga non guardata è che fa un'approssimazione arco-spline delle curve di Bezier per rendere il calcolo SDF più tracciabile nello spazio vettoriale (piuttosto che nello spazio) (Valve ha fatto quest'ultima). Ma anche con l'approssimazione arco-spline, il calcolo era ancora lento; ha detto che la sua prima versione era a 3 fps. Quindi ora fa un po 'di abbattimento basato sulla griglia per cose "troppo lontane", che sembra una forma di LOD (livello di dettaglio) ma nello spazio SDF. Con questa ottimizzazione, le sue demo si sono svolte a 60 fps (ed era probabilmente Vsync limitato). Tuttavia i suoi shader sono incredibilmente complessi e spingono i limiti di hardware e driver. Ha detto qualcosa del genere: "per ogni combinazione driver / sistema operativo abbiamo dovuto cambiare le cose". Ha anche riscontrato bug significativi nei compilatori di shader, alcuni dei quali sono stati poi risolti dai rispettivi sviluppatori. Quindi sembra molto simile allo sviluppo di titoli di gioco AAA ...

Da un altro punto di vista, sembra che Microsoft abbia commissionato / specificato un po 'di nuovo hardware GPU per migliorare la loro implementazione di Direct2D, hardware utilizzato da Windows 8, se disponibile . Questo si chiama rasterizzazione indipendente dal bersaglio ( TIR ), un nome un po 'fuorviante su ciò che sembra effettivamente fare, che è spiegato nella domanda di brevetto di Microsoft . AMD ha affermato che TIR ha migliorato le prestazioni della grafica vettoriale 2D di circa il 500% . E c'è stata un po 'di "guerra di parole" tra loro e Nvidia perché le GPU di Keplero non ce l'hanno, mentre le GPU basate su GCN di AMD lo fanno. Nvidia ha confermatoche questo è davvero un po 'di nuovo hardware, non semplicemente qualcosa che può fornire un aggiornamento del driver. Il post sul blog di Sinofsky ha alcuni dettagli in più, inclusi alcuni parametri di riferimento reali di TIR. Sto citando solo i bit dell'idea generale:

per migliorare le prestazioni durante il rendering di geometrie irregolari (ad es. bordi geografici su una mappa), utilizziamo una nuova funzionalità hardware grafica chiamata Target Independent Rasterization o TIR.

TIR consente a Direct2D di dedicare meno cicli di CPU alla tassellatura, in modo da poter dare istruzioni di disegno alla GPU in modo più rapido ed efficiente, senza sacrificare la qualità visiva. TIR è disponibile nel nuovo hardware GPU progettato per Windows 8 che supporta DirectX 11.1.

Di seguito è riportato un grafico che mostra il miglioramento delle prestazioni per il rendering della geometria anti-alias da una varietà di file SVG su una GPU DirectX 11.1 che supporta TIR: [grafico snipped]

Abbiamo lavorato a stretto contatto con i nostri partner hardware grafici [leggi AMD] per progettare TIR. Miglioramenti drammatici sono stati resi possibili grazie a quella partnership. L'hardware DirectX 11.1 è già sul mercato oggi e stiamo lavorando con i nostri partner per assicurarci che i prodotti più compatibili con TIR saranno ampiamente disponibili.

Immagino che questa sia stata una delle cose carine che Win 8 ha aggiunto che è stata per lo più persa nel mondo nel fiasco della UI della metropolitana ...

Probabilmente perché i suoi benefici non superano i costi.