Aspettando Fermi ......
-
hanno corretto il grafico
-
questa "news" nn dice nulla di più di quanto nn si sapesse già
oltretutto i bench anche ancora un velo di poca chiarezza sopra di loro che nn giova certamente a capire com'è fermi
prendendo per buone le prestazioni da urlo nn si considerano calore e consumi ma provando ad essere buoni e sorvolando su questioni nn proprio secondarie, l'incognita successiva è il prezzo se fosse davvero 600€ nn la comprerebbe nessuno (inteso come quantità significativa di persone
) o nvidia la vende sottocosto o la vedo comunque male per le vendite (se confermate le prestazioni e nn è un piccolo "se")sperando che sia un r600 firmato nvidia magari in futuro l'architettura si rivelerà per quello che si spera sia (che spero io sia
), qualcosa di valido e concorrenziale, se per caso nn lo fosse, bucando una seconda revisione e poi i 28nm... nn voglio pensare minimamente alle conseguenze! ! !Poi c'è da vedere l'incognita NI ma se ne riparla nel 2011
-
gianni1879 ha scritto:
hanno corretto il graficoA che cosa si riferisce?
-
Quei test, parlo di FarCray 2 danno risultati molto diversi dalla realtà!......è una cosa incredibile.....per quanto riguarda Heaven Benchmark cosi dice niente....magari sapendo i settaggi, si potrebbe fare un paragone...ma visto i risultati non reali della HD5870 con FarCray 2 si sono tenuti bene dal dirli.....
Ancora una volta, non è uscito niente di serio......
-
Veramente la rivale della 5870 è la 380...
Cmq è stato pubblicato il WhitePaper di GF100:
-
dj883u2 ha scritto:
A che cosa si riferisce?dovrebbero essere le presunte impostazioni fatte nel test nvdia dette da hwupgrade...
Volevo capire quanto faceva una hd5870 con quelle impostazioni con farcry2
-
gianni1879 ha scritto:
dovrebbero essere le presunte impostazioni fatte nel test nvdia dette da hwupgrade...Volevo capire quanto faceva una hd5870 con quelle impostazioni con farcry2
Fa 76 Frame con processore Core i7 920 portato a 3.0Ghz.....non rispecchiano la reale situazione....
Allora.....
Singola HD5870:
Singola HD5970:
A voi i commenti....il processore è anche a 3.0Ghz.....
-
c'è poco da commentare, mi sembra evidente che i risultati sono quantomeno di parte e falsati...
-
gianni1879 ha scritto:
c'è poco da commentare, mi sembra evidente che i risultati sono quantomeno di parte e falsati...Gianni, io ottengo quei risultati.....resto sconcertato per l'enorme differenza di punteggi......
-
dj883u2 ha scritto:
Fa 76 Frame con processore Core i7 920 portato a 3.0Ghz.....non rispecchiano la reale situazione....Allora.....
Singola HD5870:
Singola HD5970:
A voi i commenti....il processore è anche a 3.0Ghz.....
Il punto è che i risultati sono stati ricavati da un analogo sistema in redazione ad HW.... Imho o hanno ricevuto ordine di falsarli o c'è davvero qualcosa di strano (nn nei tuoi risultati ovviamente, cmq Nv30 in HW era una signor GPU quindi
)Cmq grafici di HW a parte sembra che con Tessellation ci sia un vero incremento delle prestazioni quello che mi chiedo e come possa essere possibile quando è stato inventato da ATI ed nelle architetture ATI è presente nn solo da R600 ma dalla 8500XT. Cioè che possa esser stato implementato meglio da Nvidia può essere plausibile ma quello che nn mi torna è come mai in AMD l'hanno implementato con il cavolo...
-
dj883u2 ha scritto:
Gianni, io ottengo quei risultati.....resto sconcertato per l'enorme differenza di punteggi......beh diciamo che è una pubblicità bella e buona, per far un pò calmare o esaltare alcuni utenti che attendevano nei giorni scorsi i risultati.
Indubbiamente Fermi sarà più performante di rv870 ma non sicuramente con tutta quella percentuale (ci sono screen dove si vede pure un 50% circa avanti).
-
nVidia vanterà le prestazioni, quanto di più nn è dato sapere ma è plausibile che nn saranno eclatanti
sulle altre caratteristiche tutto tace...
-
Come già stato in passato per altri articoli di quella redazione... anche questo è una gran presa per i fondelli per gli utenti finali. Lo dico e me ne assumo tutte le responsabilità del caso. Non è possibile una discrepanza di valori così elevati... è ridicola!
Io prima di riconferire parola su questa scheda aspetto test seri..magari fatti dalla nostra redazione! Vedremo...
Marco
-
mamma mia...sono rientrato da poco dal lavoro e guarda qui che bordello...
solita ondata di test inaffidabili a quanto pare...
ormai mi sono rassegnato...fermi saprò davvero come sarà quando ce l'avrò fra le mani...
-
due parole sul tessellator di nVIDIA
Faccio un copia incolla di quanto ho scritto su hwu
Il polymorph engine è un ibrido che prevede il tessellator vero e proprio in hardware e la sua parte programmabile eseguita dallo shader core. In pratica, nVIDIA ha scomposto la parte relativa alle operazioni geometriche della pipeline grafica, replicandone più volte gli elementi. Così, ogni gruppo di 128 alu ha un suo raster engine e ogni gruppo di 32 alu ha un suo tessellator dedicato.
Trova riscontro l'ipotesi che avevo fatto tempo fa sulla possiblità di avere un tessellator hardware. Come dicevo allora,s e qualcosa si può emulare questi sono hull e domain shader (ossia la parte programmabile), come avviene in RV770, mentre è del tutto controproducente farlo con il tessellator vero e proprio.
In pratica nVIDIA ha dotato ogni AP di un tessellator del tipo di quello visto per RV770 (ovviamente dimensionandolo al numero di alu che deve servire).
Vantaggi di questa soluzione sono la riduzione dell'ammontare di hardware dedicato e la possibilità di disattivare anche l'hw dedicato alle operazioni di tessellation quando si disabilitano SP.
Svantaggi: l'impatto sulle prestazioni è variabile e dipende da diversi fattori, ad iniziare dall'occuzione degli shader per finire con l'occupazione di banda tra shader core e polymorph engine. In questo caso, infatti, non si ha un flusso di dati che scorre in un solo verso, ma i vertici prelevati dallo stadio che fa vertex fetch passano allo shader core che svolge le funzioni tipiche degli hull shader, quindi tornano al polymorph engine per la tessellation, di nuovo alllo shader core per le operazioni di domain shading e, infine, al polymorph engine che prepara le operazioni di rasterizzazione. Questo complica ulteriormente la già complessa logica di controllo dei chip nVIDIA ma l'architettura con tessellator dedicato ad ogni SP dovrebbe ridurre l'impatto sulla banda passante tra polymorph engine e shader core (per essere più precisi si dovrebbero avere dati sulla capacità di trasferimento dati di quel canale).
-
yossarian ha scritto:
due parole sul tessellator di nVIDIAFaccio un copia incolla di quanto ho scritto su hwu
Il polymorph engine è un ibrido che prevede il tessellator vero e proprio in hardware e la sua parte programmabile eseguita dallo shader core. In pratica, nVIDIA ha scomposto la parte relativa alle operazioni geometriche della pipeline grafica, replicandone più volte gli elementi. Così, ogni gruppo di 128 alu ha un suo raster engine e ogni gruppo di 32 alu ha un suo tessellator dedicato.
Trova riscontro l'ipotesi che avevo fatto tempo fa sulla possiblità di avere un tessellator hardware. Come dicevo allora,s e qualcosa si può emulare questi sono hull e domain shader (ossia la parte programmabile), come avviene in RV770, mentre è del tutto controproducente farlo con il tessellator vero e proprio.
In pratica nVIDIA ha dotato ogni AP di un tessellator del tipo di quello visto per RV770 (ovviamente dimensionandolo al numero di alu che deve servire).
Vantaggi di questa soluzione sono la riduzione dell'ammontare di hardware dedicato e la possibilità di disattivare anche l'hw dedicato alle operazioni di tessellation quando si disabilitano SP.
Svantaggi: l'impatto sulle prestazioni è variabile e dipende da diversi fattori, ad iniziare dall'occuzione degli shader per finire con l'occupazione di banda tra shader core e polymorph engine. In questo caso, infatti, non si ha un flusso di dati che scorre in un solo verso, ma i vertici prelevati dallo stadio che fa vertex fetch passano allo shader core che svolge le funzioni tipiche degli hull shader, quindi tornano al polymorph engine per la tessellation, di nuovo alllo shader core per le operazioni di domain shading e, infine, al polymorph engine che prepara le operazioni di rasterizzazione. Questo complica ulteriormente la già complessa logica di controllo dei chip nVIDIA ma l'architettura con tessellator dedicato ad ogni SP dovrebbe ridurre l'impatto sulla banda passante tra polymorph engine e shader core (per essere più precisi si dovrebbero avere dati sulla capacità di trasferimento dati di quel canale).
E quindi ci dovrebbe stare tutto questo entusiasmo da gridare al "miracolo"??
-
sempre chiarissimo Stefano...
quindi da quello che dici si potrebbe intuire che l'implementazione di nvidia potrebbe dare prestazioni "entusiasmanti" con un titolo e "deludenti" con un'altro...o addirittura entrambi i casi nello stesso titolo...
-
quindi i test mostrati sono dei casi fortunati?
-
Rsdj ha scritto:
E quindi ci dovrebbe stare tutto questo entusiasmo da gridare al "miracolo"??non chiederlo a me
delly ha scritto:
sempre chiarissimo Stefano...
quindi da quello che dici si potrebbe intuire che l'implementazione di nvidia potrebbe dare prestazioni "entusiasmanti" con un titolo e "deludenti" con un'altro...o addirittura entrambi i casi nello stesso titolo...
facciamo un discorso un po' più ampio: fermi ha la possibilità di gestire 16 kernel (che non sono da intendersi come i kernel di un OS, ma come, più semplicemente, 16 gruppi di thread della stessa applicazione).
Il tessellator è frazionato in 16 unità. Mettendo a sistema queste due cose, è possibile che, in un'applicazione in cui serva il tessellator, alcuni SP svolgano funzioni di tessellation e altri si occupino della grafica. Questo significa che, sulla carta. è possibile avere un tessellator che ha una capacità di calcolo minima pari a quella del singolo SP e massima pari alla somma di quelli dei 16 SP. Quindi, possiamo definirlo "modulabile". Ovviamente, quello o quegli SP che stanno lavorando sulle operazioni di tessellation non possono essere impiegati per fare altro.
Questo significa che mentre quello di ATi può risultare a volte sottodimensionato e altre volte sovradimensionato ma lavora sempre con HW dedicato, quello di nVIDIA è in grado di dare potenza quando serve ma questa potenza la sottrae ad altri tipi di operazioni. Discorso analogo a quanto visto per physx, in parole povere.
-
yossarian ha scritto:
facciamo un discorso un po' più ampio: fermi ha la possibilità di gestire 16 kernel (che non sono da intendersi come i kernel di un OS, ma come, più semplicemente, 16 gruppi di thread della stessa applicazione).
Il tessellator è frazionato in 16 unità. Mettendo a sistema queste due cose, è possibile che, in un'applicazione in cui serva il tessellator, alcuni SP svolgano funzioni di tessellation e altri si occupino della grafica. Questo significa che, sulla carta. è possibile avere un tessellator che ha una capacità di calcolo minima pari a quella del singolo SP e massima pari alla somma di quelli dei 16 SP. Quindi, possiamo definirlo "modulabile". Ovviamente, quello o quegli SP che stanno lavorando sulle operazioni di tessellation non possono essere impiegati per fare altro.
Questo significa che mentre quello di ATi può risultare a volte sottodimensionato e altre volte sovradimensionato ma lavora sempre con HW dedicato, quello di nVIDIA è in grado di dare potenza quando serve ma questa potenza la sottrae ad altri tipi di operazioni. Discorso analogo a quanto visto per physx, in parole povere.
chiarissimo...mille grazie...
Ciao! Sembra che tu sia interessato a questa conversazione, ma non hai ancora un account.
Stanco di dover scorrere gli stessi post a ogni visita? Quando registri un account, tornerai sempre esattamente dove eri rimasto e potrai scegliere di essere avvisato delle nuove risposte (tramite email o notifica push). Potrai anche salvare segnalibri e votare i post per mostrare il tuo apprezzamento agli altri membri della comunità.
Con il tuo contributo, questo post potrebbe essere ancora migliore 💗
Registrati Accedi