[THREAD UFFICIALE] Aspettando Nvidia GTX 480 e GTX 470

[Alekos Panagulis]

Spiegazione magnifica
Chiara e semplice.

[Maury]

Ma secondo voi come mai Ati non ha reclamato per via delle versioni non equivalenti di unigine usate da nVidia ? Forse sa già che alla prova dei fatti, che avverrà presumibilmente tra poco, tutto il castello cadrà miseramente ?

[calabar]

Immagino che Nvidia, scegliendo una soluzione più dinamica, abbia anche fatto i propri calcoli, magari scommettendo un po' sul futuro.
Un po' come aveva fatto ATI con R600 e l'AA via shader, scommessa che per ati si è rivelata poi fallimentare e corretta in seguito.

Cosa sarà di questa invece lo sapremo tra qualche tempo.
Secondo me, visti i supposti consumi di Fermi, questo tipo di vantaggio dovrà mostrarsi in fretta, perchè se lo facesse quando sarà disponibile una generazione più aggiornata di schede, allora chi si terrebbe una scheda che si ha ancora prestazioni decenti, ma consumi indecenti, per godersi questo vantaggio?

A mio parere comunque, se il "potenziamento" del tessellator nvidia (che poi da quel che avevo capito non era il tessellator ad essere stato potenziato, ma gli stadi successivi che dovevano gestire il gran numero di triangoli generati dal tessellator) porterà dei vantaggi con i giochi futuri, questo accadrà quando i motori di tali giochi saranno programmati per schede con il tessellator, ossia con geometrie leggerissime arricchite poi dal tessellator, così come accade per l'Ungine bench.
E questo secondo me non si vedrà ancora per parecchi anni, ossia fino a quando ci sarà la necessità di creare una geometria di base molto fitta per poter girare su schede senza tessellator.

@skizzo99999999
Un appunto sul tuo discorso (ne riprendo i numeri):
Nel caso della GPU con l'hardware dedicato (quindi 480SP + tessellazione completa) e della GPU flessibile (512SP con parte del tessellator via shader) si rischia di farsi ingannare dai numeri.
Di fatto cioè la scheda con da 512 sarà paragonabile ad una scheda da 480+hw come prestazioni (posto che le due soluzioni possano un minimo equivalersi, sempre per ipotesi), il che significa che a parità di sp andrà di meno.
Quindi se una scheda con 512 SP può far gridare all'estrema potenza, dobbiamo ricordare che di fatto con tessellation questa scheda è come se fosse una 480 SP, e non dobbiamo stupirci se non raggiunge i risultati che ci aspettereno da un "full 512 SP".
Forse il discorso è un po' contorto, ma spero di essermi fatto capire!

[yossarian]

Originariamente inviato da calabar

Immagino che Nvidia, scegliendo una soluzione più dinamica, abbia anche fatto i propri calcoli, magari scommettendo un po' sul futuro.
Un po' come aveva fatto ATI con R600 e l'AA via shader, scommessa che per ati si è rivelata poi fallimentare e corretta in seguito.

Cosa sarà di questa invece lo sapremo tra qualche tempo.
Secondo me, visti i supposti consumi di Fermi, questo tipo di vantaggio dovrà mostrarsi in fretta, perchè se lo facesse quando sarà disponibile una generazione più aggiornata di schede, allora chi si terrebbe una scheda che si ha ancora prestazioni decenti, ma consumi indecenti, per godersi questo vantaggio?

A mio parere comunque, se il "potenziamento" del tessellator nvidia (che poi da quel che avevo capito non era il tessellator ad essere stato potenziato, ma gli stadi successivi che dovevano gestire il gran numero di triangoli generati dal tessellator) porterà dei vantaggi con i giochi futuri, questo accadrà quando i motori di tali giochi saranno programmati per schede con il tessellator, ossia con geometrie leggerissime arricchite poi dal tessellator, così come accade per l'Ungine bench.
E questo secondo me non si vedrà ancora per parecchi anni, ossia fino a quando ci sarà la necessità di creare una geometria di base molto fitta per poter girare su schede senza tessellator.

