[THREAD UFFICIALE] Aspettando Nvidia GTX 480 e GTX 470

[Athlon 64 3000+]

Se veramente in fermi non hanno implementato l'unita di tesselazione la cosa non mi piacerebbe perchè conoscendo Nvidia come hanno gia fatto con le dx 10.1 potrebbero cercare di boicottarla.:mad:

[atomo37]

boh speriamo perchè se sta 5870 continua a far girare solo i giochi che vuole lei....a me non sta bene. Sembra un componente alieno. con la GTX 275 andava tutto alla grande.

se non risolvono con i driver mi sa che posso passare ancora a Nvidia.

io francamente a tutt'oggi non ho avuto il minimo problema con nessun gioco, e considera che ne ho due in crossfire e pure su doppio display quindi una configurazione atipica.
giochi provati senza problemi:
call of juarez
shift
gta IV
cod mw 2
wolfstein (l'utlimo)
saw
resident evil 5
batman
grid
l4d 2
shuttered horizon
e sicuramente me ne sfugge qualcuno :)

[okorop]

Se veramente in fermi non hanno implementato l'unita di tesselazione la cosa non mi piacerebbe perchè conoscendo Nvidia come hanno gia fatto con le dx 10.1 potrebbero cercare di boicottarla.:mad:

scenario alquanto probabile, anche se spero che sia emulata comunque via software

[devAngnew]

no non era questa citava proprio che il tessalation sarebbe stato impiegato direttamente in hardware e non emulato, pero' nvida da settembre ad oggi potrebbe aver cambiato piano per tale implementazione, chi vivrà vedrà

Kharonte85 ha ragione nvidia non può aver cambiato proprio niente la tesselation Unit hardware o c'è o non c'è anche perchè a settembre già c'era da tempo la revisione A0 della gpu e cmq. queste cose si decido già a livello progettuale quando la gpu fisica ancora non esiste.

;)

[ertruffa]

io francamente a tutt'oggi non ho avuto il minimo problema con nessun gioco, e considera che ne ho due in crossfire e pure su doppio display quindi una configurazione atipica.
giochi provati senza problemi:
call of juarez
shift
gta IV
cod mw 2
wolfstein (l'utlimo)
saw
resident evil 5
batman
grid
l4d 2
shuttered horizon
e sicuramente me ne sfugge qualcuno :)

quoto e aggiungo i 2 crysis,pes2010,cod 4 e5,operation flash. volano;)

[Psyco89]

scusate ma 512 stream cuda non è un po' troppo ?

ATI con le nuove shcede 5870 fa fatica a star davanti alla 4870 X2 e infatti la GTX 295 è meglio, ma se Nvidia avrà 512 stream ovvero più del doppio della 285 e più di quelle della 295 ( con architettura migliore diciamo perchè non penso sia peggiorata no ? ) non dovrebbe battere abbastanza facilmente una GTX 295 e quindi la mia ATI ?

[The_SaN]

scusate ma 512 stream cuda non è un po' troppo ?

ATI con le nuove shcede 5870 fa fatica a star davanti alla 4870 X2 e infatti la GTX 295 è meglio, ma se Nvidia avrà 512 stream ovvero più del doppio della 285 e più di quelle della 295 ( con architettura migliore diciamo perchè non penso sia peggiorata no ? ) non dovrebbe battere abbastanza facilmente una GTX 295 e quindi la mia ATI ?Le ultime 3 pagine parlano proprio di questo.
Questi 512 cuda cores potranno fare 512 o 256 operazioni MADD?
Se leggi attentamente vedrai che c'é la possibilitá che vada poco piú di una gtx285.
Ovviamente é da vedere nelle recensioni...

[Psyco89]

Le ultime 3 pagine parlano proprio di questo.
Questi 512 cuda cores potranno fare 512 o 256 operazioni MADD?
Se leggi attentamente vedrai che c'é la possibilitá che vada poco piú di una gtx285.
Ovviamente é da vedere nelle recensioni...

mi sembra strano perchè Nvidia continua a dire che l'attesa sarà ricompensata, adesso so che è pubblicità o modi per attrarre l'attenzione però dire certe cose quando la vga non ha un asso speciale nella manica mi sembra eccessivo.

[The_SaN]

mi sembra strano perchè Nvidia continua a dire che l'attesa sarà ricompensata, adesso so che è pubblicità o modi per attrarre l'attenzione però dire certe cose quando la vga non ha un asso speciale nella manica mi sembra eccessivo.Peró di prestazioni e benchmarks non hanno mai parlato. Ed é questo che mi preoccupa.
Oltre al fatto di non aver smentito l'articolo di hardware.fr :stordita:

Parlano molto, forse troppo, di features aggiuntive (physx, 3d, ecc...)

Spero comunque che Fermi si riveli competitivo. La situazione di stallo odierna, unita ai problemi di TSMC di certo non aiuta il consumatore...
Purtroppo manca ancora un bel po' all'uscita della next gen nVidia.

[yossarian]

Qualcuno tempo fa qui sul forum posto' una immagine (che purtroppo non sono riuscito a ritrovare :( ) che sembrava provenire da una slide ufficiale di nvidia e faceva intendere che il tesselatore sarebbe stato in hw.

era la slide di una pipeline dx11 (non faceva diretto riferimento all'architettura di fermi). Però io sono dell'idea che il tessellator ci sarà in hardware (almeno le fixed function che si occuapano dell'operazione di tessellation vera e propria ma, immagino, anche hull shader e domain shader).
L'ipotesi di un tessellator emulato era di devAngnew, ma la ritengo molto poco plausibile

[pandyno]

Sono daccordo, emulare la tessellation significa in sostanza non averla.

Non necessariamente: avrà prestazioni di molto inferiori, ma ci saranno effetti grafici che varranno la pena essere utilizzati.



I chipset erano un terzo del fatturato...



Fidati: è meglio che si sia ritirata da quel mercato, sebbene i chipset che proponeva erano di buona qualità, il comparto driver lasciava molto a desiderare.


Ad ogni modo io non avevo niente da dire sulla serie FX e su R600, ho da dire solo ora, perché la situazione del mercato e dei competitor è molto diversa da quando AMD ha acquisito ATi e da quando Intel lavora ad una sua GPU.



E ti sei perso tante cose anche prima di R600 :)


In quel settore nVidia si fa massa ma si guadagna pochissimo, e quel cliente di cui fai l'esempio è un cliente decisamente poco comune. Detto questo nel Q1 AMD presenterà anche il low-end della nuova serie, mentre se va bene nVidia presenterà l'hi-end, quindi è un mercato che nVidia non avrà fino ad almeno il Q3 se i derivativi serie 3xx usciranno molto velocemente (visto che non hanno ancora fatto il tapeout).


Stai attento perchè GeForce è un brand fortissimo: il 99% delle persone che sento vuole NVIDIA, non sanno che la serie 5000 è disponibile; il mercato non è cambiato poi così tanto.



Sono il primo che non scommetterebbe mezzo € su Intel in campo GPU, ma allo stato attuale è più avanti Larrabee di Fermi, visto che sono riusciti a far vedere dei sample funzionanti che facevano girare delle demo, cosa che nVidia non ha fatto. Ad ogni modo ritengo che Larrabee sarà un competitor nel segmento performance, non in quello high end, cioè quello in cui l'integrazione driver in funzione del risparmio energetico con la IGP è più importante (di qui il discorso su cosa sceglieranno gli OEM).


Che è la fascia più ampia che è andato a ricoprire l'I740 anni orsono ;)


Dopo che avrò visto AVP sarò pronto a formulare la mia tesi in proposito :)

Lo spero vivamente, abbiamo subito un ristagno tecnologico grazie/a causa di xbox 360 non indifferente.

[yossarian]

il CEO di Nvidia ha dichiarato che entro il 2009 ci sarà un'incontro con la stampa specializzata per render note tutte le potenzialità dei nuovi prodotti GeForce. Ufficialmente dovrebbero esser presentate il 7 gennaio 2010 e in quanto alla commercializzazione essa è attesa per metà/fine gennaio 2010.
;)

non c'è niente che possa essere presentato il 7 gennaio 2010 che non lo possa essere il 20 dicembre 2009 :D. Si tratta di un'affermazione paragonabile a quella:"la presentazione avverrà un martedì". E' un modo di dire non dicendo nulla. Ammesso e non concesso che abbia detto una cosa del genere, può averlo fatto solo per rassicurare gli investitori con un messaggio del tipo: saltiamo il periodo di natale per scelta e non perchè abbiamo problemi.

Su Beyond3D c'è addirittura chi prospetta problemi (artefatti) per una precisione troppo alta nel gaming...

http://forum.beyond3d.com/showpost.php?p=1343003&postcount=285

http://forum.beyond3d.com/showpost.php?p=1343030&postcount=296

P.S.: per chi volesse assicurarsi una prenotazione per le primissime GeForce basate su Fermi, segnalo che può farlo alla modica cifra di 1699$ + IVA... :asd: (In cambio si ottengono anche una motherboard quad-SLI ready e 4 GTX285)

http://www.evga.com/blackfriday/

avevo letto qualcosa del genere, ma non mi viene in mente il motivo per cui dovrebbe dare artefatti, anche perchè, una pipeline di tipo FMA, con le dovute integrazioni, può eseguire normali MADD. Ovviamente quando si esegue una FMA o una MADD la "chiamata" esterna deve essere specificata in tal senso (se ho una istruzione di tipo MADD non eseguirà una FMA, per intenderci)

[A.L.M.]

scusate ma 512 stream cuda non è un po' troppo ?

ATI con le nuove shcede 5870 fa fatica a star davanti alla 4870 X2 e infatti la GTX 295 è meglio, ma se Nvidia avrà 512 stream ovvero più del doppio della 285 e più di quelle della 295 ( con architettura migliore diciamo perchè non penso sia peggiorata no ? ) non dovrebbe battere abbastanza facilmente una GTX 295 e quindi la mia ATI ?

In effetti ormai certi termini sono buoni solo per il marketing.
Ti basti sapere che i CUDA cores di Fermi sono diversi da quelli di GT200, il che non necessariamente significa che siano migliori. Se 512 cores di Fermi sono davvero come 512 cores di GT200 nel gaming, questo non si sa ancora.

Lo spero vivamente, abbiamo subito un ristagno tecnologico grazie/a causa di xbox 360 non indifferente.

Io ci aggiungerei anche (e soprattutto) grazie alla PS3, visto che se fosse per la Xbox e per ATI, avremmo già la tessellation da anni sia sulle console che sui pc, tanto per fare un esempio.

avevo letto qualcosa del genere, ma non mi viene in mente il motivo per cui dovrebbe dare artefatti, anche perchè, una pipeline di tipo FMA, con le dovute integrazioni, può eseguire normali MADD. Ovviamente quando si esegue una FMA o una MADD la "chiamata" esterna deve essere specificata in tal senso (se ho una istruzione di tipo MADD non eseguirà una FMA, per intenderci)

Non mi sono però chiari alcuni passaggi:
- perchè NVidia non dovrebbe aver implementato dei cores in cui è possibile eseguire sia MADD che FMA con lo stesso numero di clocks? Mera questione di spazio dei cores?
- la storia delle MADD "a mezza velocità", da cosa potrebbe derivare? Dal fatto che Fermi eseguendo solo MADD senza rounding intermedio (FMA), ha bisogno di qualche strano workaround per arrivare allo stesso risultato prodotto da normali unità MADD?
- Quello che inoltre non capisco dei calcoli di Hardware.fr è: mi è chiaro che esiste una differenza tra una MADD con rounding intermedi e senza, ma non capisco che differenza ci sia tra l'eseguire una semplice moltiplicazione (MUL) o addizione (ADD) con un'unità solo MADD e con una solo FMA... Non fanno entrambe il rounding alla fine? Perchè dovrebbe esserci una penalità in termini velocistici?

[Foglia Morta]

nVidia ,in mancanza d' altro, invia news sui brevetti depositati:

http://www.tcmagazine.com/comments.php?shownews=31095&catid=6

With nothing new to show until Q1 2010, Nvidia still managed to put on a smile recently due to the fact that its IP portfolio has reached 1,000 patents. The milestone patent was awarded on October 27, it has been stamped with the number 7609272, and it talks about an invention that makes the pixel processing pipeline faster and more efficient through the use of all available circuitry for partial texture loads.

According to the nTersect blog:

"Textures can be 32-bit, 64-bit, or 128-bit. But anything larger than 32-bit requires more than one pass. Before Bastos and Kilgariff's invention, texture lookups were monolithic instructions that took multiple cycles to be executed, leaving other shader functional units to sit idle. “The idle units in the pipe presented the opportunity to try to fit other, non-texture instructions in those slots – i.e., run more than one instruction per cycle,” says Bastos. But to do that, the monolithic texture-load instructions had to be split into chunks. Break a 128-bit texture into four pieces – each of which can be completed in one pass – and that lets one cycle-hungry instruction be broken into four instructions. Doing this means that other circuits keep processing instructions – no more waiting."

The partial texture load invention has first used for the GeForce 6 series cards and it also made its way into the RSX GPU which can be found in Sony's PlayStation 3 console.

Edit:

non conoscevo questo blog , ogni tanto postano qualcosa: http://blogs.nvidia.com/nTersect/

[yossarian]

Non mi sono però chiari alcuni passaggi:
- perchè NVidia non dovrebbe aver implementato dei cores in cui è possibile eseguire sia MADD che FMA con lo stesso numero di clocks? Mera questione di spazio dei cores?
- la storia delle MADD "a mezza velocità", da cosa potrebbe derivare? Dal fatto che Fermi eseguendo solo MADD senza rounding intermedio (FMA), ha bisogno di qualche strano workaround per arrivare allo stesso risultato prodotto da normali unità MADD?
- Quello che inoltre non capisco dei calcoli di Hardware.fr è: mi è chiaro che esiste una differenza tra una MADD con rounding intermedi e senza, ma non capisco che differenza ci sia tra l'eseguire una semplice moltiplicazione (MUL) o addizione (ADD) con un'unità solo MADD e con una solo FMA... Non fanno entrambe il rounding alla fine? Perchè dovrebbe esserci una penalità in termini velocistici?

provo a risonderti.
1) nel caso che sia effettivamente confermato che le madd sono l ametà delle fma, si, allora sarebbe una mera questione di spazio perchè unità di tipo fma che eseguano madd devono avere degli stadi in più.
2) ci sono tre possibili risposte: a) la madd richiede il doppio dei cicli di clock perchè viene eseguita in due passate nella stessa alu anzichè in single pass; b) la madd richiede l'impiego di due alu che lavorino in serie e, in tal caso, l'istruzione è eseguita in single pass ma impiegando la metà delle alu totali; c) solo 256 alu hanno gli stadi in più per eseguire madd.
Nel primi due casi le operazioni "mancanti in hardware" vengono emulate.
3) add e mul non sono eseguiti a mezza velocità; semplicemente una madd o una fma sono due flops (quindi devi raddoppiare il numero di istruzioni per avere il numero di operazioni), una add o una mul comportano una singola operazione. Quindi, stando a quanto riportato da hw.fr, in caso di fma hai, in totale, 1024 flops per ciclo (teoriche), ovvero 512*2; in caso di madd, 512 flops per ciclo (256*2), in caso di mul e add 512 flops per ciclo (una per ogni alu).
Da notare che secondo la slide di hw.fr, le alu di GT300, al contrario di quelle di GT200, non eseguono la mul in più.

[Psyco89]

ma scusate quindi 512 stream cuda sono riferiti al top di gamma quindi un ipotetica GTX 380 ? Quindi suppongo che un ipotetica GTX 360 ne dovrebbe avere meno di 512, più probabilmente da punto di vista matematico 480 giusto ?

[halduemilauno]

ma scusate quindi 512 stream cuda sono riferiti al top di gamma quindi un ipotetica GTX 380 ? Quindi suppongo che un ipotetica GTX 360 ne dovrebbe avere meno di 512, più probabilmente da punto di vista matematico 480 giusto ?

giusto 480 e per un'altra versione ancor + inferiore 448.
;)

[Psyco89]

Quindi con 480 già sarebbe in linea su carta con la proposta ATI. Nel senso che han raddoppiato entrambi le proprie proposte senza vantaggio evolutivo di nessuno dei 2 per ora. Anzi se gli stream CUDA dovessere essere simili agli stream GT200 possiamo prevedere una situazione del tipo 4890 & GTX 275, non mi sembra male.

Vedremo come saranno questi stream CUDA, ma non potrebbero essere anche superiori a quelli di GT200 ?

[okorop]

Kharonte85 ha ragione nvidia non può aver cambiato proprio niente la tesselation Unit hardware o c'è o non c'è anche perchè a settembre già c'era da tempo la revisione A0 della gpu e cmq. queste cose si decido già a livello progettuale quando la gpu fisica ancora non esiste.

;)

bisogna vedere quale versione han fatto, ricordo che la versione della gpu tesla non ha l'hardware tessaletion ;)

[Psyco89]

bè ma comunque bisogna vedere le prossime uscite di giochi per vedere chi sarà la vga migliore perchè Nvidia anche se inferiore va a finire che i giochi se li fa adattare dalle case.

tessellation hardware o emulato il modo di farcelo mandar giù lo trovano.

[okorop]

Chi l'ha detto? ;)

se c'è qualcosa in piu' nvida lo deve dichiarare visto che il progetto di fermi l'ha rilasciato a settembre per coerenza logica a mio avviso, e in quel progetto l'hardware tessalation non viene menzionato

[pandyno]

bè ma comunque bisogna vedere le prossime uscite di giochi per vedere chi sarà la vga migliore perchè Nvidia anche se inferiore va a finire che i giochi se li fa adattare dalle case.

tessellation hardware o emulato il modo di farcelo mandar giù lo trovano.

"Adattare" in che senso?

[okorop]

Non ha mai parlato di GeForce e Quadro, ma solo Tesla, per le quali il tessellator è del tutto irrilevante, perché parlarne?

ma scusa, l'unica vga che va a quanto pare è la tesla, l'archittettura della tesla pare essere uguale alla quadro e alla versione Geforce e dagli schemi sto hardware tessalation non c'è, o l'hanno aggiunto e per coerenza dovrebbero annunciarlo almeno in una slide oppure non c'è

[Ren]

Yoss, grazie per la tua risposta sulle FMA.

Volevo lanciare un ragionamento sulle capacità INT di Fermi. Come vediamo dagli schemi sono in misura preponderante rispetto a GT200 o Cypress.

E' plausibile un utilizzo obbligato (dalle dimensioni del chip) per emulare le fixed-fuction ?

Che io sappia il filtraggio delle texture e le rop's annoverano anche unità integer per calcoli come l'interpolazione.

Prevedi un calo prestazionale considerevole se la previsione si rivelasse esatta ?

Ultima domanda che avevo già posto,
Quanto influiscono nei giochi attuali le capacità di addressing delle texture ?

[Psyco89]

"Adattare" in che senso?

che ottimizzano per Nvidia e mettono particolari funzioni o effetti o magari utilizzando particolari algoritmi che avantaggiano Nvidia e penalizzano ATI, io infatti mi ritrovo abbastanza problematicizzato con questa ATi che ho preso, prestazioni superiori alla evcchia GTX 275 ovvio però a livello di software non è il max.



Anche la 4890 come potenza elaborativa era superiore alla GTX 285 eppure è molto inferiore.

[A.L.M.]

provo a risonderti.
1) nel caso che sia effettivamente confermato che le madd sono l ametà delle fma, si, allora sarebbe una mera questione di spazio perchè unità di tipo fma che eseguano madd devono avere degli stadi in più.
2) ci sono tre possibili risposte: a) la madd richiede il doppio dei cicli di clock perchè viene eseguita in due passate nella stessa alu anzichè in single pass; b) la madd richiede l'impiego di due alu che lavorino in serie e, in tal caso, l'istruzione è eseguita in single pass ma impiegando la metà delle alu totali; c) solo 256 alu hanno gli stadi in più per eseguire madd.
Nel primi due casi le operazioni "mancanti in hardware" vengono emulate.
3) add e mul non sono eseguiti a mezza velocità; semplicemente una madd o una fma sono due flops (quindi devi raddoppiare il numero di istruzioni per avere il numero di operazioni), una add o una mul comportano una singola operazione. Quindi, stando a quanto riportato da hw.fr, in caso di fma hai, in totale, 1024 flops per ciclo (teoriche), ovvero 512*2; in caso di madd, 512 flops per ciclo (256*2), in caso di mul e add 512 flops per ciclo (una per ogni alu).
Da notare che secondo la slide di hw.fr, le alu di GT300, al contrario di quelle di GT200, non eseguono la mul in più.

Direi che ho capito, grazie. :)

Tra l'altro rileggendo l'articolo di hw.fr sembra che loro propendano per una soluzione in cui i CUDA cores nel caso in cui ricevano istruzioni MADD dividano l'operazione in una MUL ed una ADD, in modo da avere i 2 rounding "necessari". Questo appunto li porterebbe a fare le MADD in double pass (uno per la MUL e uno per l'ADD).

[okorop]

che ottimizzano per Nvidia e mettono particolari funzioni o effetti o magari utilizzando particolari algoritmi che avantaggiano Nvidia e penalizzano ATI, io infatti mi ritrovo abbastanza problematicizzato con questa ATi che ho preso, prestazioni superiori alla evcchia GTX 275 ovvio però a livello di software non è il max.



Anche la 4890 come potenza elaborativa era superiore alla GTX 285 eppure è molto inferiore.

le prestazioni della tessalation emulata via software rispetto a una già calcolata via hardwre non son del tutto simili anzi, non c'è adattamenti che tengano..

Eh ma sono slide, non è che vanno nel dettaglio di ogni singolo componente architetturale, se non quelli di interesse alla discussione, che in tutti i casi è stata incentrata sulle Tesla.

Oppure dovremmo partire dal presupposto che le schede non hanno TMU...

si si certo, mi auguro che a breve facciano dei chiarimenti in merito anche sulla scheda video gaming alias gtx380 :)

[pandyno]

che ottimizzano per Nvidia e mettono particolari funzioni o effetti o magari utilizzando particolari algoritmi che avantaggiano Nvidia e penalizzano ATI, io infatti mi ritrovo abbastanza problematicizzato con questa ATi che ho preso, prestazioni superiori alla evcchia GTX 275 ovvio però a livello di software non è il max.



Anche la 4890 come potenza elaborativa era superiore alla GTX 285 eppure è molto inferiore.

Ma cosa intendi per potenza? :D tu hai problemi di alimentazione fidati. ;)

[Psyco89]

Ma cosa intendi per potenza? :D tu hai problemi di alimentazione fidati. ;)

Io parlo di GFlops/s

ATi nella seri 4 ne faceva di più della GTX 285 ma Nvidia penso che abbia sfruttato meglio le proprie funzionalità, no ?


Tessellation o no, io queste grandi performance non le ho viste su ATI, cioè va come una 4870 x2 e meno di una GTX 295, teoricamente quando esce una new generation in automatico tutte le altre schede dovrebbero essergli inferiori e invece questa sembra un po' impacciata no ?

[okorop]

Io parlo di GFlops/s

ATi nella seri 4 ne faceva di più della GTX 285 ma Nvidia penso che abbia sfruttato meglio le proprie funzionalità, no ?


Tessellation o no, io queste grandi performance non le ho viste su ATI, cioè va come una 4870 x2 e meno di una GTX 295, teoricamente quando esce una new generation in automatico tutte le altre schede dovrebbero essergli inferiori e invece questa sembra un po' impacciata no ?

