View Full Version : ARCHITETTURA UNIFICATA
Andrea deluxe
12-07-2006, 17:30
Ma voi siete disposti a comperare una nuova sk video NVIDIA dx10 che non abbia gli shaders unificati!
io NO!
come la pensate voi!
Ma voi siete disposti a comperare una nuova sk video NVIDIA dx10 che non abbia gli shaders unificati!
io NO!
come la pensate voi!
perchè no?
bisogna vedere come si orienteranno i programmatori, l'architettura a shaders unificati non è tanto semplice da sfruttare e sopratutto non offre sempre benefici
bYeZ!
AnarchyTop
12-07-2006, 18:03
perchè no?
bisogna vedere come si orienteranno i programmatori, l'architettura a shaders unificati non è tanto semplice da sfruttare e sopratutto non offre sempre benefici
bYeZ!
Quoto !!! Hai perfettamente ragione...
Andrea deluxe
13-07-2006, 09:17
ma qualcuno sa qualcosa della nuova architettura nvidia?
oltre agli shader non unificati! :stordita:
Window Vista
13-07-2006, 13:00
ma qualcuno sa qualcosa della nuova architettura nvidia?
oltre agli shader non unificati! :stordita:
na merda......
Crasher89
13-07-2006, 13:13
na merda......
non credo proprio si a una merda come dici tu...cmq credo ke per ora dovrebbero stare alla pari,o almeno senza grandi differenze...poi piu in la se verrà sfruttata la tecnologia a shader unificati si sarà passati ad una nuova generazione di schede e nvidia avrà gli shader unificati.
è un po come quando nvidia ha messo il supporto ai PS 3.0 e ati aveva ancora i 2.0 o2.0b
Andrea deluxe
13-07-2006, 14:18
possibile che sia la solita minestra riscaldata con un po' di sale in piu'? :mc:
magari si scopre che ha lo stesso difetto dell' fp16-32(che sta quasi sempre a 16) che nvidia si porta dietro dall' nv30! :doh:
CRYSIS sara' il banco di prova, pero' vorrei che qualcuno espertissimo postasse caratteristica sconosciuta! :read:
yossarian
13-07-2006, 15:54
possibile che sia la solita minestra riscaldata con un po' di sale in piu'? :mc:
magari si scopre che ha lo stesso difetto dell' fp16-32(che sta quasi sempre a 16) che nvidia si porta dietro dall' nv30! :doh:
CRYSIS sara' il banco di prova, pero' vorrei che qualcuno espertissimo postasse caratteristica sconosciuta! :read:
impossibile, dato che lo sm4.0 prevede l'utilizzo di fp32.
NV30, magari andasse a fp16 :D
Andrea deluxe
13-07-2006, 16:17
YOSS
solo questo sai?
yossarian
13-07-2006, 17:42
YOSS
solo questo sai?
no :D
TheDarkAngel
13-07-2006, 18:09
Ma voi siete disposti a comperare una nuova sk video NVIDIA dx10 che non abbia gli shaders unificati!
io NO!
come la pensate voi!
non importa come sia stata progettata dipende solo ed esclusivamente da quanto rende... se andrà meglio della controparte ati perchè no?
Window Vista
13-07-2006, 18:12
non importa come sia stata progettata dipende solo ed esclusivamente da quanto rende... se andrà meglio della controparte ati perchè no?
I miracoli non succedono :Prrr: .
Nvidia se fa una cosa buona è già molto!! :Prrr: :Prrr: :Prrr: :Prrr:
Brightblade
13-07-2006, 19:19
na merda......
I miracoli non succedono :Prrr: .
Nvidia se fa una cosa buona è già molto!! :Prrr: :Prrr: :Prrr: :Prrr:
Azz, allora credo che ne staro' alla larga, quasi quasi stavo per farmi fregare ancora da nvidia. Grazie per i post illuminanti e ricchi di contenuti :asd:
Ma voi siete disposti a comperare una nuova sk video NVIDIA dx10 che non abbia gli shaders unificati!
io NO!
come la pensate voi!
Ma che domanda e' :mbe: ? Dipende da come performa e come compete con la controparte nella stessa fascia di prezzo (risposta fin troppo scontata).
Andrea deluxe
13-07-2006, 23:06
la domanda era per creare qualke accesa discussione!
pero' non ne vedo nemmeno l'ombra!
la domanda era per creare qualke accesa discussione!
pero' non ne vedo nemmeno l'ombra!
:mbe: ma se non hai argomenti da portare che discussione vuoi che venga fuori?
bYeZ!
JoeLatino
14-07-2006, 09:47
ciao leggete un po' qui....
Questo articolo
http://arith17.polito.it/final/paper-164.pdf
pubblicato da due ingegneri di NVIDIA, ci annuncia che il G80 incorporerà un nuovo tipo di unità di calcolo: l'unità d'interpolazione multifunzione. Nelle attuali GPU, le unità d'interpolazione sono incaricate di calcolare alcune proprietà (come il colore, la profondità o la struttura) di ogni pixel con interpolazione a partire dagli attributi di ogni vertice. Altre unità, sono inoltre necessarie per calcolare funzioni più complesse, come i logaritmi, seno, coseno, ecc...
Queste unità, che occupano un posto apposito sul die, sono però raramente utilizzate a pieno regime. NVIDIA ha dunque cercato di creare delle unità di calcolo che raggruppano tutte le funzionalità su evidenziate. È una problematica molto simile alla riunificazione del pixel e vertex shaders sulle GPU DirecX 10. Gli autori dell'articolo evidenziano minori dimensioni del die e dei consumi a fronte di un immutato livello prestazionale.
Praticamente con questa modifica almeno per ora non sara' piu' necessaria l'unificazione delle varie unita' vertex!
altre notizie non ufficiali da prendere 'con le pinze' :
Il chip sarà in grado di processare 32 pixel shaders + 16 vertex and geometry Shaders per ogni clock, oltre ad essere rispondente a Shader Model 4.0 e compatibile al 100% con le directx 10
La prima serie di schede g80 dovrebbe uscire verso la fine di settembre ;)
perchè no?
bisogna vedere come si orienteranno i programmatori, l'architettura a shaders unificati non è tanto semplice da sfruttare e sopratutto non offre sempre benefici
bYeZ!
Beh io non direi che non offre sempre benefici. In realtà, teoricamente, un'architettura a shader unificati è sempre avvantaggiata in termini di bilanciamento di carico rispetto ad una classica.
Prendiamo due architetture entrambe dotate nel complesso di 64 unità di calcolo. Quella classica distribuisce le 64 unità così: 16 per il vertex shading e 48 per il pixel shading. Quella unificata, invece, le può usare a suo piacimento come vuole.
In questo caso l'architettura a shader unificati è sempre avvantaggiata rispetto ad una non unificata a patto però che
- le sue unità di calcolo siano efficienti esattamente come quelle dell'architettura classica sia nel calcolo dei vertex shader che in quello dei pixel shader;
- la sua architettura consenta una completa indipendenza tra le varie unità della tipologia di calcolo eseguita;
- la logica di bilanciamento di carico sia estremamente efficiente;
- tutti gli altri aspetti (accesso alla memoria, latenze, ROPs, ecc...) siano ugualmente efficaci.
Per non entrare troppo nel tecnico, a parità di capacità di calcolo, l'organizzazione a shader unfiicati dovrebbe essere sempre più veloce. Tuttavia io penso che ci saranno notevoli differenze tra le ALU di G80 e quelle di R600, così come nell'accesso alla memoria, ecc...
Del resto ci sono anche adesso tra R580 e G71 molteplici differenze. Quindi al di là del discorso shader unificati e non, bisogna tenere in considerazione veramente tantissimi altri aspetti che al momento non sappiamo per poter fare una valutazione anche solo di massima.
Andrea deluxe
14-07-2006, 14:39
infatti, secondo me e' preferibile avere una architettura unificata, che puo' essere gestita e migliorata dai driver!
tac esce gioco x con necessita' di vertex, tac faccio il driver apposito
noo
nec-3500
14-07-2006, 14:42
Beh io non direi che non offre sempre benefici. In realtà, teoricamente, un'architettura a shader unificati è sempre avvantaggiata in termini di bilanciamento di carico rispetto ad una classica.
Prendiamo due architetture entrambe dotate nel complesso di 64 unità di calcolo. Quella classica distribuisce le 64 unità così: 16 per il vertex shading e 48 per il pixel shading. Quella unificata, invece, le può usare a suo piacimento come vuole.
In questo caso l'architettura a shader unificati è sempre avvantaggiata rispetto ad una non unificata a patto però che
- le sue unità di calcolo siano efficienti esattamente come quelle dell'architettura classica sia nel calcolo dei vertex shader che in quello dei pixel shader;
- la sua architettura consenta una completa indipendenza tra le varie unità della tipologia di calcolo eseguita;
- la logica di bilanciamento di carico sia estremamente efficiente;
- tutti gli altri aspetti (accesso alla memoria, latenze, ROPs, ecc...) siano ugualmente efficaci.
Per non entrare troppo nel tecnico, a parità di capacità di calcolo, l'organizzazione a shader unfiicati dovrebbe essere sempre più veloce. Tuttavia io penso che ci saranno notevoli differenze tra le ALU di G80 e quelle di R600, così come nell'accesso alla memoria, ecc...
Del resto ci sono anche adesso tra R580 e G71 molteplici differenze. Quindi al di là del discorso shader unificati e non, bisogna tenere in considerazione veramente tantissimi altri aspetti che al momento non sappiamo per poter fare una valutazione anche solo di massima.
Straquoto!!
Brightblade
14-07-2006, 14:49
infatti, secondo me e' preferibile avere una architettura unificata, che puo' essere gestita e migliorata dai driver!
tac esce gioco x con necessita' di vertex, tac faccio il driver apposito
noo
Si', ma non sottovalutare la potenza di questi concetti dei quali al momento non si sa nulla di definitivo (almeno, io non ne so nulla, se ci sono info ufficiali aggiornatemi):
...Prendiamo due architetture entrambe dotate nel complesso di 64 unità di calcolo. Quella classica distribuisce le 64 unità così: 16 per il vertex shading e 48 per il pixel shading. Quella unificata, invece, le può usare a suo piacimento come vuole....
...Per non entrare troppo nel tecnico, a parità di capacità di calcolo, l'organizzazione a shader unfiicati dovrebbe essere sempre più veloce....
Quello che voglio dire e': sappiamo se il numero di unita' di calcolo, la loro efficienza e capacita' di calcolo nella soluzione DX10 nVidia e in quella ATI saranno identiche?
Quello che voglio dire e': sappiamo se il numero di unita' di calcolo, la loro efficienza e capacita' di calcolo nella soluzione DX10 nVidia e in quella ATI saranno identiche?
No, è per questo che non possiamo trarre conclusioni :)
Brightblade
14-07-2006, 15:16
No, è per questo che non possiamo trarre conclusioni :)
E' proprio per questo che qualche post indietro avevo criticato la domanda per come era posta :)
yossarian
14-07-2006, 16:31
ciao leggete un po' qui....
Questo articolo
http://arith17.polito.it/final/paper-164.pdf
pubblicato da due ingegneri di NVIDIA, ci annuncia che il G80 incorporerà un nuovo tipo di unità di calcolo: l'unità d'interpolazione multifunzione. Nelle attuali GPU, le unità d'interpolazione sono incaricate di calcolare alcune proprietà (come il colore, la profondità o la struttura) di ogni pixel con interpolazione a partire dagli attributi di ogni vertice. Altre unità, sono inoltre necessarie per calcolare funzioni più complesse, come i logaritmi, seno, coseno, ecc...
Queste unità, che occupano un posto apposito sul die, sono però raramente utilizzate a pieno regime. NVIDIA ha dunque cercato di creare delle unità di calcolo che raggruppano tutte le funzionalità su evidenziate. È una problematica molto simile alla riunificazione del pixel e vertex shaders sulle GPU DirecX 10.
in misura ridotta (molto ridotta), ci sono delle similitudini tra i due approcci
ciao leggete un po' qui....
Gli autori dell'articolo evidenziano minori dimensioni del die e dei consumi a fronte di un immutato livello prestazionale.
su questo ho dei forti dubbi: minori dimensioni e minori consumi di sicuro; sulle prestazioni ci sarebbero da fare alcune osservazioni; avere delle unità dedicate fa "sprecare" silicio ma permette una maggior velocità d'elaborazione per due motivi: 1) si svolgono più operazioni per ciclo (un'unità multifunzione o si dedica ad una tipologia di operazioni oppure all'altra); 2) l'unificazione dei due tipi di unità presuppone una seppur primitiva forma di arbitrato a livello locale, il che equivale a dire che qualche ciclo extra è "consumato" in operazioni diverse dalla mera esecuzione dei calcoli (problema che affligge anche un'architettura a shader unificati, in misua ben maggiore).
D'altro canto si può, almeno in parte, rimediare a questi inconvenienti, aumentando le frequenze di funzionamento del chip.
Praticamente con questa modifica almeno per ora non sara' piu' necessaria l'unificazione delle varie unita' vertex!
qui non ho capito se intendevi riferirti all'unificazione di ps e vs; se è così, questa soluzione non è alternativa all'unificazione degli shader, ma, semmai, può essere complementare
Foglia Morta
14-07-2006, 16:52
2) l'unificazione dei due tipi di unità presuppone una seppur primitiva forma di arbitrato a livello locale, il che equivale a dire che qualche ciclo extra è "consumato" in operazioni diverse dalla mera esecuzione dei calcoli (problema che affligge anche un'architettura a shader unificati, in misua ben maggiore).
D'altro canto si può, almeno in parte, rimediare a questi inconvenienti, aumentando le frequenze di funzionamento del chip.
significa che senza fast14 R600 non sarebbe stato conveniente progettarlo ? Ma poi è realistico quel rumour che dava R600 a 1Ghz ?
significa che senza fast14 R600 non sarebbe stato conveniente progettarlo ? Ma poi è realistico quel rumour che dava R600 a 1Ghz ?
sicuramente no a 65nm mi sembra impossibile senza consumare un macello...qui in ambito GPU xò si sta andando avanti tipo "guerra dei Mhz"... :rolleyes:
yossarian
14-07-2006, 21:02
significa che senza fast14 R600 non sarebbe stato conveniente progettarlo ? Ma poi è realistico quel rumour che dava R600 a 1Ghz ?
assolutamente no; dico solo che aumentando la complessità dei circuiti che eseguono i calcoli e differenziando le operazioni che lo stesso blocco deve eseguire, aumentano i cicli spesi per lo svolgimento di operazioni non strettamente connesse alla computazione vera e propria.
Il vantaggio, nell'utilizzo di shader unificati, resta comunque, indipendentemente dall'utilizzo o meno della tecnologia fast14; un'architettura tradizionale può essere conveniente, o comunque competitva, solo nei casi in cui il rapporto tra vertex e pixel ops porta a riprodurre uno schema di tipo tradizionale anche nell'architettura unificata
Foglia Morta
14-07-2006, 21:04
sicuramente no a 65nm mi sembra impossibile senza consumare un macello...qui in ambito GPU xò si sta andando avanti tipo "guerra dei Mhz"... :rolleyes:
http://www.intrinsity.com/ , non ho chiesto frequenze alte e consumi contenuti. ma fast14 fa ben sperare
Foglia Morta
14-07-2006, 21:07
assolutamente no; dico solo che aumentando la complessità dei circuiti che eseguono i calcoli e differenziando le operazioni che lo stesso blocco deve eseguire, aumentano i cicli spesi per lo svolgimento di operazioni non strettamente connesse alla computazione vera e propria.
Il vantaggio, nell'utilizzo di shader unificati, resta comunque, indipendentemente dall'utilizzo o meno della tecnologia fast14; un'architettura tradizionale può essere conveniente, o comunque competitva, solo nei casi in cui il rapporto tra vertex e pixel ops porta a riprodurre uno schema di tipo tradizionale anche nell'architettura unificata
ma praticamente fast14 cosa serve ? nelle ultime settimane si parlava di consumi enormi per le schede DX10 ma fast14 non serve anche a ridurre i consumi ?
infatti...hai riportato una notizia...ke sembra altamente inverosimile...
le future GPU credo ke infrangeranno i 700Mhz senza problemi...ma prima d arrivare a 1Ghz c saranno le GPU dualcore...credo
...
spero :D
ma praticamente fast14 cosa serve ? nelle ultime settimane si parlava di consumi enormi per le schede DX10 ma fast14 non serve anche a ridurre i consumi ?
questo lo voglio sapere pure io :confused:
infatti...hai riportato una notizia...ke sembra altamente inverosimile...
le future GPU credo ke infrangeranno i 700Mhz senza problemi...ma prima d arrivare a 1Ghz c saranno le GPU dualcore...credo
...
spero :D
si può dire che le GPU attuali siano già multicore
bYeZ!
si può dire che le GPU attuali siano già multicore
bYeZ!
ma no...io intendo 2 GPU su un singolo die come i conroe o i pentium D o gli Athlon X2 nn SLi, Crossfire o dual GPU...
ma no...io intendo 2 GPU su un singolo die come i conroe o i pentium D o gli Athlon X2 nn SLi, Crossfire o dual GPU...
le CPU sono processori general purpose, detto all'italiana "vanno bene un pò per tutto", quindi ha senso il raddoppio dei core per bilanciare il carico; nelle gpu abbiamo invece moltissime unità diverse tra loro che assolvono compiti specifici, il problema sta nel bilanciare in modo opportuno l'uso che si fa delle unità di calcolo per non andare incontro a colli di bottiglia interni. E appunto l'unificazione di PS e VS è un sistema con il quale si ottimizzano le risorse a disposizione; e, "artisticamente" parlando, è una soluzione di classe, in barba alle soluzioni multigpu che sinceramente mi fanno vomitare :D
bYeZ!
le CPU sono processori general purpose, detto all'italiana "vanno bene un pò per tutto", quindi ha senso il raddoppio dei core per bilanciare il carico; nelle gpu abbiamo invece moltissime unità diverse tra loro che assolvono compiti specifici, il problema sta nel bilanciare in modo opportuno l'uso che si fa delle unità di calcolo per non andare incontro a colli di bottiglia interni. E appunto l'unificazione di PS e VS è un sistema con il quale si ottimizzano le risorse a disposizione; e, "artisticamente" parlando, è una soluzione di classe, in barba alle soluzioni multigpu che sinceramente mi fanno vomitare :D
bYeZ!
ah si...qui quoto appieno...
Andrea deluxe
15-07-2006, 10:59
purtroppo le soluzioni multi gpu arrivano quando ci sono problemi di rese!
fa un po' schifo il multi gpu, ma spero finisca presto questa corsa a raddoppiare schede video!(consumi e soldi annessi)
spero nel successo dell'architettura unificata e in un perfezionamento dei processi produttivi a 65nm, che ci portera' ad avere schede singole dalla potenza inaudita!
sperem :mc:
Foglia Morta
15-07-2006, 12:17
purtroppo le soluzioni multi gpu arrivano quando ci sono problemi di rese!
a me pare proprio l'opposto... i G71 delle 7950 non sono versioni castrate.
fa un po' schifo il multi gpu, ma spero finisca presto questa corsa a raddoppiare schede video!(consumi e soldi annessi)
spero nel successo dell'architettura unificata e in un perfezionamento dei processi produttivi a 65nm, che ci portera' ad avere schede singole dalla potenza inaudita!
sperem :mc:
secondo me invece ati e nvidia aumenteranno le soluzioni dual gpu. se ricordo bene mesi fa un dipendente ati aveva detto che sempre ati ha 1500 ingegneri per l'hardware e 1500 per il software. Se le risorse sono equamente distribuite e sviluppare driver per sli e crossfire è oneroso allora gli potrebbe essere utile a loro sfruttare un po di più quelle spese .perchè investire per poi avere qualcosa per benchare ( marketing ) o soluzioni per l'1% del mercato ?forse potrebbero essere gestite meglio quelle risorse
Window Vista
15-07-2006, 13:15
L'unico difetto degli shader unificati è il collo di bottiglia rappresentati gioco per gioco.
L'unico difetto degli shader unificati è il collo di bottiglia rappresentati gioco per gioco.
A dire il vero è il primo punto di forza :)
A dire il vero è il primo punto di forza :)
:asd: stroncato
bYeZ!
:asd: stroncato
bYeZ!
già :asd: :asd: :asd: :asd: :asd:
Window Vista
15-07-2006, 17:04
già :asd: :asd: :asd: :asd: :asd:
Non penso proprio, perchè programmare su shader unificati vuol dire non sapere dove il collo di bottiglia, intendo dire: se Nvidia fa un scheda con 24 pippe e 8 vertex shader, si sa gà qual'è il collo di bottiglia, o l'uno o l'altro, invece nell'altro hanno una lunghissima pipèline composto da tot. shader e non sanno come devono fare il gioco, dove il punto di forza.
Questo l'aveva detto anche tomshw.it in una news.
Andrea deluxe
15-07-2006, 17:07
il discorso dei problemi di resa non e' cio' che pensi tu!
il problema e' far uscire dalle fabriche chip con 400-500 milioni di transistor!
la storia delle 7950 e' una cosa ben diversa!(hanno ottimizzato l'architetttura per ridurre i transistor cosiche' si possano avere rese superiori!
sai che bello avere un wafer 40x40cm con il 50% di die (da 500milioni di transistor) difettati!
molto meglio avere un wafer 40x40cm con il 50% di die (da 275milioni di transistor) difettati
Andrea deluxe
15-07-2006, 17:17
se il ragionamento entra bene in testa, entra bene in testa anche il motivo dell' esistenza delle soluzioni dual gpu :mbe:
Non penso proprio, perchè programmare su shader unificati vuol dire non sapere dove il collo di bottiglia, intendo dire: se Nvidia fa un scheda con 24 pippe e 8 vertex shader, si sa gà qual'è il collo di bottiglia, o l'uno o l'altro, invece nell'altro hanno una lunghissima pipèline composto da tot. shader e non sanno come devono fare il gioco, dove il punto di forza.
Questo l'aveva detto anche tomshw.it in una news.
veramente programmare su un'architettura a shader separati è di gran lunga più limitativo rispetto ad agire su di una a shader unificati; l'importante non è sapere dove sono i colli di bottiglia, ma proprio eliminarli alla base; e avendo libertà di bilanciare il carico vertex/pixel shader, potenzialmente i soli limiti derivano dalla velocità di elaborazione del chip (leggi frequenza), che si può abbastanza facilmente incrementare senza stravolgimenti architetturali.
Uno che programma un gioco con architettura a shader separati dice: "no questo non lo possiamo fare perchè quell'architettura ha solo 8vertexshader, quindi puntiamo sull'effetto col pixelshader"
Uno che programma su un'architettura a shader unificati dice: "Allora, abbiamo piena libertà, possiamo creare effetti basandoci senza preferenze su vertex e pixel shader; l'unica cosa a cui dobbiamo stare attenti è non sovraccaricare la pipeline grafica e non introdurre troppi stati d'attesa"
ovviamente aspetto correzioni da Vifani e Yossarian se necessarie :D
bYeZ!
il discorso dei problemi di resa non e' cio' che pensi tu!
il problema e' far uscire dalle fabriche chip con 400-500 milioni di transistor!
la storia delle 7950 e' una cosa ben diversa!(hanno ottimizzato l'architetttura per ridurre i transistor cosiche' si possano avere rese superiori!
sai che bello avere un wafer 40x40cm con il 50% di die (da 500milioni di transistor) difettati!
molto meglio avere un wafer 40x40cm con il 50% di die (da 275milioni di transistor) difettati
più che ridurre i transistor si tende a ridurre il processo produttivo, "per farcene stare di più nello stesso spazio" :)
bYeZ!
Andrea deluxe
15-07-2006, 18:30
lo so!
ma stavo discutendo della situazione 7950!
Window Vista
15-07-2006, 19:34
:D :D :D :D :D Vifani & co. fatevi sentir, battete un colpo se ci siete :D :D :D :D :D
Non è vero che programmare per un'architettura a shader unificati significa non conoscerne i limiti ed il collo di bottiglia. Diciamo che a causa della variabilità di configurazione delle varie unità di calcolo questi limiti non si possono più definire in maniera fissa, ma variano da situazione a situazione, ma un range di riferimento sulle operazioni che è possibile effettuare a livello di vertex, pixel e texturing viene sicuramente comunicato agli sviluppatori.
Comunque al di là di questo discorso bisogna considerare che i videogames sono quasi esclusivamente limitati nelle operazioni di pixel shading, blending e texturing. E' estremamente raro vedere un gioco limitato a livello di vertex shading perché i modellatori delle mappe e dei personaggi la prima cosa che fanno è ridurre al minimo possibile il dettaglio poligonale. Del resto effetti come il bump mapping o il parallax mapping servono proprio per conferire dettaglio a superfici che in realtà, dal punto di vista poligonale, sono piatte.
Inoltre è ormai di uso comune nei motori grafici effettuare una prima passata di rendering dedicata solo alla scrittura dei valori dello z-buffer e tutte le successive passate, invece, sono realizzate senza scrivere in questo buffer. Sto parlando delle passate di rendering necessarie alla realizzazione di un fotogramma. Questa operazione viene effettuata perché una volta fissato lo z-buffer, tutte le altre passate possono essere elaborate con una rimozione delle superfici nascoste praticamente totale e ciò limita il numero di pixel da elaborare essenzialmente al numero di pixel visualizzati sullo schermo (dovuti, quindi, alla risoluzione). Quella prima passata di rendering, non dovendo elaborare alcun colore dei pixel, ma solo la posizione dei vertici, vede le unità di vertex shading completamente occupate e quelle di pixel shading completamente a riposo. Con un'architettura a shader unificati l'efficienza in una situazione di questo tipo aumenta drammaticamente.
Esiste inoltre una tecnica di rendering piuttosto innovativa (non ricordo, ma forse non è ancora mai stata usata) chiamata deferred shading (o anche quad shading) che consiste nel fare la prima passata di rendering per memorizzare i valori dello z-buffer, della posizione, delle normali, ecc... (essenzialmente tutti i dati geometrici) in texture in formato floating point e successivamente renderizzare la scena come un rettangolo che copre l'intera superficie dello schermo (da qui il termine quad shading) usando queste texture come fonti di informazioni geometriche, ma eseguendo di fatto solo calcoli con i pixel shader in tutte le passate successive alla prima. Questo è un altro esempio in cui un'architettura a shader unificati è infinitamente più efficiente di una classica perché dedica tutte le unità disponibili all'esecuzione dei pixel shader.
Personalmente penso che un'architettura unificata a parità di capacità di calcolo, se la gestione delle unità di calcolo è efficiente e, come giustamente osservato da yossarian, non richiede troppi cicli di clock, è sempre + efficiente di una classica.
Non è vero che programmare per un'architettura a shader unificati significa non conoscerne i limiti ed il collo di bottiglia. Diciamo che a causa della variabilità di configurazione delle varie unità di calcolo questi limiti non si possono più definire in maniera fissa, ma variano da situazione a situazione, ma un range di riferimento sulle operazioni che è possibile effettuare a livello di vertex, pixel e texturing viene sicuramente comunicato agli sviluppatori.
Comunque al di là di questo discorso bisogna considerare che i videogames sono quasi esclusivamente limitati nelle operazioni di pixel shading, blending e texturing. E' estremamente raro vedere un gioco limitato a livello di vertex shading perché i modellatori delle mappe e dei personaggi la prima cosa che fanno è ridurre al minimo possibile il dettaglio poligonale. Del resto effetti come il bump mapping o il parallax mapping servono proprio per conferire dettaglio a superfici che in realtà, dal punto di vista poligonale, sono piatte.
Inoltre è ormai di uso comune nei motori grafici effettuare una prima passata di rendering dedicata solo alla scrittura dei valori dello z-buffer e tutte le successive passate, invece, sono realizzate senza scrivere in questo buffer. Sto parlando delle passate di rendering necessarie alla realizzazione di un fotogramma. Questa operazione viene effettuata perché una volta fissato lo z-buffer, tutte le altre passate possono essere elaborate con una rimozione delle superfici nascoste praticamente totale e ciò limita il numero di pixel da elaborare essenzialmente al numero di pixel visualizzati sullo schermo (dovuti, quindi, alla risoluzione). Quella prima passata di rendering, non dovendo elaborare alcun colore dei pixel, ma solo la posizione dei vertici, vede le unità di vertex shading completamente occupate e quelle di pixel shading completamente a riposo. Con un'architettura a shader unificati l'efficienza in una situazione di questo tipo aumenta drammaticamente.
Esiste inoltre una tecnica di rendering piuttosto innovativa (non ricordo, ma forse non è ancora mai stata usata) chiamata deferred shading (o anche quad shading) che consiste nel fare la prima passata di rendering per memorizzare i valori dello z-buffer, della posizione, delle normali, ecc... (essenzialmente tutti i dati geometrici) in texture in formato floating point e successivamente renderizzare la scena come un rettangolo che copre l'intera superficie dello schermo (da qui il termine quad shading) usando queste texture come fonti di informazioni geometriche, ma eseguendo di fatto solo calcoli con i pixel shader in tutte le passate successive alla prima. Questo è un altro esempio in cui un'architettura a shader unificati è infinitamente più efficiente di una classica perché dedica tutte le unità disponibili all'esecuzione dei pixel shader.
Personalmente penso che un'architettura unificata a parità di capacità di calcolo, se la gestione delle unità di calcolo è efficiente e, come giustamente osservato da yossarian, non richiede troppi cicli di clock, è sempre + efficiente di una classica.
Window...vuoi qualcosa d + :sofico:
Non è vero che programmare per un'architettura a shader unificati significa non conoscerne i limiti ed il collo di bottiglia. Diciamo che a causa della variabilità di configurazione delle varie unità di calcolo questi limiti non si possono più definire in maniera fissa, ma variano da situazione a situazione, ma un range di riferimento sulle operazioni che è possibile effettuare a livello di vertex, pixel e texturing viene sicuramente comunicato agli sviluppatori.
Comunque al di là di questo discorso bisogna considerare che i videogames sono quasi esclusivamente limitati nelle operazioni di pixel shading, blending e texturing. E' estremamente raro vedere un gioco limitato a livello di vertex shading perché i modellatori delle mappe e dei personaggi la prima cosa che fanno è ridurre al minimo possibile il dettaglio poligonale. Del resto effetti come il bump mapping o il parallax mapping servono proprio per conferire dettaglio a superfici che in realtà, dal punto di vista poligonale, sono piatte.
Inoltre è ormai di uso comune nei motori grafici effettuare una prima passata di rendering dedicata solo alla scrittura dei valori dello z-buffer e tutte le successive passate, invece, sono realizzate senza scrivere in questo buffer. Sto parlando delle passate di rendering necessarie alla realizzazione di un fotogramma. Questa operazione viene effettuata perché una volta fissato lo z-buffer, tutte le altre passate possono essere elaborate con una rimozione delle superfici nascoste praticamente totale e ciò limita il numero di pixel da elaborare essenzialmente al numero di pixel visualizzati sullo schermo (dovuti, quindi, alla risoluzione). Quella prima passata di rendering, non dovendo elaborare alcun colore dei pixel, ma solo la posizione dei vertici, vede le unità di vertex shading completamente occupate e quelle di pixel shading completamente a riposo. Con un'architettura a shader unificati l'efficienza in una situazione di questo tipo aumenta drammaticamente.
Esiste inoltre una tecnica di rendering piuttosto innovativa (non ricordo, ma forse non è ancora mai stata usata) chiamata deferred shading (o anche quad shading) che consiste nel fare la prima passata di rendering per memorizzare i valori dello z-buffer, della posizione, delle normali, ecc... (essenzialmente tutti i dati geometrici) in texture in formato floating point e successivamente renderizzare la scena come un rettangolo che copre l'intera superficie dello schermo (da qui il termine quad shading) usando queste texture come fonti di informazioni geometriche, ma eseguendo di fatto solo calcoli con i pixel shader in tutte le passate successive alla prima. Questo è un altro esempio in cui un'architettura a shader unificati è infinitamente più efficiente di una classica perché dedica tutte le unità disponibili all'esecuzione dei pixel shader.
Personalmente penso che un'architettura unificata a parità di capacità di calcolo, se la gestione delle unità di calcolo è efficiente e, come giustamente osservato da yossarian, non richiede troppi cicli di clock, è sempre + efficiente di una classica.
il mio obiettivo è arrivare al livello di quest'uomo :ave:
bYeZ!
il mio obiettivo è arrivare al livello di quest'uomo :ave:
bYeZ!
anche il mio :sofico: :ave: :ave: :ave: :ave: :ave:
Comunque fek sarebbe sicuramente un candidato più competente di me per spiegare queste cose perché io programmo motori grafici per hobby, mentre lui lo fa per professione e tra l'altro ha già programmato per l'X-Box 360 e quindi ha a che fare con un'architettura a shader unificati.
Andrea deluxe
16-07-2006, 10:15
FEEEEEEEEEEEEEK
FEEEEEEEEEEEEEK
:ave: :ave: :ave: :ave: :ave: :ave: :ave: :ave:
ghghgh
P3pPoS83
16-07-2006, 11:19
FEEEEEEEEEEEEEK
Non nominare il suo nome invano :D
Bye :cool:
perché io programmo motori grafici per hobby
Dai, questa non la sapevo. Urge vedere qualcosa :)
Comunque fek sarebbe sicuramente un candidato più competente di me per spiegare queste cose perché io programmo motori grafici per hobby, mentre lui lo fa per professione e tra l'altro ha già programmato per l'X-Box 360 e quindi ha a che fare con un'architettura a shader unificati.
sarebbe parecchio interessante sentire le prime impressioni di un programmatore su shader unificati..magari riesce a darci qualche idea concreta delle potenzialità di questa soluzione!!
ps: motori grafici per hobby.. :eek: in media quanto ci metti a finirne uno??
ps: motori grafici per hobby.. :eek: in media quanto ci metti a finirne uno??
In realtà questa domanda non ha senso perché se non hai un obiettivo del tipo "serve un motore per fare questo gioco e che faccia questo", in realtà non finisci mai :D Ed è quello che capita a me. Diciamo più che altro che mi diletto nel programmare, fare shaders, implementare HDR, shadows, ecc.. così come passa tempo.
Riguardo a farvi vedere qualcosa... se ne parla quando ci sarà qualcosa che posso far vedere. Onestamente non sono un grafico e quindi benché possa far creare stencil shadows o bump mapping, le scene su cui li faccio girare sono al massimo qualche composizione delle primitive di 3D Studio Max (sfere, parallelepipedi, piramidi, ecc...).
In realtà questa domanda non ha senso perché se non hai un obiettivo del tipo "serve un motore per fare questo gioco e che faccia questo", in realtà non finisci mai :D Ed è quello che capita a me. Diciamo più che altro che mi diletto nel programmare, fare shaders, implementare HDR, shadows, ecc.. così come passa tempo.
Riguardo a farvi vedere qualcosa... se ne parla quando ci sarà qualcosa che posso far vedere. Onestamente non sono un grafico e quindi benché possa far creare stencil shadows o bump mapping, le scene su cui li faccio girare sono al massimo qualche composizione delle primitive di 3D Studio Max (sfere, parallelepipedi, piramidi, ecc...).
il senso della domanda era appunto questo ;) io credevo ti ponessi degli obiettivi tipo "provo a fare un motore che su queste basi mi dia questi risultati" e penso sia comunque impegnativo come lavoro, non male come hobby!!
quindi mi pare di capire che tu ti metti davanti al pc cominci a scrivere e vedi cosa ti viene fuori..molto artistico :D
ps: ot-ma sei laureato ing. informatico, informatico o matematico ?
il senso della domanda era appunto questo ;) io credevo ti ponessi degli obiettivi tipo "provo a fare un motore che su queste basi mi dia questi risultati" e penso sia comunque impegnativo come lavoro, non male come hobby!!
quindi mi pare di capire che tu ti metti davanti al pc cominci a scrivere e vedi cosa ti viene fuori..molto artistico :D
ps: ot-ma sei laureato ing. informatico, informatico o matematico ?
Sono laureato in Informatica (laurea triennale) e in questi giorni sto studiando l'ultimo esame per la laurea specialistica in Informatica di secondo livello.
Sono laureato in Informatica (laurea triennale) e in questi giorni sto studiando l'ultimo esame per la laurea specialistica in Informatica di secondo livello.
E allora in groppa al lupo :)
vBulletin® v3.6.4, Copyright ©2000-2026, Jelsoft Enterprises Ltd.