@skizzo99999999
Un appunto sul tuo discorso (ne riprendo i numeri):
Nel caso della GPU con l'hardware dedicato (quindi 480SP + tessellazione completa) e della GPU flessibile (512SP con parte del tessellator via shader) si rischia di farsi ingannare dai numeri.
Di fatto cioè la scheda con da 512 sarà paragonabile ad una scheda da 480+hw come prestazioni (posto che le due soluzioni possano un minimo equivalersi, sempre per ipotesi), il che significa che a parità di sp andrà di meno.
Quindi se una scheda con 512 SP può far gridare all'estrema potenza, dobbiamo ricordare che di fatto con tessellation questa scheda è come se fosse una 480 SP, e non dobbiamo stupirci se non raggiunge i risultati che ci aspettereno da un "full 512 SP".
Forse il discorso è un po' contorto, ma spero di essermi fatto capire!

diciamo che non ha senso considerare un'architettura da 512 alu alla stregua di una di tipo 480+unità dedicate (mi tengo l'architettura 480+T che è molto più veloce anche nel'esecuzione di T). Il vantaggio di un'architettura con alu generiche è che posso bilanciare meglio i carichi di lavoro in base alle necessità e questo significa che quando mi servirà più tessellation non avrò una 480+T (tessellator) ma, magari, una 320+T, il che significa che T sarà eseguita molto più velocemente ma tutto il resto subirà notevoli rallentamenti, senza ocntare che un massiccio utilizzo di tessellation richede anche un maggior impegno dei PS

[Foglia Morta]

Originariamente inviato da calabar

Immagino che Nvidia, scegliendo una soluzione più dinamica, abbia anche fatto i propri calcoli, magari scommettendo un po' sul futuro.
Un po' come aveva fatto ATI con R600 e l'AA via shader, scommessa che per ati si è rivelata poi fallimentare e corretta in seguito.

se non sbaglio l' approccio di Fermi è simile a quello di RV770 ( che può fare hull e domain tramite VS e GS ) mentre con RV870 ATi ha scelto circuiteria dedicata , quindi al limite direi scelte diverse e stop

[Andrea deluxe]

scusate, ma non resisto....

http://www.youtube.com/watch?v=gNIPc...eature=related

[Maury]

Originariamente inviato da Ratatosk

I nodi vengono al pettine da soli nelle recensioni, perché scoprirsi prima?

E' quello che penso io

Del resto ATI è troppo tranquilla in questo periodo, va bene che non ha mai fatto chissà che proclami o attacchi mediatici alla concorrenza, ma a questo giro è davvero mansueta nel proporsi (o meglio nel non proporsi)...

Qua gatta ci cova ...

[Andrea deluxe]

Originariamente inviato da Maury

E' quello che penso io

Del resto ATI è troppo tranquilla in questo periodo, va bene che non ha mai fatto chissà che proclami o attacchi mediatici alla concorrenza, ma a questo giro è davvero mansueta nel proporsi (o meglio nel non proporsi)...

Qua gatta ci cova ...

http://www.thinq.co.uk/news/2010/3/8...-for-the-cash/

[Diobrando_21]

