[THREAD UFFICIALE] Aspettando Nvidia GTX 480 e GTX 470

[Kharonte85]

Originariamente inviato da veltosaar

'innovazione per essere sostenibile ed efficiente dovrebbe quantomeno raddoppiare le prestazioni aumentando meno che proporzionalmente i consumi.

Siccome si è arrivati ad un punto (250w solo per una scheda video è quasi come la lavatrice) di non ritorno, ora l'innovazione deve essere più che sostenibile.

Cioè raddoppiare le prestazioni mantenendo i consumi almeno uguali se non minori. Ed è questa la sfida. Ed è questo il perchè si va a ridurre il processo produttivo.

Teoricamente dovrebbe essere così, praticamente invece si hanno incrementi del 50% circa a prezzo di una leggera diminuzione o un pareggio o un leggero aumento dei cosumi.

La cosa preoccupante è che prima o poi (e io temo che i primi segnali già ci siano) la pacchia del passaggio al pp inferiore diverrà molto difficoltosa...a quel punto sarà difficile inventarsi un nuovo modo per diminuire consumi e aumentare le prestazioni.

Originariamente inviato da veltosaar

Non si capisce allora il perchè di queste lunghezze esagerate.

Io con un thermaltake element G che è al top per i middle tower potrei aver problemi con una scheda sui 30 cm ed oltre. Ed è assurdo.

In questo caso prendono piede dei case da 50 euro ma full tower contro i case da 150 euro middle tower.

Bah!

Le lunghezze sono un discorso differente, è chiaro che la 5970 paga il fatto di essere una dual GPU sullo stesso pcb (è proprio una questione di spazio/complessità) mentre per ora nvidia non ha più aumentato le dimensioni delle proprie schede sin dall'uscita di G80...

[veltosaar]

Originariamente inviato da Kharonte85

Le lunghezze sono un discorso differente, è chiaro che la 5970 paga il fatto di essere una dual GPU sullo stesso pcb (è proprio una questione di spazio/complessità) mentre per ora nvidia non ha più aumentato le dimensioni delle proprie schede sin dall'uscita di G80...

Si ma la gtx295 single pcb è lunga come la 285 ed ha 2 gpu. Non solo, è anche a 55nm! contro i 40 nm della 5970.

Vabbè, speriamo che la futura gtx380 sia almeno 27\28. Sennò perdono di senso.

In questo le cpu invece fanno da maestre. Aumentano i core nello stesse dimensioni e con consumi sempre simili.

[Milotto]

Originariamente inviato da Ratatosk

Più che altro mi chiedo perché NV30 sia stato la cagata pazzesca (cit.) che è stato se era possibile fare questa semplice magia...

Il grande limite di NV30 era la precisione di calcolo con la quale venivano eseguiti li shader.. FP16 o FP32 , mentre la controparte ATI con l'architettura R300 eseguiva in FP24 bit (scelta più saggia e "comoda" per la potenza di allora)..
Da un certo punto di vista NV30 era avanti: disponeva dello SM 3.0 poi adottato all'unanimità...

[MetalPonch]

Piu che altro a mio parere si dovrebbero ricercare nuove tecnologie non tanto per diminuire i consumi ma piu che altro per limitare lo spreco energetico...pensate a quando la scheda arriva 80°C oppure a tutto il calore emanato dalle componenti cpu vga e psu su tutte:
bene tutto quel calore è energia letteralmente buttata nel cesso xké allo stato attuale non è possibile riutilizzarla.
Se tutto quel calore invece di essere buttato fuori dal case potesse essere recuperato e riutilizzato per alimentare altre componenti o parte delle stesse da cui proviene,sarebbe un grande passo avanti.
Quindi per il futuro al di là delle performance credo ke le varie industrie sia di componenti ke di altro,dovrebbero puntare piu sull'ottimizzazione energetica.
Tanto oggi avere un sistema ke fa 100fps invece ke 120 non cambia né la vita né il piacere di gioco/esperienza
ma avere un sistema ke in full consuma 450w contro uno ke se ne succhia 600 la cambia e come...