ribadisco che questo è il thread aspettando le nuove schede video nvida e non come mai cypress non va di piu' della gtx295 :asd:, son domande che ti poni comunque lecite ma totalmente ot. Vedremo come andrà gt300, e in base a come va valuteremo il mercato delle gpu meglio di come lo stiamo faccendo attualmente. leggendo l'articolo di hw.fr sono un po scettico su tutta sta potenza in ambito videoludico di fermi, spero e mi auguro che non sia cosi........
per quanto riguarda i GFlops/s marchi male, le nvida son sempre state inferiori rispetto alle ati dall'uscita di rv780 di un anno e mezzo fa......

[The_SaN]

Io parlo di GFlops/s

ATi nella seri 4 ne faceva di più della GTX 285 ma Nvidia penso che abbia sfruttato meglio le proprie funzionalità, no ?


Tessellation o no, io queste grandi performance non le ho viste su ATI, cioè va come una 4870 x2 e meno di una GTX 295, teoricamente quando esce una new generation in automatico tutte le altre schede dovrebbero essergli inferiori e invece questa sembra un po' impacciata no ?Si ma non é mai successo che la single new gen fosse piú potente della dual old gen.
Nemmeno con la 8800gtx (la migliore nVidia di sempre, e la migliore scheda di sempre insieme alla 9700pro), visto che quando lo SLI funzionava a dovere la 7900gx2 era davanti...

Oltre al fatto che sono schede progettate per le dx11 (grande potenza negli SP, banda nella media cosi come il texturing), quindi vedremo le vere potenzialitá solo con i titoli dx11. Lo stesso dovrebbe valere per Fermi.

[Psyco89]

ribadisco che questo è il thread aspettando le nuove schede video nvida e non come mai cypress non va di piu' della gtx295 :asd:, son domande che ti poni comunque lecite ma totalmente ot. Vedremo come andrà gt300, e in base a come va valuteremo il mercato delle gpu meglio di come lo stiamo faccendo attualmente. leggendo l'articolo di hw.fr sono un po scettico su tutta sta potenza in ambito videoludico di fermi, spero e mi auguro che non sia cosi........
per quanto riguarda i GFlops/s marchi male, le nvida son sempre state inferiori rispetto alle ati dall'uscita di rv780 di un anno e mezzo fa......

Sperem così magari ripasso ad Nvidia.

[yossarian]

ma scusa, l'unica vga che va a quanto pare è la tesla, l'archittettura della tesla pare essere uguale alla quadro e alla versione Geforce e dagli schemi sto hardware tessalation non c'è, o l'hanno aggiunto e per coerenza dovrebbero annunciarlo almeno in una slide oppure non c'è

diciamo che non ne hanno parlato; il che può voler dire due cose: non è integrata nel chip oppure non è stata menzionata perchè non è funzionale al gpgpu. Nel primo caso può essere presente su un chip esterno (non credo che fermi abbia il chip NVIO esterno o, addirittura, che abbia unità interne dedicate al 2D. Penso piuttosto che la gestione del 2D sia affidata alle alu dello shader core).

Yoss, grazie per la tua risposta sulle FMA.

Volevo lanciare un ragionamento sulle capacità INT di Fermi. Come vediamo dagli schemi sono in misura preponderante rispetto a GT200 o Cypress.

E' plausibile un utilizzo obbligato (dalle dimensioni del chip) per emulare le fixed-fuction ?

Che io sappia il filtraggio delle texture e le rop's annoverano anche unità integer per calcoli come l'interpolazione.

Prevedi un calo prestazionale considerevole se la previsione si rivelasse esatta ?

Ultima domanda che avevo già posto,
Quanto influiscono nei giochi attuali le capacità di addressing delle texture ?

le unità di tipo INT di cui parla hw.fr sono quelle dello shader core. Sono utilizzate per calcoli di tipo gpgpu (alla stregua di quelle di tipo INT delle cpu) come, ad esempio, elaborazioni video o audio (si occupano delle operazioni di integer bitshift).
Per quanto riguarda le operazioni di texture filtering, in rv870 (di sicuro) e in fermi (molto probabilmente) le operazioni di interpolazione saranno affidate allo shader core; questo perchè dalle dx10.1 in poi sono previsti anche filtri di tipo custom non necessariamente frutto di interpolazione lineare. Ciò comporta l'abbandono delle unità fixed function dedicate nelle tmu per le operazioni di resolve ma non per quelle di texture sampling e texture fetch. La maggior propensione al'effettuazione di calcoli di tipo ff delle alu di GT300 avvantaggerà il chip nVidia nelle operazioni di testure filtering di tipo lineare (terreno in cui, storicamente, nVidia ha sempre avuto un certo margine di vantaggio a livello di potenza di calcolo).
Le operazioni di texture fetch e texture sampling sono tra quelle a più alta la tenza ed il loro impatto sull'elaborazione è piuttosto alto; non a caso, ad esempio ATi, da r600 in poi, ha previsto un numero di texture sampling unit di 4 volte superiore rispetto a quello di texture addressing e texture filtering unit. Per queste operazioni è previsto ancora l'uso di fixed function persino su larrabee (dove, invece, pare che si siano abbandonate le fixed function nelle rop's). A detta di Intel, questo tipo di operazioni, se emulato tramite unità programmabili può richiedere fino a 16 cicli di clock per operazioni che le fixed function eseguono in 1 o 2 cicli. In ogni caso, l'adozione di una gestione di centinaia di thread in contemporanea permette di mascherare, oggi, abbastanza bene le latenze delle operazioni di texturing (questo permette di effettuare multitexturing con molti layer senza un hit prestazionale troppo elevato).
Per quanto riguarda le rop's, fino alla generazione dx10 erano composta da fixed function per le operazioni relative all'applicazione del MSAA. Già con le dx10.1 si sono adottati filtri di tipo custom e lo stesso succederà con le dx11; sarà da vedere se si deciderà di mantenere, comunque, le unità dedicate alle operazioni di resolve del MSAA box (ovvero con filtraggio di tipo lineare) all'interno delle rop's

[Psyco89]

Si ma non é mai successo che la single new gen sia piú potente della dual old gen.
Nemmeno con la 8800gtx (la migliore nVidia di sempre, e la migliore scheda di sempre insieme alla 9700pro), visto che quando lo SLI funzionava a dovere la 7900gx2 era davanti...

Oltre al fatto che sono schede progettate per le dx11 (grande potenza negli SP, banda nella media cosi come il texturing), quindi vedremo le vere potenzialitá solo con i titoli dx11. Lo stesso dovrebbe valere per Fermi.


bè non è vero dai la 8800GTX e GTS640 ha letteralmente pestato la 7950GX2 e la GTX 260 ha superato di poco ma sempre superato la 9800GX2, dopo che è uscita la 216 stream poi l'ha anche staccata con più sicurezza, ma le dual GPU OLD gen almeno dal top di gamma sono sempre state superate.

Cioè io mi chiedo, se ATI non ha superato la GTX 295, non è più probabile che Nvidia la superi con entrambi i modelli ?

[yossarian]

Direi che ho capito, grazie. :)

Tra l'altro rileggendo l'articolo di hw.fr sembra che loro propendano per una soluzione in cui i CUDA cores nel caso in cui ricevano istruzioni MADD dividano l'operazione in una MUL ed una ADD, in modo da avere i 2 rounding "necessari". Questo appunto li porterebbe a fare le MADD in double pass (uno per la MUL e uno per l'ADD).

è una delle tre ipotesi, poichè una alu fma ha una sola unità di rounding mentre una madd ne ha due.

[kiriranshelo]

Cioè io mi chiedo, se ATI non ha superato la GTX 295, non è più probabile che Nvidia la superi con entrambi i modelli ?

In realtà sono pari, per fare i precisi una disparità del 5/7 %, se non ricordo male, a favore della GTX. cioè una media risicatissima

[Psyco89]

In realtà sono pari, per fare i precisi una disparità del 5/7 %, se non ricordo male, a favore della GTX. cioè una media risicatissima

bè 7% vuol dire che in alcuni giochi la differenza è del 0% e in altri è del 14%.
Su xbitlabs comunque la questione è ben più marcata, la mia VGA fa proprio fatica a star dietro alla 295.

[kiriranshelo]

bè 7% vuol dire che in alcuni giochi la differenza è del 0% e in altri è del 14%.
Su xbitlabs comunque la questione è ben più marcata, la mia VGA fa proprio fatica a star dietro alla 295.

si... ma il 14% su 60 fps quanti sono? 8.5 fps circa, una differenza quasi nulla direi; tranne per gli amanti del genere "fps" ovviamente.
qui (http://www.hwupgrade.it/articoli/skvideo/2287/ati-radeon-hd-5870-la-prima-scheda-video-per-directx-11_19.html) c'è, in fondo alla pagina, una differenza media di prestazioni tra 5870 e GTX295. In ogni caso potrebbe essere benissimo un problema di driver, magari appena usciti i prodotti fossero perfetti.

[Psyco89]

si... ma il 14% su 60 fps quanti sono? 8.5 fps circa, una differenza quasi nulla direi; tranne per gli amanti del genere "fps" ovviamente.
qui (http://www.hwupgrade.it/articoli/skvideo/2287/ati-radeon-hd-5870-la-prima-scheda-video-per-directx-11_19.html) c'è, in fondo alla pagina, una differenza media di prestazioni tra 5870 e GTX295. In ogni caso potrebbe essere benissimo un problema di driver, magari appena usciti i prodotti fossero perfetti.

purtroppo Hwup non ha il comparto giochi di xbitlabs, per questo ritengo xbitlabs un po' meglio sotto sto punto di vista.

ad esempio su crysis, cryostasis, resident evil 5, batman, shift, wolfenstein o lost planet la differenza fra 5870 e gtx 295 non è manco vicina a 7%, anzi quì la 5870 viene letteralmente fulminata.


Poi in quelli più in evidenza come COD 4-5-6 , left 4 dead, far cry 2, UT3 ecc vanno più o meno a braccetto.


In alcuni poi tipo stormrise o battleforge o call of juarez o Bioshock ATI va un po' di più della 295.
Però vedi che in linea di massima basta poco per ridimensionare la media mentre le prestazioni reali sono ben diverse.

[kiriranshelo]

ad esempio su crysis, cryostasis, resident evil 5, batman, shift, wolfenstein o lost planet la differenza fra 5870 e gtx 295 non è manco vicina a 7%, anzi quì la 5870 viene letteralmente fulminata.

:mbe:
articolo (http://www.xbitlabs.com/articles/video/display/radeon-hd5870_9.html#sect1)
Crysis Warhead (http://www.xbitlabs.com/images/video/radeon-hd5870/diagrams/cwh.png): 5870 28/40 fps -> GTX295 29/43.3 fps

gli altri risultati non ho tempo di postarli, però la surclassa su risoluzioni discretamente grosse dove la dualgpu fa sentire i suoi effetti! 2560x1600 e 1920x1200 (26 - 24 pollici)!

In ogni caso dire che GT300 farà meglio è una speranza più che una verità concreta.

EDIT: Posso farvi notare che il titolo del thread è "Aspettando le nuove Nvidia GTX" e non "Trovate le differenze fra le vecchie Nvidia e le nuove AMD?"
end OT :)

[pandyno]

@Psyco89

Il comparto tecnico della tua 5870 non è lontanamente paragonabile alla GTX295. :)
Lo stesso lo vedrai con Fermi anche perchè non credo che di fatto raddoppi le prestazioni di una GTX280/285 e come è stato già detto, raddoppiare il numero di unità logiche non implica di fatto il raddoppio delle prestazioni (ci sono altri fattori in gioco) ;)

L'esempio più lampante è stato il passaggio da GeForce 2 Ultra a Geforce 3: la prima mazzulava ben bene la seconda; non appena si è visto qualcosa di più complesso la serie 3 ha preso il volo. :)

Detto questo se vuoi tornare a NVIDIA incrocia le dita e aspetta :D

PS: devo dire di essere orgoglioso del nome scelto da NVIDIA per la sua prossima generazione di processori grafici. :)

[Psyco89]

bè ma scusate come ami in certi portali su stessi bench danno risultati completamente diversi ?

quì dice che in warhead vanno uguali e xbitlbas dice che la differenza è più tosta, a chi devo dare retta io ? o che sono stati fatti girare su 2 mappe differenti, boh.

Comunque xbit ha molti più giochi. Non capisco.

boh, cosa bisogna fare in queste occasioni ? non sono gli unici comunque, anche thg dà risulati diversi oppure guru3d o born3d, o altri ancora anche famosissimi.

[Severnaya]

risolvi prima i problemi che ti affliggono, poi constata sulla tua macchina la bontà dei giochi sotto 5870

[yossarian]

@Psyco89

Il comparto tecnico della tua 5870 non è lontanamente paragonabile alla GTX295. :)
Lo stesso lo vedrai con Fermi anche perchè non credo che di fatto raddoppi le prestazioni di una GTX280/285 e come è stato già detto, raddoppiare il numero di unità logiche non implica di fatto il raddoppio delle prestazioni (ci sono altri fattori in gioco) ;)

L'esempio più lampante è stato il passaggio da GeForce 2 Ultra a Geforce 3: la prima mazzulava ben bene la seconda; non appena si è visto qualcosa di più complesso la serie 3 ha preso il volo. :)

Detto questo se vuoi tornare a NVIDIA incrocia le dita e aspetta :D

PS: devo dire di essere orgoglioso del nome scelto da NVIDIA per la sua prossima generazione di processori grafici. :)

ma infatti, basterebbe utilizzare istruzioni tipo cube map array o far ricorso alle operazioni di tessellation, per non parlare del MSAA con engine deferred (con cui la ATi guadagnano un 20% come minimo), per vedere una 280 arrancare dietro ad una 4850 alle risoluzioni in cui quest'ultima non è frame buffer limited.

[DukeIT]

bè ma scusate come ami in certi portali su stessi bench danno risultati completamente diversi ?

quì dice che in warhead vanno uguali e xbitlbas dice che la differenza è più tosta, a chi devo dare retta io ? o che sono stati fatti girare su 2 mappe differenti, boh.

Comunque xbit ha molti più giochi. Non capisco.

boh, cosa bisogna fare in queste occasioni ? non sono gli unici comunque, anche thg dà risulati diversi oppure guru3d o born3d, o altri ancora anche famosissimi.Da review a review cambiano molte cose. In particolare, con l'uscita di nuovi driver, le prestazioni migliorano, se le recensioni sono fatte all'uscita delle HD58x0, ovvio che daranno risultati peggiori.
Ma alla fine, quando dici che "fai pochi FPS" con la tua HD5870, cosa intendi? Possibile che tu faccia meno di tutte le riviste che l'hanno recensita con risultati positivi?

[Iantikas]

Io parlo di GFlops/s

ATi nella seri 4 ne faceva di più della GTX 285 ma Nvidia penso che abbia sfruttato meglio le proprie funzionalità, no ?


Tessellation o no, io queste grandi performance non le ho viste su ATI, cioè va come una 4870 x2 e meno di una GTX 295, teoricamente quando esce una new generation in automatico tutte le altre schede dovrebbero essergli inferiori e invece questa sembra un po' impacciata no ?

ma io mi kiedo...ma se sta hd5870 nn ha ste grandi performance, se con la gtx275 ke avevi prima stavi così da dio, se la gtx295 è una gpu superiore...

...innanzitutto ma xkè hai deciso di cambiare gpu?

...e in secondo luogo ma xkè quando fuori da ogni logica hai deciso di cambiarla (xkè con la gtx275 stavi da dio) hai preso la hd5870 ke è così scadente e nn la gtx295 ke è tanto superiore?...


...detto questo segnalo ke oggi ho fatto la pazzia...sarò un tipo sculato ma con tutta questa scarsità di rv870 oggi mi è andato di comprare la hd5870, l'ho acquistata e la tengo già dentro al case :sofico: ...il modello della asus con in bundle la key x sbloccare in steam dirt 2 nn appena uscirà (cosa gradità dato ke sicuramente l'avrei acquistato)...


...ho installato gli ultimi whql 9.11 su una installazione pulita di win7 64bit e va tutto da dio...


...la mia precedente gpu oltretutto era proprio una evga GTX295 Backplate...finora ho provato la hd5870 con modern warfare 2, left4dead 2, BF2 moddato con AIX2, Stalker SOC e Stalker Clear Sky...

...tutti i gioki filano lisci come l'olio a 1920x1200...stalker clear sky va anke decisamente meglio rispetto alla multi-gpu nvidia...e nn si nota minimamente micro-lag ke a seconda dei driver e del gioco con la 295 quando + quando - appariva anke con framerate ben oltre la sufficenza...


...la gpu scalda molto meno e sopratutto è immensamente + silenziosa...



...scusate l'ot ma questo è x dire a Psyco89 ke se c'è l'hai veramente questa hd5870 dentro al case nn vedo come ti possa deludere rispetto alla gtx275 ke avevi prima dato ke nn sta deludendo me ke prima avevo una gtx295...


...se hai dei problemi son legati al tuo sistema e a come l'hai configurato...dagli una formattata e reinstlla tutto x bene...vedrai ke il pc andrà a meraviglia...


...ciao

[persa]

hai preso la 5870?!? ci vediamo nel thread ufficiale allora :cool: :D

[Foglia Morta]

4 pagine di intervista a Jen Hsun Huang: http://tech.tbreak.com/2009/11/nvidia-past-present-future-an-interview-with-jen-hsun-huang/1/

[A.L.M.]

...detto questo segnalo ke oggi ho fatto la pazzia...sarò un tipo sculato ma con tutta questa scarsità di rv870 oggi mi è andato di comprare la hd5870, l'ho acquistata e la tengo già dentro al case :sofico: ...il modello della asus con in bundle la key x sbloccare in steam dirt 2 nn appena uscirà (cosa gradità dato ke sicuramente l'avrei acquistato)...


No, non sei tu ad avere culo. :sofico:
E' chi parla di "paper launch" a proposito delle HD5870 a non essere bene informato (volendo usare un eufemismo). Nelle grandi città si trovano tranquillamente nei negozi fisici, se si cerca un po'. ;)
Che ci sia scarsità è vero (ma d'altro canto al lancio capita più di una volta, aggiungiamoci le difficoltà di TSMC e la frittata è fatta), ma paragonare la situazione di AMD a quella di NVidia è ridicolo.

[Foglia Morta]

4 pagine di intervista a Jen Hsun Huang: http://tech.tbreak.com/2009/11/nvidia-past-present-future-an-interview-with-jen-hsun-huang/1/

Dall' intervista:

Domanda:

That prompted me to as Jen-Hsun about the NV30 which is considered as one of the worst releases by NVIDIA and many considered it as a half-baked product.

Risposta:

“We didn’t think it was half-baked. It wasn’t a successful product and let me tell you where it went sideways on us. GeForce FX uses an interface that was different than DX9. We chose CG as our programming interface. ATI had DX9 so the compiler generator from Microsoft could be used for ATI directly but had to be recompiled JIT for our GPU. That recompile process at that time with its JIT compilation was the reason the market hated it. And we did a really bad job at explaining it.

The reviewers felt that we were cheating and so they ran it two ways- the recompiled version and the native version. Our performance was terrible at the native version because the architecture was very different than what was implemented in DX9. That was a part of our history that we didn’t handle extremely well. There are many things we could have done differently before we announced it. I would’ve taken the architecture and taught it to the world on how GeForce FX works. That’s what we did with Firmy- taught everyone how it works because its so different and the performance is going to be so much better and faster.”

[A.L.M.]

Dall' intervista:

Domanda:

That prompted me to as Jen-Hsun about the NV30 which is considered as one of the worst releases by NVIDIA and many considered it as a half-baked product.

Risposta:

“We didn’t think it was half-baked. It wasn’t a successful product and let me tell you where it went sideways on us. GeForce FX uses an interface that was different than DX9. We chose CG as our programming interface. ATI had DX9 so the compiler generator from Microsoft could be used for ATI directly but had to be recompiled JIT for our GPU. That recompile process at that time with its JIT compilation was the reason the market hated it. And we did a really bad job at explaining it.

The reviewers felt that we were cheating and so they ran it two ways- the recompiled version and the native version. Our performance was terrible at the native version because the architecture was very different than what was implemented in DX9. That was a part of our history that we didn’t handle extremely well. There are many things we could have done differently before we announced it. I would’ve taken the architecture and taught it to the world on how GeForce FX works. That’s what we did with Firmy- taught everyone how it works because its so different and the performance is going to be so much better and faster.”

A parte l'ignoranza del tizio che scrive ("Firmy" :doh: ) curioso che JHH abbia paragonato Fermi a NV30... :asd:
Perchè hanno sentito il bisogno di spiegare come funziona prima ancora che uscissero i bench? Damage control forse (quello che lui stesso dice che non fecero ai tempi delle FX)? :stordita:

[pandyno]

curioso che JHH abbia paragonato Fermi a NV30... :asd:
Perchè hanno sentito il bisogno di spiegare come funziona prima ancora che uscissero i bench? Damage control forse (quello che lui stesso dice che non fecero ai tempi delle FX)? :stordita:

Il tutto farebbe pensare ad una effettiva problematica nelle prestazioni di Fermi; sembra quasi che si stia fasciando la testa in anticipo. Ma l'errore più grande della serie FX non furono le prestazioni effettive o i presunti cheat, quanto tutta la mongolfiera montata sopra quel prodotto.

[okorop]

epic fail, volevo non crederci e invece :muro: mi auguravo di prenderne due-tre a gennaio.........vabbe forse una solo per bench magari me la prendo, di sicuro se andrà male come detto va solo sul banchetto, ma nel mio case non entra

[persa]

epic fail, volevo non crederci e invece :muro:

ma come ancora non è neanche uscita!?!? :confused: :asd:

[okorop]

ma come ancora non è neanche uscita!?!? :confused: :asd:

il paragone tra la peggiore architettura di nvida e l'accostamento con fermi parla chiaro, e in piu' l'ha fatto il ceo, hanno accantonato il mercato gaming questo sicuro, punteranno a physx cuda ecc non trovando la necessità di maggior potenza, sinceramente da quell'articolo trovo questa conclusione ed il buon yossarian dalle specifiche aveva visto proprio questo in fermi

[persa]

il paragone tra la peggiore architettura di nvida e l'accostamento con fermi parla chiaro, e in piu' l'ha fatto il ceo, hanno accantonato il mercato gaming questo sicuro

ma come hanno abbandonato il mercato gaming e si preparano ad uscire con una nuova serie di geforce? :confused:

x le prestazioni si è speculato abbastanza, anche troppo. ma alla fine si capirà bene come andrà solo quando sarà uscita :D

ed allora vedremo se sarà un fiasco ( di vino :gluglu: :asd:) o no!! :D

[Severnaya]

ma speriamo di no : |

[okorop]

ma come hanno abbandonato il mercato gaming e si preparano ad uscire con una nuova serie di geforce? :confused:

x le prestazioni si è speculato abbastanza, anche troppo. ma alla fine si capirà bene come andrà solo quando sarà uscita :D

ed allora vedremo se sarà un fiasco ( di vino :gluglu: :asd:) o no!! :D

ho scritto hanno accantonato, probabilmente subordinato l'ambito gaming al professionale è piu' corretto....

[Maury]

Speriamo che non sia proprio un bidone che la concorrenza non fa che bene :rolleyes:

[A.L.M.]

Il tutto farebbe pensare ad una effettiva problematica nelle prestazioni di Fermi; sembra quasi che si stia fasciando la testa in anticipo. Ma l'errore più grande della serie FX non furono le prestazioni effettive o i presunti cheat, quanto tutta la mongolfiera montata sopra quel prodotto.

Se è per questo su Fermi non c'è una mongolfiera, c'è un dirigibile... :asd:

[Andrea deluxe]

bè ma scusate come ami in certi portali su stessi bench danno risultati completamente diversi ?

quì dice che in warhead vanno uguali e xbitlbas dice che la differenza è più tosta, a chi devo dare retta io ? o che sono stati fatti girare su 2 mappe differenti, boh.

Comunque xbit ha molti più giochi. Non capisco.

boh, cosa bisogna fare in queste occasioni ? non sono gli unici comunque, anche thg dà risulati diversi oppure guru3d o born3d, o altri ancora anche famosissimi.

ma ti ei messo il mio pc come avatar.....:stordita:

[pandyno]

Se è per questo su Fermi non c'è una mongolfiera, c'è un dirigibile... :asd:

Sarò io ad essere cambiato, ma non lo vedo :)

