Dal suo aspetto ora ogni glSet deve includere glBind (qualcosa) al suo interno
Non esattamente. È il contrario, come descritto diversi paragrafi di seguito.
Anche se fosse vero, ricorda che i comandi GL dall'app client al server GL (aka driver) hanno un sacco di spese generali di spedizione rispetto a una normale chiamata di funzione. Anche se supponiamo che le funzioni DSA siano solo wrapper per le funzioni esistenti, sono wrapper che vivono all'interno del server GL e quindi possono avere (un po ') meno spese generali.
se OpenGL è ancora una macchina a stati non può trarre vantaggio dalle modifiche in streaming applicate a un singolo qualcosa.
Le GPU non sono macchine a stati. L'interfaccia della macchina a stati GL è un'emulazione che avvolge i driver interni simili a DSA, non viceversa.
Rimuovere uno strato di wrapping - uno strato che richiede un numero eccessivo di chiamate nel server GL - è chiaramente una vittoria, anche se piccolo.
L'approccio della macchina a stati inoltre non ha molto senso quando si ha a che fare con più thread; GL è ancora terribile in questo caso d'uso, ma i driver spesso usano thread dietro le quinte e una macchina a stati richiede molta sincronizzazione dei thread o algoritmi / costrutti paralleli davvero fantasiosi per far funzionare le cose in modo affidabile.
L'estensione DSA continua a formulare il suo funzionamento in termini di cambiamenti di stato perché, dopo tutto, è un'estensione di un documento esistente basato sullo stato e non un'API completamente nuova, quindi doveva essere pronto per il collegamento alla specifica GL esistente lingua e terminologia del documento. Anche se quel linguaggio esistente è abbastanza adatto al suo lavoro di moderna API hardware grafico.
Spiegare il ragionamento alla base e i vantaggi del nuovo DSA.
Il più grande ragionamento è che il vecchio modo era un dolore. Ha reso molto difficile comporre insieme librerie che potrebbero modificare o fare affidamento sullo stato GL. Ha reso difficile avvolgere in modo efficiente l'API GL in uno stile orientato agli oggetti o funzionale a causa delle sue profonde radici di gestione dello stato procedurale, che ha reso difficile il confezionamento dell'API in vari linguaggi non-C e ha anche reso difficile fornire wrapper per dispositivi grafici efficienti quell'astratto OpenGL di Direct3D.
Il secondo era l'overhead dell'API della macchina a stati procedurale, come descritto in precedenza.
In terzo luogo, le funzioni DSA hanno modificato la semantica, se del caso, dalle vecchie API che hanno consentito una maggiore efficienza. Le cose precedentemente mutabili sono state rese immutabili, ad esempio, il che rimuove un sacco di codice contabile dal server GL. Le chiamate dell'applicazione possono essere inviate all'hardware o convalidate prima (o in mode più parallele) quando il server GL non deve gestire oggetti mutabili.
-
Ulteriori giustificazioni e spiegazioni sono fornite nelle specifiche dell'estensione EXT_direct_state_access .
-
Le modifiche hardware rilevanti per la progettazione dell'API sono piuttosto numerose.
Ricorda che OpenGL risale al 1991. L'hardware di destinazione non era una scheda grafica di consumo (quelli non esistevano) ma grandi stazioni di lavoro CAD e simili. L'hardware di quell'epoca aveva prestazioni molto diverse rispetto a oggi; il multi-threading era più raro, i bus di memoria e le CPU avevano un gap di velocità minore e la GPU faceva poco più del rendering a triangolo a funzione fissa.
Sono state aggiunte sempre più funzioni a funzione fissa. Sono stati aggiunti vari modelli di illuminazione, modalità texture, ecc. Ognuno ha bisogno del proprio stato. Il semplice approccio basato sullo stato ha funzionato quando avevi una manciata di stati. Man mano che venivano aggiunti sempre più stati, l'API iniziò a esplodere. L'API è diventata più imbarazzante ma non si è discostata troppo dalle modalità hardware, poiché erano effettivamente basate su molti switch di stato.
Poi è arrivato l'hardware programmabile. L'hardware è diventato sempre più programmabile, al punto che ora l'hardware supporta un piccolo stato, alcuni programmi forniti dall'utente e molti buffer. Tutto quello stato dell'era precedente doveva essere emulato, così come tutti i driver a funzione fissa di quell'era venivano emulati.
Anche l'hardware è cambiato per essere sempre più parallelo. Ciò ha richiesto altre riprogettazioni hardware che hanno reso le modifiche dello stato della grafica molto costose. L'hardware funziona in grandi blocchi di stato immutabile. A causa di queste modifiche, il driver non poteva semplicemente applicare ogni piccola parte dello stato impostato dall'utente immediatamente, ma doveva impacchettare automaticamente le modifiche e applicarle quando necessario in modo implicito.
L'hardware moderno funziona ancora di più rispetto al classico modello OpenGL. DSA è un piccolo cambiamento che era necessario più di 10 anni fa (originariamente era stato promesso come parte di OpenGL 3.0), simile a quello che ha fatto D3D10. Molte delle modifiche hardware di cui sopra necessitano molto di più del semplice DSA per mantenere OpenGL rilevante, motivo per cui sono ancora disponibili estensioni ancora più grandi che cambiano drasticamente il modello OpenGL . Poi c'è la nuova API GLnext più D3D12, Mantle, Metal, ecc. Non una sola delle quali mantiene l'astrazione obsoleta della macchina a stati.