[appleroof]

Originariamente inviato da Kharonte85

cut
E' praticamente certo che le dimensioni saranno identiche alle gtx 280 &co, ricordo per l'ennesima volta che il TDP della gtx 280 era ben 236W e il chip @65nm vantava una superficie maggiore quindi niente fa pensare che vedremo schede più lunghe, sezioni di alimentazioni mai viste e/o con dissipatori diversi da quelli visti sino ad ora

quoto, non dimentichiamo poi che come sappiamo quel tdp massimo si raggiunge molto raramente, è difficile che sia raggiunto fuori da bench/sw appositi e quindi neanche in game..

io spero sia lunga quanto gtx280

[Jackaos]

Originariamente inviato da MetalPonch

Piu che altro a mio parere si dovrebbero ricercare nuove tecnologie non tanto per diminuire i consumi ma piu che altro per limitare lo spreco energetico...pensate a quando la scheda arriva 80°C oppure a tutto il calore emanato dalle componenti cpu vga e psu su tutte:
bene tutto quel calore è energia letteralmente buttata nel cesso xké allo stato attuale non è possibile riutilizzarla.
Se tutto quel calore invece di essere buttato fuori dal case potesse essere recuperato e riutilizzato cut

Ho il case posizionato in modo che l'aria vada a raccogliersi nell'angolo della stanza dove sto io, non accendo il termosifone, la mia 4870x2 fa un bel caldino , quando gioco il gatto si mette dietro al pc .

[Kharonte85]

Originariamente inviato da appleroof

quoto, non dimentichiamo poi che come sappiamo quel tdp massimo si raggiunge molto raramente, è difficile che sia raggiunto fuori da bench/sw appositi e quindi neanche in game..

io spero sia lunga quanto gtx280

Nvidia praticamente lo ha semi-ufficialmente dichiarato in tre modi: Presentando le tesla, facendo vedere quella foto di gf100 che esegue il benchmark e dicendo esplicitamente che la lunghezza della scheda è identica a quella della serie GTX 2xx

[Kharonte85]

Originariamente inviato da MetalPonch

Piu che altro a mio parere si dovrebbero ricercare nuove tecnologie non tanto per diminuire i consumi ma piu che altro per limitare lo spreco energetico...pensate a quando la scheda arriva 80°C oppure a tutto il calore emanato dalle componenti cpu vga e psu su tutte:
bene tutto quel calore è energia letteralmente buttata nel cesso xké allo stato attuale non è possibile riutilizzarla.
Se tutto quel calore invece di essere buttato fuori dal case potesse essere recuperato e riutilizzato per alimentare altre componenti o parte delle stesse da cui proviene,sarebbe un grande passo avanti.
Quindi per il futuro al di là delle performance credo ke le varie industrie sia di componenti ke di altro,dovrebbero puntare piu sull'ottimizzazione energetica.
Tanto oggi avere un sistema ke fa 100fps invece ke 120 non cambia né la vita né il piacere di gioco/esperienza
ma avere un sistema ke in full consuma 450w contro uno ke se ne succhia 600 la cambia e come...

Sarebbe la cosa da fare, ma che non verrà fatta perchè studiare meccanismi che riciclino l'energia dissipata è più dispendioso che disperderla (poi bisognerebbe stare attenti che l'energia necessaria a costruire il "sistema ricicla energia" non sia superiore all'energia dissipata altrimenti è tutto inutile).

[leoneazzurro]

Originariamente inviato da Milotto

Il grande limite di NV30 era la precisione di calcolo con la quale venivano eseguiti li shader.. FP16 o FP32 , mentre la controparte ATI con l'architettura R300 eseguiva in FP24 bit (scelta più saggia e "comoda" per la potenza di allora)..
Da un certo punto di vista NV30 era avanti: disponeva dello SM 3.0 poi adottato all'unanimità...