[mister-x]

More Fermi Rumors - Not Good

"NVIDIA had a big get-together in Hong Kong last week where a lot of the NVIDIA upper brass was on hand. It is being rumored that the first "Fermi build kits" were supposed to be prepped to go out to AIBs but NVIDIA missed the mark on having its Fermi tech ready to pass off to builders. We also heard the "Gemini" name being batted around as well and this seems to be connected to a dual GPU Fermi card. We still feel as though NVIDIA is aiming for getting Fermi shipping by the last week of February, but still think it will miss this mark. HardOCP's best guess right now is late March with any quantity to speak and we are still giving NVIDIA about even odds of marking March. April 2010 is looking more reasonable to us at this time."

Fonte: http://enthusiast.hardocp.com/news/2009/11/23/more_fermi_rumors_good

[okorop]

Sarò io ad essere cambiato, ma non lo vedo :)

quando si creano aspettative fin da settembre su un prodotto che non esce e che ha problemi rilevanti nella commercializzazione il dirigibile che ruota attorno ad esso lo vedo, purtroppo i dirigibili si sgonfiano facilmente, se fermi non andrà meglio della gtx295 non dico 5970 perchè sinceramente penso sia utopistico il solo pensarlo be gt100 ha fallito

[A.L.M.]

Sarò io ad essere cambiato, ma non lo vedo :)

Ma nooooooooo, JHH è così umile quando parla dei suoi prodotti... :asd:

Al progetto Fermi, dall'inizio fino a quando verranno consegnate le prime schede, hanno preso parte circa 3000-3500 persone e Huang non esita a definire questo progetto come uno dei più grandi "processor-project" nella storia dell'umanità.

http://www.hwupgrade.it/articoli/skvideo/2293/30909_fermi3.jpg

More Fermi Rumors - Not Good

"NVIDIA had a big get-together in Hong Kong last week where a lot of the NVIDIA upper brass was on hand. It is being rumored that the first "Fermi build kits" were supposed to be prepped to go out to AIBs but NVIDIA missed the mark on having its Fermi tech ready to pass off to builders. We also heard the "Gemini" name being batted around as well and this seems to be connected to a dual GPU Fermi card. We still feel as though NVIDIA is aiming for getting Fermi shipping by the last week of February, but still think it will miss this mark. HardOCP's best guess right now is late March with any quantity to speak and we are still giving NVIDIA about even odds of marking March. April 2010 is looking more reasonable to us at this time."

Fonte: http://enthusiast.hardocp.com/news/2009/11/23/more_fermi_rumors_good

Eretici. La commercializzazione avverrà a fine gennaio. (cit.) :O

[pandyno]

X

X

Non lo vedo perchè oramai non credo a nulla di quello che leggo e infatti mi sa che sono cambiato io :D

[okorop]

More Fermi Rumors - Not Good

"NVIDIA had a big get-together in Hong Kong last week where a lot of the NVIDIA upper brass was on hand. It is being rumored that the first "Fermi build kits" were supposed to be prepped to go out to AIBs but NVIDIA missed the mark on having its Fermi tech ready to pass off to builders. We also heard the "Gemini" name being batted around as well and this seems to be connected to a dual GPU Fermi card. We still feel as though NVIDIA is aiming for getting Fermi shipping by the last week of February, but still think it will miss this mark. HardOCP's best guess right now is late March with any quantity to speak and we are still giving NVIDIA about even odds of marking March. April 2010 is looking more reasonable to us at this time."

Fonte: http://enthusiast.hardocp.com/news/2009/11/23/more_fermi_rumors_good
posto che questa news sia vera e dato per scontato che amd sappia le prestazioni reali di fermi di cui la stampa oramai sa tutto
figuriamoci i diretti interessati, credo che nvida sia veramente messa male anche se sto fermi annienterà evergreen perchè amd puo per 2-3 mesi abbassare il prezzo delle proprie soluzioni gpu discrete per poi ritornare avanti con northern ilands già a settembre-ottobre come scritto nella road map, scenario assai grigio per la casa di santa clara, io sto alla porta e mi auguro che esca per fine gennaio tutt'al piu' fine febbraio

una mia considerazione personale, l'uscita di sta nuova scheda è molto fumosa, settembre tutti a essere stupiti della presentazione, fermi sembrava già essere usato in una scheda video funzionante la gtx380, poi foto della scheda dichiarata fake, interviste che dicevano che far gpu è assai difficile poi silenzio fino al 19 quando si mostra uno screen con una foto, puo' essere un immagine a schermo potrebbe essere in dx9 o in dx10, potrebbe essere reindirizzata da qualunque scheda, resta il fatto che abbiamo in mano solo quello screen, poi problemi con la revision a2 e c'è la necessità dell'a3, poi problemi con le frequenze e non si sa se l'a3 è già in produzione o meno, la vedo fumosa che dire credo che sia il sostantivo migliore da dover usare

le indiscrezioni del fud senza senso non le commento manco perhè quella del 19 novembre mi è sembrata assai sparata: esce la 5970 che va il 70% su per giu' in piu' della gtx285 e miracolosamente dicono: la gtx380 andrà il 70% in piu' della gtx285.......

[DVD2005]

Quindi è un po' guappo? :asd:

Io l'ho detto due mesi fa, sarò mica io la fonte di HardOCP? :asd:

non è la prima volta che accade, tu non ce la conti giusta !! :asd:

[okorop]

Quindi è un po' guappo? :asd:

Io l'ho detto due mesi fa, sarò mica io la fonte di HardOCP? :asd:

vabbe tu lavori in nvida è risaputo, la prossima news si chiamerà intervista a Ratatosk project manager nvida :asd:

[Foglia Morta]

4 pagine relative all' architettura di Fermi , ci sono anche le frequenze ( che comunque sono una stima di ciò che pensano di poter ottenere ): http://techreport.com/articles.x/17815

[A.L.M.]

4 pagine relative all' architettura di Fermi , ci sono anche le frequenze ( che comunque sono una stima di ciò che pensano di poter ottenere ): http://techreport.com/articles.x/17815

Strano che TechReport, che normalmente è un sito abbastanza tecnico, (il Rys che scrive lì è lo stesso che scrive su B3D) si lasci andare ad una previsione che mi pare difficile che venga confermata dalla realtà ("at least twice as fast as GTX285")...
Dubito fortemente infatti che vada un 30% più veloce di Hemlock, anche alla luce del fatto che anche loro confermano che:

The other sub block is a sixteen-wide, single-precision vector running computation for the other half of a thread warp. It can run a single-precision FMA per clock, or MUL or ADD. The new FMA ability of the sub blocks is important. Fusing the two ops into a single compute stage increases numerical precision over the old MADD hardware in prior D3D10-class Nvidia hardware. In graphics mode, that poses problems, since to run at the same numerical precision as GT200, Fermi chips like GF100 will be half their peak rate for MADD, because they run the old MUL and ADD in two clocks rather than one. Automatically promoting those to FMA is what the graphics driver will do, although the programmer can opt out of that if they find computational divergence that causes problems, compared to the same code on other hardware.

Strano pure che continui a dire che potrebbe non esserci un tessellator dedicato... Boh? :stordita:

[devAngnew]

The other sub block is a sixteen-wide, single-precision vector running computation for the other half of a thread warp. It can run a single-precision FMA per clock, or MUL or ADD. The new FMA ability of the sub blocks is important. Fusing the two ops into a single compute stage increases numerical precision over the old MADD hardware in prior D3D10-class Nvidia hardware. In graphics mode, that poses problems, since to run at the same numerical precision as GT200, Fermi chips like GF100 will be half their peak rate for MADD, because they run the old MUL and ADD in two clocks rather than one. Automatically promoting those to FMA is what the graphics driver will do, although the programmer can opt out of that if they find computational divergence that causes problems, compared to the same code on other hardware.


Inoltre dice che poichè l'istruzione MADD avrebbe dei limiti su Fermi come già detto da Hardware France il driver sostituirà a compiler time dello shader tali istruzioni con delle FMA. come ipotizzato.

;)

[Jackaos]

Inoltre dice che poichè l'istruzione MADD avrebbe dei limiti su Fermi come già detto da Hardware France il driver sostituirà a compiler time dello shader tali istruzioni con delle FMA. come ipotizzato.

;)

Non ne capisco una cippa, questo vorrebbe forse dire che sarebbe un'architettura che più delle passate per esprimere tutto il suo potenziale in ambito gaming dipenderà maggiormente dai driver? Se è questo che accadrà, sempre che io abbia capito il discorso, potrebbero le prestazioni di fermi in ambito videoludico essere meno stabili, meno coerenti, più altalenanti proprio perchè basate maggiormente ( rispetto al passato) sul soft che sull'hard? Ripeto, non so nemmeno se ho fatto undiscorso sensato, cioè, non so nulla di driver ecc, cerco di capire..

[ippo.g]

epic fail, volevo non crederci e invece :muro: mi auguravo di prenderne due-tre a gennaio.........vabbe forse una solo per bench magari me la prendo, di sicuro se andrà male come detto va solo sul banchetto, ma nel mio case non entra

prendi un case più grande :O

[Kharonte85]

4 pagine relative all' architettura di Fermi , ci sono anche le frequenze ( che comunque sono una stima di ciò che pensano di poter ottenere ): http://techreport.com/articles.x/17815

Praticamente in supersintesi secondo loro andrà fortissimo: circa il doppio di GT200 e sicuramente sarà più veloce della HD 5870.

Sostengono anche che il tesselatore sarà emulato via software.

Sembrano abbastanza convinti :fagiano:

[A.L.M.]

Inoltre dice che poichè l'istruzione MADD avrebbe dei limiti su Fermi come già detto da Hardware France il driver sostituirà a compiler time dello shader tali istruzioni con delle FMA. come ipotizzato.

;)

Il tutto credo che però abbia un costo in termini computazionali, no?

Non ne capisco una cippa, questo vorrebbe forse dire che sarebbe un'architettura che più delle passate per esprimere tutto il suo potenziale in ambito gaming dipenderà maggiormente dai driver? Se è questo che accadrà, sempre che io abbia capito il discorso, potrebbero le prestazioni di fermi in ambito videoludico essere meno stabili, meno coerenti, più altalenanti proprio perchè basate maggiormente ( rispetto al passato) sul soft che sull'hard? Ripeto, non so nemmeno se ho fatto undiscorso sensato, cioè, non so nulla di driver ecc, cerco di capire..

Probabile. Da questo punto di vista l'architettura NVidia perderà parte dei suoi vantaggi rispetto a quella ATi, divenendo più dipendente da ottimizzazioni nel codice e nei drivers, e meno "auto-bilanciata" e flessibile.

[Foglia Morta]

Strano che TechReport, che normalmente è un sito abbastanza tecnico, (il Rys che scrive lì è lo stesso che scrive su B3D) si lasci andare ad una previsione che mi pare difficile che venga confermata dalla realtà ("at least twice as fast as GTX285")...
Dubito fortemente infatti che vada un 30% più veloce di Hemlock, anche alla luce del fatto che anche loro confermano che:

IMO Hemlock va un po di più di quel che pensi : http://www.hardware.fr/articles/777-17/dossier-amd-radeon-hd-5970.html

[okorop]

IMO Hemlock va un po di più di quel che pensi : http://www.hardware.fr/articles/777-17/dossier-amd-radeon-hd-5970.html

basandomi su questi benchmark a 1920x1200
http://www.hardware.fr/medias/photos_news/00/27/IMG0027435.gif

fermi stando alla stima fatta dall'articolo di fermi=2 volte piu' prestante della gtx285 andrebbe un 10 fps in piu' di hemlock con aa 4x e 4 fps in piu con aa8x

invece andrebbe meno a 2560x1600

son stime ovviamente, vedremo se sarà vero, io dalla recensione di questo sito ho stimato le prestazioni di hemlock del 70% superiori rispetto alla gtx285, poi dipende dallo scenario e dai filtri usati dal grafico sopra va un 66% in piu' con aa4x e un 56% in piu' con aa 8x

[A.L.M.]

IMO Hemlock va un po di più di quel che pensi : http://www.hardware.fr/articles/777-17/dossier-amd-radeon-hd-5970.html

Beh, a 1920x1200 AA4x non va esattamente il doppio di una GTX285, ma circa l'86% in più, anche secondo hw.fr. :)
Naturalmente molto dipende dai giochi scelti, visto che su alcuni R800 letteralmente si mangia anche la GTX295. Su altri siti (computerbase) con quei settaggi però siamo a circa il 60-70% in più.
Comunque a me sembrerebbe già tanto se Fermi andasse uguale ad Hemlock, ma non la vedo come una cosa così facilmente raggiungibile...
Poi magari mi sbaglio, eh? :)

[Bastoner]

Dice che hanno inventato lo SLi e hanno inventato PhysX.

Che pezzente...




Che vergogna, dovrebbe nascondersi per quello che ha affermato.

[Foglia Morta]

Beh, a 1920x1200 AA4x non va esattamente il doppio di una GTX285, ma circa l'86% in più, anche secondo hw.fr. :)
Naturalmente molto dipende dai giochi scelti, visto che su alcuni R800 letteralmente si mangia anche la GTX295. Su altri siti (computerbase) con quei settaggi però siamo a circa il 60-70% in più.
Comunque a me sembrerebbe già tanto se Fermi andasse uguale ad Hemlock, ma non la vedo come una cosa così facilmente raggiungibile...
Poi magari mi sbaglio, eh? :)

A 1920 la situazione è più leggera che a 2560 , forse la scheda è un po troppo potente per rendere al massimo a quella risoluzione ? Io guardavo appunto le situazioni più pesanti. Inoltre Computerbase inserisce Cryostasis con Physx attivato, ovvio che non ha senso quel test con una radeon :)

son stime ovviamente, vedremo se sarà vero, io dalla recensione di questo sito ho stimato le prestazioni di hemlock del 70% superiori rispetto alla gtx285, poi dipende dallo scenario e dai filtri usati dal grafico sopra va un 66% in piu' con aa4x e un 56% in piu' con aa 8x

Non si calcolano così le percentuali... :D

[halduemilauno]

Praticamente in supersintesi secondo loro andrà fortissimo: circa il doppio di GT200 e sicuramente sarà più veloce della HD 5870.

Sostengono anche che il tesselatore sarà emulato via software.

Sembrano abbastanza convinti :fagiano:

e anche loro parlano di gennaio. vedremo. sempre in attesa di tutti i riscontri del caso.
;)

[Psyco89]

ragazzi ma come possibile che da 3 miliardi di transistors non esca nulla di buono ?
avrà dei prezzi di produzione mostruosi.

512 stream a 1.7Ghz
650Mhz di clock
48 ROPS
384bit con GDDR5 :eek:


Ma scusate cosa è più importante il single precision o il double precision nei giochi ?

[leoneazzurro]

Per il momento il single precision. Comunque le previsioni di Rys non è detto che siano legate all'ambito grafico: anche in RV870 si è avuto un raddoppio di risorse in quasi tutti gli ambiti rispetto ad HD4890 ma a parte casi sporadici non c'è stato un raddoppio dei frame. Le limitazioni possono essere parecchie: limiti di CPU, limiti del setup engine, limiti di banda e di fill rate. Ad esempio, se è vero come da ipotesi comune che RV870 sia molto limitato dalla banda, se GF100 avrà come stimato una banda passante del 30% circa superiore, non è che possa arrivare a risultati del 100% superiori (che sarebbero necessari per "passare" hemlock) a meno di una rivoluzione nella gestione della compressione dei dati. Senza contare il fattore clock: Rys ipotizza un clock di 1700 MHz nella sua analisi, ma la prima versione Tesla di Fermi, attesa per Maggio, sembra per parola ufficiale di Nvidia avere clock decisamente inferiori. Anche ipotizzando una maggiorazione del clock del 15% per le schede in versione geforce siamo comunque sotto i 1500 MHz di clock (il 15% in meno di quanto stimato da Rys).
Insomma, è probabile che Nvidia riuscirà a rendere fermi più veloce della 5870mentre sono parecchio scettico sul fatto che riesca a renderla più veloce di una 5970, e poi si tratterà di stabilire quanto più veloce di RV870 possa essere (personalmente mi aspetto che sia in media tra il 10% ed il 30% più veloce di una 5870, con le consuete forti variazioni tra un'applicazione e l'altra). Il problema è che se c'è bisogno di una revisione A3, per la commercializzazione non vedo lumi prima di Marzo. Poi è possibile che in Gennaio appaiano i primi bench della revisione A2 su sample selezionati, IMHO.

[Psyco89]

ma scusa nel single precision ATI ha un netto vantaggio, Nvidia invece nel doblu precision.


Ma scusa per eliminare in parte il problema banda basta far girare queste vga a risoluzioni tipo 1280 x 1024 e 1680 x 1050, perchè continuare a guardare il FULL HD ?

[A.L.M.]

A 1920 la situazione è più leggera che a 2560 , forse la scheda è un po troppo potente per rendere al massimo a quella risoluzione ? Io guardavo appunto le situazioni più pesanti. Inoltre Computerbase inserisce Cryostasis con Physx attivato, ovvio che non ha senso quel test con una radeon :)

Beh, considera che la scheda è una bestia, e che in certi scenari è cpu limited anche a 1680x1050 AA4x con un Core i7 975... :asd:
Boh, allora in effetti siamo lì. Comunque rimane il fatto che Fermi secondo me faticherà molto ad andare il 100% in più e oltre rispetto ad una GTX285 anche perchè già con clocks relativamente bassi (1400-1500MHz) degli shaders consuma 225W, se gli alzano i clocks consumerà più di una dual.

Per il momento il single precision. Comunque le previsioni di Rys non è detto che siano legate all'ambito grafico: anche in RV870 si è avuto un raddoppio di risorse in quasi tutti gli ambiti rispetto ad HD4890 ma a parte casi sporadici non c'è stato un raddoppio dei frame. Le limitazioni possono essere parecchie: limiti di CPU, limiti del setup engine, limiti di banda e di fill rate. Ad esempio, se è vero come da ipotesi comune che RV870 sia molto limitato dalla banda, se GF100 avrà come stimato una banda passante del 30% circa superiore, non è che possa arrivare a risultati del 100% superiori (che sarebbero necessari per "passare" hemlock) a meno di una rivoluzione nella gestione della compressione dei dati. Senza contare il fattore clock: Rys ipotizza un clock di 1700 MHz nella sua analisi, ma la prima versione Tesla di Fermi, attesa per Maggio, sembra per parola ufficiale di Nvidia avere clock decisamente inferiori. Anche ipotizzando una maggiorazione del clock del 15% per le schede in versione geforce siamo comunque sotto i 1500 MHz di clock (il 15% in meno di quanto stimato da Rys).
Insomma, è probabile che Nvidia riuscirà a rendere fermi più veloce della 5870mentre sono parecchio scettico sul fatto che riesca a renderla più veloce di una 5970, e poi si tratterà di stabilire quanto più veloce di RV870 possa essere (personalmente mi aspetto che sia in media tra il 10% ed il 30% più veloce di una 5870, con le consuete forti variazioni tra un'applicazione e l'altra). Il problema è che se c'è bisogno di una revisione A3, per la commercializzazione non vedo lumi prima di Marzo. Poi è possibile che in Gennaio appaiano i primi bench della revisione A2 su sample selezionati, IMHO.

Straquoto. :)

[Psyco89]

scusate ma come mai ATI ha voluto fare un 1600 stream super pompato e il 30% in più di banda appena ? non è un errore ?

[Gabriyzf]

Praticamente in supersintesi secondo loro andrà fortissimo: circa il doppio di GT200 e sicuramente sarà più veloce della HD 5870.

Sostengono anche che il tesselatore sarà emulato via software.

Sembrano abbastanza convinti :fagiano:

è fattibile una cosa del genere?
sarebbe ancora dx11 compliant?

[devAngnew]

Non ne capisco una cippa, questo vorrebbe forse dire che sarebbe un'architettura che più delle passate per esprimere tutto il suo potenziale in ambito gaming dipenderà maggiormente dai driver? Se è questo che accadrà, sempre che io abbia capito il discorso, potrebbero le prestazioni di fermi in ambito videoludico essere meno stabili, meno coerenti, più altalenanti proprio perchè basate maggiormente ( rispetto al passato) sul soft che sull'hard? Ripeto, non so nemmeno se ho fatto undiscorso sensato, cioè, non so nulla di driver ecc, cerco di capire..

Il tutto credo che però abbia un costo in termini computazionali, no?
.........

Se ho interpretato bene ciò che volete dire....
Bhe il tutto è fatto all'atto del caricamento dello shader in memoria diciamo durante il caricamento del livello di un ipotetico gioco quindi il driver sostituirebbe le chiamate MADD con delle FMA e poi compilerebbe il tutto ne consegue che Fermi dovrebbe lavorare alla massima velocità possibile.

[Psyco89]

Ma scusate l'ignuranza eh....ma con tessellation via Hardware quanto si guadagna in dx11 a pari scheda con tessellation disabilitato ?

[Psyco89]

non capisco ma i modelli poligonari che troviamo in ambienti 3D non sono uguali per tutti ?

[Psyco89]

magari non mi sono spiegato io.

io intendevo la 2° immagine in DX11 ok ? quei poligoni non sono ugauli per tutti ?
ovvero se un oggetto ha 1000 poligoni, non è che ATI ne renderizza con 10000 e Nvidia con 100, tutti renderingzeranno 1000 poligoni, ma allora se il tessellation non darà vantaggi solo prestazionali come fa a darli in qualità poligonare, perchè da quanto ne so il numero di poligoni che compone un oggetto lo fa la software house.

[Andrea deluxe]

magari non mi sono spiegato io.

io intendevo la 2° immagine in DX11 ok ? quei poligoni non sono ugauli per tutti ?
ovvero se un oggetto ha 1000 poligoni, non è che ATI ne renderizza con 10000 e Nvidia con 100, tutti renderingzeranno 1000 poligoni, ma allora se il tessellation non darà vantaggi solo prestazionali come fa a darli in qualità poligonare, perchè da quanto ne so il numero di poligoni che compone un oggetto lo fa la software house.

il motore grafico scala in dx9 dx10 e dx11

in base alla sk video montata calcola effetti e applica o meno il tassellatore.


il tassellatore e' una funzione automatica che genera poligoni non creati dalla software house.