Scusate è vero che in fermi nell'uso massivo di tessellazione verrano sottratte risorse x il rendering, tuttavia non vedo il problema...se ho ben capito (anche in base a discorsi precedentemente fatti) lo scopo è proprio quello di creare modelli poligonali di partenza più semplici (quindi diminuirà la RICHIESTA di risorse x il rendering) per poi arricchirli con un uso intensivo di tessellazione (quindi è giusto dedicare la maggior parte delle risorse a questa funzione)...mentre fermi potrà farlo senza problemi, le ati no, perdendo colpi nell'uso intensivo di tessellazione (visto che ad un certo punto le risorse del tessellatore ati finiscono senza possibilità di incrementarle, tra l'altro già perdono colpi adesso che la tessellazione è minima)...quindi a me sembra più che altro che fermi dia uno sguardo al futuro su l'uso che effettivamente se ne dovrà fare della tessellazione mentre le ati siano più adatte all'uso attuale...questo è quello che ho capito, spero di avere qualche delucidazione, grazie...

[appleroof]

Originariamente inviato da yossarian

sono sempre stato un convinto fautore dei bench sintetici ma solo se questi sono eseguiti a parità di condizioni. NOn posso far girare il 3dmark 2001 su una vga e il 3dmark2003 su un'altra e trarre conclusioni in merito sulle prestazioni relative

cut

non capisco, intenderesti che unigine è sbilanciato verso Nvidia?

Originariamente inviato da Ratatosk

Ti da un'idea più affidabile vedere bench di Call of Prypat, DiRT2 e AvP, per capire come vanno e andranno i giochi DX11 che non Unigine. Questo esattamente come accade per 3DMark Vantage che è molto meno affidabile di un qualunque gioco DX10 per capire come vanno i giochi DX10.
cut

ma i post li leggete?? dicevo che unigine è un test sintetico e vale per quello che è, ciò non toglie che come al solito occorre anche testare i giochi (e quanti più possibili) per capire in media come va una vga

[Andrea deluxe]

Originariamente inviato da Diobrando_21

Scusate è vero che in fermi nell'uso massivo di tessellazione verrano sottratte risorse x il rendering, tuttavia non vedo il problema...se ho ben capito (anche in base a discorsi precedentemente fatti) lo scopo è proprio quello di creare modelli poligonali di partenza più semplici (quindi diminuirà la RICHIESTA di risorse x il rendering) per poi arricchirli con un uso intensivo di tessellazione (quindi è giusto dedicare la maggior parte delle risorse a questa funzione)...mentre fermi potrà farlo senza problemi, le ati no, perdendo colpi nell'uso intensivo di tessellazione (visto che ad un certo punto le risorse del tessellatore ati finiscono senza possibilità di incrementarle, tra l'altro già perdono colpi adesso che la tessellazione è minima)...quindi a me sembra più che altro che fermi dia uno sguardo al futuro su l'uso che effettivamente se ne dovrà fare della tessellazione mentre le ati siano più adatte all'uso attuale...questo è quello che ho capito, spero di avere qualche delucidazione, grazie...

metti caso che hai fermi con 512sp.

stai eseguendo una scena senza tassellazione e sei a 300fps....

ad un certo punto della scena compaiono degli oggetti che necessitano di tassellazione.

a questo punto il driver deve associare il compito agli shader che hanno una funzione fissa di tassellazione con priorita' rispetto agli altri effetti.

da 300fps al secondo ne avrai molti meno, perche' quegli shader che stanno calcolando la tassellazione, non possono calcolare il resto allo stesso momento.

poi sara' comunque il driver a stabilire quanti shader impegnare allo stesso momento per la tassellazione e gli halt per le altre istruzioni.
tutto questo facendo attenzione a non creare colli di bottiglia per il resto delle istruzioni...

[yossarian]

Originariamente inviato da appleroof

non capisco, intenderesti che unigine è sbilanciato verso Nvidia?

nVidia ha usato una versione differente, la 1.1, che permette un incremento prestazionale del 30% in quanto riduce l'overdraw dovuto alle superfici nascoste grazie ad un uso più aggressivo delle operazioni di culling. Questo incremento, su un'architettura come quella di fermi che si giova in misuta maggiore, della riduzione di tale overdraw perchè scarica gran parte del lavoro delle unità di shading e ha più risorse da dedicate alla tessellation, può avere anche valori superiori al 30%

[skizzo99999999]

Originariamente inviato da calabar

@skizzo99999999
Un appunto sul tuo discorso (ne riprendo i numeri):
Nel caso della GPU con l'hardware dedicato (quindi 480SP + tessellazione completa) e della GPU flessibile (512SP con parte del tessellator via shader) si rischia di farsi ingannare dai numeri.
Di fatto cioè la scheda con da 512 sarà paragonabile ad una scheda da 480+hw come prestazioni (posto che le due soluzioni possano un minimo equivalersi, sempre per ipotesi), il che significa che a parità di sp andrà di meno.
Quindi se una scheda con 512 SP può far gridare all'estrema potenza, dobbiamo ricordare che di fatto con tessellation questa scheda è come se fosse una 480 SP, e non dobbiamo stupirci se non raggiunge i risultati che ci aspettereno da un "full 512 SP".
Forse il discorso è un po' contorto, ma spero di essermi fatto capire!

Ribadisco che i numeri che ho dato sono campati in aria e servono solo come esempi, ma ciò non toglie che secondo me parlare con un po di numeri aiuta. Ribadisco che quello che conta è quanto ci metto ad elaborare un frame completo di tutto: tutti i vertex, tutti i pixel, tutta la tessellazione, ecc... Mettiamo caso che un frame impieghi 16 millisedondi per essere eseguito sulla gpu1 con 480+T. In quei 16 msec, diciamo che la tessellazione ci mette 2 millisecondi. quindi per quei 2 millisendi io ho 480 sp occupati (facciamo finta che si abbia un utilizzo del 100% tanto per semplificare) più gli sp per hull e domain, mentre per i restanti 14 msec saranno occupati "soltanto" i 480 sp generici, con quelli per hull e domain a girarsi i pollici. Nella gpu2 a 512 sp, mettiamo (sempre per semplificare) di dedicare 32 sp alla tessellazione, quindi di rimanere con 480 sp generici per il resto. Quelle operazioni che prima richiedevano 2 msec, grazie alla minor efficienza degli sp generici (ma comunque relativa, visto le considerazione del post precedente) mettiamo che ne richiedono 3. Guardando gli atri 480sp, per quanto riguarda i primi 3 msec la situazione è uguale alla gpu1, presupponendo che si riesca ad occuparli tutti nonostante si abbiano meno dati in "uscita" dalla fase di tessellazione nell'unità di tempo, ma questo non possiamo saperlo (anche se il tessellator potenziato e diviso in 16 parti serve anche per poter offrire, oltre a una potenza totale maggiore anche una migliore granularità utile nel caso in questione). Negli gli altri 13 msec però, io ho a disposizione tutti e 512 gli sp, per cui posso eseguire il resto più velocemente (e quindi impiegare meno di 13 msec). Quindi rallentando una fase ho velocizzato il resto. Il fatto di dedicare 64, 128, 256, sp alla tessellazione invece che 32 non cambia il risultato: infatti gli sp "sottratti" serviranno a terminare prima la tessellazione in modo da liberarli prima per eseguire gli altri compiti, ma il tempo totale non cambia. Può essere utile per bilanciare meglio il carico in modo da tenere sempre più unità utilizzate, visto che le operazioni possono dipendere le une dalle altre ed eseguire massicciamente operazioni prima di un tipo poù essere utile per occupare meglio tutte le risorse a disposizione.
Faccicamo un altro esempio con la gpu2: mettiamo che gli sp eseguano una operazione ogni msec e ci mettano sempre un ciclo per ogni operazione (altra semplificazione, ma come sempre è per far capire): vuol dire che ho a disposizione 512 "cicli" per ogni msec, il che vuol dire 512x16=8192 cicli in totale occupati nel frame. Se io uso 32sp per hull e domai e ho detto che ci metto 3msec, vuol dire che l'operazione consuma 32x3=96 cicli. Me ne rimangono (480x3)+(512x13)=8096 a disposizione per il resto. Se io invece impiego subito 96sp, finisco tutto in 1 msec, per cui ho bruciato più sp subito, ma da'altro canto ci ho sempre messo 96 cicli, per cui ho sempre (416x1)+(512x15)=8096 per il resto. Se gli sp eseguissero invece una operazione più velocemente di un'altra allora il bialnciamento delle unità servirebbe a trovare il "punto" giusto in cui avere le migliori prestazioni, ma non è questo il nocciolo della questione. Il senso dell'esempio è che quello che conta è il tempo totale del frame, non della singola fase.

Come nel mio esempio precedente, è più o meno lo stesso principio del pixel e vertex shader contro shader unificati: questi ultimi, nonostante fossero meno efficienti (= più lenti) hanno permesso di sfruttare al meglio tutte le unità a disposizione in ogni momento, in modo da ganarare l'intero frame più velocemente. Qundi una scheda "full 512sp", cioè 512+T (che presuppone ulteriori sp per hull e domain) sarebbe si più veloce di una "512 senza T", ma sello stesso die size della 512+T magari ci posso mettere una 544 senza T. Il concetto è questo.

[Diobrando_21]

Originariamente inviato da Andrea deluxe

metti caso che hai fermi con 512sp.

stai eseguendo una scena senza tassellazione e sei a 300fps....

ad un certo punto della scena compaiono degli oggetti che necessitano di tassellazione.

a questo punto il driver deve associare il compito agli shader che hanno una funzione fissa di tassellazione con priorita' rispetto agli altri effetti.

da 300fps al secondo ne avrai molti meno, perche' quegli shader che stanno calcolando la tassellazione, non possono calcolare il resto allo stesso momento.

poi sara' comunque il driver a stabilire quanti shader impegnare allo stesso momento per la tassellazione e gli halt per le altre istruzioni.
tutto questo facendo attenzione a non creare colli di bottiglia per il resto delle istruzioni...

Originariamente inviato da Ratatosk

Il problema è che prima arricchisci i modelli poligonali e poi fai rendering su quei poligoni, quindi le richieste di risorse per il rendering on diminuiscono, ma solo il numero di poligoni che la CPU deve dare in pasto alla GPU.



Questo si sapeva anche se non ce lo diceva AMD

ok, ora è tutto più chiaro...grazie.

Però allora fermi avrà problemi x i discorsi suddetti, le ati hanno problemi non appena si attiva un minimo di tessellazione...io sinceramente non ne vedo più l'utilità...in entrambe i casi non vedo risultati che potrebbero soddisfarmi. È ovvio che se avremmo vga che stanno a 300fps senza e 100 con, sarò strafelice ma non credo proprio sia il caso di queste vga...che ne dite?

[PConly92]

Originariamente inviato da appleroof

non è vero, infatti mentre è attiva la tassellazione è attiva anche la "classica" renderizzazione (quest'ultima la puoi escludere ma normalmente il test è fatto "completo")

peccato che nvidia usasse una versione modificata di unigine dove la renderizzazione "classica" è ridotta al minimo...quindi quei frame adesso e come non ci fosserò

[calabar]

Originariamente inviato da Ratatosk

Io direi il contrario. Se la tessellation diventerà massiva nell'approccio nVIDIA toglierà risorse al rendering (che non sarà quello di Unigine), in quello AMD no.

Con "scommessa per il futuro" NON intendevo dire che quello sarà il futuro e nvidia scommetterà su di esso, ma semplicemente che nvidia ha scommesso sul fatto che in futuro quelle feature saranno un vantaggio.

Originariamente inviato da yossarian

[...] il che significa che T sarà eseguita molto più velocemente ma tutto il resto subirà notevoli rallentamenti, senza ocntare che un massiccio utilizzo di tessellation richede anche un maggior impegno dei PS

Credo che in questo Diobrando_21 abbia ragione: si può supporre che in un motore ben programmato faccia corrispondere alla tessellazione una diminuzione della necessità di potenza per il resto.
Quindi: no tessellation: SP liberi per il resto, tessellation: riversamento della potenza non più necessaria nel rendenring per fare tessellation.
Tutto sommato l'idea sembra buona, bisogna poi vedere i numeri della pratica.

Originariamente inviato da skizzo99999999

[...]

Certo Anche i miei numeri del resto lo erano.

Provo a chiarire quel che volevo dire con un ulteriore esempio, totalmente ipotetico.
Poniamo di avere un'architettura x dx11 con tessellatore dedicato (tutto!) e 240SP. Ora facciamo un'architettura nuova, con 512 sp (più del doppio) e tessellatore solo in parte dedicato (tipo fermi).
Ora, vedendo i 512SP, l'utente si aspetta prestazioni legate ad una potenza più che doppia. Ma in realtà questo non è vero, perchè la mancanza di hd dedicato lo farà andare come una 480 sp (anche stavolta, un numero quasi a caso, tanto per capirci).

Per il resto naturalmente concordo, l'unico dubbio riguarda proprio quei parametri che non conosciamo, ossia quanto un'unità dedicata è più efficiente e quanto spazio occupa rispetto alle SP.

Originariamente inviato da calabar

[...] (che poi da quel che avevo capito non era il tessellator ad essere stato potenziato, ma gli stadi successivi che dovevano gestire il gran numero di triangoli generati dal tessellator) [...]

Qualcuno può dire qualcosa di preciso a riguardo?

[yossarian]

Originariamente inviato da skizzo99999999

Ribadisco che i numeri che ho dato sono campati in aria e servono solo come esempi, ma ciò non toglie che secondo me parlare con un po di numeri aiuta. Ribadisco che quello che conta è quanto ci metto ad elaborare un frame completo di tutto: tutti i vertex, tutti i pixel, tutta la tessellazione, ecc... Mettiamo caso che un frame impieghi 16 millisedondi per essere eseguito sulla gpu1 con 480+T. In quei 16 msec, diciamo che la tessellazione ci mette 2 millisecondi. quindi per quei 2 millisendi io ho 480 sp occupati (facciamo finta che si abbia un utilizzo del 100% tanto per semplificare) più gli sp per hull e domain, mentre per i restanti 14 msec saranno occupati "soltanto" i 480 sp generici, con quelli per hull e domain a girarsi i pollici. Nella gpu2 a 512 sp, mettiamo (sempre per semplificare) di dedicare 32 sp alla tessellazione, quindi di rimanere con 480 sp generici per il resto. Quelle operazioni che prima richiedevano 2 msec, grazie alla minor efficienza degli sp generici (ma comunque relativa, visto le considerazione del post precedente) mettiamo che ne richiedono 3. Guardando gli atri 480sp, per quanto riguarda i primi 3 msec la situazione è uguale alla gpu1, presupponendo che si riesca ad occuparli tutti nonostante si abbiano meno dati in "uscita" dalla fase di tessellazione nell'unità di tempo, ma questo non possiamo saperlo (anche se il tessellator potenziato e diviso in 16 parti serve anche per poter offrire, oltre a una potenza totale maggiore anche una migliore granularità utile nel caso in questione). Negli gli altri 13 msec però, io ho a disposizione tutti e 512 gli sp, per cui posso eseguire il resto più velocemente (e quindi impiegare meno di 13 msec). Quindi rallentando una fase ho velocizzato il resto. Il fatto di dedicare 64, 128, 256, sp alla tessellazione invece che 32 non cambia il risultato: infatti gli sp "sottratti" serviranno a terminare prima la tessellazione in modo da liberarli prima per eseguire gli altri compiti, ma il tempo totale non cambia. Può essere utile per bilanciare meglio il carico in modo da tenere sempre più unità utilizzate, visto che le operazioni possono dipendere le une dalle altre ed eseguire massicciamente operazioni prima di un tipo poù essere utile per occupare meglio tutte le risorse a disposizione.
Faccicamo un altro esempio con la gpu2: mettiamo che gli sp eseguano una operazione ogni msec e ci mettano sempre un ciclo per ogni operazione (altra semplificazione, ma come sempre è per far capire): vuol dire che ho a disposizione 512 "cicli" per ogni msec, il che vuol dire 512x16=8192 cicli in totale occupati nel frame. Se io uso 32sp per hull e domai e ho detto che ci metto 3msec, vuol dire che l'operazione consuma 32x3=96 cicli. Me ne rimangono (480x3)+(512x13)=8096 a disposizione per il resto. Se io invece impiego subito 96sp, finisco tutto in 1 msec, per cui ho bruciato più sp subito, ma da'altro canto ci ho sempre messo 96 cicli, per cui ho sempre (416x1)+(512x15)=8096 per il resto. Se gli sp eseguissero invece una operazione più velocemente di un'altra allora il bialnciamento delle unità servirebbe a trovare il "punto" giusto in cui avere le migliori prestazioni, ma non è questo il nocciolo della questione. Il senso dell'esempio è che quello che conta è il tempo totale del frame, non della singola fase.

Come nel mio esempio precedente, è più o meno lo stesso principio del pixel e vertex shader contro shader unificati: questi ultimi, nonostante fossero meno efficienti (= più lenti) hanno permesso di sfruttare al meglio tutte le unità a disposizione in ogni momento, in modo da ganarare l'intero frame più velocemente. Qundi una scheda "full 512sp", cioè 512+T (che presuppone ulteriori sp per hull e domain) sarebbe si più veloce di una "512 senza T", ma sello stesso die size della 512+T magari ci posso mettere una 544 senza T. Il concetto è questo.

non hai tenuto conto di alcuni elementi:
1) gli Hull shader hanno unità constant function il cui lavoro deve essere emulato da quelle fp dello shader core (minore efficienza)
2) nell'esecuzione di VS, HS, DS, GS, PS, texture blending, sono richieste operazioni di thread switching; e tanto maggiore è il numero di tilogie di calcoli che una unità può eseguire, tanto più alto sarà la probabilità di dover eseguire uno switch (= cicli persi per ogni switch)
3) al contrario, se immagini un'elaborazione di tipo seriale (prima i VS, poi gli HS, poi la tessellation, quindi DS, GS, rasterizer) allora toriniamo al concetto di pipeline classica e si perde gran parte del vantaggio degli shader unificati.
In base a queste considerazioni, avere 512+T è meglio che avere 544 alu generiche a parità di die size.
4) se fai il raffronto con RV870 (perchè di questo si parla) il secondo è proprio nella situazione di chi ha 512+T.