Quello era NV40 (la serie 6). La NV30 disponeva del 2.0a (un superset del 2.0)

[skizzo99999999]

Originariamente inviato da leoneazzurro

Uhm... ho lasciato perdere questa discussione per un po´e ne é venuto su un flame mica da poco. La questione comunque é abbastanza di lana caprina: come si era detto giá da tempo, il codice ad alto livello viene "compilato" ma non restituisce direttamente il codice macchina della GPU, questo perché le API sono "agnostiche" rispetto all´hardware. In pratica é come se le DirectX fossero una "macchina virtuale" con un proprio linguaggio macchina, e la compilazione dell´applicazione richiama proprio le funzioni di questa macchina virtuale nel linguaggio macchina non della GPU, ma della macchina virtuale stessa. Lo strato di astrazione hardware (HAL) serve appunto allo scopo di interfacciare lo "strato" dell´API con lo "strato" del driver. Il driver riceve le chiamate da parte dell´API "tradotte" attraverso l´HAL ed invia i comandi alla GPU.
Il driver "gira" sia sulla CPU che sulla GPU, dato che interfaccia il SO (gestito dalla CPU) con la periferica "scheda video" (gestita dalla GPU). All´interno del driver c´é un ulteriore "compilatore" che traduce le chiamate dell´HAL nel linguaggio macchina della GPU e si occupa di un primo livello di ottimizzazione. Le operazioni di shader replacement, se presenti, si fanno a questo livello e anche la conversione di MADD in FMA potrebbe essere svolta tranquillamente a questo livello e probabilmente sará cosí. Poi, nella GPU, viene eseguito anche un secondo livello di ottimizzazione gestito dal thread processor.

non mi sembra così veniale sottolineare il fatto che gli shader vengano compilati nel driver (e quindi una sola volta) invece che la GPU debba interpretare al volo un codice "standard". Prestazionalmente parlando la differenza sarebbe abissale. Poi è ovvio che mica tutto si può fare al livello di compilazione (come più volte ho sottolineato), ed è quello che tu chiami secondo livello di ottimizzazione, in cui però il codice non è che viene cambiato (è già codice macchina e quello rimane, quello che si poteva fare è già stato fatto) ma viene esaminato il flusso di istruzioni con relativi salti condizionali, eventuali istruzioni indipendenti e che quindi possono essere eseguite in contemporanea, ecc, il tutto per cercare di eseguire quel codice in minor tempo possibile, ma il codice sempre quello rimane.
Se mi posso permettere un piccolo appunto, il codice ad alto livello delle directx (HLSL) viene si compilato in due fasi, mentre nelle opengl il rispettivo codice al alto livello (GLSL) arriva al driver direttamente sottoforma di sorgente, quindi senza passaggi intermedi. La sostanza non cambia molto, perchè prima di arrivare in esecuzione alla GPU entrambi (ovviamente) sono già compilati e pronti per essere eseguiti, ma l'efficienza che può avere un compilatore che esamina un sorgente è sicuramente un po' superirore a quella che può avere esaminando un codice già passato dal HLSL translator.

Spero che visto anche il tuo intervento, di sta cosa non se ne parli più.

Originariamente inviato da Ratatosk

Più che altro mi chiedo perché NV30 sia stato la cagata pazzesca (cit.) che è stato se era possibile fare questa semplice magia...