ma se il motore non supporta il tassellatore non si genera niente in automatico, anche con una sk dx11

[Psyco89]

si ma fermi è in DX11 e la mia ATI pure.

mettiamo che il motore sia in DX11 e supporti il tessellatore.

se avvio una mappa con fermi e avvio la stessa mappa con ATI il numero di poligoni non è uguale per tutti ?
quindi qualitativamente che vantaggi avrò ?

[Andrea deluxe]

si ma fermi è in DX11 e la mia ATI pure.

mettiamo che il motore sia in DX11 e supporti il tessellatore.

se avvio una mappa con fermi e avvio la stessa mappa con ATI il numero di poligoni non è uguale per tutti ?
quindi qualitativamente che vantaggi avrò ?

e' uguale per tutti!

ati lo calcola in una maniera e nvidia in un altra, ma il risulatato e' il medesimo.

ati ha una parte del chip che calcola la tassellazione, mentre nvidia ha delle funzioni fisse sugli shader che processano la tassellazione con maggiore priorita' rispetto al resto.


bisogna solo capire l'impatto prestazionale dei due approcci.

[Psyco89]

ecco e quindi sto vantaggio qualitativo da dove proviene ? se il numero di poligoni sono uguali a me viene in mente solo un vantaggio prestazionale ma qualitativo proprio 0.

[Andrea deluxe]

ecco e quindi sto vantaggio qualitativo da dove proviene ?

la differenza da capire e' solo nelle performance.

c'e' da capire in che percentuale calano le performance su ati e su nvidia.

chi cala di meno avra' fatto il lavoro migliore.

[yossarian]

Inoltre dice che poichè l'istruzione MADD avrebbe dei limiti su Fermi come già detto da Hardware France il driver sostituirà a compiler time dello shader tali istruzioni con delle FMA. come ipotizzato.

;)

The other sub block is a sixteen-wide, single-precision vector running computation for the other half of a thread warp. It can run a single-precision FMA per clock, or MUL or ADD. The new FMA ability of the sub blocks is important. Fusing the two ops into a single compute stage increases numerical precision over the old MADD hardware in prior D3D10-class Nvidia hardware. In graphics mode, that poses problems, since to run at the same numerical precision as GT200, Fermi chips like GF100 will be half their peak rate for MADD, because they run the old MUL and ADD in two clocks rather than one. Automatically promoting those to FMA is what the graphics driver will do, although the programmer can opt out of that if they find computational divergence that causes problems, compared to the same code on other hardware.

non è così semplice. Intanto su una singola istruzione si ha un passaggio in più, ovvero quello di shader replacement che fa perdere cicli di clock rispetto al sem,plice fetch, decode, execute. In secondo luogo, all'interno di una serie di centinaia di istruzioni la propagazione degli errori può dar luogo a divergenze, rispetto alla MADD tradizionale, che può portare ad artefatti; motivo per cui, si deve vedere quando sarà possible effettuare l'operazione di replacement senza problemi e, quando non sarà possibile, le prestazioni crolleranno inevitabilmente. Terzo, i driver dovranno contenere sia operazioni di replacement (sempre quando possibile) per fermi e comuni MADD per tutti i chip DX10 (GT200 e G80 non eseguono FMA a fp32).

[Psyco89]

la differenza da capire e' solo nelle performance.

c'e' da capire in che percentuale calano le performance su ati e su nvidia.

chi cala di meno avra' fatto il lavoro migliore.

ma scusate e allora perchè mi avete detto che è solo una fatto di qualità dell'immagine ? :(

allora è coem ho detto io, è solo prestazione pura. Ma quindi la mia con il tessellation hardware dovrebbe esere migliore rispetto a quello emulato via software ?

[pandyno]

magari non mi sono spiegato io.

io intendevo la 2° immagine in DX11 ok ? quei poligoni non sono ugauli per tutti ?
ovvero se un oggetto ha 1000 poligoni, non è che ATI ne renderizza con 10000 e Nvidia con 100, tutti renderingzeranno 1000 poligoni, ma allora se il tessellation non darà vantaggi solo prestazionali come fa a darli in qualità poligonare, perchè da quanto ne so il numero di poligoni che compone un oggetto lo fa la software house.

Il tessellator serve per dare dettaglio dove non c'è.
La tecnica di tessellation non serve per aumentare le prestazioni, ma il dettaglio. La tessellation ammazza comunque le prestazioni: la 5970 fa girare Unigine Heaven a 68fps a 1680.

Se un modello 3D ha 1000 poligoni, la tessellation lo porta a 400.000 poligoni, aumentando enormemente il dettaglio; è una tecnica adibita a questo, non sono i programmatori che inseriscono i 399.000 poligoni mancanti :D

[Andrea deluxe]

ma scusate e allora perchè mi avete detto che è solo una fatto di qualità dell'immagine ? :(

allora è coem ho detto io, è solo prestazione pura. Ma quindi la mia con il tessellation hardware dovrebbe esere migliore rispetto a quello emulato via software ?

uguale, ma quello software e' piu' lento.


stupido esempio:

scena 1 tass ON (hardware)= 100fps

scena 1 tass ON (software)= 30fps

[Psyco89]

Il tessellator serve per dare dettaglio dove non c'è.
La tecnica di tessellation non serve per aumentare le prestazioni, ma il dettaglio. La tessellation ammazza comunque le prestazioni: la 5970 fa girare Unigine Heaven a 68fps a 1680.

Se un modello 3D ha 1000 poligoni, la tessellation lo porta a 400.000 poligoni, aumentando enormemente il dettaglio; è una tecnica adibita a questo, non sono i programmatori che inseriscono i 399.000 poligoni mancanti :D

continuo a non capire.
allora DX11 = tessellatore = miglior qualità ok ?


Io sto chiedendo : il tessellation hardware di ATI darà significativi vantaggi prestazioni ( FPS _ fotogrammi al scondo - prestazioni pure velocistiche ) rispetto a quello emulato di Nvidia oppure robetta insignificante ?

[Andrea deluxe]

continuo a non capire.
allora DX11 = tessellatore = miglior qualità ok ?


Io sto chiedendo : il tessellation hardware di ATI darà significativi vantaggi prestazioni ( FPS _ fotogrammi al scondo - prestazioni pure velocistiche ) rispetto a quello emulato di Nvidia oppure robetta insignificante ?

si il tassellatore hardware e' piu' veloce.

ma la qualita' e' la stessa.


(comunque quello nvidia non e' emulato)

[sickofitall]

continuo a non capire.
allora DX11 = tessellatore = miglior qualità ok ?


Io sto chiedendo : il tessellation hardware di ATI darà significativi vantaggi prestazioni rispetto a quello emulato di Nvidia oppure robetta insignificante ?

l'unica differenza sono negli fps, la qualità sarà la medesima, ti è stato spiegato anche poco fa...

Se nvidia e/o ati in una scena 3d con tessellatore genera più fps rispetto all'avversario, vorrà dire che la propria unità tessellation lavora meglio ;)

non credo ci sia altro da chiarire su questo ;)

[Severnaya]

per sapere quello che chiedi tu ci vuole Nostradamus :asd:

[pandyno]

si ma fermi è in DX11 e la mia ATI pure.

mettiamo che il motore sia in DX11 e supporti il tessellatore.

se avvio una mappa con fermi e avvio la stessa mappa con ATI il numero di poligoni non è uguale per tutti ?
quindi qualitativamente che vantaggi avrò ?

Lo scenario futuro è alquanto confuso. Se il Tessellator di Fermi è emulato non è detto che venga utilizzato per tutti i titoli e non è detto che non possano ricorrere a qualche stratagemma, come del resto non è detto che sia da subito utilizzato in maniera massiccia. Spero che non sia emulato e che sia solo una voce.

[yossarian]

continuo a non capire.
allora DX11 = tessellatore = miglior qualità ok ?


Io sto chiedendo : il tessellation hardware di ATI darà significativi vantaggi prestazioni ( FPS _ fotogrammi al scondo - prestazioni pure velocistiche ) rispetto a quello emulato di Nvidia oppure robetta insignificante ?

a parità di nuovi vertici generati, un'implementazione via HW dà significativi vantaggi in termini prestazionali

[Psyco89]

l'unica differenza sono negli fps, la qualità sarà la medesima, ti è stato spiegato anche poco fa...

Se nvidia e/o ati in una scena 3d con tessellatore genera più fps rispetto all'avversario, vorrà dire che la propria unità tessellation lavora meglio ;)

non credo ci sia altro da chiarire su questo ;)

Oh finalmente qualcuno che ha capito la mia domanda.
tutti a aprlare di sta gran qualità che poi alla fine sappiamo tutti che sarà come da DX9 a Dx10 ovvero qualche effettuccio qualche fisica un po' emglio qualche modello poligonale migliore e basta.

Io volevo sapere il numero di FPS.

Ma scusate come sarebbe ? Nvidia non lo ha emulato ?

[Psyco89]

a parità di nuovi vertici generati, un'implementazione via HW dà significativi vantaggi in termini prestazionali

oh finalmente !

[Andrea deluxe]

Oh finalmente qualcuno che ha capito la mia domanda.
tutti a aprlare di sta gran qualità che poi alla fine sappiamo tutti che sarà come da DX9 a Dx10 ovvero qualche effettuccio qualche fisica un po' emglio qualche modello poligonale migliore e basta.

Io volevo sapere il numero di FPS.

Ma scusate come sarebbe ? Nvidia non lo ha emulato ?

in fermi la tassellazione viene eseguita nella pipeline degli shader in fixed function.

[pandyno]

continuo a non capire.
allora DX11 = tessellatore = miglior qualità ok ?


Io sto chiedendo : il tessellation hardware di ATI darà significativi vantaggi prestazioni ( FPS _ fotogrammi al scondo - prestazioni pure velocistiche ) rispetto a quello emulato di Nvidia oppure robetta insignificante ?

Certo che le darà, come si è visto l'emulazione ibrida e non non porta da nessuna parte. Evidentemente se così dovesse essere, pensano che tale tecnica non sarà utilizzata.

[Psyco89]

in fermi la tassellazione viene eseguita nella pipeline degli shader in fixed function.

ah ok.

[Andrea deluxe]

ah ok.

e' hardware, solo che l'approccio e' leggermente diverso da quello ati.

[Foglia Morta]

e' hardware, solo che l'approccio e' leggermente diverso da quello ati.

Mi pare che tu faccia riferimento a quella slide di nVidia. Non si riferiva a Fermi

[Kharonte85]

Per il momento il single precision. Comunque le previsioni di Rys non è detto che siano legate all'ambito grafico: anche in RV870 si è avuto un raddoppio di risorse in quasi tutti gli ambiti rispetto ad HD4890 ma a parte casi sporadici non c'è stato un raddoppio dei frame. Le limitazioni possono essere parecchie: limiti di CPU, limiti del setup engine, limiti di banda e di fill rate. Ad esempio, se è vero come da ipotesi comune che RV870 sia molto limitato dalla banda, se GF100 avrà come stimato una banda passante del 30% circa superiore, non è che possa arrivare a risultati del 100% superiori (che sarebbero necessari per "passare" hemlock) a meno di una rivoluzione nella gestione della compressione dei dati. Senza contare il fattore clock: Rys ipotizza un clock di 1700 MHz nella sua analisi, ma la prima versione Tesla di Fermi, attesa per Maggio, sembra per parola ufficiale di Nvidia avere clock decisamente inferiori. Anche ipotizzando una maggiorazione del clock del 15% per le schede in versione geforce siamo comunque sotto i 1500 MHz di clock (il 15% in meno di quanto stimato da Rys).
Insomma, è probabile che Nvidia riuscirà a rendere fermi più veloce della 5870mentre sono parecchio scettico sul fatto che riesca a renderla più veloce di una 5970, e poi si tratterà di stabilire quanto più veloce di RV870 possa essere (personalmente mi aspetto che sia in media tra il 10% ed il 30% più veloce di una 5870, con le consuete forti variazioni tra un'applicazione e l'altra). Il problema è che se c'è bisogno di una revisione A3, per la commercializzazione non vedo lumi prima di Marzo. Poi è possibile che in Gennaio appaiano i primi bench della revisione A2 su sample selezionati, IMHO.
In realtà lui fa riferimento proprio a quelle in quasi tutto l'articolo...per il resto credo che lo scenario che disegni sia molto credibile, dubito fortemente anche io che riesca a superare hemlock.

Sul fatto del tesselatore mi rende perplesso che siano così sicuri in quell'articolo...sbaglio o il tesselatore via hardware è espressamente richiesto come requisito delle dx11? In questo caso come farebbe nvidia a dichiararsi dx11 se non ce l'ha? :what:

[Psyco89]

e' hardware, solo che l'approccio e' leggermente diverso da quello ati.

e allora perchè state tutti a parlare di questa cosa ? se la tecnica risulasse un po' inferiore ad ATi al massimo quelli si fanno ottimizzare il gioco o aumentano el frequenze della scheda.

[devAngnew]

non è così semplice. Intanto su una singola istruzione si ha un passaggio in più, ovvero quello di shader replacement che fa perdere cicli di clock rispetto al sem,plice fetch, decode, execute. In secondo luogo, all'interno di una serie di centinaia di istruzioni la propagazione degli errori può dar luogo a divergenze, rispetto alla MADD tradizionale, che può portare ad artefatti; motivo per cui, si deve vedere quando sarà possible effettuare l'operazione di replacement senza problemi e, quando non sarà possibile, le prestazioni crolleranno inevitabilmente. Terzo, i driver dovranno contenere sia operazioni di replacement (sempre quando possibile) per fermi e comuni MADD per tutti i chip DX10 (GT200 e G80 non eseguono FMA a fp32).

Ovviamente, ci deve essere questo passaggio di replacemente da MADD a FMA ma il tutto avverrà in modalità JIT cioè carico lo shader e sostituisco le istruzioni e successivamente il codice viene compilato quindi questo passaggio avviene una sola volta subito dopo aver caricato lo shader.
Cioè non avviene un interpretazione passo per passo non sò se mi sono spiegato.
;)

[Gabriyzf]

la domanda è una sola: il tassellatore hw è un requisito necessario per le dx11?

[Severnaya]

si

[Psyco89]

e allora lo deve avere anche Nvidia mi sa.

[Andrea deluxe]

Mi pare che tu faccia riferimento a quella slide di nVidia. Non si riferiva a Fermi

si, e spero che quella slide non sia fake....:D

[Andrea deluxe]

e allora perchè state tutti a parlare di questa cosa ? .

bo! :O

[Psyco89]

ma se è requisito necessario lo avrà per forza altrimenti ordinerà alle case di videogiochi di non usare mai il tessellation.

[pandyno]

:asd: sei troppo forte

[Psyco89]

:asd: sei troppo forte

chi Nvidia o ATI ? non ho capito

[yossarian]

Ovviamente, ci deve essere questo passaggio di replacemente da MADD a FMA ma il tutto avverrà in modalità JIT cioè carico lo shader e sostituisco le istruzioni e successivamente il codice viene compilato quindi questo passaggio avviene una sola volta subito dopo aver caricato lo shader.
Cioè non avviene un interpretazione passo per passo non sò se mi sono spiegato.
;)

deve avvenire per ogni madd di ogni shader che viene caricato e non una tantum. Ovvero, ogni volta che viene "letta" una madd questa deve essere riconvertita e deve essere eseguita una fma: sempre se possibile. Oppure, se preferisci, carico uno shader con n madd e faccio la sostituzione di tutte prima di avviare l'esecuzione. Il tutto avviene on chip e non a livello di compilazione degli shader. L'unica cosa che il driver può fare è dare un'istruzione del tipo:"dove trovi una madd sostituiscila con una fma". Il driver non riscrive il codice elaborato dal programmatore ma può contenere delle istruzioni in sostituzione di altre. Questo significa che l'hw deve prima trovare le istruzioni da sostituire e poi procedere alla sostituzione.
Inoltre, mi pare che tu stia trascurando l'eventualità che l'operazione sia, comunque, resa impossibile dalla propagazione degli errori dovuti al mancato troncamento del risultato della mul. Al momento non mi pare che qualcuno abbia preso in considerazione l'ipotesi di sostituire madd con fma ma di eseguire madd su pipeline di tipo mfma, il che è ben diverso.
Questo potrebbe essere uno dei motivi del ritardo di fermi

[Kharonte85]

ma se è requisito necessario lo avrà per forza altrimenti ordinerà alle case di videogiochi di non usare mai il tessellation.
non ci sarebbe nemmeno bisogno, sapendo di avere una così ristretta utenza nessuno si sbatterebbe per programmare giochi con la tecnica del tesselatore...e ovviamente anche questa diverrà una feauteres inutilizzata.

[halduemilauno]

In realtà lui fa riferimento proprio a quelle in quasi tutto l'articolo...per il resto credo che lo scenario che disegni sia molto credibile, dubito fortemente anche io che riesca a superare hemlock.

Sul fatto del tesselatore mi rende perplesso che siano così sicuri in quell'articolo...sbaglio o il tesselatore via hardware è espressamente richiesto come requisito delle dx11? In questo caso come farebbe nvidia a dichiararsi dx11 se non ce l'ha? :what:

mi pare di aver letto che basti che la funzione del tessellatore sia supportata in che modo non lo specifica basti che lo faccia. cmq aggiungo che nell'articolo si dice che il prossimo mese Nvidia parlerà delle nuove schede gf100.
;)

[Psyco89]

e allora se è così o non lo faranno oppure lo faranno ottimizzato per la tecnica di Nvidia

[Kharonte85]

mi pare di aver letto che basti che la funzione del tessellatore sia supportata in che modo non lo specifica basti che lo faccia.
In tal caso non è improbabile l'ipotesi dell'emulazione...


cmq aggiungo che nell'articolo si dice che il prossimo mese Nvidia parlerà delle nuove schede gf100.
;)
Speriamo.

[pandyno]

chi Nvidia o ATI ? non ho capito

Tu :asd:

[halduemilauno]

In tal caso non è improbabile l'ipotesi dell'emulazione...


Speriamo.

Nvidia a dicembre sarà impegnata in tre eventi speriamo in uno di quelli.
;)

[A.L.M.]

non ci sarebbe nemmeno bisogno, sapendo di avere una così ristretta utenza nessuno si sbatterebbe per programmare giochi con la tecnica del tesselatore...e ovviamente anche questa diverrà una feauteres inutilizzata.

C'è anche una terza via... :asd:
Ci sono già in pipeline diversi giochi che sfrutteranno almeno in parte la tessellation (che ricordo è una feature delle DX11, non certo uno sghiribizzo di ATI)... I first movers comprano Fermi (a marzo), si accorgono che le prestazioni con la tessellation fanno pena, nessuno più compra dette schede e Fermi fa la fine di NV30, EOL dopo pochi mesi.
E non la vedo come un'opzione così remota.... ;)
Non è che all'epoca della FX nessuno usò più giochi DX9 o li programmava come voleva JHH solo perchè NV30 faceva pena in quei frangenti. Così come non è che perchè NVidia dice che PhysX è bello diventerà lo standard.
Semplicemente chi comanda in NVidia ha un complesso di inferiorità vs chi davvero comanda nel mercato (leggi MS e Intel) e spera di poter fare lo stesso: basta leggere come JHH parla di Intel nell'articolo sgrammaticato postato prima. Mi pare ovvio che il tizio non abbia capito un razzo di come gira il mercato.

[okorop]

C'è anche una terza via... :asd:
Ci sono già in pipeline diversi giochi che sfrutteranno almeno in parte la tessellation (che ricordo è una feature delle DX11, non certo uno sghiribizzo di ATI)... I first movers comprano Fermi (a marzo), si accorgono che le prestazioni con la tessellation fanno pena, nessuno più compra dette schede e Fermi fa la fine di NV30, EOL dopo pochi mesi.
E non la vedo come un'opzione così remota.... ;)
Non è che all'epoca della FX nessuno usò più giochi DX9 o li programmava come voleva JHH solo perchè NV30 faceva pena.

ribadisco anche io il concetto piu' appropiato che secondo me calza a pennello nell'introdurre una nuova tecnologia di rendering nei videogiochi: se la nuova feature non fa rimpiangere le prestazioni senza l'adozione di essa allora è un innovazione in caso contrario lo è in parte in quanto non proprio sfruttabile, se tessalation andrà bene con ati e meno con nvida, a mio avviso il ceo della casa di santa clara ostacolerà questa feature, bisogna vedere fino a che punto, non si puo' sempre rimanere alle dx9
il tizio è solo un fan boy di se stesso.......

[Psyco89]

NV30 faceva anche pena però esiste una cosa chiamata pubblicità e strategia di marketing.

in cui la grande maggioranza delle persone che compra un pc è neofita e ovviamente va a comeprare marchi conosciuti, quelli che si ifnormano sono una netta minoranza, anche quando c'era il pentium 4 contro l'Athlon 64 intel vendeva solo con il nome, Nvidia sta facendo lo stesso adesso, mica abbasserà i prezzi della 285 e 295, rimarranno simili fino all'arrivo di fermi.


Se Fermi dovesse essere non competitivo, cosa di cui dubito visto che ha 3 miliardi di transistors quindi qualche roba dentro ce la dovrebbe avere e sulla carta sembra quasi il nuovo G80 del 2010, di sicuro abbasserebbe un pochettino i prezzi e manderebbero il CEO Nvidia al Chiambretti Night o a mediaset e risolve il problema.

[yossarian]

e' hardware, solo che l'approccio e' leggermente diverso da quello ati.

nello shader core non ci sono unità di tipo ff dedicate alle operazioni di tessellation. Se viene emulato saranno le stesse fpu a fare il lavoro di hull e domain shader (come avviene in rv770) e ad emulare le fixed function che fanno tessellation. In tal caso, però, ci sarà per forza un hit prestazionale, visto che l'emulazione di una ff tramite una fpu richiede, a seconda del tipo di fpu, da 2 a 4 cicli di clock. A questio aggiungi i cicli persi per effettuare le operazioni tipiche di hull shader e domain shader (ossia le parti programmabili del tessellator dx11) che dovranno essere emulate da vertex e geometry shader. Il tutto su rv870 sarà svolto da unità dedicate che sgravano lo shader core da questo inutile carico di lavoro.
Non credo sia una buona soluzione

[Psyco89]

nello shader core non ci sono unità di tipo ff dedicate alle operazioni di tessellation. Se viene emulato saranno le stesse fpu a fare il lavoro di hull e domain shader (come avviene in rv770) e ad emulare le fixed function che fanno tessellation. In tal caso, però, ci sarà per forza un hit prestazionale, visto che l'emulazione di una ff tramite una fpu richiede, a seconda del tipo di fpu, da 2 a 4 cicli di clock.

