Aspettando Fermi ......
-
nick.sf ha scritto:
In che senso non credi che lo faranno uscire con quelle frequenze?pensi che riescano a salirle o pensi che dato lo stato attuale quelle frequenze sono già alte?
io sul fattore frequenze sono abbastanza confuso, non so piu che aspettarmi!:cheazz:
Penso che intende che non può uscire con le frequenze delle Tesla perchè sarebbero troppo basse...
yossarian ha scritto:
posso fare il vago ma non fno a questo punto
Ok ho capito... il fatto è che ho una scommessa in corso... se GF100 non suopererà più del 10% la 5870 mi ritroverò con un bel crossfire di 5970. Almeno un piccolissimo accenno tanto per mandarmi al letto contento??
Prendiamo come esempio che GF100 avrà frequenze di 648/1692/4200, di quanto riuscirà a superare la 5870??
p.s: scherzo, ovviamente se puoi
-
Capito, quindi ci toccherà aspettare ancora un po di tempo, penso che almeno 1 mese e mezzo ci vorrà prima di sapere qualche altra notizia "attendibile" dai partner nvidia!!!
-
nick.sf ha scritto:
Capito, quindi ci toccherà aspettare ancora un po di tempo, penso che almeno 1 mese e mezzo ci vorrà prima di sapere qualche altra notizia "attendibile" dai partner nvidia!!!Beh se sarà presentata il 10 marzo qualcosa di attendibile dovremmo saperlo tra un mesetto... di solito un mese prima del lancio già si sapeva tutto, anche se non in maniera ufficiale ma era come se lo fosse
-
Volevo soffermarmi a fare delle riflessioni un pò oltre a quanto descritto finora, e vorrei che mi diceste ciò che ne pensate
Se pensiamo ed immaginiamo l'obiettivo che nVidia si è prefissato con Fermi essere esclusivamente o anche solo primariamente quello dell'ambito videoludico, ci stanno tutte le giuste riflessioni fatte finora, inerentemente gli eventuali errori, di valutazione e non, che fuori dubbio nVidia avrebbe commesso sinora se si conderano limitatamnte nell'ottica dell'intrattenimento di gioco.
Vi invito a riflettere sulle caratteristiche peculiari che questa nuova architettura dovrebbe mettere a disposizione, e lascerò quindi a voi le considerazioni su quale potrebbe essere il reale target di nVidia, che imo essendo peraltro di tutt'altra natura rispetto al semplice videogioco, potrebbe anche più facilmente spiegare la relativa mancanza di fretta o di impazienza finora palesata in questa situazione di palese (per noi) empasse, in quanto allo stato attuale, sarebbe in assoluta mancanza di un vero competitor.
1) - Un set di istruzioni completamente nuovo,
molto più simile all'architettura register/register RISC (detta anche load/store) in cui le istruzioni aritmetico-logiche lavorano solo sui registri, rendendo il codice più efficiente (dovuto primariamente alla lunghezza costante delle istruzioni) con molte istruzioni elementari, facilitando il compito delle pipeline e rendendo possibile un'esecuzione completamente parallela.
2) - Istruzioni di tipo Faster Atomic di supporto ai task
Istruzioni di questo tipo leggono da locazioni di memoria condivisa, ne controllano i valori e ne scrivono di nuovi senza che nessun altro processore sia capace di modificarne i relativi valori durante le singole esecuzioni. Questo permette ai task di comunicare gli uni con gli altri tramite degli opportuni bit o flag, come vogliamo chiamarli. La cache L2 di Fermi, dove questi valori verranno prevalentemente memorizzati, renderà una sensibile accelerazione supplementare.
3) - Spazio di indirizzamento virtuale a 64bit
Il PTX (Parallel Thread eXecution layer) permetterebbe a Fermi di cambiare dalla modalità di indirizzamento a 32bit a quella a 64bit senza una negativa e deleteria interruzione di tipo software.
4) - Caches
Fermi include una caratteristica interessante per ottenere più valore dalla cache L1, cioè quella di poterne dividere il quantitativo di 64 KB o come una cache di 48 KB e 16 KB locali, o una cache da 16 KB e 48 KB locali.
Ritengo che ciò possa essere stato congegnato per consentire così al software di avere il controllo esplicito di una parte della cache, in quanto potrebbe enormemente semplificarne la programmazione, migliorandone le prestazioni e anche l'efficienza energetica della GPU stessa.
5) - Codice di Correzione di errore sia sulla memoria principale che su quella cache.
Ritengo che sia inutile spiegarne sia i concetti, i vantaggi e gli ambiti di applicazione nell'ottica di cui sopra.
6) - Formato di memoria realmente in virgola mobile a 16bit ed il supporto per i numeri de-normalizzati direttamente in hardware.
Questo consentirebbe di effettuare davvero tutti i calcoli in singola precisione.
7) - Spazio di indirizzi unificato
Nel passato le GPU avevano una varietà di diversi tipi di memorie (la memoria locale, la memoria grafica, e la memoria di sistema), ciascuna nel proprio spazio di indirizzamento. Questa tipologia di frazionamento rende problematico l'accesso a qualsiasi porzione di dati in memoria tramite i linguaggi di programmazione che si basano su puntatori come ad esempio C++, C e CUDA.
Fermi dovrebbe risolvere il problema di utilizzo di queste memorie separate (la memoria locale, la memoria grafica, e la memoria di sistema) raggruppandole in un unico spazio di indirizzamento a 64-bit, rendendo così molto più facile il compito di compilare ed eseguire programmi C, C++. facilitato anche dall'attivazione del meccanismo PTX in quanto, così come la cache, uno spazio unitario di indirizzi aumenta l'efficienza dei tipi di programmi che possono essere eseguiti ancora più efficeintemente sulle GPU.
- Fast Context SwitchingFinora siamo stati abituati acché i coprocessori, come le GPU, abbiano ignorato il context switching (cambiamento di contesto), proprio perchè il loro obiettivo primario era si, quello di accelerare i programmi, ma semplicemente uno alla volta.
Con Fermi la situazione dovrebbe cambiare radicalmente, in quanto il context-switching ha frequenza di soltanto ~25 microsecondi,
accelerando così notevolmente il cambiamento del contesto.
Ciò starebbe a significare che in pratica si potrà ottenere una più efficiente utilizzazione in alcuni ambienti, in quanto questa feature consentirà ai programmi di essere eseguiti meglio e più velocemente rendendo possibile e consentendo ad un utilizzo kernel-indipendente di sovrapporre la propria esecuzione: a.e. lasciando che uno effettui dei calcoli mentre un altro inizi una comunicazione.
9) - Supporto al Debugging
Il supporto al debug nelle precedenti GPU faceva si che avvenisse il congelamento dell'intero stato della GPU stessa.
Avveniva infatti che per consentire al debugger in CPU di leggere e scrivere i registri del thread della GPU, lo stato del thread, e la memoria della GPU attraverso il collegamento tra la memoria di sistema e quella della GPU. Solamente dopo il debugger in CPU permetteva di riprendere regolarmente l'esecuzione del thread della GPU.
In FERMI tutto ciò dovrebbe avvenire direttamente in GPU ed il proprio debugger dovrebbe poter anche colloquiare con quello della CPU e quindi interagire finanche con le chiamate di sistema.
Attendo vostri riscontri di qualsiasi genere
-
Totocellux ha scritto:
Volevo soffermarmi a fare delle riflessioni un pò oltre a quanto descritto finora, e vorrei che mi diceste ciò che ne pensate
Se pensiamo ed immaginiamo l'obiettivo che nVidia si è prefissato con Fermi essere esclusivamente o anche solo primariamente quello dell'ambito videoludico, ci stanno tutte le giuste riflessioni fatte finora, inerentemente gli eventuali errori, di valutazione e non, che fuori dubbio nVidia avrebbe commesso sinora se si conderano limitatamnte nell'ottica dell'intrattenimento di gioco.
Vi invito a riflettere sulle caratteristiche peculiari che questa nuova architettura dovrebbe mettere a disposizione, e lascerò quindi a voi le considerazioni su quale potrebbe essere il reale target di nVidia, che imo essendo peraltro di tutt'altra natura rispetto al semplice videogioco, potrebbe anche più facilmente spiegare la relativa mancanza di fretta o di impazienza finora palesata in questa situazione di palese (per noi) empasse, in quanto allo stato attuale, sarebbe in assoluta mancanza di un vero competitor.
1) - Un set di istruzioni completamente nuovo,
molto più simile all'architettura register/register RISC (detta anche load/store) in cui le istruzioni aritmetico-logiche lavorano solo sui registri, rendendo il codice più efficiente (dovuto primariamente alla lunghezza costante delle istruzioni) con molte istruzioni elementari, facilitando il compito delle pipeline e rendendo possibile un'esecuzione completamente parallela.
2) - Istruzioni di tipo Faster Atomic di supporto ai task
Istruzioni di questo tipo leggono da locazioni di memoria condivisa, ne controllano i valori e ne scrivono di nuovi senza che nessun altro processore sia capace di modificarne i relativi valori durante le singole esecuzioni. Questo permette ai task di comunicare gli uni con gli altri tramite degli opportuni bit o flag, come vogliamo chiamarli. La cache L2 di Fermi, dove questi valori verranno prevalentemente memorizzati, renderà una sensibile accelerazione supplementare.
3) - Spazio di indirizzamento virtuale a 64bit
Il PTX (Parallel Thread eXecution layer) permetterebbe a Fermi di cambiare dalla modalità di indirizzamento a 32bit a quella a 64bit senza una negativa e deleteria interruzione di tipo software.
4) - Caches
Fermi include una caratteristica interessante per ottenere più valore dalla cache L1, cioè quella di poterne dividere il quantitativo di 64 KB o come una cache di 48 KB e 16 KB locali, o una cache da 16 KB e 48 KB locali.
Ritengo che ciò possa essere stato congegnato per consentire così al software di avere il controllo esplicito di una parte della cache, in quanto potrebbe enormemente semplificarne la programmazione, migliorandone le prestazioni e anche l'efficienza energetica della GPU stessa.
5) - Codice di Correzione di errore sia sulla memoria principale che su quella cache.
Ritengo che sia inutile spiegarne sia i concetti, i vantaggi e gli ambiti di applicazione nell'ottica di cui sopra.
6) - Formato di memoria realmente in virgola mobile a 16bit ed il supporto per i numeri de-normalizzati direttamente in hardware.
Questo consentirebbe di effettuare davvero tutti i calcoli in singola precisione.
7) - Spazio di indirizzi unificato
Nel passato le GPU avevano una varietà di diversi tipi di memorie (la memoria locale, la memoria grafica, e la memoria di sistema), ciascuna nel proprio spazio di indirizzamento. Questa tipologia di frazionamento rende problematico l'accesso a qualsiasi porzione di dati in memoria tramite i linguaggi di programmazione che si basano su puntatori come ad esempio C++, C e CUDA.
Fermi dovrebbe risolvere il problema di utilizzo di queste memorie separate (la memoria locale, la memoria grafica, e la memoria di sistema) raggruppandole in un unico spazio di indirizzamento a 64-bit, rendendo così molto più facile il compito di compilare ed eseguire programmi C, C++. facilitato anche dall'attivazione del meccanismo PTX in quanto, così come la cache, uno spazio unitario di indirizzi aumenta l'efficienza dei tipi di programmi che possono essere eseguiti ancora più efficeintemente sulle GPU.
- Fast Context SwitchingFinora siamo stati abituati acché i coprocessori, come le GPU, abbiano ignorato il context switching (cambiamento di contesto), proprio perchè il loro obiettivo primario era si, quello di accelerare i programmi, ma semplicemente uno alla volta.
Con Fermi la situazione dovrebbe cambiare radicalmente, in quanto il context-switching ha frequenza di soltanto ~25 microsecondi,
accelerando così notevolmente il cambiamento del contesto.
Ciò starebbe a significare che in pratica si potrà ottenere una più efficiente utilizzazione in alcuni ambienti, in quanto questa feature consentirà ai programmi di essere eseguiti meglio e più velocemente rendendo possibile e consentendo ad un utilizzo kernel-indipendente di sovrapporre la propria esecuzione: a.e. lasciando che uno effettui dei calcoli mentre un altro inizi una comunicazione.
9) - Supporto al Debugging
Il supporto al debug nelle precedenti GPU faceva si che avvenisse il congelamento dell'intero stato della GPU stessa.
Avveniva infatti che per consentire al debugger in CPU di leggere e scrivere i registri del thread della GPU, lo stato del thread, e la memoria della GPU attraverso il collegamento tra la memoria di sistema e quella della GPU. Solamente dopo il debugger in CPU permetteva di riprendere regolarmente l'esecuzione del thread della GPU.
In FERMI tutto ciò dovrebbe avvenire direttamente in GPU ed il proprio debugger dovrebbe poter anche colloquiare con quello della CPU e quindi interagire finanche con le chiamate di sistema.
Attendo vostri riscontri di qualsiasi genere
Sinceramente non saprei come risponderti ai punti da te elencati, ma sono sicuro che a questo penserà il nostro grande Stefano alias yossarian
... però posso dirti che per il gpu computing ci sono le Tesla, mentre le Ge Force sono esclusivamente rivolte al mercato gaming. Allora secondo questa tesi quanto ho letto qualche mese fa su una rivista, ovvero che nVidia starebbe per abbandonare il settore gaming, sarebbe quasi confermato a questo punto... non sono fino a che punto ci sarebbe da star contenti di questa cosa, speriamo sia solo una boiata da giornalista.... -
se nn fossero pronti il 10 un posticipo è sempre possibile
-
Severnaya ha scritto:
se nn fossero pronti il 10 un posticipo è sempre possibileBeh questo è vero, ne ho già fatti parecchi perciò uno in più non penso gli cambi la vita
-
Rsdj ha scritto:
:asd:Ma che ci fa, tanto stiamo bene qui (cmq non con molto dispiacere che Halduemilauno non viene mai toccato quando molte volte è lui stesso a generare flame...)
Cmq dicono che domani, se ho capito bene, dovrebbe esserci un evento, tipo nVidia Editor's Day... sapete mica di cosa si tratta e di cosa si parlerà??
evitiamo polemiche...
hal avrà il suo momento, e non sarà una semplice sospensione, apparte che ha perso credibilità
-
Nvidia holds clandestine Fermi briefing | TG Daily
The worst kept secret in Vegas is currently underway in the MGM Grand as Nvidia flew in a select group of hacks just as the rest of us journos jetted off home from the scintillating city of sin.
Only a secret elite group of media were privileged enough to get in on the Fermi fandango, which apparently delved deep into all things architectural.
Our secret sauces, however, didn't seem to think much of Nvidia’s organizational skills.
"There is no outline. We were basically told to show up," the source told TG Daily.
"It was all technical. But no clock speeds, power consumption or benchmarks were being shown…yet at least," the source confirmed at the time of writing.
"The deep dive is no longer deep," he added "Now we're just talking about developer relations and what TWIMTBP works."
"It is interesting actually," he conceded.
Interesting indeed. Wonder what else will leak out of todays secret briefing, eh Nvidia?
TechConnect Magazine - Nvidia GF100 to be displayed at PDXLAN 15
After showing up at CES 2010 for its first pre-preview, Nvidia's first Fermi-based consumer product, the GF100, is now set to make an appearance at PDXLAN 15, a LAN party which is held between January 15 and the 18th. At the even there will be several GF100-equipped systems showcased and maybe more info about the card will be provided (fingers crossed)
Nvidia Club SLI members attending PDXLAN 15 will have the chance to win a GF100 card in a contest where participants will have to show, in an original way, how excited they are about GF100. The lucky winner will have to wait until the card become available (in March) to get it but it should be worth the wait.
-
gianni1879 ha scritto:
Nvidia Club SLI members attending PDXLAN 15 will have the chance to win a GF100 card in a contest where participants will have to show, in an original way, how excited they are about GF100. The lucky winner will have to wait until the card become available (in March) to get it but it should be worth the wait.
Ma daiii! Cos'è istigamento a diventare fanboy?
-
Achille GForce ha scritto:
incredibile ! 4% di resa produttiva e sono contenti ? Ma non era 40% ? non è che manca uno 0 ?quindi con un wafer ci faranno solo qualche chip al posto di un centinaio ? impossibile costerebbe 1000€ a chip.
Ma questo fattore deve ripercuotersi per forza sui prezzi ? o c'è la possibilità che dato il ritardo possano usare strategie differenti e venderli a prezzi sui 350€ ?
Fatto stà però che anche se esce castrato questo non dovrebbe chiamarsi Gt360 e avere un prezzo non di punta ?
in effetti c'è qualcosa che non va, una resa del 4% significa un disastro altro che contenti e felici.....
-
gianni1879 ha scritto:
in effetti c'è qualcosa che non va, una resa del 4% significa un disastro altro che contenti e felici.....qualcuno non ha ben capito la differenza tra four e fourty
-
si si sicuro
-
yossarian ha scritto:
se è confermata la presentazione il 10 marzo, allora entro i prossimi 20-30 giorni si avranno le informazioni mancanti (frequenze architettura delle tmu e delle rop's).
Se la gf104 dovesse essere la gpu high end, allora sarebbe confermata la mia ipotesi su gf100 con numero ridotto di alu e gf104 (a tiratura limitata) per la fascia alta in un secondo tempo.
quindi si andrebbe a confermare quella vecchia storia che vede gf100 come soluzione "provvisoria" castrata in attesa di gf104...
-
Achille GForce ha scritto:
è una supposizione questa delly.sappiamo come ho detto prima che Gf104 è la soluzione più alta del emrcato quindi o è quella a 512 stream oppure è la versione dual core
si...si...supposizione...
che sia la dual non credo...è più probabile che sia la versione con 512sp...
-
guarda...per logica fermi "castrato" dovrebbe anche avere un prezzo "castrato"...ma su questa cosa la mano sul fuoco io non ce la metto visto che secondo me il prezzo sarà cmq tutt'altro che castrato...
-
Achille GForce ha scritto:
comunque non capisco una cosa, dicono che è già in produzione il chip e hanno comunicato la resa produttiva quindi ne sono a conoscenza ( + o - ) e sanno un approssimarsi della data ma allora scusate ma se li stanno producendo adesso, l'esemplare del ces che cavolo era ? mica ci metteranno quello in produzione, ne dubito fortemente, o che il sample vero non gli è arrivato in tempo al ces
o quello del ces era un vero sample a 512 stream ancora in fase di affinamento mentre stanno producendo i 448 oppure semplicemtne è stata una mossa per mostrare false carte ad ATi, possibile ? fargli credere di essere più in difficoltà della realtà, può essere ?:cheazz:no...nvidia se non avesse avuto problemi (e problemi seri) fermi l'avrebbe mostrato ai quattro venti...se non l'ha fatto è perchè fermi al momento per loro non è assolutamente all'altezza...
l'esemplare mostrato al ces non escludo sia un sample a 512sp, magari overvoltato per mantenere un pelo di stabilità alle freq impostate..
anche se poi il crash ha rovinato un pochino il programma...
-
Achille GForce ha scritto:
su questo siamo d'accordo bisognerà vedere i nomi che assumeranno.perchè se mi chiamano il 448 Gt380 allora ci spariamo tutti, ce lo faran pagare come se fosse una VGA top di gamma fino a quando non uscirà il full optional.
comunque non capisco una cosa, dicono che è già in produzione il chip e hanno comunicato la resa produttiva quindi ne sono a conoscenza ( + o - ) e sanno un approssimarsi della data ma allora scusate ma se li stanno producendo adesso, l'esemplare del ces che cavolo era ? mica ci metteranno quello in produzione, ne dubito fortemente, o che il sample vero non gli è arrivato in tempo al ces
o quello del ces era un vero sample a 512 stream ancora in fase di affinamento mentre stanno producendo i 448 oppure semplicemtne è stata una mossa per mostrare false carte ad ATi, possibile ? fargli credere di essere più in difficoltà della realtà, può essere ?:cheazz:beh magari quello del ces è un esemplare di preproduzione... bisogna considerare che il processo produttivo dura sulle 6 settimane... non è che si fa in un giorno una gpu
si spera che quelli in produzione ora gli stiano riuscendo un po' meglio...
-
Rsdj ha scritto:
Penso che intende che non può uscire con le frequenze delle Tesla perchè sarebbero troppo basse...Ok ho capito... il fatto è che ho una scommessa in corso... se GF100 non suopererà più del 10% la 5870 mi ritroverò con un bel crossfire di 5970. Almeno un piccolissimo accenno tanto per mandarmi al letto contento??
Prendiamo come esempio che GF100 avrà frequenze di 648/1692/4200, di quanto riuscirà a superare la 5870??
p.s: scherzo, ovviamente se puoi
per come la vedo, la versione full la pomperanno al punto da superare la soglia del 10% e, probabilmente, da avvicinare quel 20% di cui ha parlato qualcuno. MOlto probabilmente non sarà la versione che uscirà per prima e sarà prodotta in pochissimi esemplari selezionati soprattutto per i bench. Questo, almeno, fino a che non sarà stato messo a punto il pp a 40 nm.
Totocellux ha scritto:
Volevo soffermarmi a fare delle riflessioni un pò oltre a quanto descritto finora, e vorrei che mi diceste ciò che ne pensate
Se pensiamo ed immaginiamo l'obiettivo che nVidia si è prefissato con Fermi essere esclusivamente o anche solo primariamente quello dell'ambito videoludico, ci stanno tutte le giuste riflessioni fatte finora, inerentemente gli eventuali errori, di valutazione e non, che fuori dubbio nVidia avrebbe commesso sinora se si conderano limitatamnte nell'ottica dell'intrattenimento di gioco.
Vi invito a riflettere sulle caratteristiche peculiari che questa nuova architettura dovrebbe mettere a disposizione, e lascerò quindi a voi le considerazioni su quale potrebbe essere il reale target di nVidia, che imo essendo peraltro di tutt'altra natura rispetto al semplice videogioco, potrebbe anche più facilmente spiegare la relativa mancanza di fretta o di impazienza finora palesata in questa situazione di palese (per noi) empasse, in quanto allo stato attuale, sarebbe in assoluta mancanza di un vero competitor.
1) - Un set di istruzioni completamente nuovo,
molto più simile all'architettura register/register RISC (detta anche load/store) in cui le istruzioni aritmetico-logiche lavorano solo sui registri, rendendo il codice più efficiente (dovuto primariamente alla lunghezza costante delle istruzioni) con molte istruzioni elementari, facilitando il compito delle pipeline e rendendo possibile un'esecuzione completamente parallela.
2) - Istruzioni di tipo Faster Atomic di supporto ai task
Istruzioni di questo tipo leggono da locazioni di memoria condivisa, ne controllano i valori e ne scrivono di nuovi senza che nessun altro processore sia capace di modificarne i relativi valori durante le singole esecuzioni. Questo permette ai task di comunicare gli uni con gli altri tramite degli opportuni bit o flag, come vogliamo chiamarli. La cache L2 di Fermi, dove questi valori verranno prevalentemente memorizzati, renderà una sensibile accelerazione supplementare.
3) - Spazio di indirizzamento virtuale a 64bit
Il PTX (Parallel Thread eXecution layer) permetterebbe a Fermi di cambiare dalla modalità di indirizzamento a 32bit a quella a 64bit senza una negativa e deleteria interruzione di tipo software.
4) - Caches
Fermi include una caratteristica interessante per ottenere più valore dalla cache L1, cioè quella di poterne dividere il quantitativo di 64 KB o come una cache di 48 KB e 16 KB locali, o una cache da 16 KB e 48 KB locali.
Ritengo che ciò possa essere stato congegnato per consentire così al software di avere il controllo esplicito di una parte della cache, in quanto potrebbe enormemente semplificarne la programmazione, migliorandone le prestazioni e anche l'efficienza energetica della GPU stessa.
5) - Codice di Correzione di errore sia sulla memoria principale che su quella cache.
Ritengo che sia inutile spiegarne sia i concetti, i vantaggi e gli ambiti di applicazione nell'ottica di cui sopra.
6) - Formato di memoria realmente in virgola mobile a 16bit ed il supporto per i numeri de-normalizzati direttamente in hardware.
Questo consentirebbe di effettuare davvero tutti i calcoli in singola precisione.
7) - Spazio di indirizzi unificato
Nel passato le GPU avevano una varietà di diversi tipi di memorie (la memoria locale, la memoria grafica, e la memoria di sistema), ciascuna nel proprio spazio di indirizzamento. Questa tipologia di frazionamento rende problematico l'accesso a qualsiasi porzione di dati in memoria tramite i linguaggi di programmazione che si basano su puntatori come ad esempio C++, C e CUDA.
Fermi dovrebbe risolvere il problema di utilizzo di queste memorie separate (la memoria locale, la memoria grafica, e la memoria di sistema) raggruppandole in un unico spazio di indirizzamento a 64-bit, rendendo così molto più facile il compito di compilare ed eseguire programmi C, C++. facilitato anche dall'attivazione del meccanismo PTX in quanto, così come la cache, uno spazio unitario di indirizzi aumenta l'efficienza dei tipi di programmi che possono essere eseguiti ancora più efficeintemente sulle GPU.
- Fast Context SwitchingFinora siamo stati abituati acché i coprocessori, come le GPU, abbiano ignorato il context switching (cambiamento di contesto), proprio perchè il loro obiettivo primario era si, quello di accelerare i programmi, ma semplicemente uno alla volta.
Con Fermi la situazione dovrebbe cambiare radicalmente, in quanto il context-switching ha frequenza di soltanto ~25 microsecondi,
accelerando così notevolmente il cambiamento del contesto.
Ciò starebbe a significare che in pratica si potrà ottenere una più efficiente utilizzazione in alcuni ambienti, in quanto questa feature consentirà ai programmi di essere eseguiti meglio e più velocemente rendendo possibile e consentendo ad un utilizzo kernel-indipendente di sovrapporre la propria esecuzione: a.e. lasciando che uno effettui dei calcoli mentre un altro inizi una comunicazione.
9) - Supporto al Debugging
Il supporto al debug nelle precedenti GPU faceva si che avvenisse il congelamento dell'intero stato della GPU stessa.
Avveniva infatti che per consentire al debugger in CPU di leggere e scrivere i registri del thread della GPU, lo stato del thread, e la memoria della GPU attraverso il collegamento tra la memoria di sistema e quella della GPU. Solamente dopo il debugger in CPU permetteva di riprendere regolarmente l'esecuzione del thread della GPU.
In FERMI tutto ciò dovrebbe avvenire direttamente in GPU ed il proprio debugger dovrebbe poter anche colloquiare con quello della CPU e quindi interagire finanche con le chiamate di sistema.
Attendo vostri riscontri di qualsiasi genere
direi che hai fatto centro. Fermi nasce soprattutto come gpu per i calcoli gp e non è un caso che si è insistito molto su questo aspetto. Il fatto è che gran parte della community si aspetta da nVIDIA il solito chip per gaming.
Fermi è la gpu che più di tutte si avvicina ad una cpu come concezione (anche gli algoritmi di branch prediction sonmo molto somiglianti a quelli visti sulle cpu ARM, ad esempio). Questo si paga in termini di prestazioni in ambito gaming perchè una maggior complessità a livello logico sottrae spazio alle unità funzionali e fa sprecare cicli di clock.
gianni1879 ha scritto:
rv870 è in produzione già da alcuni mesi mentre fermi entrerà in produzione, sembrerebbe, a febbraio (questo avvalorerebbe i dubbi esressi sulle affermazioni di JHH sul fatto che la produzione procede a gonfie vele
).L'affinamento, anche solo parziale, del pp per un chip, porta solo benefici marginali ad un'architettura completamente diversa. Quel 4% potrebbe essere riferito alle rese iniziali di rv870 e potrebbe rispecchiare le rese iniziali di fermi.
Achille GForce ha scritto:
quindi fra il 15 e il 18 potrebbe debuttare ? ad un lanparty ? bè un idea originalesperiamo che ci faccinao girare crysis
Yonariass senti una domanda ma come fai a dire che un tesla in versione geforce con le freqeunze che ha non compete con 5870 ? non dovrebbe rappresentare pur sempre una GT360 con quelle caratteristiche? Magari considerando le rops e tmu mancanti in tesla, attivati in geforce e ovviamente la GDDR5 non ecc ad alta freqeunza.
se per la GT380 originale volevano 1.7Ghz per gli shader e 650Mhz di GPU, le freqeunze del modello di punta tesla 1.4Ghz / 600Mhz potrebbe essere ottime per una eventuale GT360 no ?
basta fare due calcoli: a livello teorico, il rapporto tra MADD di un ipotetico 360 con 1400 e 600 MHz rispettivamente con rv870 in versione 5870, sarebbe pari a 0,46 mentre quello tra GT200b e RV790 era pari a 0,52. Inoltre, a livello di capacità di fare texture fetch e texture address, per la prima volta dopo anni, un chip nVIDIA starebbe sotto, anche se di pocoi (112 TMU a 600 MHz contro 80 TMU a 850 MHz). Tieni conto che nel computo delle operazioni matematiche ho considerato le sole MADD perchè sono quelle più frequenti; se prendiamo come riferimento le flops, bisogna ricordare che GT200 esegue anche una MUL (che in fermi è andata "persa") che porta le operazioni totali a 1,063 Tflops contro le 708,5 MADD e il rapporto tra flops (tra GT200 e RV790) diventa di 0,78.
Achille GForce ha scritto:
è una supposizione questa delly.sappiamo come ho detto prima che Gf104 è la soluzione più alta del emrcato quindi o è quella a 512 stream oppure è la versione dual core
non ci sarà una versione dual core, al massimo una dual gpu
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