Quello era un problema differente, e parlarne senza entrare in tecnicismi ovviamente difficili da far comprendere se non inseriti in una spiegazione ampia e giocoforza lunga e pesante è molto difficile. Cercando di rimanere sul vago, il problema era che NV30 non era stato pensato per alcune delle caratteristiche richieste dalle nuove versioni delle api; addirittura supportava un linguaggio di shading che non era ne GLSL ne HLSL, ma il cg. Per cui se per esempio le directx versione x hanno introdotto una operazione y che una GPU progettata "ad hoc" eseguiva in z passi, NV30 che non era stato pensato per e quindi velocizzare l'operazione y (che prima era magari opzionale, ma ora è richiesta per risultare conforme), si ritrova ad dover giocoforza eseguire questa operazione in z+n passi sempre che la riesca a fare. Evidentemente per i giochi di quel periodo il numero di operazioni "y" era sufficientemente elevato da affossare le prestazioni della GPU. Per doom3, che dai discorsi letti qui funzionava meglio di altri su NV30, probabilmente sono stati scelti algoritmi per il rendering che comportavano un utilizzo minore di queste operazioni penalizzanti. Che poi sia stata una cosa "mazzettata" o casuale non saprei...

[DukeIT]

Originariamente inviato da Kharonte85

Sarebbe la cosa da fare, ma che non verrà fatta perchè studiare meccanismi che riciclino l'energia dissipata è più dispendioso che disperderla (poi bisognerebbe stare attenti che l'energia necessaria a costruire il "sistema ricicla energia" non sia superiore all'energia dissipata altrimenti è tutto inutile).

Rimango sempre dell'opinione che il più grande risparmio energetico lo si avrebbe con l'ottimizzazione "lato software" e che il trend attuale sia utile solo alle case produttrici di HW.
Basta vedere le consolle, o addirittura i vecchi Commodore; ovvio che il confronto è improponibile rispetto ai giochi attuali, ma se uno và a vedere quale potenza avessero i vecchi C64 od Amiga, resta allibito.

[halduemilauno]

Originariamente inviato da skizzo99999999

non mi sembra così veniale sottolineare il fatto che gli shader vengano compilati nel driver (e quindi una sola volta) invece che la GPU debba interpretare al volo un codice "standard". Prestazionalmente parlando la differenza sarebbe abissale. Poi è ovvio che mica tutto si può fare al livello di compilazione (come più volte ho sottolineato), ed è quello che tu chiami secondo livello di ottimizzazione, in cui però il codice non è che viene cambiato (è già codice macchina e quello rimane, quello che si poteva fare è già stato fatto) ma viene esaminato il flusso di istruzioni con relativi salti condizionali, eventuali istruzioni indipendenti e che quindi possono essere eseguite in contemporanea, ecc, il tutto per cercare di eseguire quel codice in minor tempo possibile, ma il codice sempre quello rimane.
Se mi posso permettere un piccolo appunto, il codice ad alto livello delle directx (HLSL) viene si compilato in due fasi, mentre nelle opengl il rispettivo codice al alto livello (GLSL) arriva al driver direttamente sottoforma di sorgente, quindi senza passaggi intermedi. La sostanza non cambia molto, perchè prima di arrivare in esecuzione alla GPU entrambi (ovviamente) sono già compilati e pronti per essere eseguiti, ma l'efficienza che può avere un compilatore che esamina un sorgente è sicuramente un po' superirore a quella che può avere esaminando un codice già passato dal HLSL translator.

Spero che visto anche il tuo intervento, di sta cosa non se ne parli più.



Quello era un problema differente, e parlarne senza entrare in tecnicismi ovviamente difficili da far comprendere se non inseriti in una spiegazione ampia e giocoforza lunga e pesante è molto difficile. Cercando di rimanere sul vago, il problema era che NV30 non era stato pensato per alcune delle caratteristiche richieste dalle nuove versioni delle api; addirittura supportava un linguaggio di shading che non era ne GLSL ne HLSL, ma il cg. Per cui se per esempio le directx versione x hanno introdotto una operazione y che una GPU progettata "ad hoc" eseguiva in z passi, NV30 che non era stato pensato per e quindi velocizzare l'operazione y (che prima era magari opzionale, ma ora è richiesta per risultare conforme), si ritrova ad dover giocoforza eseguire questa operazione in z+n passi sempre che la riesca a fare. Evidentemente per i giochi di quel periodo il numero di operazioni "y" era sufficientemente elevato da affossare le prestazioni della GPU. Per doom3, che dai discorsi letti qui funzionava meglio di altri su NV30, probabilmente sono stati scelti algoritmi per il rendering che comportavano un utilizzo minore di queste operazioni penalizzanti. Che poi sia stata una cosa "mazzettata" o casuale non saprei...