basta non usarlo :(
i programmatori saranno felicissimi

[yossarian]

basta non usarlo :(
i programmatori saranno felicissimi

e cosa gliene frega ai programmatori; loro devono solo continuare a scrivere il codice come hanno fatto finora dando istruzioni sul tipo di superficie che la gpu deve emulare. Anzi, l'uso del tessellator può semplificare loro la vita. Puoi anche partire da superfici meno complesse delle solite e lasciare al tessellator il compito di creare i vertici mancanti (il che comporta anche un bel risparmio di banda passante)

[Psyco89]

e cosa gliene frega ai programmatori; loro devono solo continuare a scrivere il codice come hanno fatto finora dando istruzioni sul tipo di superficie che la gpu deve emulare. Anzi, l'uso del tessellator può semplificare loro la vita. Puoi anche partire da superfici meno complesse delle solite e lasciare al tessellator il compito di creare i vertici mancanti (il che comporta anche un bel risparmio di banda passante)

ah si ?
ah buono, non lo sapevo.

e perchè fino ad ora non abbiamo avuto alcun supporto ?

[devAngnew]

deve avvenire per ogni madd di ogni shader che viene caricato e non una tantum. Ovvero, ogni volta che viene "letta" una madd questa deve essere riconvertita e deve essere eseguita una fma: sempre se possibile. Oppure, se preferisci, carico uno shader con n madd e faccio la sostituzione di tutte prima di avviare l'esecuzione. Il tutto avviene on chip e non a livello di compilazione degli shader. L'unica cosa che il driver può fare è dare un'istruzione del tipo:"dove trovi una madd sostituiscila con una fma".

Bhe ed io cosa ho detto :mbe: e questo avverrebbe subito dopo il caricamento dello shader prima della compilazione.

[okorop]

e cosa gliene frega ai programmatori; loro devono solo continuare a scrivere il codice come hanno fatto finora dando istruzioni sul tipo di superficie che la gpu deve emulare. Anzi, l'uso del tessellator può semplificare loro la vita. Puoi anche partire da superfici meno complesse delle solite e lasciare al tessellator il compito di creare i vertici mancanti (il che comporta anche un bel risparmio di banda passante)

dunque la banda passante della 5870 non è limitata se si fa uno uso intensivo del tessalation a quanto pare giusto?

[yossarian]

Bhe ed io cosa ho detto :mbe: e questo avverrebbe subito dopo il caricamento dello shader prima della compilazione.

e questo va fatto per ogni singola istruzione e non una tantum, come ho detot in precedenza: il che significa che per ogni istruzione perdi un certo numero di cicli. Che ciò avvenga prima che parta l'esecuzione dello shader, quando le istruzioni sono ancora in coda all'interno del buffer o in runtime non cambia una cippa

[Psyco89]

anche se fosse così, nvidia avrebbe il 30% di banda in più che potrebbero fare al differenza.

perchè non puoi raddoppiare la potenza della GPU aumentando di un pochettino al banda.
se raddoppi uno, raddoppi anche l'altro o quantomeno cerca di alzare, aumenta l'ampiezza del bus, non so.

con il tessellation al massimo puoi dire che è meno imbottigliato ma nulla di più.

[yossarian]

dunque la banda passante della 5870 non è limitata se si fa uno uso intensivo del tessalation a quanto pare giusto?

la tessellation non è l'unico modo di risparmiare banda previsto dalle dx11. C'è anche la possibilità di utilizzare dati comuni tra thread differenti. In ogni caso, IMHO, la banda passante di RV870, in determinate situazioni, è insufficiente. Questi espedienti serviranno solo per spostare il limite un po' più in là

[yossarian]

anche se fosse così, nvidia avrebbe il 30% di banda in più che potrebbero fare al differenza.

perchè non puoi raddoppiare la potenza della GPU aumentando di un pochettino al banda.
se raddoppi uno, raddoppi anche l'altro o quantomeno cerca di alzare, aumenta l'ampiezza del bus, non so.

cosa c'entra la banda passante con il fatto che un'istruzione che può essere eseguita in un singolo ciclo ne richiede 4? Sono cose completamente diverse. Posso avere tutta la banda che voglio ma andrò sempre ad 1/4 della velocità che avrei se potessi eseguire quell'istruzioni in un solo ciclo

[Andrea deluxe]

cosa c'entra la banda passante con il fatto che un'istruzione che può essere eseguita in un singolo ciclo ne richiede 4? Sono cose completamente diverse

ma essendo fixed function, sei sicuro che ha bisogno di 3-4 cicli per essere eseguita?

in piu' , la double precision sei sicuro non venga utilizzata per tali scopi e simili?

[Psyco89]

la tessellation non è l'unico modo di risparmiare banda previsto dalle dx11. C'è anche la possibilità di utilizzare dati comuni tra thread differenti. In ogni caso, IMHO, la banda passante di RV870, in determinate situazioni, è insufficiente. Questi espedienti serviranno solo per spostare il limite un po' più in là

e io che ho detto ?
sarà meno imbottigliato ma dai 256bit in una GPU di questo calibro.....

[halduemilauno]

http://www.fudzilla.com/content/view/16544/1/

In retail & Etail

Multiple sources now claim that Nvidia has promised to ship Fermi in January time. We are talking about Fermi, the GPU that is expected to defeat ATIs Radeon 5000 offering. To make it more clear, January is the time when you can hope to buy a graphic card based on Fermi.

Fermi has been pushed from early November to January launch mainly due the fact that A2 chip revision was not good enough for volume production so A3 is about to ship to partners soon. With this in mind and if all goes well, Fermi should be ready to ship in graphics cards in January.

We also heard that the launch won't take place at CES 2010, which starts on January 7th and ends of January 10th, and that Nvidia might launch it later at some point, but still in January.


;)

[yossarian]

ma essendo fixed function, sei sicuro che ha bisogno di 3-4 cicli per essere eseguita?

in piu' , la double precision sei sicuro non venga utilizzata per tali scopi e simili?

è fixed function e de ve essere emulata da unità di tipo fp. Se ricordi, in R300, che aveva abbandonato la pipeline di tipo ff nei pixel e vertex shader, ogni pixel pipeline era in grado di eseguire 2 istruzioni di tipo fp o una sola fixed function, pur avendo due fpu in serie.
La double precision non c'entra niente con l'emulazione delle ff.

[Andrea deluxe]

http://img21.imageshack.us/img21/5937/catturait.png (http://img21.imageshack.us/i/catturait.png/)

drammatica la differenza in double precision.....


io penso che nvidia tramite driver riesca ad usare quella potenza bruta in comandi single precision....

illuminatemi.

[Psyco89]

è troppo forte sulla carta, difficile che non sia competitiva.

[Andrea deluxe]

è troppo forte sulla carta, difficile che non sia competitiva.

il problema e' questo:


http://img25.imageshack.us/img25/8602/catturabq.png (http://img25.imageshack.us/i/catturabq.png/)
http://img685.imageshack.us/img685/6177/catturaa.png (http://img685.imageshack.us/i/catturaa.png/)

a detta di molti e a meno di sorprese e segreti, e' la single precision ad essere maggiormente usata nei giochi.....

[Psyco89]

è così grave ?
Ma scusa anche la 4870 aveva un SP ben superiore alla GTX 280 no ?

[halduemilauno]

http://img21.imageshack.us/img21/5937/catturait.png (http://img21.imageshack.us/i/catturait.png/)

drammatica la differenza in double precision.....


io penso che nvidia tramite driver riesca ad usare quella potenza bruta in comandi single precision....

illuminatemi.

molto + drammatico che un 708 stia appena del 25% sotto rispetto a un 2720. semper fidelis ehm sempre in attesa di tutti i riscontri del caso.
;)

[Andrea deluxe]

molto + drammatico che un 708 stia appena del 25% sotto rispetto a un 2720. semper fidelis ehm sempre in attesa di tutti i riscontri del caso.
;)

in effetti....

yoss che ne pensi?

[devAngnew]

e questo va fatto per ogni singola istruzione e non una tantum, come ho detot in precedenza: il che significa che per ogni istruzione perdi un certo numero di cicli. Che ciò avvenga prima che parta l'esecuzione dello shader, quando le istruzioni sono ancora in coda all'interno del buffer o in runtime non cambia una cippa

IMO cambia e come perchè una cosa è interpretare una MADD a runtime come mi sembra di aver capito dalle tue risposte un' altra è fare una compilazione una volta per tutte dello shader (quindi sostituzione MADD con FMA e compilazione finale).

;)

[yossarian]

http://img21.imageshack.us/img21/5937/catturait.png (http://img21.imageshack.us/i/catturait.png/)

drammatica la differenza in double precision.....


io penso che nvidia tramite driver riesca ad usare quella potenza bruta in comandi single precision....

illuminatemi.

hai le idee un po' confuse, mi pare :)
il chip o lavora in sp o in dp; non può fare l'una e l'altra cosa contemporaneamente. Quindi non può aviluppare un potenziale teorico di 1,74 Tflops in sp e utilizzare, contemporaneamente, altre 870 Gflops per fare altro. In GT300 non ci sono alu dedicate alla dp ma sono le stesse alu che lavorano in sp che, accoppiate a due a due, eseguono calcoli in dp.
Detto questo, i 1700 MHz sono speculazioni (speranze?) di Rys. L'unico dato di fatto è che le frequenze della serie testla sono più basse di quanto ci si aspettava, il che non depone bene neppure per le geforce, da questo punto di vista. Inoltre, resta l'incognita delle madd e di come saranno eseguite. Saranno sostituite da fma? Forse, se sarà possibile e, comunque, la cosa non avverrà in maniera indolore (cicli persi e impossibilità di effetuare sempre la sostituzione). Se consideri le sole madd, anche ammettendo i 1700 MHz, avresti solo 870 Gflops per fermi in fp32.

[yossarian]

IMO cambia e come perchè una cosa è interpretare una MADD a runtime come mi sembra di aver capito dalle tue risposte un' altra è fare una compilazione una volta per tutte dello shader (quindi sostituzione MADD con FMA e compilazione finale).

;)

il numero di cicli perso è sempre lo stesso perchè le istruzioni vanno valutate sempre una per una. Che questi cicli li perda all'inizio, prima che parta l'elaborazione, oppure durante la stessa cambia poco o nulla. Anzi, forse sarebbe meglio in runtime per cercare di mascherare almeno in minima parte le latenze (se è possibile) con il multithraeding.
Inoltre, non è detto che ciò avverrà e, sicuramente, non avverrà in tutti i casi (continui a non tener conto della propagazione degli errori per shader più lunghi e le dx11 prevedono shader molto lunghi)

[Andrea deluxe]

quindi pensi sia impossibile far lavorare in double precision la gpu eseguendo grafica?

[Foglia Morta]

hai le idee un po' confuse, mi pare :)
il chip o lavora in sp o in dp; non può fare l'una e l'altra cosa contemporaneamente. Quindi non può aviluppare un potenziale teorico di 1,74 Tflops in sp e utilizzare, contemporaneamente, altre 870 Gflops per fare altro. In GT300 non ci sono alu dedicate alla dp ma sono le stesse alu che lavorano in sp che, accoppiate a due a due, eseguono calcoli in dp.
Detto questo, i 1700 MHz sono speculazioni (speranze?) di Rys. L'unico dato di fatto è che le frequenze della serie testla sono più basse di quanto ci si aspettava, il che non depone bene neppure per le geforce, da questo punto di vista. Inoltre, resta l'incognita delle madd e di come saranno eseguite. Saranno sostituite da fma? Forse, se sarà possibile e, comunque, la cosa non avverrà in maniera indolore (cicli persi e impossibilità di effetuare sempre la sostituzione). Se consideri le sole madd, anche ammettendo i 1700 MHz, avresti solo 870 Gflops per fermi in fp32.

Aspetta... nell' articolo di TechReport mi pare di aver letto che ogni cluster di 32 ALU è composto da 2 blocchi di 16 ALU ciascuno, un blocco fp32 e un blocco fp64 ( sarà utile per ottenere le gpu derivate con die size decente , eliminando le ALU fp64 ). Non porta nessun cambiamento a quanto intendevi chiarire però mi pare sia così :D

[yossarian]

molto + drammatico che un 708 stia appena del 25% sotto rispetto a un 2720. semper fidelis ehm sempre in attesa di tutti i riscontri del caso.
;)

in effetti....

yoss che ne pensi?

che quel 708 sta molto sotto al 2720 salvo il caso di esecuzione di codice stravecchio e ottimizzato per le geforce. Evidentemente hal dimentica che con AC in dx10.1 la gtx 280 andava meno della 4850 :D

[halduemilauno]

in effetti....

yoss che ne pensi?

architetture diverse. è sempre stato cosi(o cmq da molto tempo) che Nvidia nonostante valori ben inferiori era superiore alla concorrenza. e credo che questo sia il dato + importante non quanto la comparazione tra le due case ma tra le due schede ovvero la GTX285 e la GTX380(chiamiamola cosi). se in quell'articolo si citano 1700 chissa può essere altri dicono altro e quindi, non ci rimane che rimanere in attesa di tutti i riscontri del caso.
;)

[okorop]

è troppo forte sulla carta, difficile che non sia competitiva.

r600 mi ricorda qualcosa :asd:

[Psyco89]

bè in effetti la cosa era uguale anche con RV770 e GT200 anzi mi sa che ATi era meglio anche in DP eppure contro una GTX 285 le 48xx le prendevano.

ATi sembra che abbia fatto la moltiplicazione di 2 sui dati della 4890 nulla di più.
sia SP che DP sembrano solo la moltiplicazione di 2 della 4980.


Bè Nvidia invece sembra salire oltre il raddoppio, sia in SP che in DP, anche così comè adesso sembrerebbe poter battere ATi senza troppi problemi.


Il fatto non potrebbero essere i colli di bottigli della banda o dei registri interni, magari anche cache e roba varia ?

[Psyco89]

r600 mi ricorda qualcosa :asd:

Non è vero, R600 la cosa che impressionava di più erano gli stream che noi tutti pensavamo come gli stream di nvidia invece eranos tream differenti. Ma come potenza di calcolo teorica era simile al G92.

tieni conto che l'R600 era all'inizio superiore alla 8800GTS, poi ATi è ovvio che non è riuscita a sostenerla, se capitasse una cosa del genere a Nvidia è ovvio che le cose sarebbero differenti, quella si fa ottimizzare tutti i titoli e cerca di puntare tutto sui driver.

[yossarian]

Aspetta... nell' articolo di TechReport mi pare di aver letto che ogni cluster di 32 ALU è composto da 2 blocchi di 16 ALU ciascuno, un blocco fp32 e un blocco fp64 ( sarà utile per ottenere le gpu derivate con die size decente , eliminando le ALU fp64 ). Non porta nessun cambiamento a quanto intendevi chiarire però mi pare sia così :D

non credo proprio. Le alu fp che eseguono i calcoli a 32 o 64 bit sono le stesse. Non ho letto l'articolo di techreport ma spero non abbiano scritto una stupidaggine del genere :D
Dallo steso articolo, basta vedere l'immagine iniziale: sono 16 cluster; se ciascuno fosse composto da 16 unità fp32 e 16 fp64, allora in sp fermi avrebbe la metà della potenza elaborativa riportata in tabella (avrebbe solo 256 unità fp32 e non 512).
Ripeto, se hanno scritto qualcosa del genere, hanno le idee piuttosto confuse pure loro :D
In realtà, ogni cluster è composto da 2 blocchi di 16 alu fp32 che, in caso di calcoli fp64, si comportano come un unico blocco da 16 alu.

[okorop]

Non è vero, R600 la cosa che impressionava di più erano gli stream che noi tutti pensavamo come gli stream di nvidia invece eranos tream differenti. Ma come potenza di calcolo teorica era simile al G92.

tieni conto che l'R600 era all'inizio superiore alla 8800GTS, poi ATi è ovvio che non è riuscita a sostenerla, se capitasse una cosa del genere a Nvidia è ovvio che le cose sarebbero differenti, quella si fa ottimizzare tutti i titoli e cerca di puntare tutto sui driver.

sia gli stream processors sia il bus tra gpu e memorie, anche su fermi si specula tanto sui numeri che fa in doppia precisione, che poi non son tanto diferenti da quelli di rv870 ;)

non credo proprio. Le alu fp che eseguono i calcoli a 32 o 64 bit sono le stesse. Non ho letto l'articolo di techreport ma spero non abbiano scritto una stupidaggine del genere :D
Dallo steso articolo, basta vedere l'immagine iniziale: sono 16 cluster; se ciascuno fosse composto da 16 unità fp32 e 16 fp64, allora in sp fermi avrebbe la metà della potenza elaborativa riportata in tabella (avrebbe solo 256 unità fp32 e non 512).
Ripeto, se hanno scritto qualcosa del genere, hanno le idee piuttosto confuse pure loro :D
In realtà, ogni cluster è composto da 2 blocchi di 16 alu fp32 che, in caso di calcoli fp64, si comportano come un unico blocco da 16 alu.

a perfetto quidni son solo speculazioni fatte da techreport sulle prestazioni della futura gtx380 ipotizzata andare il doppio della gtx285, il dirigibile si sgonfia

[Foglia Morta]

non credo proprio. Le alu fp che eseguono i calcoli a 32 o 64 bit sono le stesse. Non ho letto l'articolo di techreport ma spero non abbiano scritto una stupidaggine del genere :D
Dallo steso articolo, basta vedere l'immagine iniziale: sono 16 cluster; se ciascuno fosse composto da 16 unità fp32 e 16 fp64, allora in sp fermi avrebbe la metà della potenza elaborativa riportata in tabella (avrebbe solo 256 unità fp32 e non 512).
Ripeto, se hanno scritto qualcosa del genere, hanno le idee piuttosto confuse pure loro :D

Ho interpretato male io ?

http://techreport.com/articles.x/17815/4

1° pagina:

Fermi now has single-SM clusters, although each SM is effectively a pair of 16-way vector sub blocks. Sub-block configuration is the key to Fermi implementation configuration. GF100, the high-end part that Nvidia outlines in the whitepaper, uses two different sub blocks in each of its sixteen SMs.

4° pagina:

Going back to the sub-block discussion, it should be clear how Nvidia might scale Fermi down to smaller variants and create derivatives. Nvidia could simply (and we use that term with all due respect to the actual difficulty involved) replace the DP-capable sub block with another of the simpler blocks. They could retain everything else about the SM, including the same scheduler, near pools, register file and even the operand gather logic.

That lets them create non-DP variants, losing some of the fearsome integer rate in the process as well (some of the integer hardware is shared with the DP silicon, necessitating that), for derivatives that don't require it, because they're addressing different markets.

Double-precision floating point is almost exclusively a non-graphics feature of GPUs, at least at this point in time (although, of course, extended-precision computation takes place all over the chip in non-programmable forms), and so it still makes sense to remove it from derivative, smaller, cheaper parts.

This modularity might also let Nvidia attempt a part with two DP sub blocks, with fairly minimal changes to the SM front end, if they so wish. Doing so will cost them area and power, but it's something they could take on. Overtaking the per-FPU, per-clock DP rate of Intel's microprocessors has to be appealing on some level.

[Psyco89]

sia gli stream processors sia il bus tra gpu e memorie, anche su fermi si specula tanto sui numeri che fa in doppia precisione, che poi non son tanto diferenti da quelli di rv870 ;)



a perfetto quidni son solo speculazioni fatte da techreport sulle prestazioni della futura gtx380 ipotizzata andare il doppio della gtx285, il dirigibile si sgonfia

si solo il 40% :D

[okorop]

si solo il 40% :D

potenza elaborativa che serve per calcoli professionali e tutto fuor'che il gaming, ci servirà? a me no :asd:

[A.L.M.]

il problema e' questo:


http://img25.imageshack.us/img25/8602/catturabq.png (http://img25.imageshack.us/i/catturabq.png/)
http://img685.imageshack.us/img685/6177/catturaa.png (http://img685.imageshack.us/i/catturaa.png/)

a detta di molti e a meno di sorprese e segreti, e' la single precision ad essere maggiormente usata nei giochi.....

E' un discorso trito e ritrito. Fino a GT200 l'efficienza dell'architettura degli shader NVidia (ossia il rapporto tra prestazioni di calcolo teoriche e quelle reali) era nettamente superiore.
I benefici erano vari: ogni shader core è indipendente, quindi può essere sfruttato fino in fondo. I core delle ATi, invece, essendo di fatto Vec4+1 riescono ad usare sì e no la metà delle risorse massime a disposizione in una situazione reale... Ed è questo il motivo per cui è difficile fare una comparazione tra il numero di cores (e quindi i GFlops teorici) delle 2 architetture.
Con Fermi però alcuni punti di forza di quell'architettura sembrano venire meno. L'impatto della trasformazione MADD->FMA è ignoto.

bè in effetti la cosa era uguale anche con RV770 e GT200 anzi mi sa che ATi era meglio anche in DP eppure contro una GTX 285 le 48xx le prendevano.

ATi sembra che abbia fatto la moltiplicazione di 2 sui dati della 4890 nulla di più.
sia SP che DP sembrano solo la moltiplicazione di 2 della 4980.


Bè Nvidia invece sembra salire oltre il raddoppio, sia in SP che in DP, anche così comè adesso sembrerebbe poter battere ATi senza troppi problemi.


Il fatto non potrebbero essere i colli di bottigli della banda o dei registri interni, magari anche cache e roba varia ?

Fermi non è nè 2x GT200, figuriamoci se è più di 2x GT200.
L'unica cosa che è più che raddoppiata sono gli shaders, col problema che però ora non sono più in grado di fare nativamente l'operazione che più viene usata nei giochi (MADD), o meglio, la sa fare, ma non non nello stesso esatto modo. Per poter calcolare tutte le MADD che ci saranno nel codice Fermi dovrà prima perdere un pochino di tempo per fare quanto diceva yossarian.
Le TMU non saranno raddoppiate, anzi con Fermi NVidia abbasserà il suo rapporto ALU:TEX al livello di ATI, perdendo un altro dei suoi punti di forza. Ricapitolando: TMU non raddoppiate, ROPs non raddoppiate, banda tutt'altro che raddoppiata, ALU che dovranno perdere più tempo per calcolare le MADD...
Mi chiedo dove stia il raddoppio, o meglio da cosa possa venir fuori. :)

E' assurdo che ad ogni giro la gente si faccia gabbare da numeri che hanno un valore assoluto molto limitato...
Ai tempi di GT200 dicevo la stessa cosa (che non poteva andare 2x G80) e in pochi mi diedero retta.
Indovinate chi ebbe ragione? :asd:

[devAngnew]

il numero di cicli perso è sempre lo stesso perchè le istruzioni vanno valutate sempre una per una. Che questi cicli li perda all'inizio, prima che parta l'elaborazione, oppure durante la stessa cambia poco o nulla. Anzi, forse sarebbe meglio in runtime per cercare di mascherare almeno in minima parte le latenze (se è possibile) con il multithraeding.
Inoltre, non è detto che ciò avverrà e, sicuramente, non avverrà in tutti i casi (continui a non tener conto della propagazione degli errori per shader più lunghi e le dx11 prevedono shader molto lunghi)

Lasciando per ora da parte il problema della propagazione dell'errore quindi possibili artefatti, IMO lo shader viene caricato (shader scritto ad alto livello) successivamente (viene compilato) questo vale sia per ATI che NVIDIA ora si avrà il codice in ASSEMBLER a questo punto dovrebbero partire eventuali ottimizzazioni nel caso NVIDIA sostituitirebbe alla MADD la FMA ma questo lo fà solo una volta prima dell'esecuzione (dello shader) perdendo questo tempo all'inizio prima che una scena venga renderizzata.

[Psyco89]

potenza elaborativa che serve per calcoli professionali e tutto fuor'che il gaming, ci servirà? a me no :asd:

Ma scusa lo sai che la 4870 ha una potenza in SP di 1.3TFlop/s ?
& la GTX 285 0.78 Tflop/s in SP ?

Eppure fra GTX 285 e 4870 c'è un bel distacco.
Ripeto che dai dati sembra che Nvidia abbia migliorato più di ATI e ha anche una banda passante, più ROPS ecc, bisogna vedere poi come vengono gestite le cose.


