Devo davvero usare un'API grafica?

È necessario utilizzare le API grafiche per ottenere l'accelerazione hardware in un gioco 3D? In che misura è possibile liberarsi dalle dipendenze dalle API della scheda grafica come OpenGL, DirectX , CUDA, OpenCL o qualsiasi altra cosa?

Posso creare la mia API grafica o libreria per il mio gioco? Anche se è difficile, è teoricamente possibile per la mia applicazione 3D contattare autonomamente il driver grafico e renderizzare tutto sulla GPU?

Penso che molte delle risposte manchino un punto importante: puoi scrivere app che accedono direttamente all'hardware, ma non sui moderni sistemi operativi . Non è solo un problema di tempo, ma un problema "non hai scelta".

Windows, Linux, OSX, ecc. Vietano tutti l'accesso diretto all'hardware ad applicazioni arbitrarie. Questo è importante per motivi di sicurezza: non si desidera che nessuna app casuale sia in grado di leggere la memoria GPU arbitraria per lo stesso motivo per cui non si desidera che nessuna app casuale sia in grado di leggere la memoria di sistema. Cose come il framebuffer per il tuo conto bancario o quello che non vive nella memoria della GPU. Volete che roba isolata e protetta e l'accesso controllato dal vostro sistema operativo.

Solo i driver possono parlare direttamente con la maggior parte dell'hardware e l'unico modo per parlare con il driver è tramite l'HAL esposto del sistema operativo e l'interfaccia proprietaria e incompatibile di ciascun driver. L'interfaccia del driver non sarà diversa solo per ciascun fornitore, ma differirà anche tra le versioni del driver stesso, rendendo quasi impossibile comunicare direttamente con l'interfaccia in un'applicazione consumer. Questi livelli sono spesso coperti da controlli di accesso che limitano ulteriormente la possibilità per un'applicazione di accedervi.

Quindi no, il tuo gioco non può semplicemente usare l'hardware direttamente, a meno che ovviamente non ti occupi solo di sistemi operativi non sicuri come DOS, e l'unica opzione possibile per un gioco su moderni sistemi operativi di consumo è quella di scegliere come target un'API pubblica come DirectX, OpenGL o Vulkan.

Praticamente è necessario, sì. È necessario perché a meno che tu non voglia passare anni a scrivere quello che è essenzialmente il codice driver per la moltitudine di diverse configurazioni hardware là fuori, devi usare un'API che unifichi con i driver esistenti scritti dai fornitori di GPU per tutti i sistemi operativi e hardware popolari.

L'unica alternativa realistica è che non usi l'accelerazione 3D, ma preferisci il rendering del software che, a condizione che sia scritto in qualcosa di veramente portatile come C, sarà in grado di funzionare praticamente su qualsiasi sistema / dispositivo. Va bene per i giochi più piccoli ... qualcosa come SDL è adatto a questo scopo ... ce ne sono anche altri là fuori. Ma questo manca di capacità 3D intrinseche, quindi dovresti costruirle tu stesso ... il che non è un compito banale.

Ricorda inoltre che il rendering della CPU è inefficiente e presenta scarse prestazioni rispetto alle GPU.

API come OpenGL o DirectX sono parzialmente implementate dal sistema operativo e parzialmente implementate dal driver grafico stesso.

Ciò significa che quando si desidera creare la propria API di basso livello che si avvale delle funzionalità delle GPU moderne, è essenzialmente necessario scrivere un proprio driver grafico. Fare in modo che il tuo driver funzioni con tutte le comuni schede grafiche sarebbe una vera sfida, soprattutto perché i fornitori spesso non sono molto aperti con le loro specifiche.

Avvia il tuo PC in MS-DOS. Quindi, usando la tua copia dell'Enciclopedia dei programmatori di giochi per PC , puoi scrivere direttamente nel VESA della scheda registri e nella memoria video. Ho ancora il codice che ho scritto 20 anni fa per fare questo e rendere il 3D rudimentale nel software.

In alternativa, puoi semplicemente usare DirectX; è un livello di astrazione davvero sottile e ti consente anche di scrivere direttamente nei buffer video e poi di scambiarli sullo schermo.

C'è anche l'approccio estremo di costruire il tuo hardware video .

Le altre risposte rispondono abbastanza bene alla tua domanda principale: tecnicamente, è possibile, ma in pratica, se il tuo obiettivo è ampliare la tua base di clienti, stai effettivamente facendo il contrario. Pur sprecando un'enorme quantità di lavoro per supportare le migliaia di diverse configurazioni hardware e del sistema operativo che è necessario supportare.

Tuttavia, ciò non significa che devi dipendere al 100% da una particolare API. Puoi sempre codificare il tuo livello di astrazione, quindi scambiare le implementazioni più specifiche (ad esempio un'implementazione DirectX, un'implementazione OpenGL, ...) dentro e fuori.

Anche allora, probabilmente non ne vale la pena. Basta scegliere qualcosa che funzioni abbastanza bene per i tuoi scopi, ed essere fatto con esso. Sei un creatore di giochi indie - devi concentrarti sulle cose che creano il gioco, non sui minutae. Crea il gioco!

In sintesi: in teoria puoi, ma è impossibile e non otterrai alcun vantaggio. Le limitazioni oggi le API sono diminuite ogni giorno, hai CUDA, OpenCL e shader. Quindi avere il pieno controllo non è più un problema.

Spiegazione più completa:

Rispondere a questo è un sì noioso . La vera domanda è: perché ?