il grande problema dell'NV30 era il bus a 128 bit(ultima gpu top di gamma ad adottarlo). poi venivano quelli ora detti da te.

[Legolas84]

Novità sulla commercializzazione della 380?

[Bastoner]

Originariamente inviato da Legolas84

Novità sulla commercializzazione della 380?

E' in arrivo nei negozi






Nessuna novità

[Severnaya]

Originariamente inviato da halduemilauno

il grande problema dell'NV30 era il bus a 128 bit(ultima gpu top di gamma ad adottarlo). poi venivano quelli ora detti da te.

come "poi"?

[skizzo99999999]

Originariamente inviato da Ratatosk

A questo punto resta quindi solo da capire se applicare delle FMA al posto delle MADD funziona oppure gli errori introdotti possono essere distruttivi a tal punto da renderlo impossibile, nel qual caso l'unica alternativa è farsi le MADD in due passi. Giusto?

Penso proprio di si. A dire il vero mi è venuto in mente un possibile problema che forse impedisce (proprio a causa dell'arrotondamento) la trasformazione MADD-FMA. Non mi sembra concettualmente complicatissimo da far capire (ma lo pensavo anche per il compilatore...), ma sarebbe comunque un discorso fine a se stesso. Se a qualcuno interessa ci posso provare

[skizzo99999999]

Originariamente inviato da halduemilauno

il grande problema dell'NV30 era il bus a 128 bit(ultima gpu top di gamma ad adottarlo). poi venivano quelli ora detti da te.

C'è da dire che i 2 tipi di "problemi" possono essere legati. La banda passante incide sulla quantità di "dati" che la GPU può caricare/scaricare per ogni frame. Se gli algoritmi usati per il rendering diventano sempre + complessi (grazie alle architetture programmabili e relativi linguaggi di shading), aumentano le operazioni da eseguire e quindi i relativi trasferimenti da e verso la memoria. Se il tipo di operazioni che NV30 richiedeva come "rimpiazzi" generavano un ulteriore appesantimento di questi trasferimenti, allora può essere che il limite della banda sia stato raggiunto + velocemente di quanto ipotizzato in fase di progetto, e che questo abbia causato un ulteriore degrado delle performance

[persa]

Originariamente inviato da appleroof

appunto ma la 5970 non ci va

ma forse nel CM690 II ci andrà. fotina http://www.coolermaster.com/upload/360/RC-690K_360.swf

[Maury]

è calato il silenzio su Fermi, se ne riparla a marzo dell'anno prossimo mi sa

[eXeS]

Originariamente inviato da Ratatosk

Ah ecco, invece di essere un'operazione diversa ma concettualmente simile (MADD vs FMA) erano operazionei del tutto diverse.

A questo punto resta quindi solo da capire se applicare delle FMA al posto delle MADD funziona oppure gli errori introdotti possono essere distruttivi a tal punto da renderlo impossibile, nel qual caso l'unica alternativa è farsi le MADD in due passi. Giusto?

Più che parlare di errori introdotti sarebbe corretto parlare di errori mancanti, e bo, mi sembra così assurdo che una operazione (FMA) che produce risultati più precisi in tempi più rapidi, sia meno preferibile a due operazioni che producono lo stesso risultato (MUL-ADD) in tempi più lunghi.

Certo, il colore del pixel risultante usando FMA al posto di MADD (MUL-ADD) potrebbe essere diverso, ma approssimerà meglio quello che avrebbe dovuto essere il vero colore finale.