Come mai la 4870 non è stata in grado di battere la GTX 285 ? nonostante la differenza netta in SP ? quella potenza in più dove è finita ?



.

[yossarian]

Ho interpretato male io ?

http://techreport.com/articles.x/17815/4

1° pagina:

Fermi now has single-SM clusters, although each SM is effectively a pair of 16-way vector sub blocks. Sub-block configuration is the key to Fermi implementation configuration. GF100, the high-end part that Nvidia outlines in the whitepaper, uses two different sub blocks in each of its sixteen SMs.

4° pagina:

Going back to the sub-block discussion, it should be clear how Nvidia might scale Fermi down to smaller variants and create derivatives. Nvidia could simply (and we use that term with all due respect to the actual difficulty involved) replace the DP-capable sub block with another of the simpler blocks. They could retain everything else about the SM, including the same scheduler, near pools, register file and even the operand gather logic.

That lets them create non-DP variants, losing some of the fearsome integer rate in the process as well (some of the integer hardware is shared with the DP silicon, necessitating that), for derivatives that don't require it, because they're addressing different markets.

Double-precision floating point is almost exclusively a non-graphics feature of GPUs, at least at this point in time (although, of course, extended-precision computation takes place all over the chip in non-programmable forms), and so it still makes sense to remove it from derivative, smaller, cheaper parts.

This modularity might also let Nvidia attempt a part with two DP sub blocks, with fairly minimal changes to the SM front end, if they so wish. Doing so will cost them area and power, but it's something they could take on. Overtaking the per-FPU, per-clock DP rate of Intel's microprocessors has to be appealing on some level.

mi sa di si :D
secondo l'articolo ogni cluster è composto da 16 alu fp64 divise in due sub-blocchi fp32 (il concetto è lo stesso epsresso da me prima ma partendo dall'assunto che si tratta di unità fp64 che possono lavorare a fp32 raddoppiando la capacità di calcolo teorica invece del contrario). Si sostiene che nVidia possa ricavare chip di fasci più bassa utilizzando, invece di cluster di 16 alu fp64 (ovvero 32 alu fp32) cluster di 16 alu fp32. (in tal caso, sembrerebbe che questi chip derivati non siano in grado di eseguire calcoli a fp64).
La cosa mi lascia piuttosto perplesso in quanto intanto non mi risulta che la alu di GT300 siano di tipo fp64 native me che, come in larrabee, si utilizzino 2 alu fp32 per eseguire calcoli a fp64. In secondo luogo, mi suona strano che per passare ad un chip derivato si modifichi la struttura del singolo cluster (cosa mai avvenuta finora).

[yossarian]

Lasciando per ora da parte il problema della propagazione dell'errore quindi possibili artefatti, IMO lo shader viene caricato (shader scritto ad alto livello) successivamente (viene compilato) questo vale sia per ATI che NVIDIA ora si avrà il codice in ASSEMBLER a questo punto dovrebbero partire eventuali ottimizzazioni nel caso NVIDIA sostituitirebbe alla MADD la FMA ma questo lo fà solo una volta prima dell'esecuzione (dello shader) perdendo questo tempo all'inizio prima che una scena venga renderizzata.

ripeto, non cambia assolutamente nulla: se hai 20 madd in uno shader devi eseguire 20 volte la sostituzione, che sia all'interno del buffer o in runtime. Non basta eseguire una sostituzione che valga per 20 o 50 istruzioni. La sostituzione avviene ogni volta che si incontra un'istruzione di tipo madd

[okorop]

Ma scusa lo sai che la 4870 ha una potenza in SP di 1.3TFlop/s ?
& la GTX 285 0.78 Tflop/s in SP ?

Eppure fra GTX 285 e 4870 c'è un bel distacco.
Ripeto che dai dati sembra che Nvidia abbia migliorato più di ATI e ha anche una banda passante, più ROPS ecc, bisogna vedere poi come vengono gestite le cose.


Come mai la 4870 non è stata in grado di battere la GTX 285 ? nonostante la differenza netta in SP ? quella potenza in più dove è finita ?



.

l'uso degli stream processors in fermi è diverso da quello di gt200, ati è andata molto vicina alle prestazioni in singola scheda della gtx285 con la 4890 ;)

[Severnaya]

Come mai la 4870 non è stata in grado di battere la GTX 285 ? nonostante la differenza netta in SP ? quella potenza in più dove è finita ?


io da profano confronterei la 4870 con la 280 e nn con la 285

[okorop]

io da profano confronterei la 4870 con la 280 e nn con la 285

quoto ed aggiungo che la gtx280 andava un 20% in piu' della 4870 proprio per gli shader unificati in cui gt200 riusciva a trarre maggior vantaggio rispetto alla soluzione ati, lo scenario che si prospetta con gt100 potrebbe anche essere completamente diverso, con ati che dovrà svolgere meno ottimizzazione dei driver rispetto a nvida

[yossarian]

Ma scusa lo sai che la 4870 ha una potenza in SP di 1.3TFlop/s ?
& la GTX 285 0.78 Tflop/s in SP ?

Eppure fra GTX 285 e 4870 c'è un bel distacco.
Ripeto che dai dati sembra che Nvidia abbia migliorato più di ATI e ha anche una banda passante, più ROPS ecc, bisogna vedere poi come vengono gestite le cose.


Come mai la 4870 non è stata in grado di battere la GTX 285 ? nonostante la differenza netta in SP ? quella potenza in più dove è finita ?



.

facciamo un'altra precisazione; i dati riportati in tabella riguardano le madd per gt200 e non le flops; gt200 può eseguire una madd e una mul per ciclo, quindi la potenza di calcolo teorica è di 1,063 Tflops e non di 708. Invece, GT300 pare non abbia la capacità di eseguire mul aggiuntive ma solo madd (o fma).
Inoltre, con codice dx10.1 la 4890 riesce a battere la 285 gtx. Se prorpio vuoi fare un confronto fallo completo: la 4890 è dx10.1 la 285 gtx no.

http://www.hwupgrade.it/articoli/skvideo/2301/ati-radeon-hd-5700-directx-11-per-la-fascia-media_9.html

ad esempio, per hawx leggo 91/77/67 per la 285 gtx in dx10 e 102/86/78 per la 4890 in dx10.1. Peccato che i driver acerbi non facciano avere gli stessi incrementi percentuali alle vga con rv870 :p

[A.L.M.]

ripeto, non cambia assolutamente nulla: se hai 20 madd in uno shader devi eseguire 20 volte la sostituzione, che sia all'interno del buffer o in runtime. Non basta eseguire una sostituzione che valga per 20 o 50 istruzioni. La sostituzione avviene ogni volta che si incontra un'istruzione di tipo madd

Interessante, non ho capito se però Rys (che scrive l'articolo) sia della stessa idea. :fagiano:

facciamo un'altra precisazione; i dati riportati in tabella riguardano le madd per gt200 e non le flops; gt200 può eseguire una madd e una mul per ciclo, quindi la potenza di calcolo teorica è di 1,063 Tflops e non di 708. Invece, GT300 pare non abbia la capacità di eseguire mul aggiuntive ma solo madd (o fma).

Mah, sulle missing MUL io non farei molto affidamento... :asd:
Erano talmente utili che alla prima occasione utile se le sono levate dai piedi... :D

Ma scusa lo sai che la 4870 ha una potenza in SP di 1.3TFlop/s ?
& la GTX 285 0.78 Tflop/s in SP ?

Eppure fra GTX 285 e 4870 c'è un bel distacco.
Ripeto che dai dati sembra che Nvidia abbia migliorato più di ATI e ha anche una banda passante, più ROPS ecc, bisogna vedere poi come vengono gestite le cose.


Come mai la 4870 non è stata in grado di battere la GTX 285 ? nonostante la differenza netta in SP ? quella potenza in più dove è finita ?

Per essere più chiari, la potenza teorica delle ATI è più teorica di quella delle NVidia... :asd:

Solo se si riescono a tenere occupati tutti e 5 i core di ogni shader unit si raggiunge la potenza teorica max. Dato che questo non avviene, ma al massimo se ne occupano 2-3, questo porta ad un primo ridimensionamento delle prestazioni. Dipende molto da come è scritto il gioco. E' il prezzo che si deve pagare per avere shaders che occupano poco spazio nella gpu.
Un altro limite che hanno le ATI è nel texturing power, che a partire da R600 in poi è più limitato che nelle NVidia. Considera però che Fermi avrà lo stesso rapporto tra numero di shaders e numero di TMU di RV870, quindi questo vantaggio è andato.

[devAngnew]

ripeto, non cambia assolutamente nulla: se hai 20 madd in uno shader devi eseguire 20 volte la sostituzione, che sia all'interno del buffer o in runtime. Non basta eseguire una sostituzione che valga per 20 o 50 istruzioni. La sostituzione avviene ogni volta che si incontra un'istruzione di tipo madd

Secondome stiamo parlano due lingue diverse :asd: :asd: :asd:
Bha allora i compilatori e gli ottimizzatori a cosa servono a nulla da quello che dici tu.
Questo non ha senso.

[yossarian]

Interessante, non ho capito se però Rys (che scrive l'articolo) sia della stessa idea. :)



quale sia l'idea di Rys conta relativamente: innanzitutto è da vedere se è possibile eseguire la sostituzione; poi è da vedere quando è possibile. Infine, a livello di driver, l'unico modo in cui si può agire è quello che ho descritto: il driver può solo indicare all'hw di effettuare una determinata operazione quando si trova di fronte ad un certo tipo di chiamata. Ad esempio, di fronte ad una madd, il driver indica all'hw di eseguire una mull un troncamento ed una add con arrotondamento. Il processo è questo: il thread processor preleva l'istruzione, la legge, la interpreta e la manda in esecuzione in base a quelli che sono i parametri della programmazione a basso livello. Il driver può intervenire su questi parametri andando a modificare l'esecuzione dell'istruzione. In tal caso può suggerire al chip di sostituire una madd con una fma. Il thread processor, quindi preleva la istruzione la decodifica e, una volta capito che si tratta di una madd la sostituisce con una fma (uno step in più rispetto all'esecuzione standard) e poi la manda in esecuzione.
Un ulteriore problema sorge nel momento in cui questo tipo di operazioni non sono sempre possibili (ed è il caso di shader molto lunghi o che richiedono una particolare precisione). Questo significa che l'operazione deve essere analizzata caso per caso e non si può effettuare indiscriminatamente l'operazione di sostituzione dell'istruzione.
Può sembrare strano parlare di precisione quando sappiamo che le fma restituiscono risultati più precisi delle madd, ma le cose stanno propio così. Quando un coder dà una certa istruzione è perchè si aspetta un determinato risultato che tiene conto anche degli eventuali arrotondamenti o troncamenti. L'assenza di uno qualsiasi dei passaggi previsti può dar luogo a risultati diversi da quelli desiderati o attesi.

[yossarian]

Secondome stiamo parlano due lingue diverse :asd: :asd: :asd:
Bha allora i compilatori e gli ottimizzatori a cosa servono a nulla da quello che dici tu.
Questo non ha senso.

stai suggerendo che i chip nVidia, con architettura superscalare, operino at compile time? Oppure non hai idea di come funzioni internamente un chip? O, magari, pensi che la sostituzione avvenga, come per incanto, istantaneamente, in tutto lo shader o, magari, in tutti gli shader caricati?
Visto che sei così sicuro, ti invito a trovarmi un documento in cui si spieghi come effettuare la sostituzione o un documento in cui si spieghi come eseguire delle madd su pipeline di tipo fma

[devAngnew]

stai suggerendo che i chip nVidia, con architettura superscalare, operino at compile time? Oppure non hai idea di come funzioni internamente un chip

Se non ricordo male già dai tempi di NV30 Nvidia faceva uso di un compilatore di shader e se non erro in G80 e derivati quindi G200 fanno lo stesso ed hanno ottimizzato la cosa ancor di più in Fermi con JIT compiler performante però ora non ricordo dove lo lessi.

[yossarian]

Se non ricordo male già dai tempi di NV30 Nvidia faceva uso di un compilatore di shader e se non erro in G80 e derivati quindi G200 fanno lo stesso ed hanno ottimizzato la cosa ancor di più in Fermi con JIT compiler performante però ora non ricordo dove lo lessi.

tutti fanno uso di compilatori, spesso si fanno anche operazioni di shader reordering e, talvolta, di shader replacement (molto frequenti ai tempi di nv30).
Il principio è sempre lo stesso: quando incontri quel tipo di istruzione sostituiscila con quest'altra. Che questo valga per una singola istruzione o per un intero shader (con nv30 si sotituivano interi pezzi di codice dx9 con codice dx8) la cosa non cambia.
State montando un caso per una battuta di Rys (ed è quello che dovranno fare i driver) buttata li senza spiegare come o quando e se la stessa sarà possibile senza problemi (e non credo che neppure lui sia in grado di rispondere)
Questa fa il paio con quella del tessellator che "tanto sarà emulato via sw senza alcun problema" (poi magari ci spiegherà come e perchè si perde tempo a implementare funzioni in hw se possono essere emulate via sw senza problemi) o con quella sulle alu fp64 che su chip di fascia bassa diventano fp32
Forse, prima di avventurarsi in previsioni, sarebbe opportuno avere qualche informazione in più anche a livello di benchmark.

[Foglia Morta]

Nel caso di nVidia è questo: http://developer.nvidia.com/object/cg_toolkit.html . edit. risolto

[okorop]

Nel caso di nVidia è questo: http://developer.nvidia.com/object/cg_toolkit.html . edit. risolto

http://developer.amd.com/Pages/default.aspx ;)

[devAngnew]

tutti fanno uso di compilatori, spesso si fanno anche operazioni di shader reordering e, talvolta, di shader replacement (molto frequenti ai tempi di nv30).


Ovviamente


Il principio è sempre lo stesso: quando incontri quel tipo di istruzione sostituiscila con quest'altra. Che questo valga per una singola istruzione o per un intero shader (con nv30 si sotituivano interi pezzi di codice dx9 con codice dx8) la cosa non cambia.

:mbe:
Appunto non cambia, una volta compilato e ottimizzato lo shader è eseguito alla max velocità possibile dalla GPU quindi l'overhead di sostituzione delle istruzione non persiste più ma ci sarà solo quello dovuto all'exe dell' FMA.

[Foglia Morta]

tutti fanno uso di compilatori, spesso si fanno anche operazioni di shader reordering e, talvolta, di shader replacement (molto frequenti ai tempi di nv30).
Il principio è sempre lo stesso: quando incontri quel tipo di istruzione sostituiscila con quest'altra. Che questo valga per una singola istruzione o per un intero shader (con nv30 si sotituivano interi pezzi di codice dx9 con codice dx8) la cosa non cambia.
State montando un caso per una battuta di Rys (ed è quello che dovranno fare i driver) buttata li senza spiegare come o quando e se la stessa sarà possibile senza problemi (e non credo che neppure lui sia in grado di rispondere)
Questa fa il paio con quella del tessellator che "tanto sarà emulato via sw senza alcun problema" (poi magari ci spiegherà come e perchè si perde tempo a implementare funzioni in hw se possono essere emulate via sw senza problemi) o con quella sulle alu fp64 che su chip di fascia bassa diventano fp32
Forse, prima di avventurarsi in previsioni, sarebbe opportuno avere qualche informazione in più anche a livello di benchmark.

Penso sia perchè JHH pone fiducia nel compilatore. Secondo lui NV30 è una bella architettura ma rimasta incompresa... e non vuole che anche Fermi resti una gpu incompresa , almeno da questa intervista pare così: http://tech.tbreak.com/2009/11/nvidia-past-present-future-an-interview-with-jen-hsun-huang/3/

[okorop]

Ovviamente



:mbe:
Appunto non cambia, una volta compilato e ottimizzato lo shader è eseguito alla max velocità possibile dalla GPU quindi l'overhead di sostituzione delle istruzione non persiste più ma ci sarà solo quello dovuto all'exe dell' FMA.

ma scusa una cosa la gpu compila le fma poi deve sostituirle in madd tutte le volte e quindi gli exe dell'fma si presenteranno sempre creando overhead, oppure sbaglio qualcosa?

Penso sia perchè JHH pone fiducia nel compilatore. Secondo lui NV30 è una bella architettura ma rimasta incompresa... e non vuole che anche Fermi resti una gpu incompresa , almeno da questa intervista pare così: http://tech.tbreak.com/2009/11/nvidia-past-present-future-an-interview-with-jen-hsun-huang/3/
mi metto le mani nei capelli allora, ci sarà da piangere........

[leoneazzurro]

In realtà lui fa riferimento proprio a quelle in quasi tutto l'articolo...per il resto credo che lo scenario che disegni sia molto credibile, dubito fortemente anche io che riesca a superare hemlock.

Sul fatto del tesselatore mi rende perplesso che siano così sicuri in quell'articolo...sbaglio o il tesselatore via hardware è espressamente richiesto come requisito delle dx11? In questo caso come farebbe nvidia a dichiararsi dx11 se non ce l'ha? :what:

Non so, non c'è nemmeno un accenno a quanti fps "faccia" GF100, le speculazioni sono tutte sul lato delle prestazioni teoriche (quanti FLOPs, quanti texel, il fill rate, ecc.) che come sappiamo spesso non si traducono in prestazioni pure. Per esempio, lo SLI di GTX285 avrà sempre più banda passante e più triangoli/s rispetto a GF100. Se si tende ad essere limitati da questi fattori ci si ritrova esattamente nella situazione della 5870 rispetto alla 4870x2. Per il tessellatore, basta che si rispettino le chiamate dell'API.

Ma scusa lo sai che la 4870 ha una potenza in SP di 1.3TFlop/s ?
& la GTX 285 0.78 Tflop/s in SP ?

Eppure fra GTX 285 e 4870 c'è un bel distacco.
Ripeto che dai dati sembra che Nvidia abbia migliorato più di ATI e ha anche una banda passante, più ROPS ecc, bisogna vedere poi come vengono gestite le cose.

Come mai la 4870 non è stata in grado di battere la GTX 285 ? nonostante la differenza netta in SP ? quella potenza in più dove è finita ?

.

Ci sono diversi fattori che influenzano le prestazioni oltre ai FLOPS: le capacità di texturing, la banda passante, il fill rate e lo z-rate delle ROPs, le capacità di elaborazione geometrica, ecc. Quindi dire che la 4870 avesse più FLOPS della GTX285 è poco significativo se non si ricorda che fill rate, Z rate, banda passante e capacità di texturing erano maggiori nelle GTX285.
Poi una cosa è la capacità di calcolo di picco, un'altra è quella effettivamente raggiungibile nelle applicazioni. RV770 da alcuni dati emersi in rete ha su applicazioni grafiche una utilizzazione media delle unità shader del 70%, mentre GT200 tende a superare il 90%. Per cui le capacità di calcolo -pratiche- di tali chip sono pressappoco sullo stesso piano e le differenze riguardano gli altri fattori visti prima. Infine viene la programmazione: se il codice tende a sfruttare meglio le unità di RV770 allora questo sarà più veloce, se invece ad esempio si utilizza codice con parecchie istruzioni scalari e dipendenti GT200 è favorito.

[yossarian]

:mbe:
Appunto non cambia, una volta compilato e ottimizzato lo shader è eseguito alla max velocità possibile dalla GPU quindi l'overhead di sostituzione delle istruzione non persiste più ma ci sarà solo quello dovuto all'exe dell' FMA.

e l'overhead per la compilazione e l'ottimizzazione dello shader non lo calcoli? O quelle sono gratis?
La sostituzione o la fai prima o dopo non cambia nulla; se l'esecuzione inizia con n cicli di ritardo perchè si devono sosittuire le madd con fma hai lo stesso sprecato dei cicli. Cosa non ti torna? :rolleyes:

[Ren]

Yoss, volevo chiederti una cosa slegata dal discorso fermi.

Vedo che le moderne GPU possono indirizzare solo 16 vertici per ciclo di clock.

Quante unità simd possono essere allocate per il calcolo dei vertex ?

Mi verrebbe spontaneo pensare che al massimo un solo stream cluster possa essere allocato, dato che ogni vettore fp32 gestisce un triangolo.

Le animazioni impegnano i geometry o i vertex shader ?
In che misura rispetto alla mera generazione della scena tridimensionale ?

Scusa OT.

[yossarian]

Yoss, volevo chiederti una cosa slegata dal discorso fermi.

Vedo che le moderne GPU possono indirizzare solo 16 vertici per ciclo di clock.

Quante unità simd possono essere allocate per il calcolo dei vertex ?

Mi verrebbe spontaneo pensare che al massimo un solo stream cluster possa essere allocato, dato che ogni vettore fp32 gestisce un triangolo.

Le animazioni impegnano i geometry o i vertex shader ?
In che misura rispetto alla mera generazione della scena tridimensionale ?

Scusa OT.

in realtà questo limite è già stato superato; dalle dx10.1, infatti, è possibile indirizzare fino a 32 vertici. Solitamente i calcoli geometrici fanno uso di vettori completi (quindi a 4 componenti), per cuiad esempio, un cluster di 16 unità scalari potrà occuparsi, al massimo, di elaborare 4 vertici per ciclo. Per operare su 16 vertici per ciclo avrai bisogno di 64 alu scalari solo per le operazioni di vertex shading

[Kharonte85]

C'è anche una terza via... :asd:
Ci sono già in pipeline diversi giochi che sfrutteranno almeno in parte la tessellation (che ricordo è una feature delle DX11, non certo uno sghiribizzo di ATI)... I first movers comprano Fermi (a marzo), si accorgono che le prestazioni con la tessellation fanno pena, nessuno più compra dette schede e Fermi fa la fine di NV30, EOL dopo pochi mesi.
E non la vedo come un'opzione così remota.... ;)
Non è che all'epoca della FX nessuno usò più giochi DX9 o li programmava come voleva JHH solo perchè NV30 faceva pena in quei frangenti. Così come non è che perchè NVidia dice che PhysX è bello diventerà lo standard.
Semplicemente chi comanda in NVidia ha un complesso di inferiorità vs chi davvero comanda nel mercato (leggi MS e Intel) e spera di poter fare lo stesso: basta leggere come JHH parla di Intel nell'articolo sgrammaticato postato prima. Mi pare ovvio che il tizio non abbia capito un razzo di come gira il mercato.
Onestamente mi sembra uno scenario poco credibile...come anche il paragone fatto da JHH con nv30, puramente dettato dal fatto che gli hanno fatto una domanda su quello e lui voleva parlare di fermi.

Nv30 aveva il problema di "essere" dx8 quando i giochi cominciavano a diventare tutti in dx9 (in open GL viaggiavano una meraviglia uguale in dx8.1), in questo momento la situazione è diversa perchè fino a che non ci leviamo di torno le console la maggior parte dei giochi rimarrà in dx9.

Al momento (ma probabilmente anche in futuro) i giochi dx10, dx10.1, dx11 e dx11 con tesselatore rappresenteranno solo una minoranza assoluta. Ecco perchè è impossibile che si ripeta l'ecatombe della serie fx. (a meno che GF100 sia dx8 :asd:)
e cosa gliene frega ai programmatori; loro devono solo continuare a scrivere il codice come hanno fatto finora dando istruzioni sul tipo di superficie che la gpu deve emulare. Anzi, l'uso del tessellator può semplificare loro la vita. Puoi anche partire da superfici meno complesse delle solite e lasciare al tessellator il compito di creare i vertici mancanti (il che comporta anche un bel risparmio di banda passante)
insomma, a vedere dall'unico benchmark in dx11 prendendo l'esempio delle scale non direi, cioè dubito fortemente che un programmatore possa lasciare le scale lisce in un gioco che dovrebbe girare anche su una GF6600 solo perchè "tanto con il tesselatore poi le vede"...finche' è un benchmark puo' farlo ma quando è un gioco ne dubito :fagiano:

[Ren]

Quindi non più di un cluster di alu Ati,(80alu) può essere indirizzato alla volta per mancanza di dati da processare(causa il setup triangle) per ciclo di clock. Le altre alu rimangono in attesa che il dato venga restituito al rasterizer per poi proseguire con i pixel shader.
In poche parole gli altri 18-19 cluster di cypress rimangono in standby per ogni ciclo di clock dedicato alla geometria...
Stesso discorso, ma con proporzioni diverse per le nvidia.

Sto dicendo una fesseria ?

[Kharonte85]

Non so, non c'è nemmeno un accenno a quanti fps "faccia" GF100, le speculazioni sono tutte sul lato delle prestazioni teoriche (quanti FLOPs, quanti texel, il fill rate, ecc.) che come sappiamo spesso non si traducono in prestazioni pure. Per esempio, lo SLI di GTX285 avrà sempre più banda passante e più triangoli/s rispetto a GF100. Se si tende ad essere limitati da questi fattori ci si ritrova esattamente nella situazione della 5870 rispetto alla 4870x2. Per il tessellatore, basta che si rispettino le chiamate dell'API.
Quello è chiaro pero' nell'articolo a differenza di quelli passati (dove si parlava di calcolo) si concentra esplicitamente sulle capacità grafiche (teoriche giustamente ;) ).