Difficilmente immagino perché vorresti fare questo se non per scopi di apprendimento. Devi sapere che a un certo punto, gli sviluppatori avevano la libertà di fare qualsiasi cosa con le loro implementazioni di rendering della CPU, tutti avevano una propria API, avevano il controllo di tutto nella "pipeline". Con l'introduzione di pipeline fisse e GPU, tutti hanno cambiato ..

Con le GPU ottieni prestazioni "migliori", ma perdi molta libertà. Gli sviluppatori grafici stanno spingendo per riavere quella libertà. Quindi, ogni giorno più pipeline di personalizzazione. Puoi fare quasi tutto usando CUDA / OpenCL e persino shader, senza toccare i driver.

Vuoi parlare con l'hardware. Devi usare un modo per parlare con l'hardware. In questo modo è l'interfaccia per l'hardware. Ecco cosa sono OpenGL, DirectX, CUDA, OpenCL e quant'altro.

Se arrivi a un livello inferiore, stai semplicemente utilizzando un'interfaccia di livello inferiore, ma stai ancora utilizzando un'interfaccia, solo una che non funziona con tante schede diverse rispetto a quella di livello superiore.

Per ottenere l'accelerazione hardware 3D senza utilizzare un'API tradizionale, è essenzialmente necessario scrivere il proprio codice per duplicare la funzionalità del driver grafico. Quindi il modo migliore per imparare come farlo è guardare il codice del driver grafico.

Per le schede NVIDIA, dovresti guardare il progetto nouveau open source . Hanno una raccolta di grandi risorse qui .

Per altre marche di schede grafiche, è possibile trovare progetti e documentazione simili.

Si noti che, come è stato menzionato in altre risposte, i sistemi operativi più moderni impediranno ai programmi di spazio utente di accedere direttamente all'hardware, quindi sarà necessario scrivere il codice e installarlo come driver del sistema operativo. In alternativa, è possibile utilizzare il sistema operativo FreeDOS, che non ha tali restrizioni e dovrebbe consentire all'utente (in teoria) di accedere direttamente all'hardware e consentire di scrivere un programma regolare che esegua il rendering della grafica con accelerazione hardware 3D. Si noti che, anche sfruttando il codice da un driver grafico open source esistente, questa sarebbe un'enorme quantità di lavoro non banale (e per quanto ne so, non è mai stato fatto e, per vari motivi, potrebbe in realtà non essere tecnicamente possibile).

Sbarazzarsi di DirectX o OpenGl non eliminerebbe le dipendenze, ne introdurrebbe di più. Le altre risposte contengono già diversi punti positivi per cui potrebbe non essere nemmeno possibile parlare direttamente con l'hardware grafico (almeno non è fattibile), ma la mia prima risposta sarebbe: se in effetti scrivessi una libreria che estrae tutti i comuni 3d software di grafica in una singola API che avrebbe effettivamente riscritto DirectX / OpenGl. Se avessi usato il tuo codice per scrivere un gioco avresti aggiunto la tua nuova libreria come nuova dipendenza, proprio come adesso hai DirectX / OpenGl come dipendenza.

Usando DirectX o OpenGl le tue dipendenze dicono sostanzialmente "Questo codice dipende da una libreria per fornire il codice che spiega come eseguire determinati comandi su diverse schede grafiche". Se fossi andato senza una libreria del genere, avresti introdotto la dipendenza di "Questo codice dipende dall'hardware grafico che si comporta esattamente allo stesso modo dell'hardware esistente al momento della creazione del gioco".

Astrazioni come OpenGl o DirectX consentono ai produttori di hardware di fornire il proprio codice (driver) che portano a una base di codice comune, quindi è più probabile che i giochi vengano eseguiti su hardware che non esisteva nemmeno quando il gioco è stato scritto.

Prima di tutto, CUDA e OpenCL non sono API grafiche. Sono API di calcolo.

Il problema con la scrittura della tua API grafica è che è molto complesso. È possibile interfacciarsi direttamente con l'hardware, ma non è garantito che se funziona su un sistema con CPU X, GPU X, quantità X di RAM e sistema operativo X funzionerà su un sistema con CPU Y, GPU Y, ecc. Un buon punto è che DirectX funziona con i driver in modalità kernel. È radicato nel kernel. Inoltre, le API grafiche non sono costruite per supportare le GPU. Le GPU (e i loro driver) sono costruite per supportarle. Quindi praticamente non è possibile creare un'API grafica a meno che non si costruisca il proprio sistema operativo e si utilizzino gli interrupt VGA forniti da x86. Ma non saresti ancora in grado di interfacciarti correttamente con la GPU e rimarrai bloccato a bassa risoluzione.

Capisco che vuoi costruire tutto da solo e non usare un motore o qualcosa del genere. Ma creare la tua API grafica creerebbe solo un inconveniente per l'utente.

Puoi scrivere il tuo driver e API, non c'è niente che ti fermi se non le tue capacità e livelli di conoscenza. Se nient'altro sarebbe una buona esperienza di apprendimento, il vero problema è che senza avere molta esperienza grafica precedente, anche se sei un grande programmatore probabilmente non sarai in grado di fare ciò che devi fare ... o addirittura per iniziare.

Tuttavia l'interfaccia che creerai sarà più facile da usare e più stabile per te di qualcosa costantemente aggiornato alle tue spalle. Quindi è un po 'sorprendente per me che più persone non seguano questa strada, ma la realtà è che poche persone hanno l'acume tecnico e nessuno vuole pagare qualcuno per anni per imparare a fare tutto questo, quindi possibilmente avere lasciano la compagnia e li lasciano in balia. La cosa positiva della standardizzazione è che rende i dipendenti molto più sacrificabili e riduce i rischi.