Tier e Feature Level: vediamo di fare un po' di chiarezza

[Alessio89]

In quella tabella Maxwell 2.0 non sfigura rispetto a GCN 1.2

Ma come hai gia' detto,
sicuramente ci sono un sacco di informazioni assenti,
imperfette, non definitive ecc...

Comunque attendo Maxwell 2.5/3.0,
insomma le schede che usciranno dopo l'estate.

Maxwell 2.0 ha sicuramente dei pregi per il rendering, è il primo a supportare le tiled resources tier 3 (ovvero le volumetriche che sfortunatamente non possono essere emulate tramite un semplice array di 2d) ed il conservative rasterization tier1.
Tuttavia per vedere algoritmi di illuminazione globale veramente rivoluzionari (roba da far impallidire VXGI) bisognerà attendere almeno il tier 2 del conservative rasterization (il tier 1 è inadatto a tale scopo) e ad un sistema di banda per la comunicazione fra CPU e GPU nettamente più performante del PCI-E (e con latenze decisamente inferiori). NVLINK per quanto bello sia su carta quanto a prestazioni difficilmente lo vedremo su desktop in meno di 3-4 anni. E in 3-4 anni di acqua sotto i ponti ne passa parecchia.
Le informazioni assenti, o meglio che non ho riportato, riguardano tutte le altre funzionalità singole dato che per quelle il supporto driver non è ancora definitivo per nessun hardware, in particolar modo il supporto multi-gpu è ancora ai primi stadi su geforce e intel, mentre su AMD non è ancora stato introdotto nei driver attuali (lo si può constatare con l'ultimo SDK pubblico di Windows 10).
Ci sarebbero infine un sacco di mini test da fare su un numero enorme di formati DXGI per quanto riguarda il supporto a MSAA e UAV, ma sinceramente per quelli non ho la minima intenzione di mettermi a scriverne il codice, si tratta in fin dei conti di formati usati solitamente come ottimizzazioni o comunque non basilari nello sviluppo. Per quelli il supporto potrebbe variare enormemente da GPU a GPU e per i i più curiosi potranno usare il caps-viewer di Microsoft non appena quello supporterà anche D3D12..

[Alessio89]

Leggendo diversi forum italiani ... posso confermare che nonostante molti utenti abbiano letto questo articolo, in pochi in realtà ci hanno capito qualcosa. Le FL 12.1 per moltissimo sono ancora un aspetto fondamentale per il pieno supporto alle DX12.

Vabbé, vorrà dire che per farli contenti Microsoft taglierà metà delle funzionalità di rendering e programmazione solo per loro, così avranno il loro pieno supporto.
Io piuttosto vorrei qualcosa di simile al XDMA di AMD sulle Geforce, in modo da eliminare quegli odiosi ponticelli.

[gridracedriver]

Bravo Alessio, vedrai che prima o poi il duro lavoro e l'impegno che ci metti ti ripagheranno a dovere

[Paro]

...

Le castronerie si sparano con le risposte, non con le domande

Che esistano o meno le domande stupide è un tema su cui si dovrebbe aprire un dibattito a parte

...

Sì, i tier del resource binding sono fissi, è stata praticamente la prima cosa stabilita e ormai i driver riportano la situazione finale al riguardo da tempo. Per altre funzionalità invece non è ancora detta l'ultima parola, specialmente per le ultime introdotte.
Gli sviluppatori devono tener conto dei tier dell'hardware che vogliono supportare, la cosa è piuttosto semplice da gestire: una volta interrogato l'hardware basta usare ad esempio dei percorsi condizionali diversi se si sa che il proprio software può sforare i limiti di un tier. Per le GPU AMD non sarà necessaria alcuna modifica, il che potenzialmente permette di diminuire la complessità del codice da eseguire se il programma gira sotto GPU AMD, il che può comportare ulteriore minor overhead (sovraccarico) della CPU e della GPU.

Sottolineo il "potenzialmente" perché, forse sarò un po' pessimista, non ci credo molto in questa ottimizzazione per amd.
Che GCN lasci più libertà agli sviluppatori non significa che questi la sfrutteranno: se tanto il codice per le gpu nvidia devono scriverselo, possono lasciarlo in esecuzione anche sulle amd, no?
Già mi vedo gli "ingegneri software" che insistono per "uniformare" il codice e lasciare tutto così com'è, basta che funzioni.
E prendendo il caso estremo di sviluppo alla Nvidia Gameworks? Col cavolo che diminuiscono l'overhead per AMD.

...

I feature level sono indicativi nel senso che servono solo a raggruppare determinate funzionalità in un colpo solo. In pratica sono una comodità per chi sviluppa.
Per capire quale feature level supporta una GPU basta provare a creare device (l'interfaccia che può essere vista come la rappresentazione virtuale della GPU) con un determinato feature level, se la creazione ha successo la GPU supporta quel determinato feature level, altrimenti no. Iterando in maniera decrescente fra i vari feature level che si vogliono avere alla fine si ottiene una device con il feature level più alto supportato dalle periferica.
Per tutte le altre funzionalità si interroga la device creata.

In pratica 'sti raggruppamenti servono a risparmiare solo qualche riga di codice e basta?
Mi chiedo allora perché si siano sprecati a farli questi "feature level", ma soprattutto è incredibile quanta retorica evidentemente inutile si stata sprecata sui portali di informatica, se davvero la questione è solo questa banalità.

[Alessio89]

Sottolineo il "potenzialmente" perché, forse sarò un po' pessimista, non ci credo molto in questa ottimizzazione per amd.
Che GCN lasci più libertà agli sviluppatori non significa che questi la sfrutteranno: se tanto il codice per le gpu nvidia devono scriverselo, possono lasciarlo in esecuzione anche sulle amd, no?
Già mi vedo gli "ingegneri software" che insistono per "uniformare" il codice e lasciare tutto così com'è, basta che funzioni.
E prendendo il caso estremo di sviluppo alla Nvidia Gameworks? Col cavolo che diminuiscono l'overhead per AMD.

Se un gioco DX12 sarà scritto bene, cercherà di fare i salti mortali nella gestione delle risorse solo quando necessario, e col tier 3 questo non dovrebbe accadere (a patto di fare enormi stupidate a livello di codice), con il tier 2 e soprattutto il tier 1 può servire una più continua e minuziosa gestione delle risorse, il che aumenta l'overhead sia di CPU che di GPU.

Certo, nessuno impedisce agli sviluppatori di scrivere codice esclusivamente pensato per il tier 1, ma questo non comporta sensibili risparmi di risorse umane e di tempo, e si rivela contro-producente a livello prestazionale. Un codice scritto bene dovrebbe essere scritto cercando di gestire eventuali limitazioni solo se necessario.

Per quanto riguarda gameworks, sicuramente verrà ottimizzato per maxwell 2.0, che è un tier 2. A meno che NV non voglia volutamente sabotare l'hardware tier 3 (il che sarebbe poco intellicente, in futuro si auspica che anche le prossime architetture geforce siano delle tier 3), il problema principale di gameworks rimane l'essere distribuito come libreria e non come sorgente completo da farci quel che si vuole.

Le console vorrei inoltre ricordarti che montano GPU tier 3 (sebbene personalmente non conosco la situazione della PS4, immagino che non abbiano cercato a tutti i costi di mettere delle assurde limitazioni nel binding sulla console della Sony), pertanto parte del lavoro di logica nel supporto del tier 3 c'è già nei titoli multi-piattaforma.

Riassumendo: è nell'avere a che fare con i tier 1 e 2 del resource-binding a dover complicare il codice, non con il tier 3. Il grosso delle complicazioni possono essere saltate semplicemente con un'espressione condizionale il cui costo è trascurabile, cosa non vero per un'eventuale mancanza.

In pratica 'sti raggruppamenti servono a risparmiare solo qualche riga di codice e basta?
Mi chiedo allora perché si siano sprecati a farli questi "feature level", ma soprattutto è incredibile quanta retorica evidentemente inutile si stata sprecata sui portali di informatica, se davvero la questione è solo questa banalità.

Non è risparmiare solo qualche riga di codice, è il dover risparmiare - qualora sia necessario - una minuziosa e continua gestione dei binding ad ogni frame. Allocare e de-allocare ogni volta dei descrittori, dei sampler aumenta l'overhead e aumenta il numero delle draw-call richieste. Prima tutto questo veniva in parte eseguito dal runtime di D3D11, ora lo si deve fare a manina.
Il risparmiare qualche riga di codice può avere impatti prestazionali più sensibili di quanto immagini, il problema non è quante righe di codice si risparmiano, ma cosa quelle righe risparmiate vanno a fare. Ti ricordo che stiamo parlando di videogiochi, ovvero simulazioni con interazioni tempo reale da parte dell'utente, non di programmini e tutorial di Java dove devi far animare una GIF.

[Paro]

...
Riassumendo: è nell'avere a che fare con i tier 1 e 2 del resource-binding a dover complicare il codice, non con il tier 3. Il grosso delle complicazioni possono essere saltate semplicemente con un'espressione condizionale il cui costo è trascurabile, il cui costo è del tutto trascurabile, cosa non vero per un'eventuale mancanza.

Sì, questo lo avevo capito, ma per mia natura tendo a non fidarmi troppo di programmatori e sviluppatori; ci sta sempre un po' troppa differenza tra quello che "fanno" e quello che "dovrebbero fare".

...

Non è risparmiare solo qualche riga di codice, è il dover risparmiare - qualora sia necessario - una minuziosa e continua gestione dei binding ad ogni frame. Allocare e de-allocare ogni volta dei descrittori, dei sampler aumenta l'overhead e aumenta il numero delle draw-call richieste. Prima tutto questo veniva in parte eseguito dal runtime di D3D11, ora lo si deve fare a manina.
Il risparmiare qualche riga di codice può avere impatti prestazionali più sensibili di quanto immagini, il problema non è quante righe di codice si risparmiano, ma cosa quelle righe risparmiate vanno a fare.

Con il "risparmiare righe di codice" mi riferivo all'interrogazione dell'hardware di cui avevi fatto l'esempio.

Ti ricordo che stiamo parlando di videogiochi, ovvero simulazioni con interazioni tempo reale da parte dell'utente, non di programmini e tutorial di Java dove devi far animare una GIF.

Già, ma a me povero scemo mi ci vogliono far diventare proprio

[Alessio89]

Sì, questo lo avevo capito, ma per mia natura tendo a non fidarmi troppo di programmatori e sviluppatori; ci sta sempre un po' troppa differenza tra quello che "fanno" e quello che "dovrebbero fare".

Solitamente a limitare queste cose sono gli editori, non tanto gli sviluppatori del back-end grafico.

Con il "risparmiare righe di codice" mi riferivo all'interrogazione dell'hardware di cui avevi fatto l'esempio.

L'interrogazione della device per richiedere i cap-bits sono si e no 3-4 righe di codice C++: un'allocazione per l'oggetto di struttura contenente le informazioni, una chiamata per farsi ritornare la struttura compilata, e un'operazione di accesso all'elemento che di cui si vuole saperne il risultato o valore. Se uno è pigro può fare copia&incolla dall'esempio su MSDN.

Già, ma a me povero scemo mi ci vogliono far diventare proprio

Lol, se mastro ronco non è cambiato, una volta passata la prima parte dell'esame per passare la seconda basta far visualizzare una finestra vuota o poco più, e puoi portarti gli esempi di codice in chiavetta ^_^

[Alessio89]

https://forum.beyond3d.com/threads/dire ... st-1849865

Oh ma guarda, non sono l'unico a pensarla così, e costoro ne sanno parecchio

[Fottemberg]

Su B3D la discussione è abbastanza pacata, mentre sul forum di Anandtech la presenza di fanboy NVIDIA è delirante.

[Alessio89]

Per tutti quelli che credono sia una gran confusione, forse fareste meglio a darvi un'occhiata a quella che è la situazione in Direct3D 9: https://msdn.microsoft.com/en-us/library/bb172513.aspx Si noti per favore che molti valori della struttura dati D3DCAPS9 ritornano a loro volta delle bit-mask (dei numeri binari dove ogni singolo bit indica un valore) di singoli ulteriori caps-bits.
Quello era un gran casino, non D3D12.