Se è come dici allora gf100 potrebbe dichiararsi dx11 senza avere un tesselatore hardware...ma emulare il tesselatore secondo me sarebbe un suicidio (a vedere quanto calano le prestazioni sulle schede HD5xx0), praticamente equivarebbe a non averlo...e sarebbe un peccato perchè a quel punto in pochissimi sarebbero incoraggiati spontaneamente ad utilizzarlo.

[pandyno]

Se è come dici allora gf100 potrebbe dichiararsi dx11 senza avere un tesselatore hardware...ma emulare il tesselatore secondo me sarebbe un suicidio (a vedere quanto calano le prestazioni sulle schede HD5xx0), praticamente equivarebbe a non averlo...e sarebbe un peccato perchè a quel punto in pochissimi sarebbero incoraggiati spontaneamente ad utilizzarlo.

E questo è allarmante. Spero davvero che tirino fuori qualcosa.

[Andrea deluxe]

Quello è chiaro pero' nell'articolo a differenza di quelli passati (dove si parlava di calcolo) si concentra esplicitamente sulle capacità grafiche (teoriche giustamente ;) ).

Se è come dici allora gf100 potrebbe dichiararsi dx11 senza avere un tesselatore hardware...ma emulare il tesselatore secondo me sarebbe un suicidio (a vedere quanto calano le prestazioni sulle schede HD5xx0), praticamente equivarebbe a non averlo...e sarebbe un peccato perchè a quel punto in pochissimi sarebbero incoraggiati spontaneamente ad utilizzarlo.

ho visto un video di dirt2 dove venivano comparate de diff con tassellatore e non, ma ho notato che viene usato come lo zafferano nel risotto.....(poco)

se si eccede con il tassellatore, si perde troppo con ati e penso pure con nvidia....

[A.L.M.]

Quello è chiaro pero' nell'articolo a differenza di quelli passati (dove si parlava di calcolo) si concentra esplicitamente sulle capacità grafiche (teoriche giustamente ;) ).

Sinceramente mi sfugge di che tipo di capacità grafiche puoi parlare se le uniche cose che si sanno sono di carattere computazionale. Sappiamo molto sugli shaders e sulle caratteristiche generali del chip, ma poco sul resto...

[yossarian]

Quindi non più di un cluster di alu Ati,(80alu) può essere indirizzato alla volta per mancanza di dati da processare(causa il setup triangle) per ciclo di clock. Le altre alu rimangono in attesa che il dato venga restituito al rasterizer per poi proseguire con i pixel shader.
In poche parole gli altri 18-19 cluster di cypress rimangono in standby per ogni ciclo di clock dedicato alla geometria...
Stesso discorso, ma con proporzioni diverse per le nvidia.

Sto dicendo una fesseria ?
stai ragionando come si faceva per i chip a shader dedicati :)
Con gli shader unificati tutti i cluster caricano istruzioni relative sia alle geometrie che al rendering e le eseguono in contemporanea solo dopo che sono stati riempiti tutti i registri costanti (diverse migliaiaa9 e gli instruction buffer. Ogni thread di tipo geometrico ne genera n per i pixel shader che vengono eseguiti mentre si continua a lavorare su altri thread geometrici.
Insomma, quello dei 16 vertici (o 32) caricati per ciclo non costituisce un limite.

[Kharonte85]

Sinceramente mi sfugge di che tipo di capacità grafiche puoi parlare se le uniche cose che si sanno sono di carattere computazionale. Sappiamo molto sugli shaders e sulle caratteristiche generali del chip, ma poco sul resto...
Non sono io che ho scritto l'articolo:

Rough performance estimates

Given everything we talked about above, we can start to draw some rough comparisons from GF100 to GT200 and RV870—and maybe estimate performance. We've got a clock estimate we're pretty confident in, and we've puts flags in the ground for the graphics-specific units, in terms of counts, so here goes nothing.

We'll consider Radeon HD 5870 for the RV870 implementation and the GeForce GTX 285 for the GT200 product. Obviously, GT200's SP rate is for MADD, since it doesn't have support for SP FMA.

http://img21.imageshack.us/img21/5937/catturait.png

The GF100's architecture means the SKU we've described (the GeForce GTX 380, possibly) comfortably outruns the GeForce GTX 285 in every way, to the point that (and we really generalize here, sorry) it should usually be at least twice as fast. Of course, you can engineer situations, usually in the middle of a frame, where the GF100 won't outpace the GT200 all that much, but in the main, it should be a solid improvement. The GF100 will outpace the Radeon HD 5870 as the top single-chip graphics product of all time, assuming AMD doesn't release anything else in the interim, between now and January. Look for the margins there to be a bit more slender, and we refer you to our Radeon HD 5870 review for the figures that'll let you imagine performance versus AMD's product.

http://techreport.com/articles.x/17815/4

[DukeIT]

emulare il tesselatore secondo me sarebbe un suicidio (a vedere quanto calano le prestazioni sulle schede HD5xx0)
Probabilmente non ho capito bene io, ma il tessellatore non dovrebbe far migliorare le prestazioni a parità di rappresentazione grafica?

[Ren]

tai ragionando come si faceva per i chip a shader dedicati
Con gli shader unificati tutti i cluster caricano istruzioni relative sia alle geometrie che al rendering e le eseguono in contemporanea solo dopo che sono stati riempiti tutti i registri costanti (diverse migliaiaa9 e gli instruction buffer. Ogni thread di tipo geometrico ne genera n per i pixel shader che vengono eseguiti mentre si continua a lavorare su altri thread geometrici.
Insomma, quello dei 16 vertici (o 32) caricati per ciclo non costituisce un limite.

Pensavo si dovesse generare l'intera geometria del frame, non solo alcuni elementi per poi rasterizzare/renderizzare...

[kiriranshelo]

Probabilmente non ho capito bene io, ma il tessellatore non dovrebbe far migliorare le prestazioni a parità di rappresentazione grafica?

no. serve per migliorare la qualità grafica, a discapito delle prestazioni talvolta, se non sbaglio

[DukeIT]

no. serve per migliorare la qualità grafica, a discapito delle prestazioni talvolta.
Eppure pensavo che fosse l'esatto contrario :(

[The_SaN]

no. serve per migliorare la qualità grafica, a discapito delle prestazioni talvolta, se non sbaglioPuoi fare tutte e 2.
O migliori la qualitá (con un impatto prestazionale ridotto rispetto ai metodi tradizionali), o mantieni lo stesso dettaglio migliorando le prestazioni.

(che poi diciamocelo, é la stessa cosa, da 2 punti di vista diversi)

[Judicator]

Probabilmente non ho capito bene io, ma il tessellatore non dovrebbe far migliorare le prestazioni a parità di rappresentazione grafica?

A parità di numero di triangoli, si, c'è una lieve differenza.
Ma bisogna pensare che al crescere del numero delle facce aumentano il numero dei triangoli che compongono gli oggetti. Quindi illuminazione ed ombreggiatura devono essere calcolati sulla base di un dettagliio geometrico maggiore.

[Ren]

Eppure pensavo che fosse l'esatto contrario

Rimane sempre un algoritmo di generazione dei poligoni. Un tuning a mano dei modelli poligonali è sicuramente di maggior qualità rispetto ad una serie di formule matematiche, anche se si scontra con i limiti di banda passante.

Quindi i modelli poligonali rimangono gli stessi, ma si applica un effetto che aumenti i poligoni matematicamente e non secondo l'idea del modellatore.

Diciamo che è un effetto che aumenta la qualità generale dei modelli come può essere un parallax mapping, ma con reale generazione dei poligoni ed il vantaggio della scalabilità del motore 3D.

Se guardi il drago postato precedentemente, l'aumento di poligoni è mostruoso, ma la qualità del prodotto finito non è poi così eclatante. (guarda i video)
Alcune superfici più semplici come i mattoni o le corde, mostrano invece uno stacco maggiore dal punto di vista qualitativo.

[yossarian]

Pensavo si dovesse generare l'intera geometria del frame, non solo alcuni elementi per poi rasterizzare/renderizzare...

si può procedere anche in contemporanea a condizione che non ci siano istruzioni tra loro dipendenti. Ad esempio, ovviamente, non si può renderizzare una superficie i cui dati geometrici non siano ancora stati processati ma si può renderizzare una superficie già calcoltata mentre in contemporanea si sta lavorando sul calcolo di altre superfici.
Considera che dopo l'avvio dell'elaborazione, man mano che si rpocede, i buffer e i registri contenenti istruzioni e dati si vanno svuotando e devono essere di nuovo riempiti. Per questo, l'unità centrale (il thread processor) riceve dei feedback da tutti i processi completati e decide, di conseguenza, cosa andare a caricare.
Anche nell'ipotesi di dover completare prima un intero frame, il limite dei 16 vertici per ciclo non rappresenterebbe un collo di bottiglia, perchè questo avverrebbe solo all'inizio dell'elaborazione del primo frame; in seguito, possono essere caricate anche istruzioni relative alle geometrie dei frame successivi mentre si sta ancora renderizzando il frame precedente.

[yossarian]

Rimane sempre un algoritmo di generazione dei poligoni. Un tuning a mano dei modelli poligonali è sicuramente di maggior qualità rispetto ad una serie di formule matematiche, anche se si scontra con i limiti di banda passante.

Quindi i modelli poligonali rimangono gli stessi, ma si applica un effetto che aumenti i poligoni matematicamente e non secondo l'idea del modellatore.

Diciamo che è un effetto che aumenta la qualità generale dei modelli come può essere un parallax mapping, ma con reale generazione dei poligoni ed il vantaggio della scalabilità del motore 3D.

Se guardi il drago postato precedentemente, l'aumento di poligoni è mostruoso, ma la qualità del prodotto finito non è poi così eclatante. (guarda i video)
Alcune superfici più semplici come i mattoni o le corde, mostrano invece uno stacco maggiore dal punto di vista qualitativo.

in realtà è il modellatore che decide secondo quale algoritmo devono essere "inseriti" i nuovi vertici. In pratica, si danno nistruzioni sul tipo di superficie da generare, fornendone i parametri.

[Ren]

Finalmente ho capito!:yeah:

Grazie.

[Ren]

in realtà è il modellatore che decide secondo quale algoritmo devono essere "inseriti" i nuovi vertici. In pratica, si danno nistruzioni sul tipo di superficie da generare, fornendone i parametri.

Si, lo avevo capito, ma non sempre i risultati mi sembrano eccellenti su tutti i modelli... (ovviamene mi riferisco al benchmark che circola)

[Marko91]

Non sono io che ho scritto l'articolo:

Rough performance estimates

Given everything we talked about above, we can start to draw some rough comparisons from GF100 to GT200 and RV870—and maybe estimate performance. We've got a clock estimate we're pretty confident in, and we've puts flags in the ground for the graphics-specific units, in terms of counts, so here goes nothing.

We'll consider Radeon HD 5870 for the RV870 implementation and the GeForce GTX 285 for the GT200 product. Obviously, GT200's SP rate is for MADD, since it doesn't have support for SP FMA.

http://img21.imageshack.us/img21/5937/catturait.png

The GF100's architecture means the SKU we've described (the GeForce GTX 380, possibly) comfortably outruns the GeForce GTX 285 in every way, to the point that (and we really generalize here, sorry) it should usually be at least twice as fast. Of course, you can engineer situations, usually in the middle of a frame, where the GF100 won't outpace the GT200 all that much, but in the main, it should be a solid improvement. The GF100 will outpace the Radeon HD 5870 as the top single-chip graphics product of all time, assuming AMD doesn't release anything else in the interim, between now and January. Look for the margins there to be a bit more slender, and we refer you to our Radeon HD 5870 review for the figures that'll let you imagine performance versus AMD's product.

http://techreport.com/articles.x/17815/4

Con quelle specifiche dovrebbe essere tra il 20% e il 30% più veloce di una HD5870.

[Judicator]

E poi andrebbe aggiunta una cosa: il test del tassellatore Unigine, a quanto pare, non si limita alla tasselazione, mi sembra che, parecchia geometria sia dislocata, quindi c'è un ulteriore carico per la GPU.

http://www.legitreviews.com/images/reviews/1117/unigine_dx9a.jpg
http://www.legitreviews.com/images/reviews/1117/unigine_dx11a_large.jpg

[leoneazzurro]

Non sono io che ho scritto l'articolo:

Rough performance estimates

Given everything we talked about above, we can start to draw some rough comparisons from GF100 to GT200 and RV870—and maybe estimate performance. We've got a clock estimate we're pretty confident in, and we've puts flags in the ground for the graphics-specific units, in terms of counts, so here goes nothing.

We'll consider Radeon HD 5870 for the RV870 implementation and the GeForce GTX 285 for the GT200 product. Obviously, GT200's SP rate is for MADD, since it doesn't have support for SP FMA.

http://img21.imageshack.us/img21/5937/catturait.png

The GF100's architecture means the SKU we've described (the GeForce GTX 380, possibly) comfortably outruns the GeForce GTX 285 in every way, to the point that (and we really generalize here, sorry) it should usually be at least twice as fast. Of course, you can engineer situations, usually in the middle of a frame, where the GF100 won't outpace the GT200 all that much, but in the main, it should be a solid improvement. The GF100 will outpace the Radeon HD 5870 as the top single-chip graphics product of all time, assuming AMD doesn't release anything else in the interim, between now and January. Look for the margins there to be a bit more slender, and we refer you to our Radeon HD 5870 review for the figures that'll let you imagine performance versus AMD's product.

http://techreport.com/articles.x/17815/4

E' proprio quello che non torna. In pratica dice in tutto l'articolo che le capacità teoriche di GF100 lo renderebbero due volte più veloce di una GTX285, ma dimentica di dire che se fosse per le capacità teoriche anche la 5870 sarebbe due volte più veloce di una HD4890 (90, non 70).
Insomma, è una risposta troppo "alla carlona", e non me lo aspetto da uno come Rys. Tralascia le limitazioni del setup (e GF100 a differenza di Cypress non sembra avere il doppio rasterizzatore), della banda (che non è il doppio della GTX285), del fillrate (che non è il doppio delle GTX285), senza contare che non solo non sappiamo nulla del texel fill rate, ma che anche con le CPU dell'anno prossimo schede come le 5970 e le GF100 rischiano di essere limitate in molti scenari dalla CPU.

[yossarian]

E' proprio quello che non torna. In pratica dice in tutto l'articolo che le capacità teoriche di GF100 lo renderebbero due volte più veloce di una GTX285, ma dimentica di dire che se fosse per le capacità teoriche anche la 5870 sarebbe due volte più veloce di una HD4890 (90, non 70).
Insomma, è una risposta troppo "alla carlona", e non me lo aspetto da uno come Rys. Tralascia le limitazioni del setup (e GF100 a differenza di Cypress non sembra avere il doppio rasterizzatore), della banda (che non è il doppio della GTX285), del fillrate (che non è il doppio delle GTX285), senza contare che non solo non sappiamo nulla del texel fill rate, ma che anche con le CPU dell'anno prossimo schede come le 5970 e le GF100 rischiano di essere limitate in molti scenari dalla CPU.

a me sembra un articolo del tipo: alcuni dati certi (quelli forniti da nVidia e riportati da tutti) e tante sue speculazioni (ad iniziare dalle frequenze, passando per l'emulazione del tessellator e per la sostituzione delle madd con le fma senza incontrare problemi e senza incorrere in hit prestazionali, per finire con le previsioni circa le prestazioni e il periodo di lancio). Insomma, "costruiamo il nostro fermi ideale" :sofico:
Io aspetterei notizie più precise da fonti ufficiali

[devAngnew]

e l'overhead per la compilazione e l'ottimizzazione dello shader non lo calcoli? O quelle sono gratis?


Ma se è 3 pagine di thread che dico che l'overhead è solo all'atto della compilazione e ho fatto pure l'esempio che ciò avvine quando viene caricato un livello di gioco in tal momento la gpu può compilare e ottimizzare lo shader.


La sostituzione o la fai prima o dopo non cambia nulla;


Ma vedi bene che la differenza c'è è come basta considerare la differenza tra un linguaggio che compila ed un altro che interpreta istruzione per istruzione.
il primo (compilato) è nettamente superiore ad uno interpretato.



se l'esecuzione inizia con n cicli di ritardo perchè si devono sosittuire le madd con fma hai lo stesso sprecato dei cicli. Cosa non ti torna? :rolleyes:

Si sprecano dei cicli durate il chaching dello shader ma cosa vuoi che importi ad un giocatore se inizia a giocare 1/2 secondo dopo aver caricato un livello di gioco.

[yossarian]

Ma se è 3 pagine di thread che dico che l'overhead è solo all'atto della compilazione e ho fatto pure l'esempio che ciò avvine quando viene caricato un livello di gioco in tal momento la gpu può compilare e ottimizzare lo shader.



Ma vedi bene che la differenza c'è è come basta considerare la differenza tra un linguaggio che compila ed un altro che interpreta istruzione per istruzione.
il primo (compilato) è nettamente superiore ad uno interpretato.




Si sprecano dei cicli durate il chaching dello shader ma cosa vuoi che importi ad un giocatore se inizia a giocare 1/2 secondo dopo aver caricato un livello di gioco.

quindi, secondo il tuo ragionamento, ci si ferma al frame iniziale. Ok, allora si gioca per un solo frame che parte in ritardo, ma tanto cosa importa al giocatore, e finisce dopo 1/60 di secondo. :sofico:
E quelli successivi? Quando vengono caricati? E quando viene fatta l'operazione di sostituzione? Sempre prima dell'inizio del frame? Magari prima dell'inizio del primo frame? Oppure per gli altri la sostituzione è gratis?
Interessante 'sta cosa :D
Ti sfugge che dati e istruzioni sono caricati di continuo una volta partita l'elaborazione e che ogni volta deve essere fatta l'operazione di sostituzione che fa perdere, comunque, cicli di clock, per cui non si può eseguire una madd alla massima velocità possibile?

[Athlon 64 3000+]

Qua hanno fatto con Dirt 2 un benchmark dove ci i test delle hd 5000 series(non la HD 5970) sulle dx9 e dx11 e il frame rate con quest'ultime attivate fa calare di non poco il frame rate.:confused:
http://www.pcgameshardware.com/aid,700050/Dirt-2-benchmarks-DX-9-vs-DX-11/Practice/

Spero di non essere andato troppo off topic.

[devAngnew]

quindi, secondo il tuo ragionamento, ci si ferma al frame iniziale. Ok, allora si gioca per un solo frame che parte in ritardo, ma tanto cosa importa al giocatore, e finisce dopo 1/60 di secondo. :sofico:
E quelli successivi? Quando vengono caricati? E quando viene fatta l'operazione di sostituzione? Sempre prima dell'inizio del frame? Magari prima dell'inizio del primo frame? Oppure per gli altri la sostituzione è gratis?
Interessante 'sta cosa :D
Ti sfugge che dati e istruzioni sono caricati di continuo una volta partita l'elaborazione e che ogni volta deve essere fatta l'operazione di sostituzione che fa perdere, comunque, cicli di clock, per cui non si può eseguire una madd alla massima velocità possibile?

Bha semmai i dati sono caricati di continuo ma il codice shader dovrebbe essere caricato prima di partire con il livello, altrimenti non ci sarebbe compilatore che tenga si ATI che NVIDIA.:read:

[yossarian]

Bha semmai i dati sono caricati ma il codice shader dovrebbe essere caricato prima di partire con il livello, altrimenti non ci sarebbe compilatore che tenga si ATI che NVIDIA.:read:

questa non l'ho capita; cosa intendi dire? Che la sostituzione avviene prima che si sappia quali istruzioni si devono elaborare? E dove avverrebbe? Il chip sa quali istruzioni deve eseguire solo dopo averle caricate e non ha modo di caricare tutti gli shader di un gioco nello stesso tempo e il compilatore ha bisogno di girare su qualcosa (non agisce al di fuori di un supporto fisico a meno che per compilatore non intendii un coder che si metta a fare la traduzione a manina di tutto il programma :D ). Il compilatore serve a istruire il chip su come riordinare ed eventualmente sostiture delle istruzioni ma solo dopo che il chip le ha incontrate. Ovvero il compilatore gli dice: guarda che quando trovi questo tipo di istruzione devi sostituirlo con quest'altra. Ma la condizione è che prima il chip incontri quell'istruzione e poi che la sostituisca. Altrimenti nisba. Non esiste un compilatore che "affidi al chip il codice originario già interamente ricompilato". Se fosse possibile caricare tutte le istruzioni relative ad un gioco sul chip e fosse possibile procedere al riordino delle stesse prima dell'inizio del rendering, i chip ATi avrebbero un rendimento prossimo al 100% e una 4850 sarebbe pari ad una 285 gtx in tutte le situazioni. Invece ci si deve acocntentare di quello che si riesca a caricare negli instruction buffer :p
L'unico modo per non avere overhead è che il codice originario faccia uso di fma invece che di madd. Gli shader che si trovano nei giochi hanno istruzioni di tipo madd e sono quelle che arrivano alla gpu e non le fma (ti sfugge questo piccolo particolare).
Comunque, sto ancora aspettando che mi linki un documento in cui si mostri come sia possibile questa operazione di sostituzione, magari senza issue o performance hit.

[devAngnew]

questa non l'ho capita; cosa intendi dire? Che la sostituzione avviene prima che si sappia quali istruzioni si devono elaborare? E dove avverrebbe? Il chip sa quali istruzioni deve eseguire solo dopo averle caricate e non ha modo di caricare tutti gli shader di un gioco nello stesso tempo e il compilatore ha bisogno di girare su qualcosa (non agisce al di fuori di un supporto fisico a meno che per compilatore non intendii un coder che si metta a fare la traduzione a manina di tutto il programma :D ). Il compilatore serve a istruire il chip su come riordinare ed eventualmente sostiture delle istruzioni ma solo dopo che il chip le ha incontrate. Ovvero il compilatore gli dice: guarda che quando trovi questo tipo di istruzione devi sostituirlo con quest'altra. Ma la condizione è che prima il chip incontri quell'istruzione e poi che la sostituisca. Altrimenti nisba. Non esiste un compilatore che "affidi al chip il codice originario già interamente ricompilato".
L'unico modo per non avere overhead è che il codice originario faccia uso di fma invece che di madd. Gli shader che si trovano nei giochi hanno istruzioni di tipo madd e sono quelle che arrivano alla gpu e non le fma (ti sfugge questo piccolo particolare).

:doh:
Ma secondo te uno shader scritto in HLSL o in GLSL viene eseguito cosi com'è dalla GPU al volo io dico di no...

[yossarian]

:doh:
Ma secondo te uno shader scritto in HLSL o in GLSL viene eseguito cosi com'è dalla GPU al volo io dico di no...

io dico che non hai capito niente di tutto il discorso.
Rileggiti tutto con calma

[appleroof]

Qua hanno fatto con Dirt 2 un benchmark dove ci i test delle hd 5000 series(non la HD 5970) sulle dx9 e dx11 e il frame rate con quest'ultime attivate fa calare di non poco il frame rate.:confused:
http://www.pcgameshardware.com/aid,700050/Dirt-2-benchmarks-DX-9-vs-DX-11/Practice/

Spero di non essere andato troppo off topic.

La mia "paura", nata in realtà solo dall'unigine che mostra una "tassellazione massiccia" è che queste prime vga dx11 non saranno in grado di gestire la nuova feature al massimo (e si che pure io avevo capito che tassellazione= sempre maggiore qualità a parità di prestazioni complessive, ma evidentemente ho capito male :( )

d'altra parte sarebbe sempre la solita storia, basta vedere le vga dx9 dove le prime si sognavano cmq le prestazioni delle ultime e pur sempre vga dx9 erano

cmq vedremo, ma ripeto, mi faccio poche illusioni


p.s.: cmq se è vero che g100 emulerà il tassellatore direi che giocoforza andrà peggio rispetto ad una vga con unità dedicata come rv 870 nei giochi con tassellazione, anche se nel complesso avrà più potenza di quest'ultimo....correggetemi se sbaglio.

[devAngnew]

io dico che non hai capito niente di tutto il discorso.
Rileggiti tutto con calma

Allora siamo in due....:sofico: :asd:
Io invece penso che forse ti sfugge qualcosa sui compilatori.... :asd: :asd: :asd:
E' risaputo che qualunque processore una volta compilato il codice originario ad alto livello (HLSL o GLSL) e ottimizzato lo esegue e basta che poi non è detto che il codice venga eseguito al massimo delle sue possibilità come nel caso ATi è quasi impossibile ottimizzare lo shader compilato di modo che vengano usate tutte e 5 le sue unità VLIW.

[Kharonte85]

La mia "paura", nata in realtà solo dall'unigine che mostra una "tassellazione massiccia" è che queste prime vga dx11 non saranno in grado di gestire la nuova feature al massimo (e si che pure io avevo capito che tassellazione= sempre maggiore qualità a parità di prestazioni complessive, ma evidentemente ho capito male :( )

eh sì...:asd:


p.s.: cmq se è vero che g100 emulerà il tassellatore direi che giocoforza andrà peggio rispetto ad una vga con unità dedicata come rv 870 nei giochi con tassellazione, anche se nel complesso avrà più potenza di quest'ultimo....correggetemi se sbaglio.
Senza dubbio peggio, ma se hai ragione nella prima parte difficilmente il tesselatore sarà sfruttato a questo giro se non nei soliti 2-3 giochi altamente sponsorizzati o come diceva qualcuno più indietro come lo "zafferano sul risotto".

[yossarian]

Allora siamo in due....:sofico: :asd:
Io invece penso che forse ti sfugge qualcosa sui compilatori.... :asd: :asd: :asd:
E' risaputo che qualunque processore una volta compilato il codice originario ad alto livello (HLSL o GLSL) e ottimizzato lo esegue e basta che poi non è detto che il codice venga eseguito al massimo delle sue possibilità come nel caso ATi è quasi impossibile ottimizzare lo shader compilato di modo che vengano usate tutte e 5 le sue unità VLIW.

allora spiega nel dettaglio come funziona la compilazione del codice ad alto livello e come il processore, una volta compilato il codice, esegue le istruzioni tenendo conto del flusso di istruzioni e non di quelle poche caricate nei registri interni del chip. E magari spiegaci anche perchè con ATi è impossibile ottimizzare lo shader (ma evidentemente lo è anche con nVidia visto che neppure gt200 raggiunge un rendimento del 100%). Infine, se come pare di capire dalle tue parole, una volta compilato il codice ad alto livello il chip ha a disposizione tutte le istruzioni del sw che deve far girare e può gestirlo a suo piacimento, spiegaci a cosa servono le operazioni di branching
Così vediamo chi non ha le idee chiare :D

[persa]

in effetti il tessellator sembrerebbe proprio una mazzata che aumenta si la qualità, ma poi ti toglie anche 20-30frames.

ora, immagino che sui giochi che ne faranno 80-70 si potrà utilizzarlo con frames di 50-60.. ma se esce un giocho che già senza fa 50-60 frames, addio tessellator.

[Kharonte85]

E' proprio quello che non torna. In pratica dice in tutto l'articolo che le capacità teoriche di GF100 lo renderebbero due volte più veloce di una GTX285, ma dimentica di dire che se fosse per le capacità teoriche anche la 5870 sarebbe due volte più veloce di una HD4890 (90, non 70).
Insomma, è una risposta troppo "alla carlona", e non me lo aspetto da uno come Rys. Tralascia le limitazioni del setup (e GF100 a differenza di Cypress non sembra avere il doppio rasterizzatore), della banda (che non è il doppio della GTX285), del fillrate (che non è il doppio delle GTX285), senza contare che non solo non sappiamo nulla del texel fill rate, ma che anche con le CPU dell'anno prossimo schede come le 5970 e le GF100 rischiano di essere limitate in molti scenari dalla CPU.

Forse voleva riferirsi a gt200 in configurazione doppia ovvero alla gtx 295, altrimenti il discorso del "doppio" della gtx 285 non ha senso alcuno (non ci sono nemmeno i numeri teorici) e su questo sono d'accordo...non è mai successo e mai succederà di avere un incremento del 100%, mentre invece è già successo che la dual GPU di generazione precedente venisse battuta dalla single GPU di generazione successiva.

[appleroof]

eh sì...:asd:


Senza dubbio peggio, ma se hai ragione nella prima parte difficilmente il tesselatore sarà sfruttato a questo giro se non nei soliti 2-3 giochi altamente sponsorizzati o come diceva qualcuno più indietro come lo "zafferano sul risotto".

già hai ragione...c'è da dire però che un motore che prevede la tassellazione potrebbe "regolarla" su vari livelli in modo da essere scalabile da questo punto di vista specifico,,,,vediamo :stordita:

[halduemilauno]

La mia "paura", nata in realtà solo dall'unigine che mostra una "tassellazione massiccia" è che queste prime vga dx11 non saranno in grado di gestire la nuova feature al massimo (e si che pure io avevo capito che tassellazione= sempre maggiore qualità a parità di prestazioni complessive, ma evidentemente ho capito male :( )

d'altra parte sarebbe sempre la solita storia, basta vedere le vga dx9 dove le prime si sognavano cmq le prestazioni delle ultime e pur sempre vga dx9 erano

cmq vedremo, ma ripeto, mi faccio poche illusioni


p.s.: cmq se è vero che g100 emulerà il tassellatore direi che giocoforza andrà peggio rispetto ad una vga con unità dedicata come rv 870 nei giochi con tassellazione, anche se nel complesso avrà più potenza di quest'ultimo....correggetemi se sbaglio.

la tessellazione va vista come un filtro se lo applichi, lo usi, ecco che l'immagine è migliore ma a scapito delle prestazioni. magari l'emulato non rende quanto l'altro sul piano della qualità ma rende meglio sul piano delle prestazioni quindi tocca vedere il rapporto qualità/prezzo ovvero decadimento prestazionale una volta applicato. ovviamente son solo ipotesi, tutte da verificare.
;)

[Kharonte85]

Con quelle specifiche dovrebbe essere tra il 20% e il 30% più veloce di una HD5870.
E' quello che mi aspetto anche io...ad Hemlock non ci arriva imho.
la tessellazione va vista come un filtro se lo applichi, lo usi, ecco che l'immagine è migliore ma a scapito delle prestazioni.

magari l'emulato non rende quanto l'altro sul piano della qualità ma rende meglio sul piano delle prestazioni quindi tocca vedere il rapporto qualità/prezzo ovvero decadimento prestazionale una volta applicato. ovviamente son solo ipotesi, tutte da verificare.
;)
Io direi piuttosato che probabilmente l'emulato rendebbe uguale come qualità ma perdebbe parecchio come prestazione...vuoi mettere avere un hardware dedicato che fa solo quello? Naa...anche ad essere molto molto ottimisti non ci si puo' sperare (se è vero che non c'è perchè non è ancora detto).

[RaZoR93]

la tessellazione va vista come un filtro se lo applichi, lo usi, ecco che l'immagine è migliore ma a scapito delle prestazioni. magari l'emulato non rende quanto l'altro sul piano della qualità ma rende meglio sul piano delle prestazioni quindi tocca vedere il rapporto qualità/prezzo ovvero decadimento prestazionale una volta applicato. ovviamente son solo ipotesi, tutte da verificare.
;)Com'è possibile che l'emulazione renda di più, in termini di performance, di hardware dedicato? A parità di qualità un chip con unità dedicate dovrebbe essere decisamente più prestante.

[persa]

Com'è possibile che l'emulazione renda di più, in termini di performance, di hardware dedicato? A parità di qualità un chip con unità dedicate dovrebbe essere decisamente più prestante.

magari l'emulato potrebbe competere come impatto prestazionale però con una qualità inferiore :boh:

[devAngnew]

allora spiega nel dettaglio come funziona la compilazione del codice ad alto livello e come il processore, una volta compilato il codice, esegue le istruzioni tenendo conto del flusso di istruzioni e non di quelle poche caricate nei registri interni del chip. E magari spiegaci anche perchè con ATi è impossibile ottimizzare lo shader (ma evidentemente lo è anche con nVidia visto che neppure gt200 raggiunge un rendimento del 100%).
Così vediamo chi non ha le idee chiare :D

Dura stà battaglia :asd: :asd: :asd:
Yossarian mi sà che dobbiamo aprire un nostro thread :sofico: :asd:
Ma perchè a te risulta che un programma compilato vengo memorizzato tutto nei registri di un processore a me no. Altrimente la memoria a che serve a solo a contenere dati.

[PConly92]

ragazzi scusate se mi intrometto. ma questo "mostro" quanto costera?
tenendo conto dell'area del chip e rese produttive sotto la media?:)
grazie
ps. speriamo non i soliti 600-650 euro di nvidia

[appleroof]

la tessellazione va vista come un filtro se lo applichi, lo usi, ecco che l'immagine è migliore ma a scapito delle prestazioni. magari l'emulato non rende quanto l'altro sul piano della qualità ma rende meglio sul piano delle prestazioni quindi tocca vedere il rapporto qualità/prezzo ovvero decadimento prestazionale una volta applicato. ovviamente son solo ipotesi, tutte da verificare.
;)

