Nonostante i progressi, le GPU moderne hanno ancora rasterizzatori fissi. Altamente personalizzabile, con shader programmabili ma tuttavia non completamente programmabili.

Perché?

Perché le GPU non possono essere semplicemente dispositivi estremamente paralleli con unità di elaborazione universali in cui il rasterizer è solo un software per quel dispositivo fornito dall'utente?

Avere hardware a funzione fissa è così vantaggioso dal punto di vista delle prestazioni che tale approccio è irrealizzabile?

gpu rasterizer

— mrpyo
fonte

"Perché un'unità di elaborazione grafica non è in un'unità di elaborazione universale", è questa la domanda?

— Andreas,

@Andreas No, la mia domanda è come è indicato nel post. Perché i rasterizzatori sono ancora una parte hardware, quando potrebbero essere eseguiti in software (in realtà potrebbero già essere eseguiti con OpenCL o shader di calcolo). La domanda è perché non è comune ... forse è semplicemente una performance, non lo so, ecco perché lo sto chiedendo ...

— MrPyo

Puoi bypassare la rasterizzazione e implementare il tuo rasterizzatore con unità di calcolo su GPU moderne e in effetti conosco persone che lo fanno per scopi specifici.

— JarkkoL,

I rasterizzatori convertono i poligoni vettoriali in un mucchio di pixel che possiamo illuminare. Quando non avremo più pixel o smettere di usare la geometria vettoriale, non avremo più bisogno di rasterizzatori. Indipendentemente dall'aspetto del resto della pipeline, alla fine della giornata (o frame), hai bisogno di pixel. Il rasterizzatore ci dice solo di quali pixel siamo preoccupati per un dato triangolo. Tutto ciò è programmabile: se si desidera un output diverso dal rasterizzatore, inviare triangoli diversi a modo suo. Oppure disegna tutto su una trama di rendering in uno shader di calcolo e trasferiscilo sullo schermo con un quad allineato alla vista.

— 3Dave

In breve, i motivi delle prestazioni sono il motivo per cui non sono programmabili.

Storia e mercato

In passato, c'erano core separati per i processori di vertici e frammenti per evitare progetti di FPU gonfiati. Ad esempio, c'erano alcune operazioni matematiche che potevi fare solo nel codice dello shader di frammenti (perché erano principalmente rilevanti solo per gli shader di frammenti). Ciò produrrebbe gravi colli di bottiglia hardware per applicazioni che non hanno sfruttato al massimo il potenziale di ciascun tipo di core.

Quando gli shader programmabili divennero più popolari, furono introdotte unità universali. Sempre più fasi della pipeline grafica sono state implementate nell'hardware per facilitare il ridimensionamento. Durante questo periodo, anche GPGPU è diventata più popolare, quindi i fornitori hanno dovuto incorporare alcune di queste funzionalità. È comunque importante notare che la maggior parte delle entrate derivanti dalle GPU erano ancora videogiochi, quindi questo non poteva interferire con le prestazioni.

Alla fine un grande giocatore, Intel, ha deciso di investire in rasterizzatori programmabili con la loro architettura Larrabee . Questo progetto avrebbe dovuto essere innovativo, ma la performance era apparentemente inferiore a quanto desiderato . È stato chiuso e alcune parti sono state recuperate per i processori Xeon Phi. Vale la pena notare, tuttavia, che gli altri fornitori non lo hanno implementato.

Tentativi di rasterizzatori software

Ci sono stati alcuni tentativi di rasterizzazione attraverso il software, ma tutti sembrano avere problemi con le prestazioni.

Uno sforzo notevole è stato un tentativo di Nvidia nel 2011 in questo documento . È stato rilasciato vicino a quando Larrabee è stato chiuso, quindi è molto probabile che questa sia stata una risposta. Indipendentemente da ciò, ci sono alcuni dati sulle prestazioni in questo, e la maggior parte di essi mostra prestazioni più volte più lente rispetto ai rasterizzatori hardware.

Problemi tecnici con la rasterizzazione del software

Ci sono molti problemi che sono stati affrontati nel documento Nvidia. Ecco alcuni dei problemi più importanti con i rasterizzatori software:

Problemi maggiori

Interpolazione: l'implementazione hardware genera equazioni di interpolazione in hardware specializzato. Questo è lento per il renderizzatore software poiché doveva essere eseguito nello shader di frammenti.
Anti-aliasing: c'erano anche problemi di prestazioni con l'anti-aliasing (in particolare con la memoria). Le informazioni relative ai campioni sub-pixel devono essere archiviate nella memoria su chip, che non è sufficiente per contenere questo. Julien Guertault ha sottolineato che la cache / cache delle texture potrebbe essere più lenta con il software. MSAA ha sicuramente dei problemi qui perché trabocca la cache (le cache non di trama) e va in memoria fuori dal chip. I rasterizzatori comprimono i dati archiviati in quella memoria, il che aiuta anche con le prestazioni qui.
Consumo di energia: Simon F ha sottolineato che il consumo di energia sarebbe inferiore. L'articolo ha menzionato che gli ALU personalizzati sono in rasterizzatori (il che ridurrebbe il consumo di energia), e questo avrebbe senso dal momento che le unità di elaborazione di frammenti e vertici in passato utilizzavano set di istruzioni personalizzate (quindi probabilmente anche ALU personalizzate). Sarebbe certamente un collo di bottiglia in molti sistemi (ad esempio, mobili), sebbene ciò abbia implicazioni oltre le prestazioni.

Sommario

TL; DR: ci sono troppe inefficienze che il rendering del software non può superare e queste cose si sommano. Ci sono anche molte limitazioni più grandi, specialmente quando hai a che fare con larghezza di banda VRAM, problemi di sincronizzazione e calcoli extra.

— assi
fonte

Non credo che sia necessario archiviare i campioni subpixel se il filtraggio a riquadri è sufficiente, quindi è possibile eseguire solo le medie correnti.

— joojaa,

Sospetto che il campionamento delle texture e la cache siano probabilmente anche aree in cui le implementazioni hardware consentono prestazioni altrimenti impossibili da raggiungere con le implementazioni software.

— Julien Guertault,

@aces Un altro elemento degno di nota è il potere. L'hardware dedicato farà lo stesso lavoro in genere con una frazione del budget di potenza e, con la limitazione della potenza già un problema, specialmente sui dispositivi mobili, andare completamente programmabile lo peggiorerebbe notevolmente.

— Simon F,

@JulienGuertault Il punto giusto, ma penso che questo sia principalmente applicabile a MSAA. I risultati dei test sembrano indicare che questo non è un grosso problema quando tutto si adatta alla memoria su chip (anche se questo potrebbe avere un impatto sulle prestazioni a prescindere).

— assi

@SimonF Penso che sia anche un ottimo punto. L'ho incluso nella risposta.