Finora sono stato in grado di scoprire che c'è stato un passaggio da un circuito molto specializzato che implementa le varie fasi della pipeline grafica ad un approccio più generale. Questa trasformazione si è parzialmente riflessa sulle API 3D sotto forma di shader programmabili. La maggior parte dei transistor sembra essere dedicata a unità SIMD massicciamente parallele che eseguono le effettive istruzioni dello shader.
Corretta. Fondamentalmente, a causa delle dimensioni relativamente grandi delle funzionalità sulle GPU più vecchie, l'unico modo per implementare in modo efficiente cose come illuminazione di base, antialias, mappatura delle trame, geometria, ecc. Era usare una pipeline a "funzione fissa". Hanno sacrificato la flessibilità per motivi di prestazioni perché non avevano una densità di chip sufficiente per essere in grado di implementarla utilizzando un'architettura SIMD massicciamente più generica parallela come le GPU attuali.
È una moderna GPU (pensa Nvidia Fermi) fondamentalmente un insieme di "stupidi" array SIMD che vengono alimentati con istruzioni e dati dalla CPU e varie cache, e tutta la logica effettiva che mappa la pipeline grafica a quelle istruzioni avviene nel driver grafico ?
Alcune cose sono ancora fatte nell'hardware; altri no. Ad esempio, i ROP vengono ancora utilizzati nella fase finale per inviare i dati pixel nel chipset VGA. Nota che sto usando "chipset VGA" qui come termine generico per riferirsi al meccanismo che trasmette un segnale video al tuo monitor, indipendentemente dal fatto che sia veramente "VGA" sotto tutti gli aspetti.
È vero, in generale, che le architetture GPU attuali come Nvidia Fermi e AMD Southern Islands sono, per la maggior parte, CPU massicciamente parallele in cui hanno un set di istruzioni personalizzato e ogni singolo "core" è estremamente debole, ma ci sono un intero sacco di nuclei (a volte diverse migliaia). Ma c'è ancora hardware specifico per la grafica:
La decodifica video hardware viene spesso eseguita, in gran parte, utilizzando chip a funzione fissa. Ciò è particolarmente vero quando è coinvolto il DRM (Digital Restrizione Management). A volte la decodifica video "hardware" significa in realtà un insieme di istruzioni guidate dal firmware che sono appena servite come vecchie attività regolari per i core SIMD. Dipende davvero.
Ad eccezione di pochissime schede Nvidia specifiche per il calcolo (Tesla), quasi tutte le schede grafiche "SIMD generiche" dispongono di una gamma completa di hardware dedicata all'output video. L'uscita video non è la stessa del rendering; gli elementi di uscita a funzione fissa includono codec LVDS / TMDS / HDMI / DisplayPort, HDCP e persino l' elaborazione audio (sostanzialmente un piccolo DSP), poiché HDMI supporta l'audio.
La "memoria grafica" è ancora memorizzata a bordo con le GPU, in modo che non debbano attraversare il bus PCIe a latenza relativamente alta e loquace per colpire la RAM di sistema, che a sua volta è più lenta e impiega più tempo a rispondere rispetto alla più costosa, memoria grafica di qualità superiore, più veloce (ad es. GDDR5) con capacità inferiori ma velocità più elevate rispetto alla memoria di sistema. Il processo di archiviazione delle cose nella memoria grafica e di recuperarle da lì alla GPU o alla CPU è ancora un'operazione a funzione fissa. Alcune GPU hanno il loro tipo di "IOMMU", ma questa unità di gestione della memoria è distinta (separata) dalla CPU. Ciò non è vero, tuttavia, per le recenti GPU Intel integrate nei loro processori (Sandy e Ivy Bridge), dove l'architettura della memoria è quasi del tutto "coerente" memoria di sistema) e le letture dalla memoria grafica sono economiche per la CPU come lo sono per la GPU.
Oppure ci sono alcune unità di controllo da qualche parte nella GPU che traducono le istruzioni in entrata di alto livello e flussi di dati (programmi shader compilati, dati e attributi dei vertici e trame) in istruzioni SIMD effettive e si occupano di sincronizzazione, allocazione della memoria ecc.?
Il linguaggio "nativo" dei SIMD è quasi sempre generato dal driver nel software e non dal firmware della GPU. Ciò è particolarmente vero per le funzionalità di livello di DirectX 9 / OpenGL 2.x. Gli shader scritti in linguaggi di alto livello come HLSL, GLSL o OpenGL ARB assembler shader vengono infine tradotti, dal driver, in istruzioni GPU sbattendo su alcuni registri e facendo i cerchi PCIe richiesti al fine di inviare su buffer batch di calcolo e / o rendering comandi.
Alcune cose, come la tassellatura hardware (DirectX 11 / OpenGL 4.0) vengono nuovamente spinte nell'hardware in modo fisso, in modo simile a come facevano quasi tutto ai vecchi tempi. Questo perché, ancora una volta, i vincoli di prestazione richiedono che il modo più efficiente per eseguire questi calcoli sia disporre di circuiti dedicati, anziché disporre che il firmware o il driver "programmino" i SIMD per farlo.
Ho il sospetto che la realtà si trovi da qualche parte tra questi due estremi, e la risposta sarebbe piuttosto lunga e basata su molte speculazioni (ci deve essere un motivo per alcuni fornitori di GPU che si rifiutano di pubblicare qualsiasi documentazione sui loro prodotti, per non parlare del driver codice sorgente ...), ma qualsiasi suggerimento nella giusta direzione e risorse utili sarebbe molto apprezzato.
AMD e Intel hanno una documentazione molto solida in chiaro sulle loro recenti GPU, oltre a driver grafici open source perfettamente funzionanti per Linux (vedere i progetti Mesa e Direct Rendering Manager). Se guardi un po 'del codice in questi driver, riderai, perché gli autori dei driver grafici devono effettivamente implementare la geometria di cose come disegnare varie forme o modelli, in "software" (ma usando i comandi hardware per inviare il vero legwork all'hardware per l'elaborazione), perché né il firmware della GPU né le funzionalità fisse sono più presenti per elaborarlo completamente nell'hardware :) È un po 'divertente quello che devono fare per supportare OpenGL 1.x / 2.x sul nuovo hardware.
L'evoluzione è andata in questo modo:
- Molto tempo fa (prima che il rendering 3d in tempo reale fosse considerato possibile): il ray-tracing sulla CPU era normale per il rendering non in tempo reale. Per una grafica semplice come quella che vedi nelle prime versioni di Windows, la CPU è stata abbastanza veloce da disegnare forme semplici (rettangoli, caratteri di un carattere, schemi di ombreggiatura, ecc.) Senza hardware a funzione fissa, ma non è riuscita a disegnare elementi troppo complessi.
- Molto tempo fa (OpenGL 1.x): quasi tutto implementato da hardware a stato solido; Le funzioni fisse "elettricamente" erano la norma anche per le operazioni di base
- Qualche tempo fa (OpenGL 2.x): era iniziata una transizione per rendere le GPU più programmabili. "Fragment shader" (aka pixel shader) su hardware di 5 anni può quasi eseguire calcoli arbitrari come una CPU, ma è limitato dall'architettura, che è ancora molto orientata verso la grafica. Pertanto, OpenCL / DirectCompute non sono disponibili su questo hardware.
- Recentemente (OpenGL 3.x): il passaggio alle GPU per uso generale è per lo più completo, ma ovviamente sono ottimizzate per i carichi di lavoro che coinvolgono grandi matrici di dati (pensa l'algebra lineare) che vengono inviati in batch, piuttosto che CPU che possono operare in modo efficiente su lunghe sequenze di dati molto piccoli (1 + 1, 2 * 4, 5 * 6 in sequenza, ecc.) L'elaborazione per scopi generici è disponibile tramite OpenCL, CUDA, ecc. ma l'hardware non è ancora un "coprocessore SIMD" completo perché (a) devi ancora martellare i registri specifici dell'hardware per accedere alla funzionalità GPU; (b) la lettura dalla GPU VRAM è molto lenta a causa del sovraccarico del bus PCIe (la lettura dalla GPU non è molto ottimizzata sull'architettura attuale); (c) l'architettura della memoria e della cache non è coerente con la CPU; un sacco di hardware a funzione fissa legacy è ancora in circolazione.
- Presente (OpenGL 4.x): sbarazzarsi di un sacco di hardware a funzione fissa legacy. Migliorata in qualche modo la latenza di lettura della GPU. Le IOMMU consentono una mappatura (tradotta) assistita dall'hardware tra VRAM e memoria di sistema. Inoltre ha introdotto la tassellatura hardware, riportando elementi di funzione fissa.
- Futuro ( HSA): La GPU è fondamentalmente un coprocessore. È quasi completamente integrato con la CPU con un'impedenza minima (per letture / scritture) tra GPU e CPU, anche per GPU dedicate sul bus PCIe. Architettura di memoria pienamente coerente - "mi memoria es su memoria" (la mia memoria è la tua memoria). I programmi di spazio utente possono leggere da "VRAM" proprio come leggono dalla memoria di sistema senza shim del driver e l'hardware se ne occupa. Hai la CPU per l'elaborazione "seriale" (fai questo, poi fallo, poi fai questo, poi fallo) per modeste quantità di dati e la GPU per l'elaborazione "parallela" (esegui questa operazione su questo enorme set di dati e dividila come ritieni opportuno). La scheda su cui si trova la GPU potrebbe avere ancora ROP, codec HDMI, ecc. Ma questa roba è necessaria per l'output del display,