no aspetta Hal, sempre per parlare come giustamente sottolinei, il mio discorso partiva dalla considerazione che già rv870 in dirt2 con le dx11 pare calare di prestazioni (nell'unigine crolla letteralmente quasi della metà) pur avendo un'unità dedicata; se g100 dovesse emularle in dirt2, per forza andrebbe peggio....credo

non so se mi sono spiegato :D

[RaZoR93]

ragazzi scusate se mi intrometto. ma questo "mostro" quanto costera?
tenendo conto dell'area del chip e rese produttive sotto la media?:)
grazieNon si sa nulla per il momento. Ovviamente andrà ad inserirsi nel mercato in base alle performance che avrà in relazione alla concorrenza. Dovrebbe comunque essere un chip piuttosto costoso da produrre per nvidia.

[Kharonte85]

ragazzi scusate se mi intrometto. ma questo "mostro" quanto costera?
tenendo conto dell'area del chip e rese produttive sotto la media?:)
grazie
Non si sa, si presume che sarà un chip caro...poi il tutto dipenderà anche dalle prestazioni.

PS: vedendo quanto nvidia ha prezzato le tesla :eek: e se riesce a venderne quante ha in mente potrebbe pure regalarle :asd:

[halduemilauno]

E' quello che mi aspetto anche io...ad Hemlock non ci arriva imho.

Io direi piuttosato che probabilmente l'emulato rendebbe uguale come qualità ma perdebbe parecchio come prestazione...vuoi mettere avere un hardware dedicato che fa solo quello? Naa...anche ad essere molto molto ottimisti non ci si puo' sperare (se è vero che non c'è perchè non è ancora detto).

Com'è possibile che l'emulazione renda di più, in termini di performance, di hardware dedicato? A parità di qualità un chip con unità dedicate dovrebbe essere decisamente più prestante.

magari l'emulato potrebbe competere come impatto prestazionale però con una qualità inferiore :boh:

è quello che ho ipotizzato. ipotizzato perchè sono ipotesi in attesa di riscontri.

[persa]

cmq x il tessellator. a questo punto manca solo alien vs predator. vedremo come sarà implementato li... ma ho paura che ci sarà un calo notevole di frames, come è successo per stalkere unigine e dirt II (cmq ben giocabile su 5870 in full hd e filtri anche con questo effetto attivo)

[yossarian]

Dura stà battaglia :asd: :asd: :asd:
Yossarian mi sà che dobbiamo aprire un nostro thread :sofico: :asd:
Ma perchè a te risulta che un programma compilato vengo memorizzato tutto nei registri di un processore a me no. Altrimente la memoria a che serve a solo a contenere dati.

non c'è da aprire un bel niente e non è una battaglia: tu sostieni che il compilatore sia in grado di fare una volta per tutte il lavoro di traduzione del codice, per cui, tornando in topic, una volta caricato il primo frame GT300 ha già tutte le madd del sw trasformate in fma e non c'è overhead se non all'atto del caricamento del primo frame. Evidentemente a te risulta che tutto il programma venga memorizzato nei registri interni, perchè se così non fosse, il processore non avrebbe alcuna informazione su ciò che è immagazzinato nella memoria centrale o nella vram.
Poi, tiri in ballo i compilatori per i linguaggi ad alto livello che hanno la funzione principale di fare da interfaccia tra linguaggi strutturato e linguaggio macchina, ossia, man mano che arrivano le istruzioni, ad esempio, il hlsl, le traducono in linguaggio macchina (la cosa non è così immediata ma sto semplificando). E ancora non vedo in che modo possa avvenire la trasformazione simultanea di tutte le madd in fma.
Ti ho chiesto di spiegare in dettaglio come funziona un'elaborazione da parte di un chip e, soprattutto, come è gestito il flusso di dati (ma non mi pare di aver ottenuyto risposte). Ti ho chiesto per quale motivo, se le cose stanno come dici, i chip ATi, ma anche quelli nVidia, non raggiungono il 100% del loro potenziale di calcolo teorico (ma non hai risposto). Ti ho chiesto di linkarmi un solo documento in cui si dica che l'operazione di cui continui a parlare sia possibile e soprattutto che lo sia senza problemi e senza performance hit ma ti sei guardato bene dal farlo (forse perchè non ne esistono :D ).
A questo punto ti faccio una domanda secca: secondo te è possibile trasformare tutte la madd di un intero programma in fma in un solo passaggio all'atto del caricamento del primo frame di un gioco e se si come e dove avverrebbe questa trasformazione?

E' una domanda semplice che richiede una risposta altrettanto elementare e per nulla articolata (come vedi non serve un thread apposito) :D

[halduemilauno]

no aspetta Hal, sempre per parlare come giustamente sottolinei, il mio discorso partiva dalla considerazione che già rv870 in dirt2 con le dx11 pare calare di prestazioni (nell'unigine crolla letteralmente quasi della metà) pur avendo un'unità dedicata; se g100 dovesse emularle in dirt2, per forza andrebbe peggio....credo

non so se mi sono spiegato :D

ecco io quel per forza pur capendo cosa intendi posso immaginare invece un'altro scenario visto che lo emulo e quindi magari non lo raggiungo sul piano della qualità magari in compenso lo pago di meno in prestazioni.
capisci questo ipotetico altro modo di vedere le cose?
ripeto non lo si deve condividere perchè son tutte ipotesi, ma solo capire come ulteriore possibilità. non do nulla per scontato sto solo ipotizzando magari il tessellatore c'è identico alle 5000 e quindi cade tutto.
è chiaro ora cosa intendo?
ciao.
;)

[A.L.M.]

Non sono io che ho scritto l'articolo:


Ma infatti non ce l'ho mica con te. :)

E' proprio quello che non torna. In pratica dice in tutto l'articolo che le capacità teoriche di GF100 lo renderebbero due volte più veloce di una GTX285, ma dimentica di dire che se fosse per le capacità teoriche anche la 5870 sarebbe due volte più veloce di una HD4890 (90, non 70).
Insomma, è una risposta troppo "alla carlona", e non me lo aspetto da uno come Rys. Tralascia le limitazioni del setup (e GF100 a differenza di Cypress non sembra avere il doppio rasterizzatore), della banda (che non è il doppio della GTX285), del fillrate (che non è il doppio delle GTX285), senza contare che non solo non sappiamo nulla del texel fill rate, ma che anche con le CPU dell'anno prossimo schede come le 5970 e le GF100 rischiano di essere limitate in molti scenari dalla CPU.

E' esattamente quello che volevo dire. :)

non c'è da aprire un bel niente e non è una battaglia: tu sostieni che il compilatore sia in grado di fare una volta per tutte il lavoro di traduzione del codice, per cui, tornando in topic, una volta caricato il primo frame GT300 ha già tutte le madd del sw trasformate in fma e non c'è overhead se non all'atto del caricamento del primo frame. Evidentemente a te risulta che tutto il programma venga memorizzato nei registri interni, perchè se così non fosse, il processore non avrebbe alcuna informazione su ciò che è immagazzinato nella memoria centrale o nella vram.
Poi, tiri in ballo i compilatori per i linguaggi ad alto livello che hanno la funzione principale di fare da interfaccia tra linguaggi strutturato e linguaggio macchina, ossia, man mano che arrivano le istruzioni, ad esempio, il hlsl, le traducono in linguaggio macchina (la cosa non è così immediata ma sto semplificando). E ancora non vedo in che modo possa avvenire la trasformazione simultanea di tutte le madd in fma.
Ti ho chiesto di spiegare in dettaglio come funziona un'elaborazione da parte di un chip e, soprattutto, come è gestito il flusso di dati (ma non mi pare di aver ottenuyto risposte). Ti ho chiesto per quale motivo, se le cose stanno come dici, i chip ATi, ma anche quelli nVidia, non raggiungono il 100% del loro potenziale di calcolo teorico (ma non hai risposto). Ti ho chiesto di linkarmi un solo documento in cui si dica che l'operazione di cui continui a parlare sia possibile e soprattutto che lo sia senza problemi e senza performance hit ma ti sei guardato bene dal farlo (forse perchè non ne esistono :D ).
A questo punto ti faccio una domanda secca: secondo te è possibile trasformare tutte la madd di un intero programma in fma in un solo passaggio all'atto del caricamento del primo frame di un gioco e se si come e dove avverrebbe questa trasformazione?

E' una domanda semplice che richiede una risposta altrettanto elementare e per nulla articolata (come vedi non serve un thread apposito) :D

Grandi, ogni tanto su questi thread ci sono discussioni di livello.... :D
Secondo me però dovreste provare a parlarne a 3 con Rys su Beyond3D... :sofico:
Anche lui sostiene che l'operazione in questione sia "for free", ed io nella mia ignoranza non ci sto capendo più una mazza... :fagiano:

[okorop]

cmq x il tessellator. a questo punto manca solo alien vs predator. vedremo come sarà implementato li... ma ho paura che ci sarà un calo notevole di frames, come è successo per stalkere unigine e dirt II (cmq ben giocabile su 5870 in full hd e filtri anche con questo effetto attivo)

ma che cavolo ne sai scusa, il gioco esce il 4 dicembre :asd:

[A.L.M.]

ecco io quel per forza pur capendo cosa intendi posso immaginare invece un'altro scenario visto che lo emulo e quindi magari non lo raggiungo sul piano della qualità magari in compenso lo pago di meno in prestazioni.

Non credo sia possibile. La tessellation o la fai o non la fai. L'output deve essere lo stesso o quasi, altrimenti non avresti un hardware DX11 compliant.
Dunque se c'è in hw avrai un impatto percentuale x, se ce l'hai in sw avrai un impatto x+n. Per forza. Ovvio che se la scheda è molto potente potresti comunque ottenere prestazioni superiori alla concorrenza, ma percentualmente perderesti di più.

[yossarian]

Ma infatti non ce l'ho mica con te. :)



E' esattamente quello che volevo dire. :)



Grandi, ogni tanto su questi thread ci sono discussioni di livello.... :D
Secondo me però dovreste provare a parlarne a 3 con Rys su Beyond3D... :sofico:
Anche lui sostiene che l'operazione in questione sia "for free", ed io nella mia ignoranza non ci sto capendo più una mazza... :fagiano:

nessuna operazione è for free, ad essere pignoli (diciamo che si abusa molto del termine); ad esempio, di una comune madd si dice che sia eseguita in un solo ciclo e impegni 4 registri (quelli relativi ai tre operandio e quello col risultato finale dell'elaborazione) e si ritiene che la alu operi una moltiplicazione e, immediatamente dopo, un'addione: niente di più sbagliato :D . Una MUL o una ADD richiedono come minimo da 5 a 7 cicli ed è coinvolto almeno un registro temporaneo intermedio tra le due operazioni che serve a sincronizzare l'operazione di addizione. Che poi il tutto sia mascherato dal fatto che parte dell'alu sta terminando una elaborazione mentre l'altra sta iniziando la successiva è un altro paio di maniche. Se Rys intende che le operazioni di trasformazione possono in qualche modo e in parte essere mascherate può aver ragione, ma che richiedano cicli di clock aggiuntivi è una cosa certa.

[persa]

ma che cavolo ne sai scusa, il gioco esce il 4 dicembre :asd:

senti chi parla, quello che qualche pagina fa si disperava per le prestazioni pessime di fermi e che diceva che nvidia lascia il mercato gpu da gaming. anche in quel caso allora: "ma che cavolo ne sai scusa?"

:O

[pandyno]

Non credo sia possibile. La tessellation o la fai o non la fai. L'output deve essere lo stesso o quasi, altrimenti non avresti un hardware DX11 compliant.
Dunque se c'è in hw avrai un impatto percentuale x, se ce l'hai in sw avrai un impatto x+n. Per forza. Ovvio che se la scheda è molto potente potresti comunque ottenere prestazioni superiori alla concorrenza, ma percentualmente perderesti di più.

Di tutte le soluzioni ibride e native HW/SW viste fino in questo momento, non ce n'è stata una che ha convinto pienamente. Basta aspetto di vedere cosa si sono inventati ;)