Il discorso di Calabar è corretto: parliamo di un chip che ha un numero massimo di 512 alu teoriche che si confronta con un chip che ne ha 1600 (di tipo differente). Se faccio uso di tessellation il secondo continuerà ad avere 1600 alu dedicate a fare ciò che facevano anche prima, il primo non avrà più 512 alu dedicate agli stessi compiti ma decisamente meno e saranno tante di mneo quante più si deciderà di dedicarne alla tessellation. Discorso analogo a quello visto per physx: attivalo e vedrai il frame rate andare a picco e tanto più è pesante l'effetto implementato e tanto più è pesante il motore grafico, tanto più le prestazioni crollano. Fisicamente parlando un'unità o un cluster che si sta occupando di tessellare o di fare calcoli fisici non può, contemporaneamente fare altro.

Diciamo che nVidia ha scelto la strada che le permetteva di implemenatre il maggior numero possibile di unità di calcolo di generiche. Questo permette di avere una maggior efficienza dell'intera architettura ma una minor efficienza in ogni singolo task. D'altra parte, con un chip così complesso la strada era pressoche obbligata e l'adozione di unità dedicate avrebbe portato ad un ulteriore aumento delle dimensioni del chip per degli stadi che sono impiegati solo quando servono (in un gioco privo di tessellation, l'unità dedicata resta del tutto inattiva mentre quelle generiche le utilizzo per fare altro). In tal senso, anche la scelta di ricorrere alle unitàà di shading per il texture blending. Restano, però, come unità dedicate, quelle di texture sampling e addressing e quelle che fanno resolve per il MSAA box. Questo significa che la loro sostituzione comportava un eccessivo aumento delle unità generiche per compensare le perdite prestazionali (un'operazione di texture sampling richiede 20 cicli con unità generiche dove una dedicata se la cava con un singolo ciclo, ad esempio).

[yossarian]

Originariamente inviato da calabar

Credo che in questo Diobrando_21 abbia ragione: si può supporre che in un motore ben programmato faccia corrispondere alla tessellazione una diminuzione della necessità di potenza per il resto.
Quindi: no tessellation: SP liberi per il resto, tessellation: riversamento della potenza non più necessaria nel rendenring per fare tessellation.
Tutto sommato l'idea sembra buona, bisogna poi vedere i numeri della pratica.

la tessellation può essere usata per aumentare il dettaglio poligonale (e allora comporta un maggior peso di calcoli anche a valle) o per conservare lo stesso dettaglio migliorando l'occupazione di memoria e la banda passante occupata (ho meno vertici da immagazzinare all'interno dei buffer, ho meno vertici da trasferire attraverso il bus, ecc). In tal caso, a valle del tessellator, la complessità dei calcoli non diminuisce. Il vantaggio è che lavora meno la cpu perchè deve definire un numero inferiore di punti iniziali

[ghiltanas]

Originariamente inviato da Diobrando_21

ok, ora è tutto più chiaro...grazie.

Però allora fermi avrà problemi x i discorsi suddetti, le ati hanno problemi non appena si attiva un minimo di tessellazione...io sinceramente non ne vedo più l'utilità...in entrambe i casi non vedo risultati che potrebbero soddisfarmi. È ovvio che se avremmo vga che stanno a 300fps senza e 100 con, sarò strafelice ma non credo proprio sia il caso di queste vga...che ne dite?

io dico che questa nn è la generazione del tessellation, e lo si vede anceh dal fatto che giochi che ne fanno uso intensivo ancora nn ce ne sono, e anche in uscita nn mi pare di aver sentito nulla a riguardo. Credo bisognerà attendere la seconda generazione di schede dx11, ati e nvidia miglioreranno sicuramente ò'hardware per tale scopo, e allora si spera sarà necessario.
Al momento entrambe le implementazioni vanno bene (sempre imho) proprio perchè tale features è implementata in maniera lieve

[Alex656]

Finalmente la discussione riacquista interesse con il confronto serrato tra Yoss e Skizzo...............alla faccia delle solite stupidaggini sulla manciata di frames in più o in meno del benckmark x o del gioco y.