View Full Version : [THREAD UFFICIALE] Aspettando Nvidia GTX 480 e GTX 470
Kharonte85
29-11-2009, 11:42
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
29-11-2009, 11:43
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
29-11-2009, 12:14
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ù.
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...
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
29-11-2009, 12:23
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
29-11-2009, 12:27
Novità sulla commercializzazione della 380?
Bastoner
29-11-2009, 12:42
Novità sulla commercializzazione della 380?
E' in arrivo nei negozi :asd:
Nessuna novità :(
Severnaya
29-11-2009, 12:43
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"? :mbe:
skizzo99999999
29-11-2009, 13:07
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
29-11-2009, 13:17
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
appunto :stordita: ma la 5970 non ci va :read:
ma forse nel CM690 II ci andrà. fotina http://www.coolermaster.com/upload/360/RC-690K_360.swf :asd:
è calato il silenzio su Fermi, se ne riparla a marzo dell'anno prossimo mi sa :fagiano:
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.
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
A me interessa
leoneazzurro
29-11-2009, 14:13
x skizzo: non é detto che lo shader sia compilato prima, potrebbe essere anche compilato in tempo reale, in quel caso ci sarebbe un ulteriore overhead dovuto all´analisi necessaria per la sostituzione. Dipende probabilmente dall´applicazione.
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.
L´operazione é piú precisa, certo, ma rispetto alla MADD c´é una differenza nel risultato che nel caso di shader lunghi potrebbe portare a differenze non trascurabili nel risultato finale e il problema diventa se il pixel che restituisce uno shader con FMA sia quello che lo sviluppatore intendeva quando ha programmato lo shader con MADD (magari con tecniche di compensazione dell´errore che adesso é di diversa entitá). In casi particolari si potrebbero avere variazioni di gamma colore oppure dei veri e propri artefatti, bisogna vedere quanti questi casi particolari sranno in realtá.
molochgrifone
29-11-2009, 15:30
appunto :stordita: ma la 5970 non ci va :read:
immagino c'entri anche la dimensione del chip in sè, per quello speravo che con un die-shrink futuro si tornasse a lunghezze complessive minori
cmq siamo del tutto OT :D
ma forse nel CM690 II ci andrà. fotina http://www.coolermaster.com/upload/360/RC-690K_360.swf :asd:
Siamo OT, ma c'è il modo di farla entrare anche nel CM attuale utilizzando il modulo 4-in-3 per gli hard disk e rimuovendo la gabbia degli HD ;)
Siamo OT, ma c'è il modo di farla entrare anche nel CM attuale utilizzando il modulo 4-in-3 per gli hard disk e rimuovendo la gabbia degli HD ;)
insomma devi svuotare mezzo case per farcela stare :sofico:
molochgrifone
29-11-2009, 15:49
insomma devi svuotare mezzo case per farcela stare :sofico:
In realtà è un'operazione abbastanza facile e veloce, che inoltre migliora il raffreddamento degli HD :)
davide155
29-11-2009, 19:28
Ragazzi insomma non c'è punte news riguardo Fermi?
Sto aspettando queste schede per scegliere la mia prossima vga tra Ati e Nvidia.
Sperando che tornino (almeno Nvidia) a fare delle schede video con lunghezze più contenute come le vecchie G80, e non quelle Limousine che hanno tirato fuori ultimamente, dato che non ne entra nemmeno una nel mio Thermaltake Armor JR :rolleyes:
appleroof
29-11-2009, 19:30
Ragazzi insomma non c'è punte news riguardo Fermi?
Sto aspettando queste schede per scegliere la mia prossima vga tra Ati e Nvidia.
Sperando che tornino (almeno Nvidia) a fare delle schede video con lunghezze più contenute come le vecchie G80, e non quelle Limousine che hanno tirato fuori ultimamente, dato che non ne entra nemmeno una nel mio Thermaltake Armor JR :rolleyes:
quoto
p.s.: ciao, era da molto tempo che non ti vedevo in questi lidi :)
skizzo99999999
29-11-2009, 19:33
x skizzo: non é detto che lo shader sia compilato prima, potrebbe essere anche compilato in tempo reale, in quel caso ci sarebbe un ulteriore overhead dovuto all´analisi necessaria per la sostituzione. Dipende probabilmente dall´applicazione.
gli shader sono si compilati in tempo reale (cioè quando l'applicazione/gioco è partita, quindi a run-time), ma all'atto del caricamento degli stessi, non quando vengono utilizzati (per più volte per frame) all'interno del loop di rendering. E non è che dipende dall'applicazione, è proprio così sempre, a meno che uno non richiami il caricamento e le successive fasi compilazione/link di ogni shader ogni volta prima di utilizzarli. E' proprio questo il motivo del contendere delle ultime pagine, ma ormai sull'argomento mi sembra sia stato detto tutto.
Per quanto riguarda i possibili problemi dell'arrotondamento, quello che mi è venuto in mente è l'integrazione tra la fixed pipeline e quella programmabile.
Fino all'arrivo delle directx 8.1/9 e opengl 2.0 le GPU non erano programmabili, per cui gli algoritmi che potevano essere utilizzati (ad esempio per l'illuminazione) erano fissi e sempre gli stessi per tutti. Con l'avvento dei pixel e vertex shader programmabili (ora anche geometry shader e compute shader), ognuno può farsi il suo modello di illuminazine utilizzando più o meno risorse, fare i calcoli per vertex o per pixel, ecc... Inoltre si possono fare processare anche altri dati oltre a quelli prettamente geometrici, per farci godere tutti gli effetti di post-processing tipo depth-of-filed, motion blur, ambient occlusion, ecc...
Ovviamente per questione di compatibilità la fixed pipeline (cioè quella non programmabile) è stata mantenuta: non nel senso che ci sono delle unità non programmabili, ma che quando questa funzionalità viene richiesta, viene caricato un codice che fa le stesse operazioni che farebbe una GPU non programmabile. Quest'ultimo concetto è molto importante perchè alcune volte, per alcuni passi di rendering non è necessario accedere a risorse particolari (mi viene in mente ad esempio se uno deve disegnare un HUD con informazioni testuali tipo quello di un fps), per cui un invece che scrivere uno shader di una decina di righe o meno può non usare gli shader e quindi utilizzare le funzioni standard. Ed è qui che può sorgere il problema. Se uno utilizza in uno shader un "risultato" prodotto da un passo "programmabile" con uno proveniente da un calcolo di un passo "fixed", potrebbe succedere che numeri che dovrebbero essere uguali, non lo sono a causa dell'utilizzo di unità diverse che effettuano calcoli a precisione diverse. Per fare un esempio terra terra, un'istruzione che si fa sempre nel vertex shader è:
gl_Position = ftransform();
che prende le coordinate del vertice in esame e le trasforma dal "world space" in "clip space" utilizzabili nel pixel shader. Questa operazione emula il comportamento della fixed e può essere svolta "a mano" operando direttamente sulle matrici e vettori:
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
teoricamente dovrebbero portare allo stesso risultato, ma visto che è possibile che una GPU abbia "ottimizzato" in un certo in modo quella operazione matematica, possono esserci delle precisioni "diverse". L'emulazione dlla fixed pipeline garantisce che avrò sempre gli stessi risultati invece. Un esempio tipico di artefatti che possono nascere da cose del genere sono gli “Z-fighting”. Mettiamo che io abbia 2 poligoni paralleli (o mooooolto vicini) alla stessa distanza dalll'osservatore che si trovano almeno in parte sovrapposti (quindi più pixel che li compongono hanno le stesse coordinate z, quelle relative alla profondità). Potrebbe accadere che alcuni pixel siano rilevati come davanti e altri dietro, formado un effetto di miscuglio di colori che viene visto come artefatto.
Il problema nasce prorpio da qui. Siccome io devo almeno far funzionare le applicazioni sulla mia scheda, mi sembra ragionevole che se verranno sostituite le MADD con le FMA, verranno anche sostituite nei calcoli che coinvolgono l'emulazione della fixed pipeline, sennò i risultati non sarebbero più confrontabili e si creerebbero probabilmente situazioni come quella descritta in precedenza. Così facendo però, non avremo più i risultati derivanti dalla fixed uguali a quelli delle altre schede, e non so se questo sia accettabile, cioè ci siano dei vincoli numerici di precisione minima e massima da rispettare in questa modalità per essere "standard".
Non so se sono stato chiarissimo ma spero che si capisca il succo del discorso
davide155
29-11-2009, 19:41
quoto
p.s.: ciao, era da molto tempo che non ti vedevo in questi lidi :)
Grande appleroof, piacere di rivederti ;)
Quello era NV40 (la serie 6). La NV30 disponeva del 2.0a (un superset del 2.0)
....yes mi sono confuso...ricordavo tutta una serie di screenshoots qui su hwupgrade dove veniva analizzata la resa qualitativa degli shader di Farcry eseguiti con FP16 (vistosi problemi di banding) e eseguiti con FP32 (framerate scadente)....
Lo SM 3.0 era causa di una altre querelle....HDR or not? :D
In realtà al cambio di pp il bus è la cosa che si restringe meno :)
Si be la dimensione del bus è più o meno sempre quella infatti con pp sempre più piccoli o si aumentano anche le dimensioni del chip (quindi maggiori transistor) oppure fisicamente nn ci stanno i bus che ci stavano nella precedente generazione (vedi 4870 e 5770)
Non credo che sia paragonabile...nv 30 era deficitario in parecchi aspetti rispetto a R300.
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 ;)
meglio così, cmq per quando mi rigurda ribadisco quando detto, e cioè che le soluzioni estreme, che garantiscono il top delle performance, anche se sforano dai 30cm nn sono poi così problematiche ;)
leoneazzurro
29-11-2009, 20:46
gli shader sono si compilati in tempo reale (cioè quando l'applicazione/gioco è partita, quindi a run-time), ma all'atto del caricamento degli stessi, non quando vengono utilizzati (per più volte per frame) all'interno del loop di rendering. E non è che dipende dall'applicazione, è proprio così sempre, a meno che uno non richiami il caricamento e le successive fasi compilazione/link di ogni shader ogni volta prima di utilizzarli.
Si, non intendevo compilati piú volte al frame, pensavo volessi dire che si puó avere lo shader precompilato giá prima dell esecuzione (ma cosí si perdono molte ottimizzazioni). Comunque anche l´ottimizzazione on-chip non é da sottovalutare ;)
yossarian
29-11-2009, 21:35
ho sperato inutilmente, ma pazienza. Ho sempre detto che il compilatore GLSL era all'interno del driver e dici bene, "che comprende il compiler e il linker, che serve da interfaccia con l'applicazione, che si occupa di fare la traduzione e che è scritto, come dice bene eXeS, in un codice che giri sulla cpu". Quello che è standard è il codice GLSL, non il codice compilato che esce dal compilatore del driver, questo sarà diverso per ogni scheda video. Dal diagramma della prima imamgine si vede bene che al driver arriva il source dello shader (che è testo) ed esce l'executable code che POI viene eseguito dalla GPU. La frase:
"the net resukt of this assumption is that graphics hardware vendors will implement the majority of the OGSL compiler and linker. Along with the OGL drivers itself, this software will tipically be included as part of the graphics driver installation package that is provided by a graphics hardware vendor"
dice che il compilatore è fornito dal produttore della scheda attraverso il driver che ognuno si scarica da internet. Mi sembra di continuare a dire questo da una vita... è proprio per questo che ogni scheda si ritrova il suo compilatore che riceve un source GLSL STANDARD e sputa un codice diverso per ogni scheda che si trova sotto.
tutto giusto in teoria; ma poichè con la sola teoria non si costruice niente, veniamo alla pratica. Secondo il tuo ragionamento, nVidia (perchè di nVidia stiamo parlando), mette mano al suo compilatore custom o ne progetta uno nuovo ogni volta che deve supportare una nuova architettura. Se ciò fosse vero, con CUDA, progetto su cui nVIdia sta lavorando da anni, dovrebbe aver messo a punto compilatore e ottimizzatore ad hoc per i proprio chip (si tratta di supportare solo quelli a shader unificati). Sentiamo cosa ha da dire proprio nVidia in proposito, premettendo ceh CUDA non significa solo "driver unificati" ma è un progetto che abbraccia l'architettura del SW e la microarchitettura dell'HW che deve far girare quel SW (l'appellativo CUDA CORE delle unità di calcolo di fermi fa esplicito riferimento, non a caso, a questa architettura)
The CUDA compiler driver splits an application into two parts, one which is run on the host CPU, and the other which is run on the GPU. The CPU code uses the default host compiler, while the GPU code uses a new toolchain that includes Open64.
Quindi il compiler ad alto livello non fa altro che dividere in due parti l'applicazione, facendo girare una parte sul compiler di default della cpu e l'altra su un compiler che fa uso di Open64. Il primo ci interessa poco, ai fini di questo discorso (utilizza istruzioni standard della cpu e dell'API su cui gira).
Vediamo il secondo.
NVIDIA already had a well-tuned low-level compiler for graphics codes, called OCG (Optimized Code Generator). This handles register allocation, scheduling, and peephole optimizations. This compiler is built into the graphics driver for doing just-in-time compilation of graphic codes.
qui parla di un optimizer a basso livello e di tipo JIT.
Because graphics codes tend to be relatively simple compared to general purpose C code (control flow has only recently been added to DirectX), and due to the compile-time limitations of needing to compile at runtime, it was decided that CUDA needed a high-level optimizer to handle the compute codes
There were three options for doing this: write a new proprietary optimizer, use GCC, or use Open64. Writing a new optimizer was ruled out because it would require too many man years to develop. So the choice was between using GCC or Open64. Because of Open64's reputation for optimization (and with my encouragement), we chose Open64.
qui si esclude la possibilità di creare un optimizer proprietario ad alto livello perchè ciò avrebbe richiesto troppi anni. Quindi si è scelto quello open64 STANDARD.
Ricapitolando: la cpu elabora codice non ottimizzato da nVidia e per la gpu si fa uso di un compiler ad alto livello Open64 STANDARD (per sistemi basati su unix, per win ce n'è un altro). Questo esempio, fatto per CUDA vale anche per OpenGL o DirectX perchè, a basso livello, si fa uso sempre dello stesso optimizer OCG (optimize code generator).
In più, il modello di ottimizzazione (che non definirei proprio at runtime) da voi proposto (la cpu fornisce in fase di compilazione il codice alla gpu che lo riceve già bello e pronto per essere elaborato) è giudicato inefficiente dalla stessa nVidia che preferisce ottimizzazioni JIT. Motivi di spreco di risorse, lentezza nel trasferimento dati tra cpu vram e gpu, difficoltà nel mettere le mani su compiler standard o nel progettarne uno custom per intero, questioni di portabilità e di compatibilità con i prodotti passati e futuri con semplici modifiche del codice dell'OCG, credo siano motivi più che sufficienti. E se non siete d'accordo protestate con nVidia.
Comunque, proseguiamo: il codice sorgente destinato alla gpu è compilato (non ottimizzato), dunque, da un compiler STANDARD e fornisce istruzioni per PTX (parallel thread execution) che è una VM installata su gpu con una sua ISA. La prima versione 1.0 risale ai tempi di G80 e con fermi si arriva alla versione 2.0. PTX provvede a ricompilare di nuovo il codice lanciando le ottimizzazioni tramite OCG. Questo tool è in grado di riconoscere il tipo di gpu e, di conseguenza, effettuare tutte le ottimizzazioni necessarie pr quella specifica architettura (cosa che una cpu che non ha accesso all'interno della gpu non potrà mai fare). Tra queste ottimizzazioni ci sono anche quelle relative all'uso di preephole che sono delle finestre che permettono di individuare parti di codice su cui intervenire. In questo caso possono permettere di individuare le MADD e effettuare la sostituzione con le FMA in modalità JIT all'interno della gpu.
"Casualmente" :D , Fermi contiene alcune ottimizzazioni atte a velocizzare il thread switching (ad esempio il dual warp scheduler) oltre ad avere una notevole potenza di calcolo con gli interi (necessaria ad effettuare preephole optimization); infine, nVidia annovera tra i "device runtime components" (col termine device indica la gpu mentre la cpu è indicata come host) proprio quelle atomic ops con interi (and, or, contronto) che servono per le preephole optimization (e quindi per le operazioni di instruction replacement) e specifica che queste sono disponibili dalla relaease 1.1 della PTX VM (quindi G80 è escluso ma fermi sembra rientrarci alla stragrande :D ).
A questo punto, sei liberissimo di continuare a credere che i driver facciano il "miracolo" di far si che la cpu ottimizzi tutto il codice all'atto della compilazione (hai una visione molto statica delle cose). E che questo avvenga in opengl con compiler custom (ma nVidia pare non voglia perdere tempo a scrivere un compiler per opengl o per open64, o per qualsivoglia piattaforma e preferisce affidarsi a compiler standard) e in D3D (non dimentichiamo che parliamo di fermi e giochi e, quindi soprattutto DX) con la modifica del compiler standard HLSL (operazione che solo un pazzo andrebbe ad intraprendere, quando ci sono vie più sicure e veloci). L'idea, poi, che la cpu possa eseguire ottimizzazioni JIT è ancora più folle: ti do solo un paio di dati: su GT200 il tempo di accesso medio stimato alla vram (non alla ram di sistema, quindi ma a quella video) era di 400-800 cicli, contro i 2-3 cicli di tempo di accesso ai registri interni e i circa 30-40 di accesso alle cache interne). Non oso pensare a quali sarebbero gli access time attraverso ram di sistema, bus pci-ex. e vram. Ci pensi ai disastri di un'ottimizzazione al volo fatta via cpu con, ad esempio, shader procedurali, o istruzioni di tessellation (con vertici fissi e funzione matematica che descrive la superficie da riprodurre) o con istruzioni che generano cascate di dati con cui sono necessarie altrettante istruzioni. Non mi meraviglio che nVidia, avendo a che fare con un processo di tipo dinamico, cerchi di eseguire il maggior numero di operazioni direttamente sulla gpu scaricando, il più possibile, persino la vram, per ridurre le latenze.
E tutta questa magia chi la fa, il driver, che non è codice scritto in linguaggio binario riconosciuto dalla gpu, ma è codice x86 o x64 eseguito dalla cpu che fra le altre cose, fa delle chiamate dirette al dispositivo grafico.
nessuno ha mai negato che il driver contenga istruzioni per la cpu. Semmai è il contrrio; quello che sostengo è che la cpu non fa una cippa di ottimizzazione all'atto della compilazione e che il driver contiene anche istruzioni per la gpu e sono questa a contenere le ottimizzazioni.
Un tutorial su come sviluppare un driver elementare e che stampa hello word
http://www.rohitab.com/discuss/index.php?showtopic=24166
Il driver a differenza di un'applicazione standard ha l'entry point che si chiama DriverEntry, un'applicazione in finestra WinMain, e una DLL DllMain
Il processo di creazione del .sys (che contiene codice binario) passa attraverso
-Compilazione
-Linking
esattamente come il processo di creazione del binario di un exe o dll.
interessante, ma l'utilità ai fini di ciò di cui si discute?
Aggiungo inoltre, ma se il driver non contenesse codice eseguibile dalla CPU, come cavolo farebbe in funzione del nome dell'exe ad applicare ottimizzazioni specifiche, attivare sli e crossfire, forzare l'uso dell'AA e quant'altro, chi è che fa il test sul nome dell'eseguibile, la GPU ? :D
cosa che nessuno, ripeto, sta mettendo in dubbio
Non mi sembra che tu abbia bisogno di alleati :) , ho dato solo un piccolo contributo per avallare la tesi da te inizialmente ipotizzata e non condivisa da yossarian, secondo la quale il codice del driver può tranquillamente fare il replace della mad prima che lo shader venga inviato alla gpu, con hit prestazionale che si manifesta solo nel momento dell'invio dello shader alla gpu, e non ogni volta che le istruzioni ivi contenute vengono processate dalla gpu.
Se ancora ci fossero dei dubbi sull'affermazione secondo la quale il driver contiene codice eseguibile dalla cpu, basta dissassemblare qualunque .sys, per notare che il disassemblato contiene istruzioni assembler x86 ;)
http://www.pctunerup.com/up/results/_200911/th_20091126224744_nuovo-1.jpg (http://www.pctunerup.com/up/image.php?src=_200911/20091126224744_nuovo-1.jpg)
infatti yossarian (e pare anche nVidia, il cui parere, ritengo sia più autorevole, in quanto si parla di Fermi), continua a non condividere la tesi delle ottimizzazioni fatte dalla stessa cpu in fase di compilazione e ritiene improbabili quelle JIT fatte dalla cpu. Insomma, nVidia pensa che meno traffico ci sia nel bus pci-express e meno la cpu (e, addirittura, la vram) interviene e meglio è per tutti. Voi, liberi di pensarla come volete :D
Foglia Morta
29-11-2009, 21:59
Dopo "tanto" tempo quando nessuno se lo aspettava più ritorni con una doppietta :D , sarai micca parente di Huntelaar :asd:
Dopo "tanto" tempo quando nessuno se lo aspettava più ritorni con una doppietta :D , sarai micca parente di Huntelaar :asd::asd:
Sono juventino :sob:
yossarian
29-11-2009, 23:14
Si, non intendevo compilati piú volte al frame, pensavo volessi dire che si puó avere lo shader precompilato giá prima dell esecuzione (ma cosí si perdono molte ottimizzazioni). Comunque anche l´ottimizzazione on-chip non é da sottovalutare ;)
per ottimizzazioni "al volo" è l'unica strada percorribile.
:asd:
Sono juventino :sob:
Ci stiamo prendendo solo limoni :sob:
Questa l'avevate letta?
http://www.fudzilla.com/content/view/16601/1/
maurilio968
30-11-2009, 09:15
infatti yossarian (e pare anche nVidia, il cui parere, ritengo sia più autorevole, in quanto si parla di Fermi), continua a non condividere la tesi delle ottimizzazioni fatte dalla stessa cpu in fase di compilazione e ritiene improbabili quelle JIT fatte dalla cpu. Insomma, nVidia pensa che meno traffico ci sia nel bus pci-express e meno la cpu (e, addirittura, la vram) interviene e meglio è per tutti. Voi, liberi di pensarla come volete :D
Bene, mi sembra che siamo giunti ad un punto chiarificatore: non è impossibile "ottimizzare" (nel senso in cui intende skizzo) per la singola gpu il fatto è che non è conveniente farlo perchè tale ottimizzazione sarebbe a carico della cpu e quindi troppo lenta.
E lo direbbe la stessa nvidia.
Sicuramente sembra non essere conveniente farlo in directx per i videogames.
Forse in opengl è diverso ed è uno dei motivi per cui i giochi si sono spostati tutti su architettura dx.
Notate i "sembra" ed i condizionali non per mettere in dubbio quanto dice yossarian ma per sottolineare che non vorrei aver capito male io.
Vorrei comunque ringraziare sia Yossarian che skizzo per questa discussione che a me sembra molto interessante.
maurilio968
30-11-2009, 09:16
Ci stiamo prendendo solo limoni :sob:
OT
e continueremo a prenderne se non cambia la proprietà di questa squadra.
Per lo stato attuale potremmo adottare nvidia come sponsor ufficiale ed
andare in giro con la scitta "FERMI" sulle magliette.
Fine OT
skizzo99999999
30-11-2009, 10:00
nessuno ha mai negato che il driver contenga istruzioni per la cpu. Semmai è il contrrio; quello che sostengo è che la cpu non fa una cippa di ottimizzazione all'atto della compilazione e che il driver contiene anche istruzioni per la gpu e sono questa a contenere le ottimizzazioni.
ah si? veramente qui
il driver della gpu che agisce sulla cpu? Non credo proprio :D . La cpu non si occupa di rendering ma solo di inviare i dati iniziali sui vertici del frame e, al massimo, di fisica e IA; e poi non ha senso anche solo pensare che il driver di una periferica agisca su un'altra.
e qui
non esiste un fantomatico compilatore generico (il compilatore l'ha tirato in ballo il tuo compare). Si chiamano ottimizzazioni e non vengono fatte dal compilatore standard o della cpu o chiamalo come ti pare.
Intanto non hai risposto alla domanda: è la cpu che si occupa di effettuare la sostituzione? Perchè dovrebbe farlo e chi glielo dovrebbe dire? I driver nVidia? Non pilotano un chip di cui non conoscono l'architettura; sai che per scrivere un driver devi conoscere a fondo l'architettura del chip per il quale lo scrivi? Significa che se nVidia scrive un driver che dica al compilatore di una cpu intel di ottimizzare il codice per fermi, nVidia deve conoscere a menadito l'rchitettura intel (non solo fermi).
e qui
La risposta corretta è: il compilatore (ma non volgio chiamarlo in quel modo), diciamo il tool che si occupa di effetuare le sostituzioni e le ottimizzazioni di qualunque natura è all'interno dei driver. Dei driver di chi? Di nVidia, ovviamente, nello specifico. Allora, se questo tool è nei driver di nVidia, come può essere che a fare le sostituzioni ci pensa la cpu prima di inviare il tutto alla vram? Non mi risulta che nVidia abbia cpu x86 e anche se le avesse, parliamo comunque del driver della gpu. Quindi, non può essere la cpu. Allora la gpu (escludiamo l'ipotesi che il codice sorgente arrivi già compilato per fermi). Ok, lo fa la gpu (d'altro canto il driver è suo).
e qui
Tornando a quanto detto prima, nVidia non si prenderà mai la briga di scrivere un compilatore per hlsl di tipo, diciamo "standard", di quelli integrati nel s.o. e basati sulle api di riferimento, Non potrà mai scrivere un tool che "faccia lavorare" per le sue gpu le cpu intel o amd ottimizzando per loro (dovrebbe conoscerne le architetture e scriverne uno per ciascuna; in pratica dovrebbe scrivere dei driver per cpu
e soprattutto qui
A questo punto, le ottimizzazioni per il chip grafico può farle solo il chip grafico guidato dai suoi driver (driver significa, appunto, conducente, guidatore, colui che guida, ecc). Ora, salvo pensare che questi driver (del chip grafico) non pilotino anche la cpu, verrebbe spontaneo immaginare che, in questo universo e in questo tempo (cosa accada in universi paralleli sfugge al controllo dei nostri sensi) sia la gpu a fare le ottimizzazioni relative.
sicuramente me ne sono sfuggite altre ma queste bastano e avanzano. Può anche darsi che ti sei spiegato male, tutte le volte. Ritornando al nostro solito (...) argomento, per prima cosa linko il documento in modo che chi se lo voglia leggere integralmente lo possa fare facilmente:
http://www.capsl.udel.edu/conferences/open64/2008/Papers/101.doc
Mi sembra buona norma linkare le fonti, in modo che se c'è qualche volenteroso che ha voglia/tempo/capacità per capire lo possa fare senza sbattersi. Tanto se ho le citazioni vuol dire che ho il documento, per cui linkarlo non mi costa nulla.
Bisogna dire subito che questo paper è riferito a CUDA, e quindi con la grafica non centra nulla. Proprio nulla no ma ci siamo capiti. Conseguenza diretta di questo è che tutte le considerazioni sono riferite alla programmazione general purpose e non ai linguaggi di shading. Infatti già nella prima citazione questa caratteristica emerge subito; se invece di partire da quel punto si legge anche la frase prima, già molte cose risultano più chiare a chi legge:
"CUDA provides a few simple extensions to C/C++ that enables users to specify what part of their program they want to run in parallel on a GPU. The CUDA compiler driver splits an application into two parts, one which is run on the host CPU, and the other which is run on the GPU."
Qua si sta parlando di codice c/c++, quindi assolutamente impossibile da eseguire per qualsiasi GPU. Infatti NVIDIA a fatto delle estensioni al c grazie alle quali il programmatore definisce le parti di codice che, adottando comunque sempre una sintassi c-like, possano essere possibili da eseguire dalle GPU. E quindi il codice viene diviso in 2 parti: quello "normale" che il programmatore ha deciso che sarà eseguito dalla CPU e che segue una via più tradizionale, e quello da dare in pasto tramite CUDA alla GPU.
Anche questo codice però non è gestibile direttamente così com'è (e non sto parlando del fatto che sia un sorgente e non compilato), a causa del possibile/probabile uso di strutture dati/costrutti che la GPU non può eseguire. L'esempio più banale che mi viene in mente è, ad esempio che il GLSL supporta soltanto (almeno fino alle opengl 2.1, ma non credo che dopo la situazione cambi radicalmente, e anche se cambiasse visto che gli shader c'erano anche con le directx9 e opengl 2.1, il discorso deve essere valido) vettori di 4 elementi o matrici fino a 4x4. Dimensioni ridicole per codice general purpose. Ovviamente ci sono le texture, che presumo siano, come negli shader, la via maestra per passare i dati alla GPU; però siccome in c le texture non ci sono e nella GPU "lavorano" in maniera diversa rispetto a semplici array, bisogna usarle in modo adeguato. Da questo derivano considerazioni circa l'inadeguatezza del compilatore usato finora per la grafica e quindi gli shader:
"NVIDIA already had a well-tuned low-level compiler for graphics codes, called OCG (Optimized Code Generator). This handles register allocation, scheduling, and peephole optimizations. This compiler is built into the graphics driver for doing just-in-time compilation of graphic codes. Because graphics codes tend to be relatively simple compared to general purpose C code (control flow has only recently been added to DirectX), and due to the compile-time limitations of needing to compile at runtime, it was decided that CUDA needed a high-level optimizer to handle the compute codes."
Infatti dice che essendo il "graphics code" semplice rispetto al "general purpose C code" (fa riferimento pure al fatto che solo recentemente nel HLSL delle directx è stato inserito l'if-then-else, questo per farvi capire di che dimensione di semplicità stiamo parlando), il compilatore risulta inadeguato e quindi hanno dovuto piazzarci in mezzo qualcosa d'altro. Veniamo ora a due belle cosette: la prima è Il riferimento alla compilazione just-in-time che di primo acchito può essere fourviante, ma anche qui basta ragionarci un po per capire meglio. Il primo dubbio può venire già dal nome just-in-time (al volo), che sembra non lasciare scampo. Per questo è forse sufficiente anche una lettura da wikipedia (inglese) che però non so se basta se si parte a digiuno con l'argomento. Questi compilatori sono utilizzati solitamente per migliorare le prestazioni dei linguaggi INTERPRETATI, cioè che non sono compilati nativamente per la macchina su cui l'applicazione viene eseguita, ma che vengono compilati in, ad esempio, bytecode. Questo codice viene quindi letto dall'interprete che, al volo, lo traduce in linguaggio macchina da eseguire. Che vantaggi comporta tutto ciò? semplice: se scrivo un programma e lo compilo in bytecode, basta avere un interprete di bytecode per ogni piattaforma su cui vorrò fare girare il programma che esso potrà girare senza bisogno di ricompilarlo. Quindi è possibilie scrivere un programma che giri su osx, linux windows, ecc... Un esempio è JAVA. Problemi? prestazioni pestilenziali. E allora? arriva in aiuto la compilazione just-in-time che provvede, durante l'avvio del programma, a compilare il programma da bytecode a codice macchina in modo che, dopo un primo avvio più lento rispetto con un interprete classico, il programma risulti moooolto più svelto (vi ricorda qualcosa questo comportamento?). Assodato che quindi il termine just-in-time non significa quello che può sembrare ad un primo sguardo, passo ora ala seconda considerazione, in cui si fa riferimento ai limiti della compilazione a run-time. Anche qui la questione è chiara: gli shader hanno pochi tipi di dati e semplici, pochi costrutti e sono PICCOLI, cioè composti da poche righe, il tutto ovviamente rapportato a quante linee di codice potrebbe contenere un normale programma, magari commerciale/professionale in ambito, per esempio, di calcolo scientifico. Nei giochi infatti si parla di programmi che devono terminare il loro ciclo di esecuzione anche un centinaio di volte al secondo (i nostri cari fps) di cui per giunta non tutto il tempo è speso in calcoli della GPU, mentre in un classico programma una "operazione" può richiedere un tempo nettamente più lungo, e qui mi sento che di esempi non ne servono. Chiunque poi abbia programmato in linguaggi tipo c/c++ visual basic ecc... sa che in progetti anche di piccole dimensioni la compilazione non è assolutamente una operazione istantanea. Quindi ci si può immaginare se sia di buon auspicio per un cliente avere un tempo di attesa nel lanci dell'applicativo che non si misura certo in frazioni di secondo...
Per cui si è reso necessario un ulteriore stadio di compilazione che potesse rendere il lavoro per il compilatore del Just-in-time del driver sopportabile (quindi in tempi "ragionevoli"). E' da qui che nasce tutto il discorso su Open64 e via discorrendo cosa che quindi non centra assolutamente nulla con il tema del contendere. Tra l'altro in questo caso si tratta proprio di cercare di compilare in maniera "definitiva" la maggior parte del codice (cioè lo fa una volta lo sviluppatore e poi basta), in modo che il grosso del lavoro venga fatto prima di dover utilizzare, ad ogni avvio, il compilatore Just-in-time del driver.
Risulta ora anche chiaro il riferimento alla difficoltà di farlo questo compilatore, con la scelta di optare per implementare una derivazione di Open64: bisogna infatti adattare il dataset del linguaggio c-like a quello per forza di cose ridotto delle GPU. E' sempre riguardo a questo è anche il riferimento a PTX:
"The GPU input is then processed by our Open64 compiler (called nvopencc), which emits an assembly language that we created called PTX (Parallel Thread Execution). PTX provides a virtual machine model that multiple tools can target, and which is independent of the underlying processor. Some important features of PTX are that it has:
• unlimited virtual registers of different sizes,
• explicit memory segments for different levels of sharing between threads,
• no stack or heap,
• strongly typed instructions,
• vector support for memory accesses,
• predication for branching,
• C-like syntax for calls."
Serve infatti come interfaccia al nostro Just-in-time per rendergli il tutto digeribile.
Concludendo (...), non mi sembra che ci sia niente di nuovo su cui discutere. Adesso spero che se qualcuno avesse avuto delle difficoltà a capire la differenza tra interprete e compilatore ora abbia le idee più chiare.
ragazzi, news importanti su date?
yossarian
30-11-2009, 10:56
ah si? veramente qui
e qui
e qui
e qui
e soprattutto qui
sicuramente me ne sono sfuggite altre ma queste bastano e avanzano. Può anche darsi che ti sei spiegato male, tutte le volte. Ritornando al nostro solito (...) argomento, per prima cosa linko il documento in modo che chi se lo voglia leggere integralmente lo possa fare facilmente:
http://www.capsl.udel.edu/conferences/open64/2008/Papers/101.doc
Mi sembra buona norma linkare le fonti, in modo che se c'è qualche volenteroso che ha voglia/tempo/capacità per capire lo possa fare senza sbattersi. Tanto se ho le citazioni vuol dire che ho il documento, per cui linkarlo non mi costa nulla.
Bisogna dire subito che questo paper è riferito a CUDA, e quindi con la grafica non centra nulla. Proprio nulla no ma ci siamo capiti. Conseguenza diretta di questo è che tutte le considerazioni sono riferite alla programmazione general purpose e non ai linguaggi di shading. Infatti già nella prima citazione questa caratteristica emerge subito; se invece di partire da quel punto si legge anche la frase prima, già molte cose risultano più chiare a chi legge:
"CUDA provides a few simple extensions to C/C++ that enables users to specify what part of their program they want to run in parallel on a GPU. The CUDA compiler driver splits an application into two parts, one which is run on the host CPU, and the other which is run on the GPU."
Qua si sta parlando di codice c/c++, quindi assolutamente impossibile da eseguire per qualsiasi GPU. Infatti NVIDIA a fatto delle estensioni al c grazie alle quali il programmatore definisce le parti di codice che, adottando comunque sempre una sintassi c-like, possano essere possibili da eseguire dalle GPU. E quindi il codice viene diviso in 2 parti: quello "normale" che il programmatore ha deciso che sarà eseguito dalla CPU e che segue una via più tradizionale, e quello da dare in pasto tramite CUDA alla GPU.
Anche questo codice però non è gestibile direttamente così com'è (e non sto parlando del fatto che sia un sorgente e non compilato), a causa del possibile/probabile uso di strutture dati/costrutti che la GPU non può eseguire. L'esempio più banale che mi viene in mente è, ad esempio che il GLSL supporta soltanto (almeno fino alle opengl 2.1, ma non credo che dopo la situazione cambi radicalmente, e anche se cambiasse visto che gli shader c'erano anche con le directx9 e opengl 2.1, il discorso deve essere valido) vettori di 4 elementi o matrici fino a 4x4. Dimensioni ridicole per codice general purpose. Ovviamente ci sono le texture, che presumo siano, come negli shader, la via maestra per passare i dati alla GPU; però siccome in c le texture non ci sono e nella GPU "lavorano" in maniera diversa rispetto a semplici array, bisogna usarle in modo adeguato. Da questo derivano considerazioni circa l'inadeguatezza del compilatore usato finora per la grafica e quindi gli shader:
"NVIDIA already had a well-tuned low-level compiler for graphics codes, called OCG (Optimized Code Generator). This handles register allocation, scheduling, and peephole optimizations. This compiler is built into the graphics driver for doing just-in-time compilation of graphic codes. Because graphics codes tend to be relatively simple compared to general purpose C code (control flow has only recently been added to DirectX), and due to the compile-time limitations of needing to compile at runtime, it was decided that CUDA needed a high-level optimizer to handle the compute codes."
Infatti dice che essendo il "graphics code" semplice rispetto al "general purpose C code" (fa riferimento pure al fatto che solo recentemente nel HLSL delle directx è stato inserito l'if-then-else, questo per farvi capire di che dimensione di semplicità stiamo parlando), il compilatore risulta inadeguato e quindi hanno dovuto piazzarci in mezzo qualcosa d'altro. Veniamo ora a due belle cosette: la prima è Il riferimento alla compilazione just-in-time che di primo acchito può essere fourviante, ma anche qui basta ragionarci un po per capire meglio. Il primo dubbio può venire già dal nome just-in-time (al volo), che sembra non lasciare scampo. Per questo è forse sufficiente anche una lettura da wikipedia (inglese) che però non so se basta se si parte a digiuno con l'argomento. Questi compilatori sono utilizzati solitamente per migliorare le prestazioni dei linguaggi INTERPRETATI, cioè che non sono compilati nativamente per la macchina su cui l'applicazione viene eseguita, ma che vengono compilati in, ad esempio, bytecode. Questo codice viene quindi letto dall'interprete che, al volo, lo traduce in linguaggio macchina da eseguire. Che vantaggi comporta tutto ciò? semplice: se scrivo un programma e lo compilo in bytecode, basta avere un interprete di bytecode per ogni piattaforma su cui vorrò fare girare il programma che esso potrà girare senza bisogno di ricompilarlo. Quindi è possibilie scrivere un programma che giri su osx, linux windows, ecc... Un esempio è JAVA. Problemi? prestazioni pestilenziali. E allora? arriva in aiuto la compilazione just-in-time che provvede, durante l'avvio del programma, a compilare il programma da bytecode a codice macchina in modo che, dopo un primo avvio più lento rispetto con un interprete classico, il programma risulti moooolto più svelto (vi ricorda qualcosa questo comportamento?). Assodato che quindi il termine just-in-time non significa quello che può sembrare ad un primo sguardo, passo ora ala seconda considerazione, in cui si fa riferimento ai limiti della compilazione a run-time. Anche qui la questione è chiara: gli shader hanno pochi tipi di dati e semplici, pochi costrutti e sono PICCOLI, cioè composti da poche righe, il tutto ovviamente rapportato a quante linee di codice potrebbe contenere un normale programma, magari commerciale/professionale in ambito, per esempio, di calcolo scientifico. Nei giochi infatti si parla di programmi che devono terminare il loro ciclo di esecuzione anche un centinaio di volte al secondo (i nostri cari fps) di cui per giunta non tutto il tempo è speso in calcoli della GPU, mentre in un classico programma una "operazione" può richiedere un tempo nettamente più lungo, e qui mi sento che di esempi non ne servono. Chiunque poi abbia programmato in linguaggi tipo c/c++ visual basic ecc... sa che in progetti anche di piccole dimensioni la compilazione non è assolutamente una operazione istantanea. Quindi ci si può immaginare se sia di buon auspicio per un cliente avere un tempo di attesa nel lanci dell'applicativo che non si misura certo in frazioni di secondo...
Per cui si è reso necessario un ulteriore stadio di compilazione che potesse rendere il lavoro per il compilatore del Just-in-time del driver sopportabile (quindi in tempi "ragionevoli"). E' da qui che nasce tutto il discorso su Open64 e via discorrendo cosa che quindi non centra assolutamente nulla con il tema del contendere. Tra l'altro in questo caso si tratta proprio di cercare di compilare in maniera "definitiva" la maggior parte del codice (cioè lo fa una volta lo sviluppatore e poi basta), in modo che il grosso del lavoro venga fatto prima di dover utilizzare, ad ogni avvio, il compilatore Just-in-time del driver.
Risulta ora anche chiaro il riferimento alla difficoltà di farlo questo compilatore, con la scelta di optare per implementare una derivazione di Open64: bisogna infatti adattare il dataset del linguaggio c-like a quello per forza di cose ridotto delle GPU. E' sempre riguardo a questo è anche il riferimento a PTX:
"The GPU input is then processed by our Open64 compiler (called nvopencc), which emits an assembly language that we created called PTX (Parallel Thread Execution). PTX provides a virtual machine model that multiple tools can target, and which is independent of the underlying processor. Some important features of PTX are that it has:
• unlimited virtual registers of different sizes,
• explicit memory segments for different levels of sharing between threads,
• no stack or heap,
• strongly typed instructions,
• vector support for memory accesses,
• predication for branching,
• C-like syntax for calls."
Serve infatti come interfaccia al nostro Just-in-time per rendergli il tutto digeribile.
Concludendo (...), non mi sembra che ci sia niente di nuovo su cui discutere. Adesso spero che se qualcuno avesse avuto delle difficoltà a capire la differenza tra interprete e compilatore ora abbia le idee più chiare.
invece io non sto a perdere tempo a quotare tutte le vollte che hai asserito che il compilatore si occupa di effettuare le sostituzioni di cui si sta parlando e che sono l'oggetto del contendere (basta tornare indietro di qualche pagina) né quante volte hai affermato che gli hw vendor si scrivono compilatori ottimizzati per i loro device (nVidia ti dimostra che neppure per cuda, un loro "sistema" proprietario, si sono fatti un compilatore ad hoc ma si appogginao a compilatori standard) e neppure quante volte hai affermato che non aveva senso un doppio stadio di compilazione con ottimizzazioni a valle quando si poteva fare tutto insieme. Dal link che hai riportato è evidente che nVidia non ha modificato o scritto compilatori ad hoc né per cuda né per le gpu ante dx10 ma che ha semplicemente introdotto delle ottimizzazioni a valle delle operazioni di complazione, utilizzndo compilatori standard (cosa che hai ripetutamente negato, arrivando persino a prospettare modifiche al compilatore hlsl di windows).
CUDA non c'entra niente con la grafica? CUDA non è solo GPGPU ma un insieme di architettura SW e microarchitettura HW e serve per ottimizzare anche le operazioni grafiche su gpu (mi spieghi cosa c'entrerebbe, ad esempio, la gestione delle operazioni su texture e la loro allocazione in memoria con applicazioni di tipo gpgpu?). E comunque, grazie ai tool messi a disposizione con cuda ci si può fare un'idea di quelle che sono le operazioni possibili su una gpu (e le preephole optimization rientrano tra queste).
Inoltre, visto che l'oggetto del contendere sono le ottimizzazioni e non la compilazione (mi dici, ripeto, dove avrei scritto che la compilazione è a carico della gpu?) e, in particolare le sostituzioni di MADD con FMA e che queste si effettuano facendo uso di preephole e su linguaggio binario (la cpu può effettuare la traduzione del codice dei prephole, semmai), ti invito a dare un'occhiata a questo link, con l'avvertenza che si tratta di una versione vecchia di cuda e non si quella destinata a girare su Fermi (che non è detto che sia retrocompatibile e, sicuramente, non lo sarà in toto con le gpu dx10).
http://moss.csc.ncsu.edu/~mueller/cluster/nvidia/GPU+CUDA.pdf
dove, a pagina 30, riporta, tra le operazioni svolte a runtime dal device (GPU) le atomic ops, tra cui and, or e confronti tra interi, che servono per eseguire preephole optimization. Le atomic operation sono state introdotte con l'adozione dei compute shader 4.0 (DX10).
Qui, invece, parla dell'adozione di vere e proprie cache (non le L1 e L2 dei chip fino a GT200 che sono solo texture cache) per poter eseguire atomic operations direttamente on chip senza dover accedere continuamente alla vram
http://www.behardware.com/articles/772-5/nvidia-fermi-the-gpu-computing-revolution.html
e qui dell'adozione di puntatori (con CUDA 3.0 e PTX2.0, scritti appositamente per Fermi).
http://www.behardware.com/articles/772-3/nvidia-fermi-the-gpu-computing-revolution.html
Dalla tua invocata wikipedia
http://it.wikipedia.org/wiki/Compilatore_just-in-time
riporto testualmente
In un ambiente JIT la prima fase è costituita dalla compilazione del bytecode, in cui si trasforma il codice sorgente in una rappresentazione intermedia portabile e ottimizzabile, detta appunto bytecode. Successivamente il codice bytecode viene installato sul sistema di destinazione. Quando il codice viene eseguito, il compilatore dell'ambiente di esecuzione lo traduce in codice macchina nativo. La traduzione in codice macchina può avvenire per file o per funzione: le funzioni possono essere compilate solo quando stanno per essere eseguite, da qui il nome just-in-time, ovvero "appena in tempo".
La compilazione just-in-time permette di ottenere un buon compromesso tra velocità d'esecuzione e portabilità del codice. Nella fase di compilazione del bytecode è eseguita la maggior parte del "lavoro pesante", ovvero tutte quelle operazioni che richiedono molto tempo per essere eseguite, come l'analisi sintattica e semantica del codice sorgente e una prima fase di ottimizzazione; la compilazione da bytecode a codice nativo è invece molto più veloce. I compilatori da bytecode a codice macchina (tra cui, appunto, i sistemi JIT) sono più semplici da scrivere perché la maggior parte del lavoro è già stata compiuta dal compilatore che ha prodotto il bytecode; questo, inoltre, rende i programmi in bytecode più facilmente portabili su nuove architetture.
Insomma, secondo le schema di nVidia, c'è un compilatore STANDARD che fa la compilazione in bytecode (chi ha detto che non c'è il compilatore standard?). In questa fase si suole fare le ottimizzazioni ma, abbiamo visto, secondo lo schema adottato da nVidia le cose non stanno così, dato che l'OCG che si occupa delle ottimizzazioni, è a valle della PTX che fa traduzione JIT.
Infine la traduzione JIT prevede che le funzioni siano tradotte al momento in cui stanon essere eseguite (e nel caso di nVidia tradotte e ottimizzate, aggiungerei). Questo significa che la cpu non invia codice già bello e pronto prima dell'esecuzione, perchè il codice bello e pronto arriva solo dopo la compilazione JIT. Se se ne occupa la cpu significa che ciò comporta un traffico continuo tra cpu, ram di sistema, vram e gpu che è prorpio quello che i progettisti di gpu stanno cercando da alcuni anni di evitare come la peste (trasferimento in batch di migliaia di vertici invece di singoli triangoli, texture e cube map array, ecc). Sai cosa me ne frega di quant'è veloce una cpu a fare la sostituzione se poi quell'istruzione arriva alla gpu dopo due giorni? Non si può teorizzare senza avere bene in mente il sistema fisico su cui si deve operare e i suoi colli di bottiglia (e il canale tra cpue gpu, nonostante il pci-express, è uno dei peggiori).
Quindi la sostituzione di madd con fma, semmai si farà e se sarà possibile, sarà fatta in runtime dalla gpu e direttamente on chip. (come sto dicendo da 10 pagine), dal momento che fermi, a detta della stessa nVidia, pare perfettamente in grado di fare preephole optimizzation direttamente on chip.
ragazzi, news importanti su date?
mmm non credo se non si trovano sui maggiori siti di hw.. (quindi escluso fudzilla che la dava x gennaio in step A3) XD
in effetti è qualche settimana che non si hanno notizie. :rolleyes:
Andrea deluxe
30-11-2009, 11:55
nVidia dice Gennaio.
Se lo stepping A2 funziona è possibile con disponibilità irrisorie giusto per la stampa e reale disponibilità in febbraio.
Se come si dice da alcune fonti non confermate è nessaria una versione A3 è possibile che la presentazione venga comunque fatta per la stampa con la A2 a gennaio, ma per vederle sugli scaffali toccherà aspettare almeno fine marzo nella migliore delle ipotesi, giugno nella peggiore, obiettivamente fra aprile e maggio sempra l'ipotesi più consistente.
e perché ci vorrebbe tutto sto tempo?
nVidia dice Gennaio.
Se lo stepping A2 funziona è possibile con disponibilità irrisorie giusto per la stampa e reale disponibilità in febbraio.
Se come si dice da alcune fonti non confermate è nessaria una versione A3 è possibile che la presentazione venga comunque fatta per la stampa con la A2 a gennaio, ma per vederle sugli scaffali toccherà aspettare almeno fine marzo nella migliore delle ipotesi, giugno nella peggiore, obiettivamente fra aprile e maggio sempra l'ipotesi più consistente.
ok grazie... nvidia, ci vediamo al prossimo giro :(
Oggi a Milano.....ore 16.00.....Nvidia....speriamo bene.;)
konzendoji
30-11-2009, 13:38
ok grazie... nvidia, ci vediamo al prossimo giro :(
io mi tengo la mia giusto perchè ho 1gb di ram
cmq fai bene...sono d'accordo con te...nVidia se lo merita di perdere fette di mercato!
I propri clienti li considera meno di quella cosa che si pesta accidentalmente ai giardinetti...
E poi è l'ora che perda un po', giusto per rimboccarsi le maniche e per mettere prezzi decenti
Bastoner
30-11-2009, 14:00
PhysX, 3DVision, FTW, KickAss?
Lol :asd:
Kickass fa ridere :D
konzendoji
30-11-2009, 14:01
PhysX, 3DVision, FTW, KickAss?
In effetti non so cosa possa presentare nvidia oggi alle 16:00 a milano :sofico:
In effetti non so cosa possa presentare nvidia oggi alle 16:00 a milano :sofico:
fanno una presentazione sulle vecchie glorie fino alla 8800!
:Prrr:
fanno una presentazione sulle vecchie glorie fino alla 8800!
:Prrr:
Si, test in anteprima della NUOVISSIMA nvidia TNT con 16 MB di sdram onboard!!! :rolleyes:
A sto giro ha fatto veramente una figura da cioccolataia che metà basta... :rolleyes: :rolleyes: :rolleyes:
PhysX, 3DVision, FTW, KickAss?
bisogna vedere cosa succede se poi alla fine esce e fa il sedere a tutti come reagirà la clientela ? :D
bisogna vedere cosa succede se poi alla fine esce e fa il sedere a tutti come reagirà la clientela ? :D
Si, vabbè, ma se vanno avanti così ora che esce sarà diventato obsoleto proprio il concetto di VGA... :rolleyes:
Non è che se arrivano un anno dopo c'è poi da stupirsi che vada più forte, e ci mancherebbe altro...
No no, per me sto giro hanno fatto proprio una gran bella figuraccia, e da nvidia-ista da ani, mi sa che stavolta li mollo..
paolox86
30-11-2009, 15:49
E' si, che vuoi che presentino a Milano.... Probabilmente dimostreranno che, basandosi sulle configurazioni hardware medie degli italiani, il loro prodotto che si addice meglio per non essere CPU limited è il Geforce 4 Ti 4600 :D
Legolas84
30-11-2009, 15:49
Si, vabbè, ma se vanno avanti così ora che esce sarà diventato obsoleto proprio il concetto di VGA... :rolleyes:
Non è che se arrivano un anno dopo c'è poi da stupirsi che vada più forte, e ci mancherebbe altro...
No no, per me sto giro hanno fatto proprio una gran bella figuraccia, e da nvidia-ista da ani, mi sa che stavolta li mollo..
nvidia-ista da ani...... lol chissà che mestiere è :asd:
nvidia-ista da ani...... lol chissà che mestiere è :asd:
AZZ!! Che erroraccio..
Sorry....
Comunque no, non è quel mestiere li...
Vabbè che in sto periodo va di moda eh, però però...
skizzo99999999
30-11-2009, 16:00
invece io non sto a perdere tempo a quotare tutte le vollte che hai asserito che il compilatore si occupa di effettuare le sostituzioni di cui si sta parlando e che sono l'oggetto del contendere (basta tornare indietro di qualcje pagina) né quante volte hai affermato che gli hw vendor si scrivono compilatori ottimizzati per i loro device.
io ho quotato perchè tu avevi negato di avere detto che il driver non poteva pilotare la CPU. Io invece non nego affatto quello che ho riportato sopra, anzi è proprio questo (come hai detto) l'oggetto del contendere, quindi che significato ha negarlo da parte mia? se lo negassi, automaticamente sarei daccordo con te e non posterei più. Quindi confermo, che il compilatore all'interno del driver si occupa di fare le sostituzioni e che gli hw vendor si scrivono compilatori ottimizzati per i loro device (quello che nei post precendenti abbiamo chiamato il compilatore just-in-time). Non mi sembra necessario ribadirlo tutte le volte, visto che non ho cambiato idea.
Dal link che hai riportato è evidente che nVidia non ha modificato o scritto compilatori ad hoc né per cuda né per le gpu ante dx10 ma che ha semplicemente introdotto delle ottimizzazioni a valle delle operazioni di complazione, utilizzndo compilatori standard (cosa che hai ripetutamente negato, arrivando persino a prospettare modifiche al compilatore hlsl di windows).
Dal link che ho riportato (che è solo il documento completo da cui avevi prima perso le citazioni tu in precedenza) è spiegato che NVIDIA ha modificato adattato open64. Non so se sono i termini più appropriati, ma non penso che gli sia andato perfetto open64, visto che viene detto "We use a subset of Open64" e quindi almeno un taglia e cuci lo hanno fatto, ma non mi sembra che per i nostri scopi si debba andare in dettaglio su questo aspetto, visto che tra l'altro nelle operazioni grafiche tutta sta roba descritta nel documento non si usa (come ho cercato di spiegare nel post precedente già kilometrico abbastanza), ma essa deriva dal fatto che in cuda vengono utilizzate strutture dati che non ci sono in HLSL e GLSL, per cui per i relativi compilatori nei driver sarebbe tutto inutilizzabile, e a modificarli per digerire il tutto a runtime (perchè appunto il JIT del driver va a run-time) renderebbe l'operazione ovviamente troppo lenta. Si è quindi operata questa scelta di piazzare questo ulteriore strato software tra il jit ed il codice che facesse gran parte del lavoro e snellire quello necessario a a run-time. Ma ste cose le ho spiegate meglio nel post precedente per cui mi sembra già di essermi ripetuto a sufficienza. Poi ovvio che NVIDIA non avesse fatto un lavoro del genere per GPU precedenti alle directx10 (per g80), perchè, non essendoci CUDA e interesse verso il GPGPU, non serviva.
Voglio però ritornare velocemente alla questione del compilatore standard HLSL. riporto nuovamente i 2 grafici che ho già linkato:
HLSL (directx)
http://img109.imageshack.us/img109/2233/grafico.jpg
GLSL (opengl, il discorso continua poi nelle altre 2 pagine seguenti)
http://img69.imageshack.us/img69/5382/45128354.jpg
siccome quando la discussione è partita pensavo di dover solo fare una puntualizzazione veloce e non sta opera enciclopedica, ho parlato solo (l'ho specificato quasi subito) di opengl visto che è l'ambito che conosco bene. Andando poi a pescare le fonti di quello che stavo spiegando sono incappato in una breve descrizione dello schema delle directx che è leggermente diverso ma non sposta in modo sostanziale il problema. Qualche post fa sono sicuro di avere accennato alla questione ma vedendo questa domanda o non è stata letto il pezzo in questione o non sono stato abbastanza chiaro.
In entrambi i mondi è sempre nel driver che avviene la compilazione dello shader, infatti la frecetta del graphics hardware viene dubito dopo. Quello che è diverso, è che in opengl il source dello shader GLSL arriva direttamente nel driver, l'operazione di compilazione in linguaggio macchina avviene tutta li. In HLSL invece c'è "l'HLSL translator" che effettua una prima traduzione, ma che ovviamente non può essere in linguaggio macchina perchè essendo quel modulo uguale per tutti non può compilare per tutti (la compilazione è una operazione "su misura"). In pratica fa qualcosa tipo il bytecode del JAVA. Questo codice passa al driver (che come nel caso dell'opengl è prodotto dal "graphics hardware vendor") che si preoccupa di compilare lo shader nel linguaggio macchina. Alla fine il risultato è il medesimo in entrambi i casi. In una delle pagine successive (mi sembra in quella dopo) si fa un ragionamento su quale approccio sia preferibile. Essendo il libro di riferimento delle opengl, non ci sono dubbi su quale sia l'approccio che venga reputato migliore (ognuno tira l'acqua al suo mulino), ma i concetti hanno validità generale. L'approccio opengl è sicuramente più oneroso per quanto riguarda il compilatore del driver, visto che deve eseguire a run-time la completa conversione dalle istruzioni ad alto livello al linguaggio macchina. Quindi o risulta più lento (il che non comporta frame-rate minori visto che viene fatta una volta sola, ma comunque non può essere lento oltre un certo limite) oppure "ottimizza" meno (anche se è un termine troppo semplicistico ma ci siamo capiti). In HLSL invece il compito del driver è molto più leggero perchè il grosso del lavoro lo ha fatto l'HLSL translator (che può metterci quanto gli pare visto che può non essere eseguito a runtime e quindi rentere il codice più compatto possibile). Il difetto di questo approccio è che se l'architettura della GPU diverge troppo dal generico modello di calcolo previsto dal codice "intermedio" che gli arriva al driver, allora quest'ultimo lo adatterebbe sicuramente peggio che in opengl, non avendo le informazioni del sorgente ma solo il codice uscito dal translator (si perde parecchia informazione).
Se quindi non ci fossero limiti di tempo, sicuramente l'approccio GLSL sarebbe nettamente superiore, ma visto che non può metterci ore (è una battuta) per compilare, allora il risultato dipende appunto dal bilanciamento complessità della GPU/tempo a disposizione.
Quindi nessuno dei due approcci è in modo totale migliore dell'altro.
Ritornando all'argomento del quote, io non ho mai detto (e se l'ho detto mi sono sbagliato) che viene modificato il traduttore HLSL di windows, ho fatto sempre riferimento a quello del driver, responsabile in entrambni i casi della generazione del codice macchina.
(mi spieghi cosa c'entrerebbe, ad esempio, la gestione delle operazioni su texture e la loro allocazione in memoria con applicazioni di tipo gpgpu?)
http://www.mathematik.uni-dortmund.de/~goeddeke/gpgpu/tutorial.html
il GPGPU si faceva anche prima dell'avvento degli shader unificati quindi di cuda, il quale ha solo aggiunto un livello di astrazione e reso + semplice per il programmatore non perdersi in tecnicismi prettamente grafici (come appunto le texture) ma che sono la via privilegiata per la GPU di ricevere i dati. Non penso che cuda "internamente" lavori molto diversamente, ma rende più semplice la vita allo sviluppatore, oltre certamente, vista la maggiore attenzione delle nuove GPU al mondo general purpose, a offrire qualcosa in più ma che non dipende da cuda ma dall'HW sottostante. Non conosco però dettagliatamente CUDA per esprimere giudizi definitivi in merito, ma non capisco perchè inserire tutto nel caldernone di questa discussione che ha un argomento ben preciso e focalizzato. Alla fine il risultato è solo confondere le idee a chi ci legge.
Inoltre, visto che l'oggetto del contendere sono le ottimizzazioni e non la compilazione (mi dici, ripeto, dove avrei scritto che la compilazione è a carico della gpu?)
Visto che prima hai detto che ho perso tempo a quotare tutte le volte che hai detto/negato un certo fatto, stavolta passo. Comunque così papale papale non so se l'hai mai detto, ma io ho capito così dai tuoi numerosi post. L'oggetto del contendere però è proprio la fase di compilazione, in cui vengono svolte le prime "ottimizzazioni" e che viene fatta dal compiler del driver (che non fa niente di generico o standard). Siccome tra tutto quello che mi viene in mente una eventuale brutale sostituzione MADD->FMA è la cosa più semplice possibile e per giusta senza nessun problema di analisi del flusso o balle varie (tipo: sto compilando una riga in cui ci sono moltiplicazioni e somme di vec4, quindi ci saranno fiumi di madd. Il compilatore sarà quindi stato programmato per produrre in uscita assembler con FMA invece che MADD), sicuramente se si farà la si farà a questo livello. Quindi come vedi la questione è la compilazione.
Le due pagine dell'articolo che hai linkato e il pdf riguardano sempre la questione CUDA-GPGPU di cui ho già parlato sopra e, meglio, nel post precedente, e che non centra nulla con quello di cui stiamo discutendo.
Comunque oltre a yoss qualcuno legge quello che scrivo? sennò tutto sto casino per una persona sola lo rende spam e basta
yossarian
30-11-2009, 16:00
Si, vabbè, ma se vanno avanti così ora che esce sarà diventato obsoleto proprio il concetto di VGA... :rolleyes:
Non è che se arrivano un anno dopo c'è poi da stupirsi che vada più forte, e ci mancherebbe altro...
No no, per me sto giro hanno fatto proprio una gran bella figuraccia, e da nvidia-ista da ani, mi sa che stavolta li mollo..
in realtà fermi rappresenta il primo step di un progetto che si propne proprio di rendere obsoleto il concetto di vga e di chip grafico. :D
in realtà fermi rappresenta il primo step di un progetto che si propne proprio di rendere obsoleto il concetto di vga e di chip grafico. :D
Mah, per ora mi sa solo di gran ciofecata, spero comunque di sbagliarmi, sia ben chairo..
nvidia-ista da ani...... lol chissà che mestiere è :asd:
Il mestiere di chi basandosi su sigle che a logica dovrebbero informare compra il nuovo modello e scopre che è vecchio?
yossarian
30-11-2009, 16:16
io ho quotato perchè tu avevi negato di avere detto che il driver non poteva pilotare la CPU. Io invece non nego affatto quello che ho riportato sopra, anzi è proprio questo (come hai detto) l'oggetto del contendere, quindi che significato ha negarlo da parte mia? se lo negassi, automaticamente sarei daccordo con te e non posterei più. Quindi confermo, che il compilatore all'interno del driver si occupa di fare le sostituzioni e che gli hw vendor si scrivono compilatori ottimizzati per i loro device (quello che nei post precendenti abbiamo chiamato il compilatore just-in-time). Non mi sembra necessario ribadirlo tutte le volte, visto che non ho cambiato idea.
Dal link che ho riportato (che è solo il documento completo da cui avevi prima perso le citazioni tu in precedenza) è spiegato che NVIDIA ha modificato adattato open64. Non so se sono i termini più appropriati, ma non penso che gli sia andato perfetto open64, visto che viene detto "We use a subset of Open64" e quindi almeno un taglia e cuci lo hanno fatto, ma non mi sembra che per i nostri scopi si debba andare in dettaglio su questo aspetto, visto che tra l'altro nelle operazioni grafiche tutta sta roba descritta nel documento non si usa (come ho cercato di spiegare nel post precedente già kilometrico abbastanza), ma essa deriva dal fatto che in cuda vengono utilizzate strutture dati che non ci sono in HLSL e GLSL, per cui per i relativi compilatori nei driver sarebbe tutto inutilizzabile, e a modificarli per digerire il tutto a runtime (perchè appunto il JIT del driver va a run-time) renderebbe l'operazione ovviamente troppo lenta. Si è quindi operata questa scelta di piazzare questo ulteriore strato software tra il jit ed il codice che facesse gran parte del lavoro e snellire quello necessario a a run-time. Ma ste cose le ho spiegate meglio nel post precedente per cui mi sembra già di essermi ripetuto a sufficienza. Poi ovvio che NVIDIA non avesse fatto un lavoro del genere per GPU precedenti alle directx10 (per g80), perchè, non essendoci CUDA e interesse verso il GPGPU, non serviva.
Voglio però ritornare velocemente alla questione del compilatore standard HLSL. riporto nuovamente i 2 grafici che ho già linkato:
HLSL (directx)
http://img109.imageshack.us/img109/2233/grafico.jpg
GLSL (opengl, il discorso continua poi nelle altre 2 pagine seguenti)
http://img69.imageshack.us/img69/5382/45128354.jpg
siccome quando la discussione è partita pensavo di dover solo fare una puntualizzazione veloce e non sta opera enciclopedica, ho parlato solo (l'ho specificato quasi subito) di opengl visto che è l'ambito che conosco bene. Andando poi a pescare le fonti di quello che stavo spiegando sono incappato in una breve descrizione dello schema delle directx che è leggermente diverso ma non sposta in modo sostanziale il problema. Qualche post fa sono sicuro di avere accennato alla questione ma vedendo questa domanda o non è stata letto il pezzo in questione o non sono stato abbastanza chiaro.
In entrambi i mondi è sempre nel driver che avviene la compilazione dello shader, infatti la frecetta del graphics hardware viene dubito dopo. Quello che è diverso, è che in opengl il source dello shader GLSL arriva direttamente nel driver, l'operazione di compilazione in linguaggio macchina avviene tutta li. In HLSL invece c'è "l'HLSL translator" che effettua una prima traduzione, ma che ovviamente non può essere in linguaggio macchina perchè essendo quel modulo uguale per tutti non può compilare per tutti (la compilazione è una operazione "su misura"). In pratica fa qualcosa tipo il bytecode del JAVA. Questo codice passa al driver (che come nel caso dell'opengl è prodotto dal "graphics hardware vendor") che si preoccupa di compilare lo shader nel linguaggio macchina. Alla fine il risultato è il medesimo in entrambi i casi. In una delle pagine successive (mi sembra in quella dopo) si fa un ragionamento su quale approccio sia preferibile. Essendo il libro di riferimento delle opengl, non ci sono dubbi su quale sia l'approccio che venga reputato migliore (ognuno tira l'acqua al suo mulino), ma i concetti hanno validità generale. L'approccio opengl è sicuramente più oneroso per quanto riguarda il compilatore del driver, visto che deve eseguire a run-time la completa conversione dalle istruzioni ad alto livello al linguaggio macchina. Quindi o risulta più lento (il che non comporta frame-rate minori visto che viene fatta una volta sola, ma comunque non può essere lento oltre un certo limite) oppure "ottimizza" meno (anche se è un termine troppo semplicistico ma ci siamo capiti). In HLSL invece il compito del driver è molto più leggero perchè il grosso del lavoro lo ha fatto l'HLSL translator (che può metterci quanto gli pare visto che può non essere eseguito a runtime e quindi rentere il codice più compatto possibile). Il difetto di questo approccio è che se l'architettura della GPU diverge troppo dal generico modello di calcolo previsto dal codice "intermedio" che gli arriva al driver, allora quest'ultimo lo adatterebbe sicuramente peggio che in opengl, non avendo le informazioni del sorgente ma solo il codice uscito dal translator (si perde parecchia informazione).
Se quindi non ci fossero limiti di tempo, sicuramente l'approccio GLSL sarebbe nettamente superiore, ma visto che non può metterci ore (è una battuta) per compilare, allora il risultato dipende appunto dal bilanciamento complessità della GPU/tempo a disposizione.
Quindi nessuno dei due approcci è in modo totale migliore dell'altro.
Ritornando all'argomento del quote, io non ho mai detto (e se l'ho detto mi sono sbagliato) che viene modificato il traduttore HLSL di windows, ho fatto sempre riferimento a quello del driver, responsabile in entrambni i casi della generazione del codice macchina.
http://www.mathematik.uni-dortmund.de/~goeddeke/gpgpu/tutorial.html
il GPGPU si faceva anche prima dell'avvento degli shader unificati quindi di cuda, il quale ha solo aggiunto un livello di astrazione e reso + semplice per il programmatore non perdersi in tecnicismi prettamente grafici (come appunto le texture) ma che sono la via privilegiata per la GPU di ricevere i dati. Non penso che cuda "internamente" lavori molto diversamente, ma rende più semplice la vita allo sviluppatore, oltre certamente, vista la maggiore attenzione delle nuove GPU al mondo general purpose, a offrire qualcosa in più ma che non dipende da cuda ma dall'HW sottostante. Non conosco però dettagliatamente CUDA per esprimere giudizi definitivi in merito, ma non capisco perchè inserire tutto nel caldernone di questa discussione che ha un argomento ben preciso e focalizzato. Alla fine il risultato è solo confondere le idee a chi ci legge.
Visto che prima hai detto che ho perso tempo a quotare tutte le volte che hai detto/negato un certo fatto, stavolta passo. Comunque così papale papale non so se l'hai mai detto, ma io ho capito così dai tuoi numerosi post. L'oggetto del contendere però è proprio la fase di compilazione, in cui vengono svolte le prime "ottimizzazioni" e che viene fatta dal compiler del driver (che non fa niente di generico o standard). Siccome tra tutto quello che mi viene in mente una eventuale brutale sostituzione MADD->FMA è la cosa più semplice possibile e per giusta senza nessun problema di analisi del flusso o balle varie (tipo: sto compilando una riga in cui ci sono moltiplicazioni e somme di vec4, quindi ci saranno fiumi di madd. Il compilatore sarà quindi stato programmato per produrre in uscita assembler con FMA invece che MADD), sicuramente se si farà la si farà a questo livello. Quindi come vedi la questione è la compilazione.
Le due pagine dell'articolo che hai linkato e il pdf riguardano sempre la questione CUDA-GPGPU di cui ho già parlato sopra e, meglio, nel post precedente, e che non centra nulla con quello di cui stiamo discutendo.
Comunque oltre a yoss qualcuno legge quello che scrivo? sennò tutto sto casino per una persona sola lo rende spam e basta
allora mi sa che hai frainteso tutto: l'oggetto del contendere erano solo le sostituzioni di madd con fma. Tu ritieni che saranno fatte (se saranno fatte) in sede di compilazione dalla cpu, io, in base a quello che so su fermi e a quello che so (riportato dai vari documenti linkati) sul modo di ottimizzare da parte di nVidia e non solo (anche ATi fa lo stesso: compilatore generico, VM, compilatore JIT e ottimizzazioni; lo schema che hai linkato nell'immagine rappresenta degli step teorici ma allo stesso risultato si può arrivare in tanti modi e ti assicuro che nessuno si mette a scrivere compilatori o a modificarne di esistenti quando basta molto meno per fare le ottimizzazioni necessarie), ritengo, invece, che sarà il chip grafico a fare materialmente la sostituzione. So bene che la può fare anche la cpu ma non è affatto conveniente che sia la cpu a farla. Per quael motivo si deve mettere mano ad un compilatore quando bastano poche righe di codice inserite in un optimizer a valle del compilatore, per ottenere lo stesso risultato? Inoltre, come detto, i preephole lavorano su linguaggio binario e quindi sono perfettamente digeribili anche da gpu meno flessibili e programmabili di fermi.
Ripeto, CUDA serve a capire come funziona una gpu (nVidia nella fattispecie) e cosa può fare.
Ora abbiamo appurato che esiste un compilatore standard (OPEN64, HLSL, GLSL) che fa una prima compilazione e sappiamo che le preephole optimizatin sono fatte dall'OCG su linguaggio binario (c'è scritto esplicitamente). l'OCG è a valle della PTX (quindi agisce dopo la compilazione JIT) e le preephole optimization si servono di quelle che sono definite atomic ops sugli interi (and, or, compare) e di salti condizionati. Fermi gestisce alla perfezione entrambe le cose (ha una gestione dei predicate cpu like). Quindi non ha nessuna difficoltà ad effettuare la sostituzione al volo sulla singola istruzione quando viene chiamata. E questo riduce anche il traffico tra cpu e gpu.
Non vedo una sola buona ragione per cui debba essere la cpu ad effettuarla in sede di compilazione JIT.
EDIT
aggiungo, sempre da wikipedia
http://en.wikipedia.org/wiki/Just-in-time_compilation
i vantaggi della compilazione JIT
1. The compilation can be optimized to the targeted CPU and the operating system model where the application runs. For example JIT can choose SSE2 CPU instructions when it detects that the CPU supports them. To obtain this level of optimization specificity with a static compiler, one must either compile a binary for each intended platform/architecture, or else include multiple versions of portions of the code within a single binary.
2. The system is able to collect statistics about how the program is actually running in the environment it is in, and it can rearrange and recompile for optimum performance. However, some static compilers can also take profile information as input.
3. The system can do global code optimizations (e.g. inlining of library functions) without losing the advantages of dynamic linking and without the overheads inherent to static compilers and linkers. Specifically, when doing global inline substitutions, a static compiler must insert run-time checks and ensure that a virtual call would occur if the actual class of the object overrides the inlined method (however, this need not be the case for languages employing a static type discipline).
4. Although this is possible with statically compiled garbage collected languages, a bytecode system can more easily rearrange memory for better cache utilization..
ovviamente cpu va sostituita con gpu. In particolare, i due punti in neretto rappresentano due dei motivi principali per cui è opportuno che sia la gpu a fare le ottimizzazioni, quando possibile. Il punto 2 parla di riarrangiare al volo il codice per meglio ottimizzare l'elaborazione (ce lo vedi il bus pci intasato dall'andirivieni tra cpu e gpu? E i continui load/store tra vram e gpu a botta di 500-600 cicli per volta?). Il punto 4 parla di miglior utilizzo della cache (con ovvio riferimento alla cpu; ma in questo caso è la cpu stessa che gestisce tutto e ottimizza la propria cache. Nel caso in questione, la cpu non ha accesso alcuno alla cache interna della gpu). Quindi, questo tipo di operazioni può farle solo la gpu stessa.
Come vedi, non vale il discorso del codice già bello e pronto da essere usato e, tanto meno, è pensabile la gestione JIT da parte della cpu di buona parte delle ottimizzazioni. Nel caso specifico della sostituzione delle madd con fma ho già detto quello che penso: fa parte di quelle ottimizzazioni a carico delle gpu, anche perchè rientrano tra quelle che obbligano a riarrangiare la gestione dei thread in corso di elaborazione (i dati sono elaborati in maniera dinamica e un insieme di vertici ne può generare uno molto più grande, oppure da un vertice possono venir fuori un gran numero di pixel e solo il thread processor della gpu può decidere in che ordine far eseguire le relative istruzioni e, di conseguenza, come distribuire e allocare le risorse).
In quanto all'ultima frase, mi sa che nessuno ci sta filando e per quanto mi riguarda, possiamo chiuderla, visto che siamo ad un punto morto :D
Il mestiere di chi basandosi su sigle che a logica dovrebbero informare compra il nuovo modello e scopre che è vecchio?
A no caro mio, non ci penso proprio, compro solo se ne vale la pena, non per brand..
Infatti hosempre avuto nvidia dai tempi della TNT perchè secondo me più performante, a parte il periodo ATI 9700-9800 in cui sono passato al rosso perchè nettamente migliore ATI all'epoca...
E mi sa che a sto giro la storia si ripererà con il rapporto 5870 / GT 300: 9700 bis?:mbe:
Vivete sereni, siete gli unici che scrivono cose interessanti! Criptiche per i profani, ma interessanti!
Drakogian
30-11-2009, 16:25
... cut ...
Comunque oltre a yoss qualcuno legge quello che scrivo? sennò tutto sto casino per una persona sola lo rende spam e basta
... cut...
In quanto all'ultima frase, mi sa che nessuno ci sta filando e per quanto mi riguarda, possiamo chiuderla, visto che siamo ad un punto morto :D
Io vi leggo... anzi molte volte vi "rileggo"... indovinate perchè... :D
Sempre in rispettoso silenzio.... ;)
Scherzi a parte... l'argomento è ostico però qualcosa si imparara sempre... andate avanti.
Dieghen620
30-11-2009, 16:33
Io vi leggo... anzi molte volte vi "rileggo"... indovinate perchè... :D
Sempre in rispettoso silenzio.... ;)
Scherzi a parte... l'argomento è ostico però qualcosa si imparara sempre... andate avanti.
Quotone anche da parte mia... non ci capisco na mazza, ma ogni tanto qualche concetto lo afferro... :asd:
Vorrei che però si arrivaste ad un punto in cui sono tutti d'accordo... in fondo è naturale che sia così se si discute tra persone ragionevoli, no? Soprattutto visto che si parla di questioni tecniche e quindi dimostrabili...
yossarian
30-11-2009, 17:01
Quotone anche da parte mia... non ci capisco na mazza, ma ogni tanto qualche concetto lo afferro... :asd:
Vorrei che però si arrivaste ad un punto in cui sono tutti d'accordo... in fondo è naturale che sia così se si discute tra persone ragionevoli, no? Soprattutto visto che si parla di questioni tecniche e quindi dimostrabili...
anche i problemi tecnici si possono risolvere in tanti modi differenti; tutto sta a vedere quale sia meglio in quello specifico contesto.
Diobrando_21
30-11-2009, 17:34
allora mi sa che hai frainteso tutto: l'oggetto del contendere erano solo le sostituzioni di madd con fma. Tu ritieni che saranno fatte (se saranno fatte) in sede di compilazione dalla cpu, io, in base a quello che so su fermi e a quello che so (riportato dai vari documenti linkati) sul modo di ottimizzare da parte di nVidia e non solo (anche ATi fa lo stesso: compilatore generico, VM, compilatore JIT e ottimizzazioni; lo schema che hai linkato nell'immagine rappresenta degli step teorici ma allo stesso risultato si può arrivare in tanti modi e ti assicuro che nessuno si mette a scrivere compilatori o a modificarne di esistenti quando basta molto meno per fare le ottimizzazioni necessarie), ritengo, invece, che sarà il chip grafico a fare materialmente la sostituzione. So bene che la può fare anche la cpu ma non è affatto conveniente che sia la cpu a farla. Per quael motivo si deve mettere mano ad un compilatore quando bastano poche righe di codice inserite in un optimizer a valle del compilatore, per ottenere lo stesso risultato? Inoltre, come detto, i preephole lavorano su linguaggio binario e quindi sono perfettamente digeribili anche da gpu meno flessibili e programmabili di fermi.
Ripeto, CUDA serve a capire come funziona una gpu (nVidia nella fattispecie) e cosa può fare.
Ora abbiamo appurato che esiste un compilatore standard (OPEN64, HLSL, GLSL) che fa una prima compilazione e sappiamo che le preephole optimizatin sono fatte dall'OCG su linguaggio binario (c'è scritto esplicitamente). l'OCG è a valle della PTX (quindi agisce dopo la compilazione JIT) e le preephole optimization si servono di quelle che sono definite atomic ops sugli interi (and, or, compare) e di salti condizionati. Fermi gestisce alla perfezione entrambe le cose (ha una gestione dei predicate cpu like). Quindi non ha nessuna difficoltà ad effettuare la sostituzione al volo sulla singola istruzione quando viene chiamata. E questo riduce anche il traffico tra cpu e gpu.
Non vedo una sola buona ragione per cui debba essere la cpu ad effettuarla in sede di compilazione JIT.
In quanto all'ultima frase, mi sa che nessuno ci sta filando e per quanto mi riguarda, possiamo chiuderla, visto che siamo ad un punto morto :D
no xké dovete chiuderla? Io vi sto seguendo, a stento ma vi seguo e qualche cosa la sto anche capendo (a grandi linee :D)...e a quanto pare nn sono l'unico, continuate pure ;)
BebeMatley
30-11-2009, 18:21
In quanto all'ultima frase, mi sa che nessuno ci sta filando e per quanto mi riguarda, possiamo chiuderla, visto che siamo ad un punto morto :D
Anche io vi seguo in silenzio, riesco a seguire abbastanza il ragionamento ma non mi sento in grado di appoggiare una o l'altra tesi.
Sottolineo come altri che una discussione così sul forum non si vedeva da un bel pò.
Ciao e grazie
maurilio968
30-11-2009, 19:13
Vorrei comunque ringraziare sia Yossarian che skizzo per questa discussione che a me sembra molto interessante.
mi autoquoto, è da un bel po che vi seguo.
Molti di noi non intervengono attivamente semplicemente perchè...non possono.
A stento vio seguiamo ma è l'occasione giusta per avvicinarsi a temi ostici che ci appassionano.
scusate non so se avete notato ma nel sito tutti gli stream processor sono stai rinominati come cuda core, perciò chi vi ha detto che questi stream siano diversi e non solo una rinominazione.
scusate non so se avete notato ma nel sito tutti gli stream processor sono stai rinominati come cuda core, perciò chi vi ha detto che questi stream siano diversi e non solo una rinominazione.
Cosa cambia lo ha già detto in maniera ufficiale NVidia... :)
Stiamo parlando di quello da n pagine... ;)
l'articolo dice : "Sviluppiamo ora quelle che sono le caratteristiche architetturali della nuova architettura Fermi di NVIDIA, alla luce di quello che il produttore ha sino ad ora reso disponibile per il pubblico. Partiamo dal numero di stream processors, passato dai precedenti 240 delle achitetture GT200 agli attuali 512; NVIDIA ha scelto di chiamare questi componenti come CUDA Cores e non più come stream processors, ma di fatto sono la stessa cosa in termini di architettura della GPU ".
probabilmente organizzati in modo differente ma allora perchè dite che l'efficienza di questi CUDA core sono incerti rispetto a quelli di GT200 ? da quel che mi è smebrato è parsa più un evoluzione del Gt200.
yossarian
30-11-2009, 21:36
scusate non so se avete notato ma nel sito tutti gli stream processor sono stai rinominati come cuda core, perciò chi vi ha detto che questi stream siano diversi e non solo una rinominazione.
sono diversi
Cosa cambia lo ha già detto in maniera ufficiale NVidia... :)
Stiamo parlando di quello da n pagine... ;)
è stato detto qualcosa, qualcos'altro si può leggere tra le righe ;)
l'articolo dice : "Sviluppiamo ora quelle che sono le caratteristiche architetturali della nuova architettura Fermi di NVIDIA, alla luce di quello che il produttore ha sino ad ora reso disponibile per il pubblico. Partiamo dal numero di stream processors, passato dai precedenti 240 delle achitetture GT200 agli attuali 512; NVIDIA ha scelto di chiamare questi componenti come CUDA Cores e non più come stream processors, ma di fatto sono la stessa cosa in termini di architettura della GPU ".
probabilmente organizzati in modo differente ma allora perchè dite che l'efficienza di questi CUDA core sono incerti rispetto a quelli di GT200 ? da quel che mi è smebrato è parsa più un evoluzione del Gt200.
fermi è un'altra architettura. GT200 è l'ultimo step della vecchia, GT300 il primo della nuova
CUDA core è solo una rinominazione da quanto ho capito ma sono quasi i medesimi o dei derivati degli stream da GT200.
Quindi se sono dichiarati 512 stream effettivamente potrebbe voler dire molto a livello di prestazione.
nessuno ha mai negato che il driver contenga istruzioni per la cpu. Semmai è il contrrio; quello che sostengo è che la cpu non fa una cippa di ottimizzazione all'atto della compilazione e che il driver contiene anche istruzioni per la gpu e sono questa a contenere le ottimizzazioni.
Che è quello che parzialmente sostengo anch'io, e mi sembrava d'averlo già scritto ovvero:
- Il gioco fa indirettamente una chiamata ai driver per inviare lo shader alla gpu
- Il driver nell'ambito dell'esecuzione della chiamata usando codice assembler x86/x64, rimpiazza le madd con le fma e prepara le istruzioni per la gpu che conterranno quindi le ottimizzazioni.
- Il driver invia le istruzioni ottimizzate alla gpu.
Parzialmente in quanto la teoria che i driver contengano staticamente già le istruzioni per la gpu ottimizzate mi sembra poco probabile, e, perchè richiederebbe che i driver conoscano gli shader di tutti i giochi sviluppati, e, perchè questo replace non vedo perchè non si possa far eseguire alla cpu
interessante, ma l'utilità ai fini di ciò di cui si discute?
Quando hai descritto cosa i driver possono e non possono fare sembrava che non ti fosse chiaro il concetto che fossero binari x86/x64, poichè non ho la presunzione che chi mi legge debba credermi sulla parola, dalla lettura di quel tutorial anche chi ha una scarsa conoscenza del software ma comunque sa cosa è un compilatore ed un linker, avrebbe compreso che effettivamente i driver sono alla stregua dei binari eseguibili che tutti conosciamo, binari particolari ma non direttamente eseguibili con doppio click.
infatti yossarian (e pare anche nVidia, il cui parere, ritengo sia più autorevole, in quanto si parla di Fermi), continua a non condividere la tesi delle ottimizzazioni fatte dalla stessa cpu in fase di compilazione e ritiene improbabili quelle JIT fatte dalla cpu. Insomma, nVidia pensa che meno traffico ci sia nel bus pci-express e meno la cpu (e, addirittura, la vram) interviene e meglio è per tutti. Voi, liberi di pensarla come volete :D
Non ho seguito le ultime news ma continuo a pensarla come detto sopra, anche perchè un'ottimizzazione fatta dalla cpu che fa un replace di una madd con una fma non genera traffico nel bus, userà qualche ciclo di clock (della cpu), pazienza.
Non è detto che poi questa sarà la strada seguita da nVidia, quest'ultima come farebbe chiunque attuerà le ottimizzazioni compatibilmente con il miglior rapporto costi/benefici, e se il rapporto migliore deriverà adottando una soluzione simile a quella da te prospettata sceglierà quella, altrimenti ne sceglierà una simile a quella prospettata dal sottoscritto o un'altra ancora.
Il punto è che comunque sono ambedue tecnicamente fattibili, mentre seguendo il dibattito sembrava che l'unica verosimile fosse un replace eseguito dalla gpu durante la decodifica delle istruzioni.
skizzo99999999
30-11-2009, 22:55
allora mi sa che hai frainteso tutto: l'oggetto del contendere erano solo le sostituzioni di madd con fma. Tu ritieni che saranno fatte (se saranno fatte) in sede di compilazione dalla cpu, io, in base a quello che so su fermi e a quello che so (riportato dai vari documenti linkati) sul modo di ottimizzare da parte di nVidia e non solo (anche ATi fa lo stesso: compilatore generico, VM, compilatore JIT e ottimizzazioni; lo schema che hai linkato nell'immagine rappresenta degli step teorici ma allo stesso risultato si può arrivare in tanti modi e ti assicuro che nessuno si mette a scrivere compilatori o a modificarne di esistenti quando basta molto meno per fare le ottimizzazioni necessarie), ritengo, invece, che sarà il chip grafico a fare materialmente la sostituzione. So bene che la può fare anche la cpu ma non è affatto conveniente che sia la cpu a farla. Per quael motivo si deve mettere mano ad un compilatore quando bastano poche righe di codice inserite in un optimizer a valle del compilatore, per ottenere lo stesso risultato? Inoltre, come detto, i preephole lavorano su linguaggio binario e quindi sono perfettamente digeribili anche da gpu meno flessibili e programmabili di fermi.
secondo me invece tutti (e ripeto tutti) i documenti linkati invece danno la certezza (e alcuni lo dicono esplicitamente, ma ne abbiamo già parlato) che il compilatore generico non esiste o se ce n'è uno che fa qualcosa di simile (tipo in HLSL) il suo codice viene comunque poi compilato anche lui dal driver. Come ho quindi già ampiamente spiegato prima in entrambi i casi il codice viene sempre compilato dal compilatore JIT del driver (che non è per niente standard ed è diverso per ogni scheda).
Io quando dico compilatore del driver indico tutta la fase che dal codice sorgente (opengl) o dal codice restituito dall'HLSL translator (directx) restituisce il codice macchina per la GPU. Che poi la compilazione JIT e ottimizzazione sia composta da più passi è ovvio ma mi sono sempre limitato a dire il compilatore "ottimizza" per cercare di rendere la discussione più digeribile. Il succo del discorso è che partendo dallo shader, dal "blocco" software del driver esce il codice macchina che la GPU quando lo esegue non lo tocca più. E' appunto per questo che le sostituzioni si fanno a questo livello e non a run-time, sennò le dovrei fare tutte le volte invece così le faccio una volta sola. Tra l'altro se non si facesse in questo modo il codice non sarebbe compilato, ma richiederebbe una ulterirore interpretazione, cosa assolutamente priva di ogni significato visto che si sta parlando di ambiti dove la prestazione pura è quello che conta e se si può risparmiare qualcosa lo si fa. Quindi visto che nel driver si sa già molto di quello che si deve fare (almeno, lo ripeto, per operazioni prettamente statiche come appunto lasostituzione e la compilazione in generale) lo si fa li e basta. Perchè se lo si fa prima che lo shader passi a run-time, lo si fa una volta sola e basta.
Forse non riesco a spiegarmi bene sul concetto di run-time: è ovvio che gli shader vengono compilati a run-time (da qui il nome di compiler just-in-time) ma il run-time è riferito all'applicazione e non agli shader; cioè per quanto riguarda la GPU siamo "fermi" (verbo e non l'architettura NVIDIA). Ad un certo punto nell'applicazione si arriva alla chiamata di caricamento degli shader che vengono compilati e installati all'interno della GPU pronti per essere eseguiti. Ed è quindi prima di arrivare all'esecuzione che alcune ottimizzazioni "statiche" (cioè come già detto che non riguardano l'esame del flusso delle istruzioni) come le sostituzioni possono venire eseguite dal JIT (o comunque subito dopo, ma prima di arrivare all'esecuzione sulla GPU, ci siamo capiti su cosa voglio dire), in modo da non dover essere fatte tutte le volte dalla GPU al volo; saranno pure rapide e mascherabili, ma sarà ben meglio non farle no? è questo il senso dei compilatori just-in-time che parlando in generale sono stati creati per velocizzare i linguaggi interpretati e che qui hanno lo stesso significato, cioè traducono "al volo" prima della prima esecuzione il codice degli shader. E' per questo che è assolutamente conveniente fare tutto il possibile qui invece che farle mentre gli shader sono in esecuzione sulla GPU. Spero di essere stato abbastanza chiaro nel non identificare queste ottimizzazione con tutto quello che si fa a runtime (qua intendo il run-time degli shader, cioè mentre la GPU lavora) per sfruttare l'enorme potenziale parallelo delle GPU. Ma ste cose le ho già ripetute a sufficienza e la mia posizione ritengo sia abbastanza chiara.
Ripeto, CUDA serve a capire come funziona una gpu (nVidia nella fattispecie) e cosa può fare.
secondo me invece rende molto più complicate le cose, perchè cuda non ha lo stesso linguaggio dei 2 linguaggi di shading che abbiamo considerato (che tra di loro sono si diversi ma le differenze non sono importanti). E' un "quasi c" che quindi è molto più complesso da compilare e che richiede tutta quella pletora di moduli software (tipo OPEN64) che senza di esso non servono e non vengono usati.
Ora abbiamo appurato che esiste un compilatore standard (OPEN64, HLSL, GLSL) che fa una prima compilazione e sappiamo che le preephole optimizatin sono fatte dall'OCG su linguaggio binario (c'è scritto esplicitamente). l'OCG è a valle della PTX (quindi agisce dopo la compilazione JIT) e le preephole optimization si servono di quelle che sono definite atomic ops sugli interi (and, or, compare) e di salti condizionati. Fermi gestisce alla perfezione entrambe le cose (ha una gestione dei predicate cpu like). Quindi non ha nessuna difficoltà ad effettuare la sostituzione al volo sulla singola istruzione quando viene chiamata. E questo riduce anche il traffico tra cpu e gpu.
Non vedo una sola buona ragione per cui debba essere la cpu ad effettuarla in sede di compilazione JIT.
una parte standard è solo per hlsl (ma una parte, e per motivi che ho spiegato in un post precedente), per GLSL nulla e per open64 si ma non c'entra nulla con quello di cui stiamo parlando, è uno strato aggiuntivo per il codice c-like (e poi come per l'interprete HLSL è tutta "roba" che avviene in stadi precedenti, e che deve sempre passare dal compilatore "custom" JIT del driver NVDIA). Parlare di compilatore standard mi sembra proprio una contraddizione: se compila, compila per una certa architettura (es: nelle cpu x86, mips, ecc...). Non può essre standard, se il codice che esce deve essere diverso da GPU a GPU, e non può essere altrimenti sennò è una operazine che fa perdere tempo e basta, visto che bisognerebbe rimediare al volo nella GPU.
Fai poi un riferimento al OCG ed al JIt come se fossero due entità distinte ma sono la stessa cosa (riporto sempre da un documento precedente):
"NVIDIA already had a well-tuned low-level compiler for graphics codes, called OCG (Optimized Code Generator). This handles register allocation, scheduling, and peephole optimizations. This compiler is built into the graphics driver for doing just-in-time compilation of graphic codes"
Magari ho frainteso cosa volevi dire, è stata una giornata pazzesca e sono un po' cotto...
Poi non vedo il problema del traffico tra CPU e GPU visto che il JIT è nel driver e fino a che non ha finito la GPU non lavora (almeno a quello che sta lavorando il JIT in compilazione). Magari sta eseguendo un altro shader, ma ritengo sia difficile in quanto è buona norma in qualsiasi gioco/applicazione compilare tutti gli shader prima di qualsivoglia operazione di rendering
Il punto 2 parla di riarrangiare al volo il codice per meglio ottimizzare l'elaborazione (ce lo vedi il bus pci intasato dall'andirivieni tra cpu e gpu? E i continui load store tra vram e gpu a botta di 500-600 cicli per volta?). Il punto 4 parla di miglior utilizzo della cache (con ovvio riferimento alla cpu; ma in questo caso è la cpu stessa che gestisce tutto e ottimizza la propria cache. Nel caso in questione, la cpu non ha accesso alcuno alla cache interna della gpu). Quindi, questo tipo di operazioni può farle solo la gpu stessa.
Come vedi, non vale il discorso del codice già bello e pronto da essere usato e, tanto meno, è pensabile la gestione JIT da parte della cpu di buona parte delle ottimizzazioni. Nel caso specifico della sostituzione delle madd con fma ho già detto quello che penso (fa parte di quelle ottimizzazioni a carico delle gpu, anche perchè rientrano tra quelle che obbligano a riarrangiare la gestione dei thread in corso di elaborazione (i dati sono elaborati in maniera dinamica e un insieme di vertici ne può generare uno molto più grande, oppure da un vertice possono venir fuori un gran numero di pixel e solo il thread processor della gpu può decidere in che ordine far eseguire le relative istruzioni e, di conseguenza, come distribuire e allocare le risorse).
In quanto all'ultima frase, mi sa che nessuno ci sta filando e per quanto mi riguarda, possiamo chiuderla, visto che siamo ad un punto morto :D
Anche qui mi sembra di essere stato chiaro oltre ogni ragionevole dubbio che con ottimizzazioni che si eseguono a compile-time (degli shader, run-time dell'appplicazione) si intendono solo quelle che non riguardano la gestione, come hai giustamente fatto notare (ma sono sicuro di averlo detto chiaramente diverse volte), dei thread o per esempio dell'ordine delle istruzioni. Sono cose che "staticamente" sono per ragioni più che evidenti impossibili da prevedere e che vengono gestite a run-time (sia dell'applicazione che degli shader). Rifaccio il parallelo che ho gia fatto cn le CPU: se ho un programma in sorgente c, lo compilo, per esempio in architettura x86 per un processore intel core i7. Ora intel fa degli ottimi compilatori che ottimizzano e compattano tutto l'ottimizzabile, ovviamente di quello che si può a compile-time, per le proprie architetture. Se invece utilizzo un compilatore c del visual studio 6, il risultato sarà sicuramente peggiore in termini di prestazioni. Abbiamo quindi il codice assembler nativo x86 pure "ottimizzato" per la propria cpu. Ma adesso non è che quando viene eseguito la cpu non ci lavora su, lo so bene che deve fare un gran lavoro! è dal pentium pro che è stata introdotta per esempio l'esecuzione fuori sequenza: visto che i processori moderni possono elaborare più istruzioni per volta, se l'istruzine successiva deve necessariamente aspettare il risultato di quella precedente per essere eseguita, il processore la "salta" mettendola in attesa ed eseguendo quella dopo. E' ovvio che questo non può essere fatto a compile time, visto che non so quando e in che "condizioni" si trovaranno le unità di esecuzione al raggiungimento di quella situazione. C'è poi la predizione dei salti in base a tabelle statistiche che vengono riempite in base ai risultati precedenza e mille (si fa per dire) altre cose che incidono notevolmente sulle prestazioni. Risulta altrettanto ovvio che questo tipo di ottimizzazioni non possono che essere a carico che della CPU (gran parte del silicio dei processori è destinato a robe del genere), e di conseguenza alle GPU se si gira tutto il discorso e ci si riferisce agli shader.
Ma la sostituzione è una cosa che non implica nessuna analisi che non si possa fare a compile-time, per cui la si fa li, dal compilatore nel driver.
Parzialmente in quanto la teoria che i driver contengano staticamente già le istruzioni per la gpu ottimizzate mi sembra poco probabile, e, perchè richiederebbe che i driver conoscano gli shader di tutti i giochi sviluppati, e, perchè questo replace non vedo perchè non si possa far eseguire alla cpu
Certo che non è così, quando parlavo di ottimizzare non specificavo perchè l'unica ottimizzazione di cui si stava discutendo era quella della sostituzione. Spero che con il discorso del paragrafo precedente di essere stato, se possibile, più chiaro. Per il resto concordo con il tuo post, anche se...
Non è detto che poi questa sarà la strada seguita da nVidia, quest'ultima come farebbe chiunque attuerà le ottimizzazioni compatibilmente con il miglior rapporto costi/benefici, e se il rapporto migliore deriverà adottando una soluzione simile a quella da te prospettata sceglierà quella, altrimenti ne sceglierà una simile a quella prospettata dal sottoscritto o un'altra ancora.
...non vedo nessuna possibile convenienza a non eseguire la sostituzione nel driver, visto che anche se la penalità di tempo non fosse trascurabile, vista la "zona" non avrebbe nessun peso (caricamento) e sicuramente anche un piccolo rallentamento durante l'esecuzione dello shader sarebbe peggio.
yossarian
01-12-2009, 01:10
secondo me invece tutti (e ripeto tutti) i documenti linkati invece danno la certezza (e alcuni lo dicono esplicitamente, ma ne abbiamo già parlato) che il compilatore generico non esiste o se ce n'è uno che fa qualcosa di simile (tipo in HLSL) il suo codice viene comunque poi compilato anche lui dal driver. Come ho quindi già ampiamente spiegato prima in entrambi i casi il codice viene sempre compilato dal compilatore JIT del driver (che non è per niente standard ed è diverso per ogni scheda).
Io quando dico compilatore del driver indico tutta la fase che dal codice sorgente (opengl) o dal codice restituito dall'HLSL translator (directx) restituisce il codice macchina per la GPU. Che poi la compilazione JIT e ottimizzazione sia composta da più passi è ovvio ma mi sono sempre limitato a dire il compilatore "ottimizza" per cercare di rendere la discussione più digeribile.
il compilatore generico c'è per hlsl, per open64 e c'è anche per glsl. Secondo te, ora che stanno per lanciare fermi, nVidia si mette a scrivere un nuovo compilatore per opengl? Oppure, secondo te, nei driver unificati c'è una parte comune o abbiamo tanti compilatori quante sono le architetture dei chip supportati? Sai che due chip che hanno identica architettura ma, ad esmepio, differente numero dei registri, hanno differenti ISA? Ad esempio, G80 è differente da G70 che è diverso da NV40 che non è neppure parente di NV30 e tutti sono diversi da G92, da GT200 ecc. E tutti saranno molto diversi da fermi. Non esiste un compilatore ottimizzato per una determinata architettura con nessun tipo di API. Ogni compilatore è diviso in due partI: una standard che genera bytecode e una che fa compilazione JIT e gira, per i chip dx10 o successivi, su una VM.
Inoltre, tutti i documenti linkati hanno parlato di ottimizzazioni a valle del compilatore JIT (la certezaz è che lo si fa con cuda e con hlsl; tu sostieni che ciò non avvenga in opengl e io sono convinto del contrario e, comunque, la cosa risulta del tutto irrilevante, visto che si parla di giochi e, quindi, quasi esclusivamente, di DirectX). In quanto alle ottimizzazioni in questione, è chiaro che quando nVidia, parlando di cuda, dice: un buon ottimizzatore già lo avevamo (OCG) intende dire che questo ottimizzatore esisteva già prima di cuda ed era usato in altri ambiti. E la cosa non mi stupisce: ho un ottimizzatore che funziona bene per le mie architetture, l'unica cosa di cui mi devo preoccupare è di migliorare il più possibile la sua portabilità in modo da poterlo usare in tutti gli ambiti. Questo OCG agisce su codice binario e fa preephole optimization.
Il succo del discorso è che partendo dallo shader, dal "blocco" software del driver esce il codice macchina che la GPU quando lo esegue non lo tocca più. E' appunto per questo che le sostituzioni si fanno a questo livello e non a run-time, sennò le dovrei fare tutte le volte invece così le faccio una volta sola.
allora avevo capito bene! Il modello che proponi è con le sostituzioni at compile time? Esattamente quello che nVidia non vuole. Grosso spreco di risorse, più traffico nel bus. E, comunque, le sostituzioni si possono fare solo su codice binario.
Tra l'altro se non si facesse in questo modo il codice non sarebbe compilato, ma richiederebbe una ulterirore interpretazione, cosa assolutamente priva di ogni significato visto che si sta parlando di ambiti dove la prestazione pura è quello che conta e se si può risparmiare qualcosa lo si fa.
ma anche no. Parliamo di ambiti dove il problema principale è fare le ottimizzazioni il più in fretta possibile e non perdere tempo a ottimizzare, magari per anni, per una determinata architettura. Questo perchè cambiano le architetture e queste si devono adeguare rapidamente alle applicazioni vecchie e nuove. Inoltre, lo schema indicato da nVidia è piuttosto eloquente: da un parte il codice compilato che non deve essre ottimizzato (la stragrande maggioranza) che è quello indicato con "codice pr la cpu"; dall'altro quello che richiede la compilazione JIT che è una piccola parte ed è anche quello che viene ottimizzato. Quindi non si fa la ricompilazione di tutto ma solo quello destinato alla gpu diventa bytecode per girare su VM. Inoltre, l'utilità di scindere il due parti l'operazione di compilazione permette di unire i vantaggi della compilazione at compile time (con compiler standard) e dell'ottimizzazione at run time per architetture che, con ottimizzazione dinamica arrivano a guadagnare, statisticamente, anche un 30-40% in più rispetto ad una fatta at compile time (quindi ci sono anche evidennti vantaggi prestazionali)
Quindi visto che nel driver si sa già molto di quello che si deve fare (almeno, lo ripeto, per operazioni prettamente statiche come appunto lasostituzione e la compilazione in generale) lo si fa li e basta. Perchè se lo si fa prima che lo shader passi a run-time, lo si fa una volta sola e basta.
nVIdia dice che le ottimizzazioni si fanno JIT. Ora, seguendo lo schema visto per CUDA, è evidente che il "ramo cpu" non presenta alcun optimizer e non riconosce neppure l'architettura del chip. Quindi non può in alcun modo fare ottimizzazioni per fermi. Immagina un driver che faccia la sostituzione di cui dici at compile time nel "ramo cpu". La sostituzione avviene indiscriminatamente per tutti i chip e, così, fermi lavora in maniera ottimale, GT200 diventa un chiodo e tutti gli altri neppure partono :D . Viceversa, se le ottimizzazioni i fanno nel "ramo gpu", PTX ricinisce l'architettura, sa che sta girando su fermi e effettua la sostituzione, oppure che si tratta di GT200 e lascia invariate le MADD. Però, come specificato e più volte ripetuto, le ottimizzazioni avvengono JIT e non at compile time.
Forse non riesco a spiegarmi bene sul concetto di run-time: è ovvio che gli shader vengono compilati a run-time (da qui il nome di compiler just-in-time) ma il run-time è riferito all'applicazione e non agli shader; cioè per quanto riguarda la GPU siamo "fermi" (verbo e non l'architettura NVIDIA).
skizzo, mi sei simpatico e sei anche preparato, ma questo non l'ho proprio capito. Gli shader sono una cosa avulsa dall'applicazione? :D
Ok, torniamo seri (i complimenti sono sentiti, però).:)
Ad un certo punto nell'applicazione si arriva alla chiamata di caricamento degli shader che vengono compilati e installati all'interno della GPU pronti per essere eseguiti. Ed è quindi prima di arrivare all'esecuzione che alcune ottimizzazioni "statiche" (cioè come già detto che non riguardano l'esame del flusso delle istruzioni) come le sostituzioni possono venire eseguite dal JIT (o comunque subito dopo, ma prima di arrivare all'esecuzione sulla GPU, ci siamo capiti su cosa voglio dire), in modo da non dover essere fatte tutte le volte dalla GPU al volo; saranno pure rapide e mascherabili, ma sarà ben meglio non farle no? è questo il senso dei compilatori just-in-time che parlando in generale sono stati creati per velocizzare i linguaggi interpretati e che qui hanno lo stesso significato, cioè traducono "al volo" prima della prima esecuzione il codice degli shader.
io ho capito quello che vuoi dire, ma non è possibile farlo; non in questo caso. Non stiamo parlando della sostituzione dell'istruzione che si fa una tantum: ad esempio, forzare l'AA in un gioco da driver. In quel caso, il tutto avviene all'inizio, modificando una sola impostaizone all'atto del caricamento del gioco. A tutto il resto pensa la gpu che ha il suo algortmo di edge detect che entra in funzione in automatico quando viene forzato il MSAA. Qui parliamo di una sostituzione che si deve fare su tutte le istruzioni di pixel, vertex e geometry shader e texture blending, tenendo conto anche di eventuali operazioni di tessellatin che generano un numero molto più elevato di vertici su cui si devono applicare le stesse operazioni, di shader procedurali e di vertex e geometry shader che generano un gran numero di pixel su cui si devono operare delle madd. E il tutto avviene all'interno della gpu e non al suo esterno e non è neppure pensabile che, alla bisogna, le istruzioni che si rendono necessarie vengono ottimizzate dalla cpu e caricate al volo (passerebbero secoli). In realtà è la prima volta che ci si trova di fronte ad una situazione in cui si potrebbe rendere necessaria una sostituzione di istruzioni su vastissima scala.
Per risolvere il problema tu proponi un'ottimizzazione, di fatto, at compile time che nVidia (ma non solo lei) non gradisce, che mal si adatta ad un'architettura superscalare (che necessità di un compilatore dinamico per poter meglio ottimizzare) e che comporta un notevole dispendio di risorse. Inoltre, ripeto, la stessa nVidia parla di ottimizzazini JIT e non at compile time.
E' per questo che è assolutamente conveniente fare tutto il possibile qui invece che farle mentre gli shader sono in esecuzione sulla GPU. Spero di essere stato abbastanza chiaro nel non identificare queste ottimizzazione con tutto quello che si fa a runtime (qua intendo il run-time degli shader, cioè mentre la GPU lavora) per sfruttare l'enorme potenziale parallelo delle GPU. Ma ste cose le ho già ripetute a sufficienza e la mia posizione ritengo sia abbastanza chiara.
invece è molto più conveniente sfruttare l'enorme potenziale della gpu mentre gli shader sono in esecuzione, sia per diminuire le latenze delle operazioni, sia per rendere più agevoli le altre ottimizzazini (quelle che può fare solo la gpu) sia aumentare l'efficienza della gpu facendo girare più thread (aumentare la pressione sui registri e sulla cache interna significa fare offload rispetto a cpu e vram, situazione ottimiale, se ben gestita a livello di distribuzione dei carichi di lavoro, per aumentare l'efficienza del chip.
secondo me invece rende molto più complicate le cose, perchè cuda non ha lo stesso linguaggio dei 2 linguaggi di shading che abbiamo considerato (che tra di loro sono si diversi ma le differenze non sono importanti). E' un "quasi c" che quindi è molto più complesso da compilare e che richiede tutta quella pletora di moduli software (tipo OPEN64) che senza di esso non servono e non vengono usati.
CUDA è c-like come hlsl e glsl e non ha nulla di complesso: è open64 con qualche ottimizzazione per chip nVidia. Studiarlo è utile per capire come funzionano i chip, quali sono le loro potenzialità e qual è la strategia di nVidia (anche in relazione alle ottimizzazioni).
una parte standard è solo per hlsl (ma una parte, e per motivi che ho spiegato in un post precedente), per GLSL nulla e per open64 si ma non c'entra nulla con quello di cui stiamo parlando, è uno strato aggiuntivo per il codice c-like (e poi come per l'interprete HLSL è tutta "roba" che avviene in stadi precedenti, e che deve sempre passare dal compilatore "custom" JIT del driver NVDIA). Parlare di compilatore standard mi sembra proprio una contraddizione: se compila, compila per una certa architettura (es: nelle cpu x86, mips, ecc...). Non può essre standard, se il codice che esce deve essere diverso da GPU a GPU, e non può essere altrimenti sennò è una operazine che fa perdere tempo e basta, visto che bisognerebbe rimediare al volo nella GPU.
Fai poi un riferimento al OCG ed al JIt come se fossero due entità distinte ma sono la stessa cosa (riporto sempre da un documento precedente):
"NVIDIA already had a well-tuned low-level compiler for graphics codes, called OCG (Optimized Code Generator). This handles register allocation, scheduling, and peephole optimizations. This compiler is built into the graphics driver for doing just-in-time compilation of graphic codes"
Magari ho frainteso cosa volevi dire, è stata una giornata pazzesca e sono un po' cotto...
le cose stanno in maniera molto semplice, come spiegato dai documenti postati. Il codice è scisso in due parti: una standard, che è la stragrande maggioranza del codice, è compilata dalla cpu secondo il compilatore delle API di riferimento; questa non contiene alcuna ottimizzazione. Un'altra è destinata alla gpu; la cpu compila un bytecode da far girare su una VM. Questa provvede ad effettuare le ottimizzazioni riconoscendo l'architettura del chip e procedendo, di conseguenza, alle ottimizzazioni necessarie per quell'architettura. Queste ultime sono eseguite JIT e su linguaggio binario; ad occuparsene può essere la cpu (in caso di interventi possibili prima del lancio dell'applicazione) o la gpu (in caso di interventi che è opportuno demandare al device). Le sostituzioni in questione rientrano in questa seconda categoria,
Poi non vedo il problema del traffico tra CPU e GPU visto che il JIT è nel driver e fino a che non ha finito la GPU non lavora (almeno a quello che sta lavorando il JIT in compilazione). Magari sta eseguendo un altro shader, ma ritengo sia difficile in quanto è buona norma in qualsiasi gioco/applicazione compilare tutti gli shader prima di qualsivoglia operazione di rendering
A me risulta che una compilazione JIT prevede, invece, proprio la compilazione mentre l'applicazione sta girando. Se si compila prima tutto il codice e lo si ottimizza parliamo di compile time. Semmai può essere che si tratti di un aparte del codice e, mentre la gpu lavora su questo, la cpu ottimizza un'altra porzione, ma, allora, il traffico si crea eccome e si crea anche una gran confusione. Chi dà alla cpu le informazioni sulle istruzioni chiamate sulla gpu? Come sa quale parte del codice ottimizzare se non sa su cosa sta lavorando la gpu perchè non ha accesso al suo interno? Come fa a sapere che un'istruzione non abbia generato dati che devono essere processati prima di altri già schedulati? In parole povere, in base a quale criterio decide l'ordine in cui procedere?
se, poi, parliamo di compile time, allora è un altro paio di maniche (ma nVidia dice JIT e un'architettura superscalare ha bisogno di compilazione dinamica).
Anche qui mi sembra di essere stato chiaro oltre ogni ragionevole dubbio che con ottimizzazioni che si eseguono a compile-time (degli shader, run-time dell'appplicazione) si intendono solo quelle che non riguardano la gestione, come hai giustamente fatto notare (ma sono sicuro di averlo detto chiaramente diverse volte), dei thread o per esempio dell'ordine delle istruzioni. Sono cose che "staticamente" sono per ragioni più che evidenti impossibili da prevedere e che vengono gestite a run-time (sia dell'applicazione che degli shader).
si tratta di ottimizzazioni fortemente dipendenti dall'ordine delle istruzioni che arriverebbero già ottimizzate. Vedi punto sopra: la cpu non può sapere su cosa sta lavorando la gpu e non può, di conseguenza, fare sostituzine JIT delle istruzioni necessarie. La gestione dei thread è un processo dinamico e non statico; ripeto, qui non parliamo di forzare l'AA via driver all'atto del lancio dell'applicazione.
Rifaccio il parallelo che ho gia fatto cn le CPU: se ho un programma in sorgente c, lo compilo, per esempio in architettura x86 per un processore intel core i7. Ora intel fa degli ottimi compilatori che ottimizzano e compattano tutto l'ottimizzabile, ovviamente di quello che si può a compile-time, per le proprie architetture. Se invece utilizzo un compilatore c del visual studio 6, il risultato sarà sicuramente peggiore in termini di prestazioni. Abbiamo quindi il codice assembler nativo x86 pure "ottimizzato" per la propria cpu. Ma adesso non è che quando viene eseguito la cpu non ci lavora su, lo so bene che deve fare un gran lavoro! è dal pentium pro che è stata introdotta per esempio l'esecuzione fuori sequenza: visto che i processori moderni possono elaborare più istruzioni per volta, se l'istruzine successiva deve necessariamente aspettare il risultato di quella precedente per essere eseguita, il processore la "salta" mettendola in attesa ed eseguendo quella dopo. E' ovvio che questo non può essere fatto a compile time, visto che non so quando e in che "condizioni" si trovaranno le unità di esecuzione al raggiungimento di quella situazione. C'è poi la predizione dei salti in base a tabelle statistiche che vengono riempite in base ai risultati precedenza e mille (si fa per dire) altre cose che incidono notevolmente sulle prestazioni. Risulta altrettanto ovvio che questo tipo di ottimizzazioni non possono che essere a carico che della CPU (gran parte del silicio dei processori è destinato a robe del genere), e di conseguenza alle GPU se si gira tutto il discorso e ci si riferisce agli shader.
Ma la sostituzione è una cosa che non implica nessuna analisi che non si possa fare a compile-time, per cui la si fa li, dal compilatore nel driver.
ti ho già spiegato perchè non è possibile fare una "semplice sostituzione" at compile time: perchè si parla di migliaia di semplici sostituzioni che devono servire ad elaborare dati che ancora non sono stati creati e di cui non si conosce nè il numero né gli altri parametri tra cui l'ordine in cui dovranno essere processati. (la cpu conosce solo i valori iniziali dei vertici di un frame). Inoltre, ripeto per l'ennesima volta, un'architetura superscalare vuole un compiler dinamico (pena pessima ottimizzazione) e nVdia non parla di preephole optimization at compile time (ci sarà un motivo)?
...non vedo nessuna possibile convenienza a non eseguire la sostituzione nel driver, visto che anche se la penalità di tempo non fosse trascurabile, vista la "zona" non avrebbe nessun peso (caricamento) e sicuramente anche un piccolo rallentamento durante l'esecuzione dello shader sarebbe peggio.
invece io ritengo, per quanto esposto, che la sostituzione, ammesso che sia possibile e che si farà, avverrà sulla gpu.
E mi pare che siamo di nuovo ad un punto morto e, poichè ho un avita sociale, un lavoro e un articolo da scrivere (tranquilli non è su fermi, anche se ci sarebbe materiale per una serie completa degna di beautiful :p ), ritengo poco costruttivo contìnuare una discussione in cui ognuno ha espresso i suoi concetti (anche più volte) senza arrivare ad una conclusione di sorta. :D
Bastoner
01-12-2009, 06:24
E mi pare che siamo di nuovo ad un punto morto e, poichè ho una vita sociale, un lavoro e un articolo da scrivere (tranquilli non è su fermi, anche se ci sarebbe materiale per una serie completa degna di beautiful :p ), ritengo poco costruttivo contìnuare una discussione in cui ognuno ha espresso i suoi concetti (anche più volte) senza arrivare ad una conclusione di sorta. :D
Allora aspettiamo la prima puntata della Fermi-soap :eek:
maurilio968
01-12-2009, 08:34
....
un articolo da scrivere (tranquilli non è su fermi, anche se ci sarebbe materiale per una serie completa degna di beautiful :p ), ritengo poco costruttivo contìnuare una discussione in cui ognuno ha espresso i suoi concetti (anche più volte) senza arrivare ad una conclusione di sorta. :D
Invece io grazie alle vostre ulteriori repliche ho avuto modo di chiarirmi
le idee ancora meglio. Ringrazio Skizzo e Yoss.
Alla fine della fiera resto dell'idea che Yoss abbia ragione. Comunque le repliche di Skizzo hanno chiarito che non è impossibile fare come dice lui, solo non è conveniente e questo per come sono fatte le archittetture "fisiche" delle Gpu. Questo è un punto importante per noi "illetterati" e ci ha costretto a sudare un bel po' per capire meglio tutto il discorso.
Yoss, ho messo da parte le patatine, parti con gli articoli saga-telenovela che ti seguo! :oink:
PhysX, 3DVision, FTW, KickAss?
3DVision. Bocche cucite su "Fermi"....appuntamento a gennaio 2010 in America.:)
Certo che non è così, quando parlavo di ottimizzare non specificavo perchè l'unica ottimizzazione di cui si stava discutendo era quella della sostituzione.
La mia risposta era riferita a quanto sosteneva yossarian, ovvero
il driver contiene anche istruzioni per la gpu e sono questa a contenere le ottimizzazioni
La parte in grassetto sembra che voglia dire che i driver contengano già, e quindi staticamente, le fma al posto delle madd.
A meno che intendesse dire, che i driver in qualche modo suggeriscono all'instruction decoder di trattare una madd esattamente come una fma, eseguendo quindi durante la decodifica della madd lo stesso microcodice eseguito durante la decodifica della fma, e se gli operandi sono gli stessi, chiedo a yossarian, la cosa non sarebbe fattibile ?
3DVision. Bocche cucite su "Fermi"....appuntamento a gennaio 2009 in America.:)
Giusto oggi che è martedì 1 dicembre, data che veniva indicata come probabile per la presentazione ufficiale :D .
Sempre più contento della nuova 5850.
yossarian
01-12-2009, 12:28
La mia risposta era riferita a quanto sosteneva yossarian, ovvero
La parte in grassetto sembra che voglia dire che i driver contengano già, e quindi staticamente, le fma al posto delle madd.
A meno che intendesse dire, che i driver in qualche modo suggeriscono all'instruction decoder di trattare una madd esattamente come una fma, eseguendo quindi durante la decodifica della madd lo stesso microcodice eseguito durante la decodifica della fma, e se gli operandi sono gli stessi, chiedo a yossarian, la cosa non sarebbe fattibile ?
le ottimizzazioni a livello driver dedicate alla gpu, in questo caso, sono costituite da una semplice "finestra" in grado di individuare ed evidenziare un certo tipo di istruzione. Quando l'istruzione è mandata in esecuzione, al momento in cui l'unità di decodifica "legge" madd all'interno di questa finestra, sa che deve sostituirla con fma. Quindi effettua al volo la sostituzione.
Il fatto che gli operandi siano gli stessi non viol dire niente; anzi, se si scindesse una madd in mul + add, su fermi andrebbero iin esecuzione in questa sequenza (prima la mul con troncamento e poi la add con troncamento/arrotondamento) e il tutto richiederebbe due cicli al posto di uno. Questo eprchè sia mul che add prevedono il troncamento alla fine dell'operazione e fermi non ha lo stadio che fa troncamento dopo la mul e deve utilizzare 'lunico a disposizione (quello a valle della add).
http://www.appuntidigitali.it/site/wp-content/uploads/fma-classica.jpg
questa è una pipeline di tipo fma (sul modello di quella di fermi). se chiami una madd o una mul + add, prima si esegue la mul e si salta la add, utilizzando solo lo stadio di troncamento a valle di questa e poi si esegue la add. Totale due cicli. Se chiami una fma fa tutto in un'unico ciclo (prima la mul senza troncamento, poi la add con troncamento finale).
Volevo dire gennaio 2010.:D
Comunque Nvidia ha in servo molte belle cose....molto interessanti su nuove tecnologie. Ieri sono rimasto colpito da due cose. Il 2010 promette bene.:)
Bastoner
01-12-2009, 12:38
Il forum di B3D ci fa un baffo! :D
yossarian
01-12-2009, 12:39
Tutto come previsto...
Quello che mi chiedo io, dal basso del mio più alto livello (li arrivo, abbiate pazienza), è se ciò sia fattibile a livello applicativo, nel senso se un applicativo pensato per delle MADD continui a funzionare quando il chip invece esegue delle FMA.
Credo che solo le performance di Fermi potranno dare la risposta definitiva al dubbio...
le operazioni di replacement fatte in passato permettevano di sostituire interi shader dx(n) con shader dx(n-1) e l'applicazione continuava a girare tranquillamente. L'unico dubbio è la eventuale generazione di artefatti dovuti ad un differente livello di precisione. Da considerare che il replecement va fatto su tutte le istruzioni relative a vertex, pixel, geometry shader e texture blending (che nei chip dx11 è fatto dallo shader core).
yossarian
01-12-2009, 12:49
E se non mi sbaglio questo significa una costante dipendenza dai driver per il tuning su ogni titolo. Mi sbaglio?
dipende. Se faccio una sostituzione di uno shader dx9 con uno dx8 (come avveniva con NV30) in una determinata applicazione, ovviamente avrò bisogno di sostituire quella specifica sequenza di istruzioni con una del tutto equivalente, solo espressa in uno sm differente. Ciò significa che i driver devono contenere lo shader con cui rimpiazzo l'originale (impensabile che sia contenuto nell'applicazione). Se il gioco viene patchato e con la patch si introducono altre istruzioni dx9, dovrò mettere nei driver i loro equivalenti dx8 (quindi fare una patch della patch :D ); stesso discorso se passo ad altri titoli. In questo caso non è necessario. A parte il fatto che le fma, dal 2008, sono entrate a far parte del mondo della grafica ma, comunque, se anche non facessero parte dello sm o del codice sorgente, basterebbe introdurle una sola volta nei driver. Al resto ci pensa il preephole che ha come target le madd. Insomma, basta una sola patch per tutti i giochi :D
Scusate ma è stato pubblicato qualche bench delle vga fermi? così giusto per avere un idea sulle potenzialità delle vga....vorrei sostituire la 4870x2 e sono indeciso se prendere una ati 5xxx o aspettare nvidia e la sua controproposta....solo che nn so quando arriva e nn ho ancora letto nulla a riguardo di ufficiale!
Andrea deluxe
01-12-2009, 13:01
Volevo dire gennaio 2010.:D
Comunque Nvidia ha in servo molte belle cose....molto interessanti su nuove tecnologie. Ieri sono rimasto colpito da due cose. Il 2010 promette bene.:)
quali 2 cose?
Scusate ma è stato pubblicato qualche bench delle vga fermi? così giusto per avere un idea sulle potenzialità delle vga....vorrei sostituire la 4870x2 e sono indeciso se prendere una ati 5xxx o aspettare nvidia e la sua controproposta....solo che nn so quando arriva e nn ho ancora letto nulla a riguardo di ufficiale!
Non circala niente di ufficiale da parte di Nvidia su fermi. C'è veramente molto silenzio.A gennaio ci sarà qualcosa di dimostrativo.
quali 2 cose?
Non posso dirlo, cerca di capirmi....parlo del campo 3DVision. Comunque Nvidia sa il fatto suo, o almeno è quello che vuole dare a intendere.;)
Andrea deluxe
01-12-2009, 13:09
Non posso dirlo, cerca di capirmi....parlo del campo 3DVision. Comunque Nvidia sa il fatto suo, o almeno è quello che vuole dare a intendere.;)
:O
okkkeyy
la mia casella pvt e' libera...... :asd:
Non circala niente di ufficiale da parte di Nvidia su fermi. C'è veramente molto silenzio.A gennaio ci sarà qualcosa di dimostrativo.
E quindi bisogna aspettare fino a gennaio? io sinceramente ho come l'impressione che questo silenzio non sia un buon segno....secondo me i santa clara sono messi male....
Mi sembra strano che dopo che sono uscite le proposte ati e che stanno vendendo anche bene, nvidia non faccia trapelare nulla.... se sapesse gia di essere in grado di superare ati avrebbe fatto circolare qualcosa, così magari qualcuno come me che è in procinto di cambiare vedendo i risultati aspetterebbe anche prima di acquistare! poi sotto natale che è un periodo favoloso per la vendita di componenti per pc!
Sto silenzio mi fa pensare che in nvidia stanno lavorando a manetta per evitare al ces di lasvegas di fare vedere che sono indietro con il lavoro! non pensate?
E quindi bisogna aspettare fino a gennaio? io sinceramente ho come l'impressione che questo silenzio non sia un buon segno....secondo me i santa clara sono messi male....
Mi sembra strano che dopo che sono uscite le proposte ati e che stanno vendendo anche bene, nvidia non faccia trapelare nulla.... se sapesse gia di essere in grado di superare ati avrebbe fatto circolare qualcosa, così magari qualcuno come me che è in procinto di cambiare vedendo i risultati aspetterebbe anche prima di acquistare! poi sotto natale che è un periodo favoloso per la vendita di componenti per pc!
Sto silenzio mi fa pensare che in nvidia stanno lavorando a manetta per evitare al ces di lasvegas di fare vedere che sono indietro con il lavoro! non pensate?
Queste considerazioni unitamente alle dichiarazioni della società di questi ultimi 3 mesi fanno ricordare veramente molto i mesi prima del lancio di R600... Speriamo bene anche se nn è di certo di buon auspicio
E quindi bisogna aspettare fino a gennaio? io sinceramente ho come l'impressione che questo silenzio non sia un buon segno....secondo me i santa clara sono messi male....
Mi sembra strano che dopo che sono uscite le proposte ati e che stanno vendendo anche bene, nvidia non faccia trapelare nulla.... se sapesse gia di essere in grado di superare ati avrebbe fatto circolare qualcosa, così magari qualcuno come me che è in procinto di cambiare vedendo i risultati aspetterebbe anche prima di acquistare! poi sotto natale che è un periodo favoloso per la vendita di componenti per pc!
Sto silenzio mi fa pensare che in nvidia stanno lavorando a manetta per evitare al ces di lasvegas di fare vedere che sono indietro con il lavoro! non pensate?
Ti ripeto, non sono in grado di dirti "del perchè" di questo silenzio. Posso solo dirti che al CES di Lasvegas "gennaio 2010", Nvidia parlerà di Fermi e mostrerà qualcosa.Siamo stati invitati ad andare......sarà la volta buona che si va in America!:asd: Questo è quello che gli Ingegneri Nvidia hanno detto.
Il resto sono solo supposizini.Chiaramente una mia idea me la sono fatta,ma è una mia idea.
Ti ripeto, non sono in grado di dirti "del perchè" di questo silenzio. Posso solo dirti che al CES di Lasvegas "gennaio 2010", Nvidia parlerà di Fermi e mostrerà qualcosa.Questo è quello che gli Ingegneri Nvidia hanno detto.
Il resto sono solo supposizini.Chiaramente una mia idea me la sono fatta,ma è una mia idea.
Ma in giro si dice che subito dopo il ces la scheda potrebbe essere gia sugli scaffali! se tu mi dici che a gennaio al ces nvidia mostrerà qualcosa vuol dire che a gennaio sugli scaffali non ci sarà nulla!
inizio a pensare che fermi sarà l'R600 di nvidia!!!!
Tanto per avere un idea ho capito che non puoi parlare (se puoi in pvt la casella è libera) ma tu che idea ti sei fatto?
Ma in giro si dice che subito dopo il ces la scheda potrebbe essere gia sugli scaffali! se tu mi dici che a gennaio al ces nvidia mostrerà qualcosa vuol dire che a gennaio sugli scaffali non ci sarà nulla!
inizio a pensare che fermi sarà l'R600 di nvidia!!!!
Tanto per avere un idea ho capito che non puoi parlare (se puoi in pvt la casella è libera) ma tu che idea ti sei fatto?
Raga, siete intelligenti, non chiedetemi informazioni in pvt.:p
Questo è quanto è emerso ieri....CES, Las Vegas dal 7 al 10 gennaio 2010....Fermi. Ieri si è parlato di 3D Vision.:)
se Nvidia sarà l'R600 cosa che non credo visto che da quanto ho capito io i cuda core sono poco più di rinominazioni degli stream quindi 512 stream a quella freq dovrebbe farli mangiare la polvere.
Ma anche se fosse un R600 style di sicuro Nvidia fra un ottimizzazione e la'ltra sosterrà bene il progetto.
Gabriyzf
01-12-2009, 13:54
Ma in giro si dice che subito dopo il ces la scheda potrebbe essere gia sugli scaffali! se tu mi dici che a gennaio al ces nvidia mostrerà qualcosa vuol dire che a gennaio sugli scaffali non ci sarà nulla!
inizio a pensare che fermi sarà l'R600 di nvidia!!!!
Tanto per avere un idea ho capito che non puoi parlare (se puoi in pvt la casella è libera) ma tu che idea ti sei fatto?
speriamo di no, anche se le premesse sembrano esserci :muro:
Raga, siete intelligenti, non chiedetemi informazioni in pvt.:p
Questo è quanto è emerso ieri....CES, Las Vegas dal 7 al 10 gennaio 2010....Fermi. Ieri si è parlato di 3D Vision.:)
Scusa ma non ho seguito per niente questa cosa del 3d vision! me lo spiegheresti in 4 parole?
halduemilauno
01-12-2009, 14:05
Raga, siete intelligenti, non chiedetemi informazioni in pvt.:p
Questo è quanto è emerso ieri....CES, Las Vegas dal 7 al 10 gennaio 2010....Fermi. Ieri si è parlato di 3D Vision.:)
quella era l'ultima chiamata. in precedenza si era rumoreggiato del Siggraph di Tokio 15/19 dicembre. ma di certo le tue info sono le + aggiornate possibili.
;)
halduemilauno
01-12-2009, 14:07
Scusa ma non ho seguito per niente questa cosa del 3d vision! me lo spiegheresti in 4 parole?
http://www.nvidia.it/object/GeForce_3D_Vision_Main_it.html
;)
http://www.nvidia.it/object/GeForce_3D_Vision_Main_it.html
;)
Mi sembra una grande cazzata se bisognerà anche cambiare i monitor e acquistare gli occhiali!!!! se uno deve spendere 1000 euro per una vga che senso ha? con 750 euro circa si prendono 2 5870 in xfire!!!
Bastoner
01-12-2009, 14:45
Non posso dirlo, cerca di capirmi....parlo del campo 3DVision. Comunque Nvidia sa il fatto suo, o almeno è quello che vuole dare a intendere.;)
"Prima butta la pietra e poi nasconde la mano"
:rolleyes:
le ottimizzazioni a livello driver dedicate alla gpu, in questo caso, sono costituite da una semplice "finestra" in grado di individuare ed evidenziare un certo tipo di istruzione. Quando l'istruzione è mandata in esecuzione, al momento in cui l'unità di decodifica "legge" madd all'interno di questa finestra, sa che deve sostituirla con fma. Quindi effettua al volo la sostituzione.
Il fatto che gli operandi siano gli stessi non viol dire niente; anzi, se si scindesse una madd in mul + add
Ho infatti parlato di MADD e FMA che dovrebbero avere gli stessi operandi, ma comunque io pensavo ad uno schema di questo tipo nel quale ad esempio, premesso che non so un ca..o di hardware, introdurre una sorta di Instruction Translator tra il fetcher e il decoder, un qualcosa come questo:
Instruction Fetcher
|
Instruction Translator
|
Instruction Decoder
Se IF IT e ID riescono a operare in parallelo e quindi sullo stesso ciclo di clock, a regime, la traduzione tra MADD e FMA, potrebbe avere costo nullo ?
skizzo99999999
01-12-2009, 17:51
il compilatore generico c'è per hlsl, per open64 e c'è anche per glsl. Secondo te, ora che stanno per lanciare fermi, nVidia si mette a scrivere un nuovo compilatore per opengl? Oppure, secondo te, nei driver unificati c'è una parte comune o abbiamo tanti compilatori quante sono le architetture dei chip supportati? Sai che due chip che hanno identica architettura ma, ad esmepio, differente numero dei registri, hanno differenti ISA? Ad esempio, G80 è differente da G70 che è diverso da NV40 che non è neppure parente di NV30 e tutti sono diversi da G92, da GT200 ecc. E tutti saranno molto diversi da fermi. Non esiste un compilatore ottimizzato per una determinata architettura con nessun tipo di API. Ogni compilatore è diviso in due partI: una standard che genera bytecode e una che fa compilazione JIT e gira, per i chip dx10 o successivi, su una VM.
Infatti per ogni architettura nvidia come ati e come ogni sviluppatore di chip grafico ha un compilatore ad hoc (uno per NV30, NV40, G80, ecc...). Se non fosse così non lo chiamaerebbero neppure compilatore ma traduttore (infatti la parte "standard" nel sistema operativo che agisce sull'HLSL si chiama HLSL translator, non HLSL compiler; la parte che compila è sempre dentro nel driver), visto che per sua natura dal compilatore esce codice macchina, che è quindi "personalizzato" e diverso per ogni serie di chip, e quindi ognuno avrà il suo bel compilatore. Riguarda anche questo l'onere dello sviluppo dei driver.
allora avevo capito bene! Il modello che proponi è con le sostituzioni at compile time? Esattamente quello che nVidia non vuole. Grosso spreco di risorse, più traffico nel bus. E, comunque, le sostituzioni si possono fare solo su codice binario.
invece proprio quello che, in qualsiasi ambito, si cerca di fare è poter fare tutto il possibile a compile time, per poi ridurre il lavoro e quindi tempo perso a run-time. Infatti siccome il compile -time sa fa una volta e il run-time tutte le volte, i benefici sono ovvi. C'è maggior lavoro di programmazione, ma gli sviluppatori dei driver sono li anche per quello. Non c'è poi nessuno spreco di risorse, niente traffico sul bus, visto che avvenendo nel driver a compile-time (dello shader, run-time dell'applicazione) è tutto PRIMA che lo shader venga eseguito.
ma anche no. Parliamo di ambiti dove il problema principale è fare le ottimizzazioni il più in fretta possibile e non perdere tempo a ottimizzare, magari per anni, per una determinata architettura. Questo perchè cambiano le architetture e queste si devono adeguare rapidamente alle applicazioni vecchie e nuove. Inoltre, lo schema indicato da nVidia è piuttosto eloquente: da un parte il codice compilato che non deve essre ottimizzato (la stragrande maggioranza) che è quello indicato con "codice pr la cpu"; dall'altro quello che richiede la compilazione JIT che è una piccola parte ed è anche quello che viene ottimizzato. Quindi non si fa la ricompilazione di tutto ma solo quello destinato alla gpu diventa bytecode per girare su VM. Inoltre, l'utilità di scindere il due parti l'operazione di compilazione permette di unire i vantaggi della compilazione at compile time (con compiler standard) e dell'ottimizzazione at run time per architetture che, con ottimizzazione dinamica arrivano a guadagnare, statisticamente, anche un 30-40% in più rispetto ad una fatta at compile time (quindi ci sono anche evidennti vantaggi prestazionali)
ti stai riferendo probabilmente allo schema contenuto nella seconda pagina del .doc giò liknato in precedenza:
http://www.capsl.udel.edu/conferences/open64/2008/Papers/101.doc
Come scritto nel post precedente inserire CUDA nel discorso confonde e basta. Questo schema prima di tutto non è uno schema di cosa avviene a runtime ma della catena che segue il codice dell'applicazione durante la fase di sviluppo, e quindi quando si parte dal sorgente. L'ho già spiegato prima in modo + dettagliato ma faccio un breve sunto (se si vuole dipiù basta leggere qualche post precedente). Siamo al punto che lo sviluppatore ha finito il suo progetto e deve compilare.Il grafico si divide in due dopo essere passato in "cudafe" perchè deve dividere il codice c generico dell'applicazione destinato alla CPU dal codice cuda che dovrà essere gestito dalla GPU. La parte sinistra verrà quindi gestita in maniera tradizionale usando gli strumenti di compilazione che lo sviluppatore usa solitamente (se siamo in visual studio per esempio usare il compilatore c di quell'ambiente). La parte destra invece prende una strada diversa, perchè dovrà essere compilata non per girare sulla CPU ma sulla GPU presente nel sistema, quindi ci sono tutti qui bei moduli software che servono a fa arrivare un codice "utilizzabile" dal solito OCG/JIT in modo che possa gestirlo e compilarlo come se fosse uno shader. Tutta sta roba nella grafica 3d non c'è perchè non c'è nulla da dividere (l'applicativo e gli shader sono già divisi) e la parte del grafico che li sta a sinistra NVIDIA non la vede nemmeno perchè non passando da "cudafe" non sa neanche che esista (è una battuta, ovviamente se gli shader arrivano al driver ci sarà una applicazione che glieli invia...), come non ci saranno tutte quelle operazioni della parte destra per adattare il codeice alla GPU. Sulla ultima parte riguardante le prestazioni, mi sembra di averne parlato ampiamente già nei miei post precedenti. Posso solo aggiungere che niente è più veloce di un linguaggio compilato nativamente. Infatti, parlando di programmazione generica e non grafica (dove è più facile per tutti quelli che leggono capire), un programma compilato in c è imbattibile per chiunque, che sia JAVA, uno qualsiasi della suite .net (c# ad esempio), perchè questi ultimi sono interpretati e non compilati. La compilazione JIT è stata introdotta soltanto per tentare di ridurre il gap, che comunque rimane. Se come riferimento prendo le prestazione senza la fase di JIT, il c è anche 10-20 volte più veloce. Nella grafica se ci fosse stata scelta avrebbero sicuramente compilato tutto anche li; ma visto che a differenza delle CPU in cui, almeno per il mondo windows che è quello di cui stiamo parlando, il x86 rimane incontrastato e ci sono solo delle estensioni (mmx, sse, ecc...) che si possono decidere o meno di utilizzare (e la granparte dei programmi non usa), nelle GPU l'architettura cambia in continuazione. Se gli sviluppatori compilassero i sorgenti degli shader come compilano i sorgenti dell'applicativo/gioco, visto che i tempi di sviluppo dei gichi tripla A di oggi rihiedono anni, alla data di uscita ci sarebbero già le nuove schede che non funzionerebbero. Per cui si è scelta questa strada di "compromesso" in cui la parte shader viene compilata a run-time, ma comunque compilata prima di essere eseguita.
nVIdia dice che le ottimizzazioni si fanno JIT. Ora, seguendo lo schema visto per CUDA, è evidente che il "ramo cpu" non presenta alcun optimizer e non riconosce neppure l'architettura del chip. Quindi non può in alcun modo fare ottimizzazioni per fermi. Immagina un driver che faccia la sostituzione di cui dici at compile time nel "ramo cpu". La sostituzione avviene indiscriminatamente per tutti i chip e, così, fermi lavora in maniera ottimale, GT200 diventa un chiodo e tutti gli altri neppure partono :D . Viceversa, se le ottimizzazioni i fanno nel "ramo gpu", PTX ricinisce l'architettura, sa che sta girando su fermi e effettua la sostituzione, oppure che si tratta di GT200 e lascia invariate le MADD. Però, come specificato e più volte ripetuto, le ottimizzazioni avvengono JIT e non at compile time.
Riguarda sempre CUDA e qundi vale il discorso precedente. Voglio solo sottlineare ancora, se ce ne fosse bisogno, che del "ramo cpu" alla GPU non gliene può fregare di meno, ovvio che li non viene compilato niente (da NVIDIA), perchè non gira su NVIDIA ma sul processore, ed infatti quella parte di codice viene trattata dal compilatore della piattaforma di sviluppo dello sviluppatore. Anche questo già detto, ma è anche ovvio che tutta questa fase non ha nessuna pertinenza con l'esecuzione del programma, ma serve a chi lo fa. Infatti nel PC di chi esegue l'applicativo il ramo sinistro non esiste (e anche buona parte di quello destro).
skizzo, mi sei simpatico e sei anche preparato, ma questo non l'ho proprio capito. Gli shader sono una cosa avulsa dall'applicazione? :D
Ok, torniamo seri (i complimenti sono sentiti, però).:)
Vedo che erano le 2 del mattino, magari eri più stravolto di me... ma davvero hai dei dubbi sul fatto che gli shader siano distinti dall'applicazione? Questa è talmente grossa che non so neanche da dove partire. Faccio un breve schemino base:
applicazione (per mia semplicità scritta in pseudo c)
int main (int argc, char** argv)
{
inizializzo_contesto();
leggo_config.ini();
carico_modelli();
carico_texture();
carico_shader();
...
inizializzo_luci();
inizializzo_VBO();
...
mainloop();
}
all'inizio subito dopo aver inizializzato il contesto/i (se uso varie librerie), leggo un file di configurazione che mi dice i valori di alcuni settaggi che posso impostare; poi passo a caricare i modelli, le texture (le quali possono venire subito spostate nella vram), i modelli poligonali del mondo e carico gli shader. Dentro la carica shader si carica, compila, linka, ecc... gli shader che possono essere in file distinti (io facci così) in nuo solo oppure, per mantenere meglio la proprietà intellettuale se si è implementato un algoritmo originale, possono essere anche piazzati sottoforma di stringa all'interno del sorgente c, ma è un po scomodo poi modificarli. Questo ad esempio si applica in casi in cui si debba modificare in base ad alcuni stati di esecuzione lo shader che si deve applicare, che comunque deve poi passare alla compilazione, link, ecc...
Ad esempio la funzione che inizializza gli shader che uso io è più o meno così (per un singolo shader):
// geometry shader
GLchar *GeometryStageVSname = "Shaders/GeometryStageVS.vs";
GLchar *GeometryStageFSname = "Shaders/GeometryStageFS.fs";
GLubyte *GeometryStageVStext;
GLubyte *GeometryStageFStext;
create_vertex_shader_object(cpw, "Geometry", &GeometryStageVS);
create_fragment_shader_object(cpw, "Geometry", &GeometryStageFS);
attach_shader(cpw, &GeometryStageVSname, &GeometryStageVStext, &GeometryStageVS);
attach_shader(cpw, &GeometryStageFSname, &GeometryStageFStext, &GeometryStageFS);
compile_shader(cpw, "Geometry", "vertex", &GeometryStageVS);
compile_shader(cpw, "Geometry", "fragment", &GeometryStageFS);
create_attach_program_object(cpw, &GeometryProgram, &GeometryStageVS, &GeometryStageFS);
link_program_object(cpw, "Geometry", &GeometryProgram);
validate_program_object(cpw, "Geometry", &GeometryProgram);
Ci sono tutte le fasi preliminari che avvengono prima dell'esecuzione e che istruiscono il compilatore su cosa e quando deve tradurre.
C'è poi la fase di inizializzazione che mi sembra autoesplicativa tranne forse per la il VBO che è il VertxBufferObject e che serve per "compattare" e inviare in un formato gestibile più velocemente (e nella vram) i modelli caricati iin precedenza. Poi si lancia il mainloop, che rappresenta il ciclo di rendering che sarà eseguito all'infinito. Durante questo ciclo, dovrò renderizzare i modelli che ho caricato. Mettiamo (sto sempre semplificando molto) di avere una funzione che piazza un albero in un certo punto. Questa funzione conterrà anche i "settaggi" che servono per definirlo (colore, texture, posizione, ecc...) ed anche la chiamata al nostro benedetto shader che utilizzerà queste informazioni come input per disegnare l'albero usando gli algoritmi di illuminazione, ombre, ecc... che abbiamo scritto nello shader (ne servirà più di uno, ma facciamo finta di no) e che, tramite quels'ultimo, la GPU applicherà ai vertici e pixel che gli "arrivano" (dipende se è un vertex o un pixel shader). Quindi:
imposto_colore();
uso_texture23();
traslo_nello_spazio();
glUseProgram(LightningProgram);
disegno_albero(qua dentro ci saranno specificati i vertici, o comunque quale parte dei VBO usare);
E' importante sottolineare che al momento della carico_shader() se stessi eseguendo il gioco sarei nella situazione di run-time dell'applicazione, ma di compile-time dello shader, il quale comunque una volta terminata questa fase non va in esecuzione nella GPU fino al raggiungimento di una glUseProgram.
Quando lo sviluppatore ha finito il gioco, ha delle cartelle che contengono il codice sorgente del gioco, le texture, i suoni, i modelli, ecc... . Ci sarà probabilmetne anche una cartella che contiene gli shader (se non ha deciso di codificarlo in una stringa nel sorgente, ma per quello che succede dopo non cambia niente e rende solo più difficile seguire il discorso). Alla fine quindi compila il sorgente del gioco ed ottiene un bell'exe (fa sparire così il sorgente che tiene per se). Poi mette tutto su DVD e lo mette in vendita. L'utente compra il dvd, installa il gioco e si ritrova nella stessa situazione dello sviluppatore, ma senza il sorgente. Ha però tutti i modelli, texture, ecc... tra cui anche gli shader, ancora da compilare (per gli ovvi motivi spiegati più in alto nel post), addirittura in sorgente se è un gioco opengl (cioè se li apro con notepad vedo prorpio il codice GLSL ad alto livello, provate a scaricarvi un demo opengl già compilato che contenga shader GLSL e potrete verificare).
Quando l'utente fa doppio click sull'eseguibile, il gioco esegue le funzioni descritte in precedenza, compresa la carico_shader() in cui faccio la chiamata alla compilazione. Il driver riceve gli shader e li compila. Quando arriverà il momento della glUseProgram(LightningProgram), vengono messi in esecuzione i vertex e pixel shader compilati (magari anche geometry shader se siamo in una versione delle directx/opengl che li usa) che verranno eseguiti sui successivi dati in arrivo, finche non chiamerò una glUseProgram su uno shader diverso.
Un aneddoto divertente che ho scoperto tempo fa riguarda gli shader per calcolare l'SSAO (screen space ambient occlusion), che stavo cercando di capire bene in modo da implementarla. L'ambient occlusion è un effetto che simula l'illuminazione globale (che a differenza dei classici modelli locali tiene conto delle riflessioni/rifrazioni delle luci) considerando la vicinanza e inclinazione tra i vari poligoni che compongono un modello cercando di calcolare dove ci saranno delle zone + scure (angoli, cavità, ecc...) in cui la luce non "passa" per bene. E' una descrizione brutale ma se volete saperne di più in rete è una tecnica ampiamente descritta, almeno qualitativamente. E' quindi ovvio che calcolando la visibilità di ogni poligono rispetto agli altri (cioè quanta ombra ogni poligono potrebbe fare a gli altri che compongono la scena), richiede un tempo quadratico e quindi improponiobile in realtime, soprattutto se calcolata poi per pixel e non per vertex. E' stata per esempio utilizzata in shrek. Crytek, nel fantomatico Crysis (ed è uno dei tanti motivi per cui è pesante come la morte) ha introdotto una tecnica per approssimare l'AO in screen space (da cui SSAO), in modo che i calcoli vengano fatti solo sui pixel che compongono l'immagine visualizzata e non anche i pixel delle superfici nascoste o non visualizzate, ma che comunque concorrerebbero alla occlusione e quindi si dovrebbe tenerne conto. Il paper,presentato nel 2007 che descriveva in modo molto sisntetico e qualitativo la tecnica, è stato oggetto di "culto" per diverso tempo in cui molti hanno tentato di replicare la tecnica, ma con risultati inferiori. Questo fino a che qualcuno (con due OO così), sbirciando nelle cartelle del gioco ha trovato gli shader e aprendoli è riuscito + o - a capirne la tecnica pratica di base. Avevo provato anch'io a guardarli (non ho crysis ma li avevano subito piazzati in rete), ma non erano molto intuitivi, poco commentati e per giunta in directx per cui ho rinunciato. C'è anche da dire che se non vengono utilizzati dei nomi autoesplicativi per le variabili e i sampler delle texture, uno dovrebbe capire che cosa rappresentano in base a che uso ne viene fatto nello shader, ma se guardo lo shader per capire cosa fa, stiamo a cavallo...
io ho capito quello che vuoi dire, ma non è possibile farlo; non in questo caso. Non stiamo parlando della sostituzione dell'istruzione che si fa una tantum: ad esempio, forzare l'AA in un gioco da driver. In quel caso, il tutto avviene all'inizio, modificando una sola impostaizone all'atto del caricamento del gioco. A tutto il resto pensa la gpu che ha il suo algortmo di edge detect che entra in funzione in automatico quando viene forzato il MSAA. Qui parliamo di una sostituzione che si deve fare su tutte le istruzioni di pixel, vertex e geometry shader e texture blending, tenendo conto anche di eventuali operazioni di tessellatin che generano un numero molto più elevato di vertici su cui si devono applicare le stesse operazioni, di shader procedurali e di vertex e geometry shader che generano un gran numero di pixel su cui si devono operare delle madd. E il tutto avviene all'interno della gpu e non al suo esterno e non è neppure pensabile che, alla bisogna, le istruzioni che si rendono necessarie vengono ottimizzate dalla cpu e caricate al volo (passerebbero secoli). In realtà è la prima volta che ci si trova di fronte ad una situazione in cui si potrebbe rendere necessaria una sostituzione di istruzioni su vastissima scala.
Per risolvere il problema tu proponi un'ottimizzazione, di fatto, at compile time che nVidia (ma non solo lei) non gradisce, che mal si adatta ad un'architettura superscalare (che necessità di un compilatore dinamico per poter meglio ottimizzare) e che comporta un notevole dispendio di risorse. Inoltre, ripeto, la stessa nVidia parla di ottimizzazini JIT e non at compile time.
Il JIT si fa a compile-time! è compile-time dello shader e run-time dell'applicazione, ma visto che stiamo parlando di GPU è compile-time! in fatti il JIt è un compilatore e compila; per compilare dovrà pure leggerlo il codice no? quindi se lo shader ha 200 istruzioni, dopo la compilazione magari ci sono 1000 MADD, bene: il driver le cancella e gli mette 1000 FMA. quanto vuoi che ci metta? siccome poi sta cosa la deve fare una volta sola (perchè sta compilando il codice, non lo sta eseguendo, l'esecuzione si farà sul codice che esce da quà e che si va poi a piazzare per essere eseguito dagli stream processor), è evidente che sarà ben più efficiente. E con una volta solo non intendo ovviamente che se ci sono 1000 MADD con UNA sostituzione sono a posto: è ovvio che le cambio tutte e 1000. Ma diciamo che lo shader viene eseguito 60 volte al secondo. LA GPU farebbe 1000*60 sostituzioni al secondo (nel migliore dei casi: è molto probabile che ci siano dei cicli e che quindi nel codice ci siano meno istruzioni di quante siano effettivamente le esecuzioni, anche se non so le l'assembler di ogni GPU prevede i goto o similari come in x86 oppure "srotola" il ciclo) se così non fosse contro le 0 se la sostituzione venisse (come avviene) effettuata dal JIT prima dell'inizio dell'elaborazione dello shader. Che poi quelle numerose sostituzioni possano incidere poco e siano tecnicamente altamente mascherabili non lo metto in dubbio (infatti per cose che non si possono "aggiustare" a compile time bisogna giocoforza intervenire a run-time), ma battere lo 0 mi risulta sia davvero difficile.
CUDA è c-like come hlsl e glsl e non ha nulla di complesso: è open64 con qualche ottimizzazione per chip nVidia. Studiarlo è utile per capire come funzionano i chip, quali sono le loro potenzialità e qual è la strategia di nVidia (anche in relazione alle ottimizzazioni).
Mi sembra di avere già spiegato perchè nella nostra discussione CUDA crei solo confusione e non sia per niente d'aiuto
A me risulta che una compilazione JIT prevede, invece, proprio la compilazione mentre l'applicazione sta girando. Se si compila prima tutto il codice e lo si ottimizza parliamo di compile time. Semmai può essere che si tratti di un aparte del codice e, mentre la gpu lavora su questo, la cpu ottimizza un'altra porzione, ma, allora, il traffico si crea eccome e si crea anche una gran confusione. Chi dà alla cpu le informazioni sulle istruzioni chiamate sulla gpu? Come sa quale parte del codice ottimizzare se non sa su cosa sta lavorando la gpu perchè non ha accesso al suo interno? Come fa a sapere che un'istruzione non abbia generato dati che devono essere processati prima di altri già schedulati? In parole povere, in base a quale criterio decide l'ordine in cui procedere?
se, poi, parliamo di compile time, allora è un altro paio di maniche (ma nVidia dice JIT e un'architettura superscalare ha bisogno di compilazione dinamica).
Sempre lo stesso inghippo: Come già spiagato, la tecnica JIT è stata introdotta per evitare la fase di interpretazione dei linguaggi interpretati (può sembrare un controsenso ma è così). Per esempio JAVA:
sviluppatore
sorgente->(compilatore)->bytecode
utente (senza JIT):
bytecode->(interprete)->esecuzione
L'interprete è l'anello debole della catena perchè deve tradurre in linguaggio macchina istruzione per istruzione, e (in una implementazione senza scorciatotie) se c'è un loop da eseguire 100 volte, lo traduce 100 volte. Con il JIT invece appena prima dell'esecuzione (ho fatto doppio click con i mouse) compila direttamente il codice, in modo da poterlo eseguire più velocemente, Ovviamente questo comporta che il lancio sarà più lungo, ma è ampiamente compensato dalla maggior prestazione in esecuzione. Il JIT per gli shader lavora un po più "tranquillo", perchè quando l'applicativo lancia la compile, link, ecc..., non è che l'operazione successiva è l'esecuzione dello shader, ma probabilmente ci saranno altre cose da fare (come da esempio poco sopra). E' quindi un compile-time reale, ma viene chiamato JIT comunque perchè
1) viene fatto mentre l'applicativo sta già girando e lo shader partirà di li a poco.
2) viene comunque rieseguita tutte le volte che rieseguo l'applicazione
si tratta di ottimizzazioni fortemente dipendenti dall'ordine delle istruzioni che arriverebbero già ottimizzate. Vedi punto sopra: la cpu non può sapere su cosa sta lavorando la gpu e non può, di conseguenza, fare sostituzine JIT delle istruzioni necessarie. La gestione dei thread è un processo dinamico e non statico; ripeto, qui non parliamo di forzare l'AA via driver all'atto del lancio dell'applicazione.
la gestione dei thread infatti viene fatta tutta dalla GPU (come molte altre cose), l'ho specificato più volte. Visto che comunque in base a quello che dico io le sostituzioni sono una delle mansioni del JIT e che quindi vengono fatte prima che lo shader passi in esecuzione, la CPU sa benissimo cosa sta facendo la GPU riguardo a quel particolare shader: nulla.
ti ho già spiegato perchè non è possibile fare una "semplice sostituzione" at compile time: perchè si parla di migliaia di semplici sostituzioni che devono servire ad elaborare dati che ancora non sono stati creati e di cui non si conosce nè il numero né gli altri parametri tra cui l'ordine in cui dovranno essere processati. (la cpu conosce solo i valori iniziali dei vertici di un frame). Inoltre, ripeto per l'ennesima volta, un'architetura superscalare vuole un compiler dinamico (pena pessima ottimizzazione) e nVdia non parla di preephole optimization at compile time (ci sarà un motivo)?
che c'entra che i vertici/dati non ci sono? se scrivo un programma in c che prende un file txt e leggendolo sostituisce tutte le occorrenze "berlusconi" con "presidente del consiglio" restituendo un secondo file, non è che quando lo compilo ho bisogno che il compilatore abbia a disposizione i dati di input (in questo caso il TXT). Il compilatore semplicemente traduce in codice macchina le istruzioni che trova, le quali prevedono anche queste sostituzioni di stringhe. LA MADD con FMA è un po la stessa cosa: il JIT vede che ci dovrebbe essere MADD a, b, c, d e ci piazza FMA a, b, c, d. Semplice e statico.
invece io ritengo, per quanto esposto, che la sostituzione, ammesso che sia possibile e che si farà, avverrà sulla gpu.
E mi pare che siamo di nuovo ad un punto morto e, poichè ho un avita sociale, un lavoro e un articolo da scrivere (tranquilli non è su fermi, anche se ci sarebbe materiale per una serie completa degna di beautiful :p ), ritengo poco costruttivo contìnuare una discussione in cui ognuno ha espresso i suoi concetti (anche più volte) senza arrivare ad una conclusione di sorta. :D
Per me va bene, anzi è anche meglio, visto che negli ultimi post sto/stiamo ripetendo le stesse cose. Spero almeno che qualcuno (basta 1 e sono contento) si sia letto per bene il materiale linkato ed abbia maturato l'interesse di approfondire un po e farsi una sua idea non basata su ciò che diciamo noi.
yossarian
01-12-2009, 18:02
Ho infatti parlato di MADD e FMA che dovrebbero avere gli stessi operandi, ma comunque io pensavo ad uno schema di questo tipo nel quale ad esempio, premesso che non so un ca..o di hardware, introdurre una sorta di Instruction Translator tra il fetcher e il decoder, un qualcosa come questo:
Instruction Fetcher
|
Instruction Translator
|
Instruction Decoder
Se IF IT e ID riescono a operare in parallelo e quindi sullo stesso ciclo di clock, a regime, la traduzione tra MADD e FMA, potrebbe avere costo nullo ?
IF, IT e ID lavorano in serie. Dopo la decodifica avviene la comparazione con l'istruzione "in finestra"; se le due istruzioni coincidono (si tratta di una madd) viene mandata in esecuzione una fma, se non coincidono si invia in esecuzione l'istruzione caricata. In pratica i passaggi in più sono comparazione e sostituzione. NIente è a costo zero (considera che su un'architettura supescalare come quella di GT200, l'accesso ai registri per operazioni di read/write richiede 11 cicli (contro 1 teorico :D ). Quindi un paio di step in più non sono esattamente a costo zero. Quello che si può fare è mascherare le latenze di questi ulteriori passaggi, sfruttando la gestione multithraeding del chip (che rispetto a GT200 ha ridotto il thread switching in maniera drastica) e può gestire due thread in contemporanea per alu. Questo significa che, anche tenendo conto dei vincoli (non può andare in esecuzione in contemporanea un'istruzione fp, una INT e una che gira su SFU ma solo una per ciclo), sfruttando i tempi di idle di una delle altre istruzioni in esecuzione può avvenire si può inserire la sostituzione nel modo più indolore possibile.
Stando alle specifiche, fermi dovrebbe gestire molto bene le operazioni di algebra booleana e le istruzioni di salto che, guarda caso, sono le operazioni necessarie ad effettuare questo tipo di ottimizzazione al volo :p
Severnaya
01-12-2009, 18:03
io consiglierei 500mg di Torazina...
:asd:
cut
madonna.... servirebbe un licenziamento per leggere il tuo post, visto che le ferie non basterebbero :eek:
Diobrando_21
01-12-2009, 18:57
Mi sembra una grande cazzata se bisognerà anche cambiare i monitor e acquistare gli occhiali!!!! se uno deve spendere 1000 euro per una vga che senso ha? con 750 euro circa si prendono 2 5870 in xfire!!!
scusa ma devo contraddirti...non sono affatto una cazzata, sono il futuro ;)
nVidia da questo punto di vista ha anticipato tutti fornendo la possibilità di utilizzare la stereoscopia con occhiali lcd attivi applicabile al 90% dei game (non occorre che siano programmati appositamente)...sono il futuro perché già dal prox anno tanti produttori adotteranno la stessa tecnologia (Sony, Samsung, Panasonic e mi sembra anche Toshiba).
io li ho e ti posso assicurare che una volta provati non puoi (vuoi) più tornare indietro, tutto sembra piatto e scialbo. Se vuoi x qualsiasi chiarimento sono a disposizione e non ti servono 1000euro ma con 450euro ti porti a casa monitor 120hz nativi + kit 3d Vision. ti rimando al thread apposito perché qui siamo OT ;)
http://www.hwupgrade.it/forum/showthread.php?t=1993079
Raga, siete intelligenti, non chiedetemi informazioni in pvt.:p
Questo è quanto è emerso ieri....CES, Las Vegas dal 7 al 10 gennaio 2010....Fermi. Ieri si è parlato di 3D Vision.:)
scusa puoi almeno dirci cos'hanno detto del 3d vision? mica tireranno fuori un nuovo kit, vero? :mbe:
Bastoner
01-12-2009, 19:29
io consiglierei 500mg di Torazina...
:asd:
:sbonk:
IF, IT e ID lavorano in serie.
Ahhhh.... quindi nelle gpu non esistono come nelle cpu meccanismi di data/instruction prefetch ?
Edit: Sempre in riferimento all'argomento, esecuzione codice shader ovviamente :)
freedom07
02-12-2009, 08:25
mah :eek: in pratica ankora nulla ....
Simedan1985
02-12-2009, 10:56
Bè se nn esce almeno qualcosa entro natale ,si puo dire che nvidia nn è stata per niente di parola .....
Inizialmente avevano dato come data il Black Friday, quindi sono già fuori.
considerando che io le aspettavo per metà novembre XD
Simedan1985
02-12-2009, 11:44
considerando che io le aspettavo per metà novembre XD
Idem...allora si vede che i problemi ci sono ,e forse anche + grossi del previsto:(
che ci sia qualcosa che non va è palese, se manco col Natale in arrivo vola una mosca vuole dire che le acque sono molto scure... :rolleyes:
Simedan1985
02-12-2009, 11:56
Anche perchè, sinceramente ,se partiamo da ottobre e finiamo a marzo ....nn mi sembra un ottima strategia commerciale far rimanere la concorrenza 6 mesi da sola sul mercato a coprire tutte le fascie di prezzo
yossarian
02-12-2009, 12:32
CUT
mi hai convinto; credo che quella che prospetti sia la soluzione migliore.
Approfitto anche per scusarmi sia con te che con devAngnew se, in qualche occasione, ho trasceso in qualche espressione.
E' sempre un piacere parlare con persone preparate; si può sempre imparare qualcosa. :mano:
Ahhhh.... quindi nelle gpu non esistono come nelle cpu meccanismi di data/instruction prefetch ?
Edit: Sempre in riferimento all'argomento, esecuzione codice shader ovviamente :)
no; una pipeline grafica è composta da un'alternanza di stadi di tipo fixed function e di stadi programmabili. I primi fanno prefetch, per i secondi la cosa è estremamente difficile perchè si creano troppe dipendenze tra l'elaborazione in corso e quella immediatamente successiva e tra elaborazioni parallele e richiedono accessi alla memoria (buffer, registri, cache) a granularità molto fine. Di conseguenza, le pipeline alternano stadi in cui sono presenti unità che fanno prefetch a stadi in cui queste unità sono del tutto assenti.
Contrariamente a quanto avviene con le cpu, le gpu sono dispositivi ottimizzati per avere una bandwidth molto ampia verso la memoria piuttosto che latenze ridotte (che sono mascherate dal massiccio uso del multithreading).
Bastoner
02-12-2009, 12:33
mi hai convinto; credo che quella che prospetti sia la soluzione migliore.
Approfitto anche per scusarmi sia con te che con devAngnew se, in qualche occasione, ho trasceso in qualche espressione.
E' sempre un piacere parlare con persone preparate; si può sempre imparare qualcosa. :mano:
Bugiardo! :sbonk:
yossarian
02-12-2009, 12:34
Bugiardo! :sbonk:
stavolta sono serissimo. Ci si può anche sbagliare e non sempre si può avere ragione.
Bastoner
02-12-2009, 12:38
stavolta sono serissimo. Ci si può anche sbagliare e non sempre si può avere ragione.
Uhm sarà....ma io sono scettico :fiufiu:
marco XP2400+
02-12-2009, 12:45
yoss su cosa ti eri sbagliato ad interpretare???
yossarian
02-12-2009, 13:08
Uhm sarà....ma io sono scettico :fiufiu:
capita tante volte di sbagliarsi; sul lavoro, nella vita. Persino sui forum. L'importante è accorgersene per tempo (e non sempre succede) ed avere sufficiente intelligenza ed onestà intellettuale da ammetterlo. Comunque, dovendo scegliere tra le tre opzioni, preferisco sbagliarmi sul forum :D
yoss su cosa ti eri sbagliato ad interpretare???
ho avuto una visione parziale del problema (errore grave ma che a volte può capitare). In pratica ho considerato quello che un'architettura come quella di fermi può fare e non quello che è meglio o più opportuno che si faccia. In effetti, se è possibile compilare tutto il codice prima dell'avvio del gioco, non ha senso sbattersi per fare la stessa cosa JIT sulla gpu. Come non ha senso impegnarsi a cercare e scrivere un modello di preephole per gpu quando quelli per cpu sono già belli e pronti.
Questo è dovuto al fatto che la mia conoscenza della programmazione è limitata a reminiscenze di tipo scolastico.
Simedan1985
02-12-2009, 14:23
Bè ...questo insomma x nvidia nn è prorpio un bel momento,sbeffeggiata,anche se solo sulla carta,anche da intel:http://www.tomshw.it/cont/news/intel-larrabee-stritola-tre-volte-nvidia-tesla/23055/1.html
halduemilauno
02-12-2009, 14:27
Bè ...questo insomma x nvidia nn è prorpio un bel momento,sbeffeggiata,anche se solo sulla carta,anche da intel:http://www.tomshw.it/cont/news/intel-larrabee-stritola-tre-volte-nvidia-tesla/23055/1.html
secondo intel è 2.7 volte il tesla attuale non il tesla fermi.
secondo intel è 2.7 volte il tesla attuale non il tesla fermi.
diciamo che sia la nuova tesla nvida sia larabee si sanno solamente le notizie di delle presunte slide, nulla è certo, sicuramente intel è piu' veritiera negli ultimi tempi rispetto a nvida
diciamo che sia la nuova tesla nvida sia larabee si sanno solamente le notizie di delle presunte slide, nulla è certo, sicuramente intel è piu' veritiera negli ultimi tempi rispetto a nvida
...speriamo che nVidia riesca a piazzare questa generazione del campo del gpgpu perchè alla prossima tornata intel sarà prepotentemente presente...
...vedremo...
...ciao Andrea...
Kharonte85
02-12-2009, 17:14
Cuttone
Spero almeno che qualcuno (basta 1 e sono contento) si sia letto per bene il materiale linkato ed abbia maturato l'interesse di approfondire un po e farsi una sua idea non basata su ciò che diciamo noi.
CTRL+D :D
capita tante volte di sbagliarsi; sul lavoro, nella vita. Persino sui forum. L'importante è accorgersene per tempo (e non sempre succede) ed avere sufficiente intelligenza ed onestà intellettuale da ammetterlo. Comunque, dovendo scegliere tra le tre opzioni, preferisco sbagliarmi sul forum :D
ho avuto una visione parziale del problema (errore grave ma che a volte può capitare). In pratica ho considerato quello che un'architettura come quella di fermi può fare e non quello che è meglio o più opportuno che si faccia. In effetti, se è possibile compilare tutto il codice prima dell'avvio del gioco, non ha senso sbattersi per fare la stessa cosa JIT sulla gpu. Come non ha senso impegnarsi a cercare e scrivere un modello di preephole per gpu quando quelli per cpu sono già belli e pronti.
Questo è dovuto al fatto che la mia conoscenza della programmazione è limitata a reminiscenze di tipo scolastico.
A quanto pare alla fine avete sbrogliato la matassa! :p
Posso dirvi che è stata la discussione più interessante mai apparsa su questo forum da quando sono iscritto (oltretutto nonostante i tecnicismi dimostrate di sapervi spiegare molto bene) ...quindi complimenti a tutti e 2 :mano: in particolare alla onesta' di Yoss, davvero.
marco XP2400+
02-12-2009, 17:47
infatti quasi mi dispiace che si sia risolta la questione!!!
devAngnew
02-12-2009, 19:51
mi hai convinto; credo che quella che prospetti sia la soluzione migliore.
Approfitto anche per scusarmi sia con te che con devAngnew se, in qualche occasione, ho trasceso in qualche espressione.
E' sempre un piacere parlare con persone preparate; si può sempre imparare qualcosa. :mano:
.............
Scuse accettate :mano: , approfitto di questi 2 minuti liberi che ho per dire ai restanti utenti probabilmente sarò stato vago riguardo il ragionamento circa i compilatori ma del resto ho trovato poco opportuno parlare in modo approfondito di analisi lessicale, sintattica e automi a stati finiti, modalità JIT ecc. ecc. mi scuso se sono stato poco chiaro.
Alla fine l’intervento di skizzo è stato fondamentale grazie anche alla sua conoscenza specifica nel campo della CG. Ancora grazie.
Yossarian approfitto per ribadire che in elettronica sei preparato dopotutto ognuno conosce il suo mestiere.
skizzo99999999
02-12-2009, 20:01
mi hai convinto; credo che quella che prospetti sia la soluzione migliore.
Approfitto anche per scusarmi sia con te che con devAngnew se, in qualche occasione, ho trasceso in qualche espressione.
E' sempre un piacere parlare con persone preparate; si può sempre imparare qualcosa. :mano:
ricambio il piacere volentieri. :mano: E non c'è bisogno di scuse, anche se gli apprezzamenti fanno sempre piacere.
scusa ma devo contraddirti...non sono affatto una cazzata, sono il futuro ;)
nVidia da questo punto di vista ha anticipato tutti fornendo la possibilità di utilizzare la stereoscopia con occhiali lcd attivi applicabile al 90% dei game (non occorre che siano programmati appositamente)...sono il futuro perché già dal prox anno tanti produttori adotteranno la stessa tecnologia (Sony, Samsung, Panasonic e mi sembra anche Toshiba).
io li ho e ti posso assicurare che una volta provati non puoi (vuoi) più tornare indietro, tutto sembra piatto e scialbo. Se vuoi x qualsiasi chiarimento sono a disposizione e non ti servono 1000euro ma con 450euro ti porti a casa monitor 120hz nativi + kit 3d Vision. ti rimando al thread apposito perché qui siamo OT ;)
http://www.hwupgrade.it/forum/showthread.php?t=1993079
scusa puoi almeno dirci cos'hanno detto del 3d vision? mica tireranno fuori un nuovo kit, vero? :mbe:
Stasera al TG1 delle 20, hanno detto qualche novità Nvidia che si è visto al 3D Vision. Hai seguito?:)
Andrea deluxe
03-12-2009, 09:23
http://www.tweaktown.com/news/13631/nvidia_fermi_launch_delayed_to_march_2010/index.html?
:stordita:
http://www.tweaktown.com/news/13631/nvidia_fermi_launch_delayed_to_march_2010/index.html?
:stordita:
male molto male e intanto: http://www.tomshw.it/cont/news/chipset-amd-con-cpu-amd-presto-il-monopolio/23068/1.html
greeneye
03-12-2009, 09:32
http://www.tweaktown.com/news/13631/nvidia_fermi_launch_delayed_to_march_2010/index.html?
:stordita:
La stessa Nvidia ha detto Q1, quindi gennaio, febbraio o marzo.
Altre voci sussurrano febbraio....bisognerà aspettare.
http://vr-zone.com/forums/515794/fermi-could-have-to-wait-until-march.html
To be honest, we ourselves at HWZ have also heard murmurs of a possibility of a February launch. This is surely worrying for the graphics giant. To read the original story, click here.
ciccionamente90
03-12-2009, 09:56
Ora basta che mi fate venire la carie :asd:
volemossebbene!
Diobrando_21
03-12-2009, 10:27
Stasera al TG1 delle 20, hanno detto qualche novità Nvidia che si è visto al 3D Vision. Hai seguito?:)
purtroppo no, sono stato fuori casa tutto il giorno...cos'hanno detto? Quale novità ci sono x il 3d vision? Anche in pvt se vuoi, così niente OT ;)
greeneye
03-12-2009, 10:49
purtroppo no, sono stato fuori casa tutto il giorno...cos'hanno detto? Quale novità ci sono x il 3d vision? Anche in pvt se vuoi, così niente OT ;)
Un servizio piuttosto inutile: qualche banalità e qualche marchetta.
http://www.rai.tv/dl/RaiTV/programmi/media/ContentItem-94b8e93e-f016-4fa7-bfff-7543f2cd1fda.html
Kharonte85
03-12-2009, 11:35
http://www.tweaktown.com/news/13631/nvidia_fermi_launch_delayed_to_march_2010/index.html?
:stordita:
Che la commercializzazione avverrà a Marzo si sospettava da un pezzo, a me piacerebbe sapere quando avranno intenzione di diffondere i dati prestazionali (con le revision A2 funzionanti o coi sample A3)...tanto non potranno di certo fare peggio di AMD a questo giro che ha presentato schede fantasma dal 23 settembre che non si trovano tutt'ora...certo la colpa è anche di TSMC pero' mai vista una situazione del genere :doh:
male molto male e intanto: http://www.tomshw.it/cont/news/chipset-amd-con-cpu-amd-presto-il-monopolio/23068/1.html
Era ovvio (ed è eticamente scorretto tanto per ribadire l'ovvietà che non esistono aziende "buone") che AMD approfittasse della sua posizione.
Bastoner
03-12-2009, 11:48
Le schede fantasma di AMD stanno già in decine di migliaia di case nel mondo, c'è molto spazio per fare peggio, si chiama paper launch.
Si chiama anche rebranding. Nvidia 310 docet.
Pensandoci su, AMD potrebbe prendere un po' di 4890 e appiccicarci su uno sticker della 5870....Ci si deve pure arrangiare :mc:
Che idea eh? :D
Se la propongo ad AMD mi fanno CEO :sofico:
supersalam
03-12-2009, 11:51
male molto male e intanto: http://www.tomshw.it/cont/news/chipset-amd-con-cpu-amd-presto-il-monopolio/23068/1.html
Ecco! Le soluzioni sono 2:
1: Nvidia sborsa una montagna di soldi e produce un chipset compatibile sia con amd che intel la cui resa supera qualunque chipset per le due piattaforme.
2: Nvidia si fonde con Apple e porta il gaming ad alti livelli su Mac, facendo ciao ciao con la manina a AMD.
greeneye
03-12-2009, 11:53
Ecco! Le soluzioni sono 2:
1: Nvidia sborsa una montagna di soldi e produce un chipset compatibile sia con amd che intel la cui resa supera qualunque chipset per le due piattaforme.
2: Nvidia si fonde con Apple e porta il gaming ad alti livelli su Mac, facendo ciao ciao con la manina a AMD.
Entrambe cose impossibili.
Bastoner
03-12-2009, 11:55
Ecco! Le soluzioni sono 2:
1: Nvidia sborsa una montagna di soldi e produce un chipset compatibile sia con amd che intel la cui resa supera qualunque chipset per le due piattaforme.
2: Nvidia si fonde con Apple e porta il gaming ad alti livelli su Mac, facendo ciao ciao con la manina a AMD.
Che fantasia :asd:
Kharonte85
03-12-2009, 11:56
Le schede fantasma di AMD stanno già in decine di migliaia di case nel mondo, c'è molto spazio per fare peggio, si chiama paper launch.
In realtà la situazione non ha una definizione, non lo chiamerei nemmeno Soft launch (perchè di solito la disponibilità va aumentando non diminuendo col tempo)...le uniche schede vendute sono state le prime (hd5870, 5850), dopodiche' il silenzio (e basta farsi un giro nei thread ufficiali per vedere quanti stanno pensando di annullare gli ordini perchè sono 1-2mesi che aspettano), un paper launch dichiarato sarebbe meglio di un lancio come quello che ha fatto AMD che ti costringe ad una caccia al colpo di fortuna con risultati incerti (e prezzi gonfiati)...o pensiamo che AMD ci stia prendendo in giro :ciapet: (ma la cosa è poco probabile) oppure questo è stato un errore strategico di AMD abbastanza grave (anche se TSMC ha avuto problemi AMD avrebbe dovuto prevedere dei margini maggiori) tanto più che non c'era nessuna fretta dato che anche i muri sapevano che nvidia era in ritardo.
greeneye
03-12-2009, 11:59
La prima è irrealizzabile perchè intel non concede la licenza del bus QPI.
Se si legge l'articolo originale (non la fantasiosa interpretazione che ne ha dato toms) amd non ha detto che impedirà a nvidia di fornire chipset per i suoi processori ma che aspira a venderne più dei suoi.
In fin dei conti è la stessa nvidia che non fa uscire un chipset nuovo per amd dal 2007 e che nel segmento server è ancora peggio perchè le soluzioni che fornisce sono ancora dei nforce3/4 rimarchiati.
greeneye
03-12-2009, 12:07
In realtà la situazione non ha una definizione, non lo chiamerei nemmeno Soft launch (perchè di solito la disponibilità va aumentando non diminuendo col tempo)...le uniche schede vendute sono state le prime (hd5870, 5850), dopodiche' il silenzio (e basta farsi un giro nei thread ufficiali per vedere quanti stanno pensando di annullare gli ordini perchè sono 1-2mesi che aspettano), un paper launch dichiarato sarebbe meglio di un lancio come quello che ha fatto AMD che ti costringe ad una caccia al colpo di fortuna con risultati incerti (e prezzi gonfiati)...o pensiamo che AMD ci stia prendendo in giro :ciapet: (ma la cosa è poco probabile) oppure questo è stato un errore strategico di AMD abbastanza grave (anche se TSMC ha avuto problemi AMD avrebbe dovuto prevedere dei margini maggiori) tanto più che non c'era nessuna fretta dato che anche i muri sapevano che nvidia era in ritardo.
Ce ne sono poche ma se la si vuole la si riesce ad avere:
http://img138.imageshack.us/img138/2930/jshot.jpg
http://img138.imageshack.us/img138/1426/jshoti.jpg
http://img138.imageshack.us/img138/4421/jshots.jpg
marco XP2400+
03-12-2009, 12:13
Se si legge l'articolo originale (non la fantasiosa interpretazione che ne ha dato toms) amd non ha detto che impedirà a nvidia di fornire chipset per i suoi processori ma che aspira a venderne più dei suoi.
però pure hwu dà un'interpretazione del genere, mi sembra di capire
Kharonte85
03-12-2009, 12:22
Ce ne sono poche ma se la si vuole la si riesce ad avere
A leggere il thread ufficiale l'impressione non è questa...dal giretto che ho fatto molte di quelle che vengono date per disponibili sono in realtà prenotabili per data X o con disponibilità talmente scarsa che tu fai l'ordine ma poi ti fanno attendere...io spero che la situazione si sblocchi al più presto anche perchè i prezzi sono alle stelle.
Kharonte85
03-12-2009, 12:26
quotone anche la revisione a2 a bassa resa andrebbe bene cavoli un sample funzionante dovrebbero gia averlo perchè se Fermi è cosi potente nn dare una dimostrazione di potenza???
sai quanti lascierebbero perdere la serie 5000 per aspettare gt300??!!
secondo me stanno appena alla rev A3 devono migliorare la resa e aspettare TSMC per mostrare bench e dire:
"ok questo mostro sarà venduto presto e nn rimarra solo un sample!!"
Credo anche io una cosa del genere...
quotone anche la revisione a2 a bassa resa andrebbe bene cavoli un sample funzionante dovrebbero gia averlo perchè se Fermi è cosi potente nn dare una dimostrazione di potenza???
sai quanti lascierebbero perdere la serie 5000 per aspettare gt300??!!
secondo me stanno appena alla rev A3 devono migliorare la resa e aspettare TSMC per mostrare bench e dire:
"ok questo mostro sarà venduto presto e nn rimarra solo un sample!!"
penso vogliano evitare altre figure di m***a nvidia ha gia chiuso la sezione chipset certo che se stanno cosi in ritardo campa cavallo ad aspettare.:cry:
per RATATOSK :bellissimo l avatar ahahhahah!
un mostro? :confused: se i rumors saranno rispettati andrà un 10% in piu' della 5870 e quanto costerà? sinceramente per me sarà tutto tranne che un mostro.........
Drakogian
03-12-2009, 13:09
sono scettico infatti se sarà piu potente ben venga ma ci sono ancora troppe cose da considerare:
-reali prestazioni in dx11(nn si sa niente di niente)
-consumi
-dual-gpu nvidia?(ci credo poco)
l' importante è che esca e come prestazioni sia simile alla 5970 in modo da creare una reale competizione sui prezzi.
Questo è il punto che più mi interessa... ;)
sono scettico infatti se sarà piu potente ben venga ma ci sono ancora troppe cose da considerare:
-reali prestazioni in dx11(nn si sa niente di niente)
-consumi
-dual-gpu nvidia?(ci credo poco)
l' importante è che esca e come prestazioni sia simile alla 5970 in modo da creare una reale competizione sui prezzi.
utopia posto che lo step A2 va un 10% in piu di Cypress xt, anche alzando le frequenze non andrà mai dico mai piu' o come Hemlock ;)
Simedan1985
03-12-2009, 13:37
Quoto okorop ,quando ipotizza un 20% rispetto a 5870 ,in effetti sarebbe un buon 120% su Gt 200b ...cmq nn sarebbe malvagio come "salto",ovviamente parlo di singola gpu.Quindi a mio avviso sarebbe impossibile prendere Hemlock.
Sulla x2 nvida ..penso che ci vorrà almeno un due mesi dopo.
Detto questo ovvio ,che l'ottimismo mi porti a pensare che questo silenzio serve per celare un mostro,che vada se nn + ma quasi come hemlock....e che sià subito disponibile in versione x2 .Ma meglio rimanere su considerazioni + obbiettive.
Sinceramente stavo vedendo Hemlock ,avevo anche chiamato un paio di store per l'effettiva disponibilità...pero poi sono andato sul thread ufficiale e ho un attimo cambiato idea causa lo stuttering piuttosto diffuso e la poca solidita della ventola che tocca le plastiche,e sinceramente spende 550 e rittrovarmi con dei problemi nn mi andava ....anche perche la mia 295 va liscia come l'olio.
A leggere il thread ufficiale l'impressione non è questa...dal giretto che ho fatto molte di quelle che vengono date per disponibili sono in realtà prenotabili per data X o con disponibilità talmente scarsa che tu fai l'ordine ma poi ti fanno attendere...io spero che la situazione si sblocchi al più presto anche perchè i prezzi sono alle stelle.
Le schede non sono disponibili in grandi numeri (per i motivi detti e ridetti, e no per colpa di AMD), ma ci sono. Nei grandi centri si trovano pure in alcuni negozi fisici.
Ovvio che se uno le ordina sui negozi dove sono in ordinazione o non disponibili non le riceve a breve...
Detto ciò, se NVidia avesse avuto la possibilità di mettere sul mercato le schede, lo avrebbe fatto, in qualunque modo, come qualunque altra azienda.
NVidia presenterà probabilmente in maniera ufficiale delle schede che saranno in vendita dopo diversi mesi, e nemmeno in versione definitiva (cioè in una revisione che equivale ad un prototipo): e per te questo sarebbe meglio? :asd:
Meglio per chi? :asd:
http://www.tweaktown.com/news/13631/nvidia_fermi_launch_delayed_to_march_2010/index.html?
:stordita:
Situazione tutt'altro che felice... in quanto nn solo Nvidia nn avrà il top su singola scheda ma avendo accumulato un ritardo di ben 5 mesi (ipotizzando per febbraio il lancio con disponibilità di fermi) si troverebbe pericolosamente vicina ad un'imminente revisione di Rv870 (che tutt'oggi ha 20 simd su 28 attivi)
Le schede non sono disponibili in grandi numeri (per i motivi detti e ridetti, e no per colpa di AMD), ma ci sono. Nei grandi centri si trovano pure in alcuni negozi fisici.
Ovvio che se uno le ordina sui negozi dove sono in ordinazione o non disponibili non le riceve a breve...
Detto ciò, se NVidia avesse avuto la possibilità di mettere sul mercato le schede, lo avrebbe fatto, in qualunque modo, come qualunque altra azienda.
NVidia presenterà probabilmente in maniera ufficiale delle schede che saranno in vendita dopo diversi mesi, e nemmeno in versione definitiva (cioè in una revisione che equivale ad un prototipo): e per te questo sarebbe meglio? :asd:
Meglio per chi? :asd:Bah, dico solo che se si cerca bene si trovano senza problemi.
Mi é arrivata oggi la 5850 dopo 2 giorni che l'ho ordinata ;)
Peccato che potró montarla solo il 22...
Detto questo spero che nVidia faccia meglio.
Simedan1985
03-12-2009, 13:56
Volevo dire una cosa sulla disponibiltà delle Ati :
E' vero che comunque volendo ci sono ,però è indubbio il fatto che nn ci sia un invasione.....e secondo me quei negozi che hanno disponibiltà i prezzi li alzano eccome .
kiriranshelo
03-12-2009, 14:06
...Sinceramente stavo vedendo Hemlock ,avevo anche chiamato un paio di store per l'effettiva disponibilità...pero poi sono andato sul thread ufficiale e ho un attimo cambiato idea causa lo stuttering piuttosto diffuso e la poca solidita della ventola che tocca le plastiche,e sinceramente spende 550 e rittrovarmi con dei problemi nn mi andava ....anche perche la mia 295 va liscia come l'olio.
Cosa intendi con stuttering? :confused:
tu hai un 295 io una 4870x2 cambiarle avrebbe poco senso ora se nn per giochi che sfruttino davvero le dx11!
lo stuttering di hemlock è uguale a quello che aveva la 4870x2 ocn i primi driver verrà risolto e nn tutte le 5970 hanno quel problema alle ventole quindi nn esageriamo con i difetti se ne trovano anche sulle nvidia!;)
ati cmq ha tutto il tempo di lasciar sviluppare soluzioni nn reference per nn parlare di probabili 5870 con 2 gb di memoria e della 5950!
stiamo a vedere se nvidia manterrà le promesse credo che posso sfidare o battere hemlock altrimenti prevedo un flop di quelli........che almeno sia competitiva in ambito mainstream!!
ci dovrebbero essere già le vga nvida per il mercato mainstream: la gt210 rinominata in gt310, la gt220 e la gt240 tutte a 40nm dx10.1 ;)
Simedan1985
03-12-2009, 14:14
tu hai un 295 io una 4870x2 cambiarle avrebbe poco senso ora se nn per giochi che sfruttino davvero le dx11!
lo stuttering di hemlock è uguale a quello che aveva la 4870x2 ocn i primi driver verrà risolto e nn tutte le 5970 hanno quel problema alle ventole quindi nn esageriamo con i difetti se ne trovano anche sulle nvidia!;)
ati cmq ha tutto il tempo di lasciar sviluppare soluzioni nn reference per nn parlare di probabili 5870 con 2 gb di memoria e della 5950!
stiamo a vedere se nvidia manterrà le promesse credo che posso sfidare o battere hemlock altrimenti prevedo un flop di quelli........che almeno sia competitiva in ambito mainstream!!
Ah lo so ne ho avute 3 di 4870x2 :asd: ...e ti quoto sul fatto di aspettare e vedere veramente le differenze tra un gioco dx11 e gli altri
Cosa intendi con stuttering? :confused:
http://www.frasi.net/dizionari/inglese-italiano/default.asp?vocabolo=stuttering
Ovviamente riferito al settore videogame
http://www.hwupgrade.it/forum/showpost.php?p=29916154&postcount=469
kiriranshelo
03-12-2009, 14:23
http://www.frasi.net/dizionari/inglese-italiano/default.asp?vocabolo=stuttering
Ovviamente riferito al settore videogame
http://www.hwupgrade.it/forum/showpost.php?p=29916154&postcount=469
si intende quando va a scatti? più o meno?
Simedan1985
03-12-2009, 14:26
si intende quando va a scatti? più o meno?
Si dovrebbero essere dei microscattini ...purtoppo con la 4870x2 ne ho avuti molti.
Kharonte85
03-12-2009, 14:27
Le schede non sono disponibili in grandi numeri (per i motivi detti e ridetti, e no per colpa di AMD), ma ci sono. Nei grandi centri si trovano pure in alcuni negozi fisici.
Ovvio che se uno le ordina sui negozi dove sono in ordinazione o non disponibili non le riceve a breve...
Detto ciò, se NVidia avesse avuto la possibilità di mettere sul mercato le schede, lo avrebbe fatto, in qualunque modo, come qualunque altra azienda.
NVidia presenterà probabilmente in maniera ufficiale delle schede che saranno in vendita dopo diversi mesi, e nemmeno in versione definitiva (cioè in una revisione che equivale ad un prototipo): e per te questo sarebbe meglio? :asd:
Meglio per chi? :asd:
Ho detto che fare un paper launch dichiarato (cioè con disponibilità effettiva rimandata di 1 mese e mezzo) è meglio che lanciare un prodotto che dopo pochi giorni si alza di prezzo e che comincia ad avere una disponibilita più rara che scarsa per i successivi mesi costringendo molti a ricerche spasmodiche, ad aspettare per mesi (cosa che fa sentirsi presi per il :ciapet: ) o a rinunciare alla scheda.
Forse AMD non poteva prevederlo ma personalmente son convinto che hanno sottostimato qualcosa e che non stiano capitalizzando il vantaggio temporale che avevano guadagnato.
kiriranshelo
03-12-2009, 14:28
Si dovrebbero essere dei microscattini ...purtoppo con la 4870x2 ne ho avuti molti.
Ottimo grazie ;)
Speriamo li risolvano con i driver
halduemilauno
03-12-2009, 14:53
Quoto okorop ,quando ipotizza un 20% rispetto a 5870 ,in effetti sarebbe un buon 120% su Gt 200b ...cmq nn sarebbe malvagio come "salto",ovviamente parlo di singola gpu.Quindi a mio avviso sarebbe impossibile prendere Hemlock.
Sulla x2 nvida ..penso che ci vorrà almeno un due mesi dopo.
Detto questo ovvio ,che l'ottimismo mi porti a pensare che questo silenzio serve per celare un mostro,che vada se nn + ma quasi come hemlock....e che sià subito disponibile in versione x2 .Ma meglio rimanere su considerazioni + obbiettive.
Sinceramente stavo vedendo Hemlock ,avevo anche chiamato un paio di store per l'effettiva disponibilità...pero poi sono andato sul thread ufficiale e ho un attimo cambiato idea causa lo stuttering piuttosto diffuso e la poca solidita della ventola che tocca le plastiche,e sinceramente spende 550 e rittrovarmi con dei problemi nn mi andava ....anche perche la mia 295 va liscia come l'olio.
come 120%???? è come se la 5870 vada il 100% ovvero il doppio della gtx285. nemmeno la 5970 va il doppio della gtx285 figuriamoci la 5870. basta andare un 50% in + della gtx285 e gia hai superato la 5870. cmq ha ragione Kharonte85 nel suo ritardo nvidia ha beccato amd in grandi ambasce.
Kharonte85
03-12-2009, 15:03
Direi che quelli che l'hanno comprata preferiscono senz'altro questa situazione a quella dover aspettare dei mesi.
Loro sì ovviamente (oltretutto a prezzi "giusti" fortunelli), gli altri non tanto (se non ci fosse stata questa penuria di schede probabilmente avrei preso una hd5850)
Ad ogni modo se non aver previsto una cosa mai vista nella storia della produzione di chip è aver sottostimato qualcosa allora hai ragione.
Io intendevo che di solito ci si assicurano margini di manovra anche in caso di guerra atomica (perlomeno me lo aspetterei da certe aziende) :sofico:
Credo anche io che abbiano sottostimato qualcosa. Qualcosa che a un'azienda X non meglio definita sarà costato tantissimo subito, e ad un'azienda Y non meglio definita costerà molto di più dopo.
Non capisco a chi ti riferisci...:confused:
Simedan1985
03-12-2009, 15:30
come 120%???? è come se la 5870 vada il 100% ovvero il doppio della gtx285. nemmeno la 5970 va il doppio della gtx285 figuriamoci la 5870. basta andare un 50% in + della gtx285 e gia hai superato la 5870. cmq ha ragione Kharonte85 nel suo ritardo nvidia ha beccato amd in grandi ambasce.
Si scusa ho raddoppiato le percentuali:D
marco XP2400+
03-12-2009, 16:07
per aziende di questo calibro, il magazzino deve essere gestito secondo la filosofia del Just in time; sarebbe inefficiente e scandalosa la gestione del vecchio tipo, poi sarebbe assurdo che un'azienda di tecnologia non utilizzasse modelli informatici e sistemi di comunicazione come previsto nel just in time (http://it.wikipedia.org/wiki/Just_in_time)
p.s. chi non utilizza questo modello è tagliato fuori dal circuito o improduttivo
halduemilauno
03-12-2009, 17:06
http://www.fudzilla.com/content/view/16685/1/
January for samples
In January, Nvidia should have the final samples and a limited number of Fermi Geforce GT300 chips, but the launch might take place later.
If pushed, Nvidia might launch Fermi Geforce in late January as the final chips should be there by then, but real volume shipments should start towards end of Q1 2010.
The most realistic availability date is March 2010, and again only if everything goes right. Judging by our previous information, Nvidia delayed its plans by more than one, if not two quarters.
This is rather unpleasant for Nvidia and the only thing that really keeps Nvidia sane is the fact that ATI also suffers from massive shortages of its 40nm RV870 based chips.
altra news...
http://www.fudzilla.com/content/view/16686/1/
TSMC 40nm is still immature
TSMC's 40nm process maturity can simply be described as disastrously bad. According to our sources, yields are currently at around 50 percent, which is catastrophic for a „mature“ and more than a year old process. One could say that TSMC is really immature about its 40 nm yields.
At this time, TSMC should be at 90 percent + yields, but this is simply not happening. The worst part is that nothing will change in early 2010. The shortage will last throughout Q1 2010 and both ATI’s RV870 and Nvidia’s Fermi will be heavily affected to their die size and complexity.
Things might start getting better in Q2 2010, but this means that you might have to wait all the way to April 2010 if not later to get more than a single 40nm card sitting on the store shelve for more than a day
Molto difficile, per non dire impossibile, che ci sia una x2 di Fermi a 40nm, a meno che non sia il raddoppio di due chip molto rimaneggiati, più di quanto non siano i due chip di Hemlock (frequenze più basse) rispetto a CypressXT o lo sia una GPU di GTX295 rispetto alla GTX275.
Direi che quelli che l'hanno comprata preferiscono senz'altro questa situazione a quella dover aspettare dei mesi.
Ad ogni modo se non aver previsto una cosa mai vista nella storia della produzione di chip è aver sottostimato qualcosa allora hai ragione.
Credo anche io che abbiano sottostimato qualcosa. Qualcosa che a un'azienda X non meglio definita sarà costato tantissimo subito, e ad un'azienda Y non meglio definita costerà molto di più dopo.
Quoto e aggiungo che per Nvidia, a meno di drastici cambiamenti nella resa produttiva di chip di certe dimensioni a 40nm, si ritroveranno in una situazione peggiore di quella che sta affrontando AMD. Del resto Fermi sembra essere almeno un 150mm^2 più grande di rv870
Kharonte85
03-12-2009, 17:30
Capirai dopo i 28nm :)
Addirittura :ops:
http://www.fudzilla.com/content/view/16685/1/
January for samples
In January, Nvidia should have the final samples and a limited number of Fermi Geforce GT300 chips, but the launch might take place later.
If pushed, Nvidia might launch Fermi Geforce in late January as the final chips should be there by then, but real volume shipments should start towards end of Q1 2010.
The most realistic availability date is March 2010, and again only if everything goes right. Judging by our previous information, Nvidia delayed its plans by more than one, if not two quarters.
This is rather unpleasant for Nvidia and the only thing that really keeps Nvidia sane is the fact that ATI also suffers from massive shortages of its 40nm RV870 based chips.
altra news...
http://www.fudzilla.com/content/view/16686/1/
TSMC 40nm is still immature
TSMC's 40nm process maturity can simply be described as disastrously bad. According to our sources, yields are currently at around 50 percent, which is catastrophic for a „mature“ and more than a year old process. One could say that TSMC is really immature about its 40 nm yields.
At this time, TSMC should be at 90 percent + yields, but this is simply not happening. The worst part is that nothing will change in early 2010. The shortage will last throughout Q1 2010 and both ATI’s RV870 and Nvidia’s Fermi will be heavily affected to their die size and complexity.
Things might start getting better in Q2 2010, but this means that you might have to wait all the way to April 2010 if not later to get more than a single 40nm card sitting on the store shelve for more than a day
Tutto molto bello :doh: speriamo si ripiglino alla TSMC senno' è un disastro per tutti...
halduemilauno
03-12-2009, 17:38
Addirittura :ops:
Tutto molto bello :doh: speriamo si ripiglino alla TSMC senno' è un disastro per tutti...
che il pp a 40nm era molto immaturo gia lo si sapeva ma che maturasse cosi tardi no.
vedremo.
;)
Kharonte85
03-12-2009, 18:14
che il pp a 40nm era molto immaturo gia lo si sapeva ma che maturasse cosi tardi no.
vedremo.
;)
Pazzesco...spero che non siano i segnali dell'inizio della fine (intesa come abbiamo finito di fare il trucco di diminuire il pp per stare più piccoli e consumare meno) ma che siano problemi dovuti all'incapacità tecnica-produttiva della sola TSMC.
per aziende di questo calibro, il magazzino deve essere gestito secondo la filosofia del Just in time; sarebbe inefficiente e scandalosa la gestione del vecchio tipo, poi sarebbe assurdo che un'azienda di tecnologia non utilizzasse modelli informatici e sistemi di comunicazione come previsto nel just in time (http://it.wikipedia.org/wiki/Just_in_time)
p.s. chi non utilizza questo modello è tagliato fuori dal circuito o improduttivo
ma guarda nvida gestisce benissimo il magazzino
3-2-1 miracolo stessa vga 2 nomi diversi per essere commercializzata
http://img689.imageshack.us/img689/8996/oldnewnvidia.gif
Andrea deluxe
03-12-2009, 18:55
oggi, mentre pulivo un macchinario del mio frantoio pensavo......
con sta storia dei rebrand, chi ha una vecchia 8800gtx e 8800gt, si ritrova oggi con un supporto driver eccezionale.....
rovescio della medaglia di avere prodotti tutti uguali.....
Per chi l'ha comprata per primo si... il problema è per quello che la compra per ultimo :D
Andrea deluxe
03-12-2009, 19:04
Per chi l'ha comprata per primo si... il problema è per quello che la compra per ultimo :D
be, certo.....:)
Kharonte85
03-12-2009, 19:05
ma guarda nvida gestisce benissimo il magazzino
3-2-1 miracolo stessa vga 2 nomi diversi per essere commercializzata
Cut
:asd:
Comunque la geforce 310 è solo per gli OEM (per ora).
oggi, mentre pulivo un macchinario del mio frantoio pensavo......
con sta storia dei rebrand, chi ha una vecchia 8800gtx e 8800gt, si ritrova oggi con un supporto driver eccezionale.....
rovescio della medaglia di avere prodotti tutti uguali.....
:D
unnilennium
03-12-2009, 19:09
oggi, mentre pulivo un macchinario del mio frantoio pensavo......
con sta storia dei rebrand, chi ha una vecchia 8800gtx e 8800gt, si ritrova oggi con un supporto driver eccezionale.....
rovescio della medaglia di avere prodotti tutti uguali.....
avevano lo stesso supporto le mitiche tnt2, ma ati allora faceva pena, :Prrr:
adesso stanno spremendo lo spremibile, però all'orizzonte sembra di vedere fuffa... sarà sicuramente di colore verde, ma mica si capisce cosa sarà....
Simedan1985
03-12-2009, 19:23
Cmq visto che ormai abbiamo + di qualche indizio,potremmo dire che le nuove nvidia le vedremo quasi sicuramente a Marzo??:stordita: ..ovviamente con disponibilità ad aprile:(
davide155
03-12-2009, 20:00
Cmq visto che ormai abbiamo + di qualche indizio,potremmo dire che le nuove nvidia le vedremo quasi sicuramente a Marzo??:stordita: ..ovviamente con disponibilità ad aprile:(
A marzo??? :eek: :eek: :eek: :eek:
Ma manca ancora 4 mesi!! :mbe:
Due sono le cose...........o voi sparate a vanvera, oppure alla nvidia hanno voluto fare il passo più lungo della gamba :O
Bastoner
03-12-2009, 20:07
A marzo??? :eek: :eek: :eek: :eek:
Ma manca ancora 4 mesi!! :mbe:
Due sono le cose...........o voi sparate a vanvera, oppure alla nvidia hanno voluto fare il passo più lungo della gamba :O
Purtroppo è così, non vedremo VGA funzionanti prima di marzo, nella migliore delle ipotesi.
A marzo??? :eek: :eek: :eek: :eek:
Ma manca ancora 4 mesi!! :mbe:
Due sono le cose...........o voi sparate a vanvera, oppure alla nvidia hanno voluto fare il passo più lungo della gamba :ONo no, non sono sparate a vanvera...
Si vocifera da un po' che sia necessario uno step A3, quindi tra nuovo step, verificazione della sua bontá, produzione in massa del chip, invio degli stessi e packaging della scheda, Marzo é la migliore delle ipotesi...
Purtroppo è così, non vedremo VGA funzionanti prima di marzo, nella migliore delle ipotesi.
Sperando sia per i nostri portafogli che soprattutto per Nvidia che con l'introduzione dello step A3 nn si introducano anche nuove problematiche che richiedano un ipotetico A4. La faccenda ricorda molto, per chi la seguì, l'evoluzione dei primi K10, che richiedettero prima della commercializzazione ben sei step ed un altro per risolvere i numerosissimi bug (A0, A1, B0, B1, BA, B2 che fu cmq una mezza tragedia, infatti venne commercializzato solo per marketing, ed alla fine B3). Nvidia si trova già almeno a 3 e lavorare con circa tre miliardi di transistor sicuramente ha grossissimi svantaggi :(
Andrea deluxe
03-12-2009, 20:30
Sperando sia per i nostri portafogli che soprattutto per Nvidia che con l'introduzione dello step A3 nn si introducano anche nuove problematiche che richiedano un ipotetico A4. La faccenda ricorda molto, per chi la seguì, l'evoluzione dei primi K10, che richiedettero prima della commercializzazione ben sei step ed un altro per risolvere i numerosissimi bug (A0, A1, B0, B1, BA, B2 che fu cmq una mezza tragedia, infatti venne commercializzato solo per marketing, ed alla fine B3). Nvidia si trova già almeno a 3 e lavorare con circa tre miliardi di transistor sicuramente ha grossissimi svantaggi :(
minchia e' vero.....
davide155
03-12-2009, 20:51
Nvidia è fortunata solo di una cosa.
Che ormai quasi tutti i clienti del settore mid-high end hanno una vga discreta in modo che non soffra troppo le applicazioni odierne.
Perchè veniamo da 1 anno abbondante di stallo......sia di potenza richiesta dai videogiochi che di potenza data dalle vga. Siamo alla frutta come si suol dire.
Tutti aspettano le nuove tecnologie (DX11-Shader5.0, nuovi motori grafici ecc), quindi nessuno ha furia di cambiare vga.
Questo vuol dire che nvidia non perderà tanti clienti, anche perchè la controparte ATi con la sua 5870 non ha sbaragliato come ci aspettavamo.
Io credo di essere la prova vivente di questa teoria. Mi fa molto gola la 5870, ma siccome non c'è punte applicazioni (o quasi) che la sfrutterebbero, mi conviene aspettare l'uscita di Fermi per decidere a quel punto su quale buttarmi, godendomi ancora un pò la gloriosa 8800gt.
E non credo di essere il solo a pensarla così ;)
GOWMarcus
03-12-2009, 21:05
a marzo ?
ma stiamo scherzando ?
Bastoner
03-12-2009, 21:07
Nvidia è fortunata solo di una cosa.
Che ormai quasi tutti i clienti del settore mid-high end hanno una vga discreta in modo che non soffra troppo le applicazioni odierne.
Perchè veniamo da 1 anno abbondante di stallo......sia di potenza richiesta dai videogiochi che di potenza data dalle vga. Siamo alla frutta come si suol dire.
Tutti aspettano le nuove tecnologie (DX11-Shader5.0, nuovi motori grafici ecc), quindi nessuno ha furia di cambiare vga.
Questo vuol dire che nvidia non perderà tanti clienti, anche perchè la controparte ATi con la sua 5870 non ha sbaragliato come ci aspettavamo.
Io credo di essere la prova vivente di questa teoria. Mi fa molto gola la 5870, ma siccome non c'è punte applicazioni (o quasi) che la sfrutterebbero, mi conviene aspettare l'uscita di Fermi per decidere a quel punto su quale buttarmi, godendomi ancora un pò la gloriosa 8800gt.
E non credo di essere il solo a pensarla così ;)
Guarda, la 5870 non ti conviene perchè giochi con un 19", non per gli argomenti che hai esposto nel tuo ragionamento.
Bastoner
03-12-2009, 21:08
a marzo ?
ma stiamo scherzando ?
No :O
Drakogian
03-12-2009, 21:09
a marzo ?
ma stiamo scherzando ?
Se persino fudzilla dice fine Q1 2010... allora potrebbe anche essere dopo Marzo. ;)
davide155
03-12-2009, 21:19
Guarda, la 5870 non ti conviene perchè giochi con un 19", non per gli argomenti che hai esposto nel tuo ragionamento.
Sono un amante della grafica, quindi prediligo maggiormente un altissimo dettaglio, con AA e anisotropico a palla sacrificando così le dimensioni del monitor.
Crysis piega pure la 5870 con i filtri attivi a 1440x900.......quinidi non sarebbe sprecata per le mie esigenze ;)
Bastoner
03-12-2009, 21:23
Sono un amante della grafica, quindi prediligo maggiormente un altissimo dettaglio, con AA e anisotropico a palla sacrificando così le dimensioni del monitor.
Crysis piega pure la 5870 con i filtri attivi a 1440x900.......quinidi non sarebbe sprecata per le mie esigenze ;)
Crysis non scala sulle ATi, privilegia l'architettura Nvidia quindi hai preso l'esempio sbagliato. Nel mio caso (SLI gtx280) ci gioco a 50 frames con AA4x 1680x1050. Perdo 5-10 frames se gioco con il 24" in full hd.
Con un 19" prendere una 5870 sarebbe come andare sullo sterrato con una Ferrari. Se non lo capisci allora pace...
GOWMarcus
03-12-2009, 21:26
tutti palranod i 5870 sul Full hd ecc, ma prova a mettere crysis in DX10 very high o enthusiast setting e giocaci con i filtri, ti dico già che a 1280 x 1024 con AA4x non rulla benissimo sulla 5870.
Bastoner
03-12-2009, 21:28
tutti palranod i 5870 sul Full hd ecc, ma prova a mettere crysis in DX10 very high o enthusiast setting e giocaci con i filtri, ti dico già che a 1280 x 1024 con AA4x non rulla un corno con la 5870 !
Infatti il problema è Crysis, non la 5870.
davide155
03-12-2009, 21:29
Crysis ha un engine scritto da un gregge.
Tu compreresti oggi una VGA pensando a Crysis? :mbe:
Io non comprerei........io comprai la 8800gt pensando a Crysis, ovviamente soldi permettendo.
I giochi multipiattaforma in versione pc fanno sempre più schifo, quindi me li prendo su console, mentre quei pochissimi e rari esclusivi per PC li voglio godere al massimo.
Crysis è uno di questi e non mi va più di leggere il solito luogo comune che crysis è stato scritto a cane, perchè non è così.
I miracoli li faceva una persona sola. Per dire che la grafica in termini di qualità si paga sempre, è sempre stato e sarà sempre così.
GOWMarcus
03-12-2009, 21:31
Infatti il problema è Crysis, non la 5870.
se fosse così come mai man mano che si evolvono le VGA si gioca sempre meglio.
una 5970 probabilmente a 1280 x 1024 riusciremo a giocarlo benissimo anche con AA4x e AF al massimo.
il problema è che non abbiamo abbastanza potenza su singola GPU da far girare crysis al top delle impostazioni.
davide155
03-12-2009, 21:32
Crysis non scala sulle ATi, privilegia l'architettura Nvidia quindi hai preso l'esempio sbagliato. Nel mio caso (SLI gtx280) ci gioco a 50 frames con AA4x 1680x1050. Perdo 5-10 frames se gioco con il 24" in full hd.
Con un 19" prendere una 5870 sarebbe come andare sullo sterrato con una Ferrari. Se non lo capisci allora pace...
Non è un problema mio ma loro. Se la ferrari non ci va sullo sterrato ed io voglio andare sullo sterrato mi prendo un Range Rover. Non vedo dove sia il problema.
Cmq hai messo a confronto due vga contro una. Le quali anche essendo tecnologia vecchia la gtx280 costa quanto la 5870.
Facciamo dei paragoni più razionali.........
Bastoner
03-12-2009, 21:34
Si ok hai ragione, una 5870 per giocare a 1280x1024 sarebbe una buona scelta :sbonk:
davide155
03-12-2009, 21:37
Si ok hai ragione, una 5870 per giocare a 1280x1024 sarebbe una buona scelta :sbonk:
Forse non hai capito :mbe:
Sto dicendo l'esatto contrario..........la 5870 non mi gusta perchè non da il massimo che mi aspettavo e perchè non viene sfruttata bene con i pochi giochi esclusivi per pc, Crysis in primis.
Quindi aspetto Fermi.
L'avevo spiegato anche nel mio primo post dell'altra pagina :)
Ps: La risoluzione ormai fa sempre meno peso..........sono i filtri a dettare legge.
Bastoner
03-12-2009, 21:43
Forse non hai capito :mbe:
Sto dicendo l'esatto contrario..........la 5870 non mi gusta perchè non da il massimo che mi aspettavo e perchè non viene sfruttata bene con i pochi giochi esclusivi per pc, Crysis in primis.
Quindi aspetto Fermi.
L'avevo spiegato anche nel mio primo post dell'altra pagina :)
E' evidente che non ci capiamo. Tu hai scritto tutta una serie di motivi per i quali avevi deciso di non prendere la 5870, nonostante ti facesse gola, e di aspettare Fermi. Io ho detto: c'è un solo motivo per il quale non devi prendere la 5870, perchè giochi a 1280x1024.
Poi tu hai messo in mezzo sto discordo di Crysis che non c'entra nulla. In ogni caso un 5870 per giocare con un 19 è la stuoidaggine del secolo, e questo è quello che ho affermato io, cioè l'esatto contrario di quello che hai scritto tu. E meno male che scripta manent.
Per quanto riguarda la tua ultima affermazione:
la 5870 non mi gusta perchè non da il massimo che mi aspettavo e perchè non viene sfruttata bene con i pochi giochi esclusivi per pc, Crysis in primis.
Ma LOL!!! Ehm vediamo...le esclusive per PC nell'ultimo periodo sono state: Crysys: gira di merda su tutte le schede in particolar modo sulle ATI
Arma II: gira di merda e basta
Non mi vengono altre esclusive....direi che non bastano a reggere il tuo ragionamento.
Cioè ma ti rendi conto di quello che scrivi?
davide155
03-12-2009, 21:49
Eppure mi sembra così semplice da capire........voglio una vga single chip (non voglio spendere 500€ per una scheda video) che riesca a spingere crysis al massimo. Nessuna per ora ci riesce, nemmeno su un 19", come sostieni.
Se per te 30fps di media con i filtri attivi vuol dire giocare bene, allora si......la 5870 ci riesce in pieno.
Ma per me non bastano, quindi aspetto Fermi. Non ho furia.
Che c'è che non ti torna?? :mbe:
supersalam
03-12-2009, 21:52
Eppure mi sembra così semplice da capire........voglio una vga single chip (non voglio spendere 500€ per una scheda video) che riesca a spingere crysis al massimo. Nessuna per ora ci riesce, nemmeno su un 19", come sostieni.
Se per te 30fps di media con i filtri attivi vuol dire giocare bene, allora si......la 5870 ci riesce in pieno.
Ma per me non bastano, quindi aspetto Fermi. Non ho furia.
Che c'è che non ti torna?? :mbe:
Davide anch'io la penso come te. E infatti abbiamo la stessa vga. ;)
Bastoner
03-12-2009, 21:54
Eppure mi sembra così semplice da capire........voglio una vga single chip (non voglio spendere 500€ per una scheda video) che riesca a spingere crysis al massimo. Nessuna per ora ci riesce, nemmeno su un 19", come sostieni.
Se per te 30fps di media con i filtri attivi vuol dire giocare bene, allora si......la 5870 ci riesce in pieno.
Ma per me non bastano, quindi aspetto Fermi. Non ho furia.
Che c'è che non ti torna?? :mbe:
Ah bhè se decidi di scegliere una vga solo un funzione di Crysis....
Buona fortuna :)
Severnaya
03-12-2009, 21:55
Eppure mi sembra così semplice da capire........voglio una vga single chip (non voglio spendere 500€ per una scheda video) che riesca a spingere crysis al massimo. Nessuna per ora ci riesce, nemmeno su un 19", come sostieni.
Se per te 30fps di media con i filtri attivi vuol dire giocare bene, allora si......la 5870 ci riesce in pieno.
Ma per me non bastano, quindi aspetto Fermi. Non ho furia.
Che c'è che non ti torna?? :mbe:
in cosa ti faceva gola la 5870 allora?
davide155
03-12-2009, 21:59
Davide anch'io la penso come te. E infatti abbiamo la stessa vga. ;)
Aggiungerei GLORIOSA prima della parola "vga" :O
Ah bhè se decidi di scegliere una vga solo un funzione di Crysis....
Buona fortuna :)
Vedo che alla fine hai capito cosa volevo :)
Scelgo in base a quello perchè è l'unico gioco degno di nota in esclusiva PC secondo me.
Potrei rigirare la domanda a te chiedendoti, chi te lo ha fatto fare di prendere due gtx280 visto che TU stesso hai delineato solo due esclusive pc che reputi oltretutto una merda in grado di mettere in ginocchio le più potenti vga (e le tue sono 2 delle più potenti vga al mondo).
Ma non mi interessa ;)
davide155
03-12-2009, 22:01
in cosa ti faceva gola la 5870 allora?
Dx11 e shader 5.0......aspettavo i primi giochi in dx11 per decidere, ma dopo aver visto dirt2 in dx11 ho deciso che non c'è furia e che posso benissimo aspettare Fermi, visto che le prox uscite in dx11 sono per la primavera 2010.
Bastoner
03-12-2009, 22:03
Aggiungerei GLORIOSA prima della parola "vga" :O
Vedo che alla fine hai capito cosa volevo :)
Scelgo in base a quello perchè è l'unico gioco degno di nota in esclusiva PC secondo me.
Potrei rigirare la domanda a te chiedendoti, chi te lo ha fatto fare di prendere due gtx280 visto che TU stesso hai delineato solo due esclusive pc in grado di mettere in ginocchio le più potenti vga (e le tue sono 2 delle più potenti vga al mondo), che reputi oltretutto una merda.
Ma non mi interessa ;)
io le reputo una merda???? :mbe: Ma che dici?
Le ho prese per giocare in fullhd con aa16x in tutti i giochi (tranne uno :asd:, a cui gioco a 4x e fa 40-50 frames).
Hai le idee un po' confuse :)
Severnaya
03-12-2009, 22:07
occhio, adesso spunterà qualcuno a dire che gli effetti DX11 di Dirt rivoluzionano completamente il modo di giocare.. al contrario di quelle cagate di mirrors edge e batman... :asd:
penso che gli effetti directx 11 cambieranno il modo di giocare come ci fu il passaggio dalle 8 alle 9, alle 9 alle 10... :mbe:
quoto che gli effetti di mirror's edge e batman delle cagate :asd:
Bastoner
03-12-2009, 22:07
occhio, adesso spunterà qualcuno a dire che gli effetti DX11 di Dirt rivoluzionano completamente il modo di giocare.. al contrario di quelle cagate di mirrors edge e batman... :asd:
Che grande gioco, lo amo :smack:
davide155
03-12-2009, 22:08
Le ho prese per giocare in fullhd con aa16x in tutti i giochi (tranne uno :asd:, a cui gioco a 4x e fa 40-50 frames).
Hai le idee un po' confuse :)
Non vedo il bisogno dell'aa16x, e quindi nemmeno delle due gtx280, ma è la prova che ognuno dei propri soldi fa quel che vuole, proprio come dicevo per il mio caso prima ;)
io le reputo una merda???? :mbe: Ma che dici?
Mi sono confuso......reputi che gira di merda.......pardon.
occhio, adesso spunterà qualcuno a dire che gli effetti DX11 di Dirt rivoluzionano completamente il modo di giocare.. al contrario di quelle cagate di mirrors edge e batman... :asd:
Si ci manca solo questa :asd:
Si parla tanto di crysis, ma dai test si evince che la 5870 va praticamente come una gtx295.
Cosa si deve pretendere di piú?
Se questo "gioco" non é giocabile con la nuova ATi, dubito che lo sará con le nuove nVidia...
Simedan1985
03-12-2009, 22:49
Si parla tanto di crysis, ma dai test si evince che la 5870 va praticamente come una gtx295.
Cosa si deve pretendere di piú?
Se questo "gioco" non é giocabile con la nuova ATi, dubito che lo sará con le nuove nVidia...
E questo anche è vero(infatti confido in una x2,avendo un 26")....Sul fatto di crysis ,bè che dire ...io faccio parte di quelli che vogliono giocarci a manetta,...sicuramente il motore grafico è esossissimo di risorse,pero a mio avviso sia ati che nvidia dovrebbero ringraziare la crytek se vendono tutte quelle schede top top :asd:,inoltre la grafica di crysis a me lascia senza fiato...... ...Adesso sfido chiunque abbia comprato una nuova scheda top ,a dire che nn ha provato a vedere come ci gira crysis!!:ciapet:
Edit: Ottimo Ratatosk nn è un gioco ma un benchmark ,però di affascinante bellezza (almeno x me)
Edit2 :asd: :Confido molto nella grafica di Bad company 2....sopratutto per l'interazione con il paesaggio e oggetti e poi gli sviluppatori sembra che c'è la stiano mettendo tutta per fare un cavolavoro graficamente parlando e nn solo
GOWMarcus
03-12-2009, 23:04
battlefield BC2 ha come requisito raccomandato un quad e una GTX 260, quindi penso che chi avrà una GTX 260, simile o derivato giocherà al limite del giocabile quindi penso dovremmo cambiare VGA per farlo girare.
battlefield BC2 ha come requisito raccomandato un quad e una GTX 260, quindi penso che chi avrà una GTX 260, simile o derivato giocherà al limite del giocabile quindi penso dovremmo cambiare VGA per farlo girare.
anche perchè sarà in dx11 :asd:
suneatshours86
04-12-2009, 02:27
c'è chi compra una gtx285 solo perchè su crysis (un gioco del 2007 che oltre all'impatto visivo personalmente non mi ha regalato così tante emozioni) fa 4 fps in più di una 5850.
Aggiungiamo qualche considerazione:
* fare 40fps su crysis non significa scattare, sono passati 2 anni e penso che ormai l'abbiate capito
* crysis in 2 anni di ottimizzazzioni driver e di cryEngine è se non lo stesso poco ci manca
* a conferamare le mie precedenti considerazioni il nuovo cryengine3 non guadagnerà particolari impatti visivi ma si limiterà ad una ottimizzazzione generale per farlo snellire sulle configurazioni meno potenti e per farlo approdare su xbox e playstation
* aspettare 6 mesi, fino a gennaio, per vedere cosa farà una vga Fermi su un videogioco che avrà a quel punto 3 anni mi pare veramente un ragionamento infantile
non cerchiamo scusanti però: non si può affermare di non voler passare ad una 5870 perchè ci si aspettava di più. Parliamo di almeno 5/6 mesi dall'uscita della serie 5xxx, non di 2 per aspettare Fermi, un qualcusa di cui non sappiamo date ufficiali, caratteristiche e ombra di test (se non una scatola nera bella da vedere). ORA come ORA possiamo non scegliere una 5xxx al posto di GTX285/275/295, ma con la consapevolezza che avremo meno tecnlogie a disposizione e consumi elevati che richiedono alimentatori più performati, più che progresso e acquisto azzeccato parliamo nel caso di regresso e fregatura. Fermatemi se il ragionamento è sbagliato
davide155
04-12-2009, 05:57
c'è chi compra una gtx285 solo perchè su crysis (un gioco del 2007 che oltre all'impatto visivo personalmente non mi ha regalato così tante emozioni) fa 4 fps in più di una 5850.
Aggiungiamo qualche considerazione:
* fare 40fps su crysis non significa scattare, sono passati 2 anni e penso che ormai l'abbiate capito
* crysis in 2 anni di ottimizzazzioni driver e di cryEngine è se non lo stesso poco ci manca
* a conferamare le mie precedenti considerazioni il nuovo cryengine3 non guadagnerà particolari impatti visivi ma si limiterà ad una ottimizzazzione generale per farlo snellire sulle configurazioni meno potenti e per farlo approdare su xbox e playstation
* aspettare 6 mesi, fino a gennaio, per vedere cosa farà una vga Fermi su un videogioco che avrà a quel punto 3 anni mi pare veramente un ragionamento infantile
non cerchiamo scusanti però: non si può affermare di non voler passare ad una 5870 perchè ci si aspettava di più. Parliamo di almeno 5/6 mesi dall'uscita della serie 5xxx, non di 2 per aspettare Fermi, un qualcusa di cui non sappiamo date ufficiali, caratteristiche e ombra di test (se non una scatola nera bella da vedere). ORA come ORA possiamo non scegliere una 5xxx al posto di GTX285/275/295, ma con la consapevolezza che avremo meno tecnlogie a disposizione e consumi elevati che richiedono alimentatori più performati, più che progresso e acquisto azzeccato parliamo nel caso di regresso e fregatura. Fermatemi se il ragionamento è sbagliato
Sono tue opinioni personale e le accetto ma non le condivido del tutto.
Cmq le caratteristiche di Fermi si conoscono fin troppo bene.
L'articolo di HWU spiega com'è strutturato Fermi in maniera molto chiara:
http://www.hwupgrade.it/articoli/skvideo/2293/nvidia-fermi-la-nuova-architettura-scopre-le-carte_3.html
http://www.tomshw.it/cont/news/nvidia-fermi-a-gennaio-ma-non-per-voi/23088/1.html
;)
http://www.tomshw.it/cont/news/nvidia-fermi-a-gennaio-ma-non-per-voi/23088/1.html
;)
sarebbe bello mettere la manine sopra i primi sample :D :D
Simedan1985
04-12-2009, 09:27
http://www.tomshw.it/cont/news/nvidia-fermi-a-gennaio-ma-non-per-voi/23088/1.html
;)
Ragazzi quà facciamo prima a comprare larrabbe:fagiano:
Severnaya
04-12-2009, 09:34
Sono tue opinioni personale e le accetto ma non le condivido del tutto.
Cmq le caratteristiche di Fermi si conoscono fin troppo bene.
L'articolo di HWU spiega com'è strutturato Fermi in maniera molto chiara:
http://www.hwupgrade.it/articoli/skvideo/2293/nvidia-fermi-la-nuova-architettura-scopre-le-carte_3.html
sono oggettive nn sono personali
Ragazzi quà facciamo prima a comprare larrabbe:fagiano:
quando nei primi mesi dell'anno inizieranno ad uscire i vari titoli nuovi che più o meno tutti aspettiamo, se non c'è fuori niente mi sa che in molti (me compreso) si rivolgeranno ad Ati (sempre che per allora abbiano risolto i problemi di assortimento :p )
al momento l'unica cosa sicura è ci sarà un natale molto rosso.... @_@
venderanno tutto quello che producono, nenache passano per il magazzino....
a marzo in teoria si presenta la top gamma single gpu, per le fasce inferiori ci sarà ULTERIORE attesa.
halduemilauno
04-12-2009, 10:21
al momento l'unica cosa sicura è ci sarà un natale molto rosso.... @_@
venderanno tutto quello che producono, nenache passano per il magazzino....
a marzo in teoria si presenta la top gamma single gpu, per le fasce inferiori ci sarà ULTERIORE attesa.
mi dispiace(per modo di dire ovviamente)ma non saranno quelle poche serie 5 a far si che il natale sia molto rosso visto che nvidia detiene il 63% del mercato mondiale delle schede video desktop. e pensa amd neanche possiede il restante 37 ma il 34%. per spostare di un solo punto % avoja te quante schede ne deve vendere in +.
mi dispiace(per modo di dire ovviamente)ma non saranno quelle poche serie 5 a far si che il natale sia molto rosso visto che nvidia detiene il 63% del mercato mondiale delle schede video desktop. e pensa amd neanche possiede il restante 37 ma il 34%. per spostare di un solo punto % avoja te quante schede ne deve vendere in +.
...fonte?...
...ciao Andrea...
halduemilauno
04-12-2009, 10:33
...fonte?...
...ciao Andrea...
fonte de che???? lo sanno tutti che la situazione mondiale è quella basta ti vai a riprendere i dati dell'ultimo trimestre.
la fonte.
:D
mi dispiace(per modo di dire ovviamente)ma non saranno quelle poche serie 5 a far si che il natale sia molto rosso visto che nvidia detiene il 63% del mercato mondiale delle schede video desktop. e pensa amd neanche possiede il restante 37 ma il 34%. per spostare di un solo punto % avoja te quante schede ne deve vendere in +.
...fonte?...
...ciao Andrea...
Probabilmente è sul libro paga Nvidia ed avrà le sue fonti... :confused: :confused:
unnilennium
04-12-2009, 10:35
mi dispiace(per modo di dire ovviamente)ma non saranno quelle poche serie 5 a far si che il natale sia molto rosso visto che nvidia detiene il 63% del mercato mondiale delle schede video desktop. e pensa amd neanche possiede il restante 37 ma il 34%. per spostare di un solo punto % avoja te quante schede ne deve vendere in +.
sempre grato dei commenti di un fan sfegatato di nvidia, ma penso che stavolta un pò di preoccupazione ce l'hai anche tu.. e chipset nuovi niente,a meno di non considerare ion un nuovo prodotto, e gpu nuove nulla, ma sempre figli bastardi di g80, rimarchiati a profusione.. adesso hanno rimarchiato pure sui portatili le g92 in gtx, e stiamo tutti a sospirare per le nuove top di gamma per marzo o aprile... nel frattempo mi è morta la 8600gt, senza alcun motivo,se non forse quello arcinoto di chi tanto s'era parlato,su notebook e desktop.. secondo te cosa mi prendo, una nvidia o una ati? ad aspettare a marzo divento vecchio :)
halduemilauno
04-12-2009, 10:36
quando nei primi mesi dell'anno inizieranno ad uscire i vari titoli nuovi che più o meno tutti aspettiamo, se non c'è fuori niente mi sa che in molti (me compreso) si rivolgeranno ad Ati (sempre che per allora abbiano risolto i problemi di assortimento :p )
cmq credo che per moltissimi gia sapere le prestazioni delle nuove schede basate su gf100 sia + che sufficiente per valutare l'eventuale attesa. e pare certo che tutto questo dovrebbe avvenire il prossimo 7 gennaio.
;)
cmq credo che per moltissimi gia sapere le prestazioni delle nuove schede basate su gf100 sia + che sufficiente per valutare l'eventuale attesa. e pare certo che tutto questo dovrebbe avvenire il prossimo 7 gennaio.
;)
mmm 7 Gennaio? troppo presto secondo me.
Foglia Morta
04-12-2009, 10:46
al momento l'unica cosa sicura è ci sarà un natale molto rosso.... @_@
venderanno tutto quello che producono, nenache passano per il magazzino....
a marzo in teoria si presenta la top gamma single gpu, per le fasce inferiori ci sarà ULTERIORE attesa.
Ma infatti se ci mettono 4-5 mesi per presentare tutte le gpu della serie G300 IMO si può dire che la prossima generazione di schede nVidia sia più vicina al rilascio della serie HD6000 che non alla HD5000
unnilennium
04-12-2009, 10:47
cmq credo che per moltissimi gia sapere le prestazioni delle nuove schede basate su gf100 sia + che sufficiente per valutare l'eventuale attesa. e pare certo che tutto questo dovrebbe avvenire il prossimo 7 gennaio.
;)
dubito anch'io così presto, magari ci scappa qualche review, ma su esemplari di pre-produzione, o smple engineering, certo non su pprodotti finiti.. fintanto che non escono sugli scaffali, non è che ci si può fidare di fudzilla o dei siti cinesi che pubblicano immagini e reviews prima di chiunque....
unnilennium
04-12-2009, 10:50
Ma infatti se ci mettono 4-5 mesi per presentare tutte le gpu della serie G300 IMO si può dire che la prossima generazione di schede nVidia sia più vicina al rilascio della serie HD6000 che non alla HD5000
http://www.hwupgrade.it/news/skvideo/rese-ancora-inferiori-alla-media-per-i-40nm-di-tsmc_30971.html
chissà quando sarà... se se le fanno fare tutti da tsmc con questi problemi non se ne vede la fine davvero... nè ati nè nvidia, tocca tenersi le schede attuali x forza :)
fonte de che???? lo sanno tutti che la situazione mondiale è quella basta ti vai a riprendere i dati dell'ultimo trimestre.
la fonte.
:D
...parli di questi?...
http://www.dvhardware.net/news/jon_peddie_gpu_market_q3_2009.jpg
...fonte (http://www.dvhardware.net/article38784.html)...e news (http://www.benzinga.com/markets/analyst-research/analyst-color/45247/nvda-may-continue-to-lose-market-share-in-graphics-card) dal mondo finanziario...
...ciao Andrea...
Foglia Morta
04-12-2009, 10:59
http://www.hwupgrade.it/news/skvideo/rese-ancora-inferiori-alla-media-per-i-40nm-di-tsmc_30971.html
chissà quando sarà... se se le fanno fare tutti da tsmc con questi problemi non se ne vede la fine davvero... nè ati nè nvidia, tocca tenersi le schede attuali x forza :)
Quella news ( tra l'altro fudzillata ) però non c'entra nulla con quanto ho detto :D
halduemilauno
04-12-2009, 11:04
sempre grato dei commenti di un fan sfegatato di nvidia, ma penso che stavolta un pò di preoccupazione ce l'hai anche tu.. e chipset nuovi niente,a meno di non considerare ion un nuovo prodotto, e gpu nuove nulla, ma sempre figli bastardi di g80, rimarchiati a profusione.. adesso hanno rimarchiato pure sui portatili le g92 in gtx, e stiamo tutti a sospirare per le nuove top di gamma per marzo o aprile... nel frattempo mi è morta la 8600gt, senza alcun motivo,se non forse quello arcinoto di chi tanto s'era parlato,su notebook e desktop.. secondo te cosa mi prendo, una nvidia o una ati? ad aspettare a marzo divento vecchio :)
fan sfegatato di nvidia non credo proprio ma per carità mi sono stufato di star li a replicare a simili sciocchezze. la preoccupazione credo che l'abbiano altri(e cmq io ne ho per cose molto + serie e importanti) io ho una sana passione per il mondo pc e ben + di quella ho sanissima passione per l'onestà intellettuale e la buonafede. ma lasciamo stare anche queste cose stufatissimo di stare qui a spiegarle che tanto non serve a nulla tanto + quando esposte a persone che appalesano la loro malafede.
in quanto al resto io ho sempre detto che finche si è in possesso di un prodotto valido che risulta concorrenziale si fa bene a spremerlo fino in fondo perchè star li a sviluppare nuovi prodotti (che costa farlo) quando quello che gia si possiede è valido. ripeto è la mia opinione. non confondere le due strategie commerciali ati, nvidia la prima con le serie 3 e 4 ha dovuto rincorrere per porre rimedio al fallimento della serie 2 e non ha neanche ottenuto grandi risultati. ora con la serie 5 è in vantaggio? certo è sotto gli occhi di tutti. poi si può discutere sulla portata di tale vantaggio ma come detto è un vantaggio sotto gli occhi di tutti.
non vuoi aspettare, a marzo diventi vecchio? ma per fortuna ci sono le ati cosa aspetti?
ps i chipset? tra il colosso intel e il 10% che vale amd per me fa bene a chiudere la divisione chipset. ripeto per me.
The Quaker
04-12-2009, 11:04
A Marzo ? Si e magari sarà pure un paper lanch.
Grazie Nvidia !
Ma perchè entrambe le case non fanno causa a questa TSMC ? Non ho capito ci devo rimettere anche io consumatore perchè questi non sanno fare il loro mestiere, cos'è sono in cassa integrazione ?
halduemilauno
04-12-2009, 11:05
...parli di questi?...
http://www.dvhardware.net/news/jon_peddie_gpu_market_q3_2009.jpg
...fonte (http://www.dvhardware.net/article38784.html)...e news (http://www.benzinga.com/markets/analyst-research/analyst-color/45247/nvda-may-continue-to-lose-market-share-in-graphics-card) dal mondo finanziario...
...ciao Andrea...
ovviamente no. ti aiuto, intel non deve figurare.
ovviamente no. ti aiuto, intel non deve figurare.
...ah ok...altri ritocchi alla tabella?...inutile girarci attorno Intel è leader incontrastata...quella è la situazione di mercato e quelle sono le percentuali di market share...mentre nell'altro link ci sono i valori delle azioni...
...ciao Andrea...
ps i chipset? tra il colosso intel e il 10% che vale amd per me fa bene a chiudere la divisione chipset. ripeto per me.
...se il mercato chipset amd è così scarso perchè mai nvidia si è imbarcata in questa cosa addirittura arrivando ad acquisire sis?...senza dimenticare il divario amd/intel di 4 anni fa...mi sembra la storia della volpe e l'uva...
...ciao Andrea...
halduemilauno
04-12-2009, 11:16
...ah ok...altri ritocchi alla tabella?...inutile girarci attorno Intel è leader incontrastata...quella è la situazione di mercato e quelle sono le percentuali di market share...mentre nell'altro link ci sono i valori delle azioni...
...ciao Andrea...
si sta parlando di schede video desktop. a te risulta che intel faccia tali schede? no non le fa la situazione attuale vede nvida ati 63 vs 34. il rimanente 3 la solita paccottiglia sis, via e matrox.
The Quaker
04-12-2009, 11:16
Non solo si cita FudZilla, ma anche su una boiata particolarmente colossale come le rese di un processo, che tecnicamente non ha alcun senso.
Le rese si riferiscono all'insieme di un prodotto (progetto, librerie e processo) e non ad un processo e basta.
Questa notizia non ha alcun senso.
le rese produttive tocca a loro farle, la GPU è progettata dalle case ma al realizzazione fisica le fa TSMC, ovvio che un progetto può essere più semplice da realizzare.
Per me bisognerebbe far causa e farsi risarcire, possibile che lì la gente non lavori ?
halduemilauno
04-12-2009, 11:17
...se il mercato chipset amd è così scarso perchè mai nvidia si è imbarcata in questa cosa addirittura arrivando ad acquisire sis?...senza dimenticare il divario amd/intel di 4 anni fa...mi sembra la storia della volpe e l'uva...
...ciao Andrea...
lo ripeto oggi(evidentemente allora era altro)è un mercato poco redditizio e mantenere una divisione di sviluppo costa e non ne vale + la pena. ripeto per me fa bene a chiuderla.
lo ripeto oggi(evidentemente allora era altro)è un mercato poco redditizio e mantenere una divisione di sviluppo costa e non ne vale + la pena. ripeto per me fa bene a chiuderla.
Non è che fa bene a chiuderla è che deve chiuderla dato che ne amd ne intel per il futuro accettano più la sua "collaborazione" :asd:
si sta parlando di schede video desktop. a te risulta che intel faccia tali schede? no non le fa la situazione attuale vede nvida ati 63 vs 34. il rimanente 3 la solita paccottiglia sis, via e matrox.
...possiamo giocare con le percentuali quanto vogliamo...ma questo è il mercato...e nella totalità del dato nvidia amd stanno 3 a 2...e devono entrambe andare molto caute con i passi falsi...senza dimenticare chi comanda...se domani l'integrata intel diventa un derivato di larrabee le cose potrebbero complicarsi un bel po'...
...ciao Andrea...
The Quaker
04-12-2009, 11:28
io sicneramente sono stufo di questa TSMC. non importa se ne escono 2 buoni goni 100, vorrà dire che dovranno incrementare la forza di lavoro di 50 volte. Nvidia ha fatto ordinazioni, e loro la devono rispettare. Che vuol dire che non riescono ?
Hanno ordinato un tot e un tot devono essere pronti, prima si presenta il conto e poi si fa trovare il prodotto finito on viceversa per cui Nvidia dovrebbe aver già pagato sta TSMC.
halduemilauno
04-12-2009, 11:31
...possiamo giocare con le percentuali quanto vogliamo...ma questo è il mercato...e nella totalità del dato nvidia amd stanno 3 a 2...e devono entrambe andare molto caute con i passi falsi...senza dimenticare chi comanda...se domani l'integrata intel diventa un derivato di larrabee le cose potrebbero complicarsi un bel po'...
...ciao Andrea...
ma non sto giocando(anche se le schede video servono a quello)io parlavo e parlo proprio di schede video non di chip video dove intel la fa da padrone. capito ora? schede video per pc desktop quelle che vanno inzeppate negli slot pci express. intel non ne fa. li farà forse, un domani, chissa, bho.
Foglia Morta
04-12-2009, 11:32
Non è che fa bene a chiuderla è che deve chiuderla dato che ne amd ne intel per il futuro accettano più la sua "collaborazione" :asd:
All' ultima conference call riguardante i risultati finanziari però JHH ha detto che nel corso del Q1 2010 presenteranno due chipset edit: per processori intel ( che non saranno per i3 , i5 e i7 ). Quindi IMO la volontà per raschiare il fondo del barile ce l' hanno , forse pensano di non riuscire ad essere competitivi.
ma non sto giocando(anche se le schede video servono a quello)io parlavo e parlo proprio di schede video non di chip video dove intel la fa da padrone. capito ora? schede video per pc desktop quelle che vanno inzeppate negli slot pci express. intel non ne fa. li farà forse, un domani, chissa, bho.
...si ho capito...ma che siano integrate nel chipset o siano su pci-ex...poco importa...quello che importa sono i numeri di chip venduti...certo i margini potranno anche essere diversi...a mio avviso poi le integrate su chipset stanno sempre piu' prendendo piede...
...ciao Andrea...
Severnaya
04-12-2009, 12:00
no una cosa sono i chip video e un'altra cosa sono le schede video discrete... nn confondiamo le mele con le pere per cortesia
Raumizio
04-12-2009, 12:14
io sicneramente sono stufo di questa TSMC. non importa se ne escono 2 buoni goni 100, vorrà dire che dovranno incrementare la forza di lavoro di 50 volte. Nvidia ha fatto ordinazioni, e loro la devono rispettare. Che vuol dire che non riescono ?
Hanno ordinato un tot e un tot devono essere pronti, prima si presenta il conto e poi si fa trovare il prodotto finito on viceversa per cui Nvidia dovrebbe aver già pagato sta TSMC.
Non penso sia così facile e scontato produrre chip, nè implementare nuove tecnologie...se pensi di saperlo fare meglio dei vari capoccia, proponiti. :asd:
Capisco la frustrazione che può generare il fatto che Fermi non esca a breve, io stesso sono molto curioso di vederlo all'opera (pur ammirando le vga prodotte da ati che ahinoi sono ancora disponibili in quantità bassissime), però mi sto stancando di leggere su vari forum "sono incapaci", "cacchio fa Nvidia", "cacchio fa TSMC"...sicuramente dietro c'è gente che ha ben più di un diavolo per capello con simili problematiche alle spalle, con giri d'affari di milioni di dollari che dipendono dal tuo operato.
Non credo che siano là a prendersi un thè...
Quindi leggere in una pagina 3 post di semi-insulti a terzi che magari adesso sono là con una certa ansia e tensione nervosa addosso, da fastidio.;)
ma non sto giocando(anche se le schede video servono a quello)io parlavo e parlo proprio di schede video non di chip video dove intel la fa da padrone. capito ora? schede video per pc desktop quelle che vanno inzeppate negli slot pci express. intel non ne fa. li farà forse, un domani, chissa, bho.
Ma basta con la tua disinformazione. A questo punto fai prima ad usare uno dei tuoi utenti cloni, che con quel nick non ti crede piu' nessuno :rolleyes:
http://www.atomicmpc.com.au/News/153350,amd-wins-in-the-discrete-gpu-market.aspx
AMD wins in the discrete GPU market
Agosto 2009 (53% market share)
mi dispiace(per modo di dire ovviamente)ma non saranno quelle poche serie 5 a far si che il natale sia molto rosso visto che nvidia detiene il 63% del mercato mondiale delle schede video desktop. e pensa amd neanche possiede il restante 37 ma il 34%. per spostare di un solo punto % avoja te quante schede ne deve vendere in +.
Mi dispiace (per modo di dire ovviamente) che ti senta punto nel tuo thread pro verde, tuttavia non ho capito bene dove vai a parare balbettando le attuali percentuali di market share (che inoltre confermo, fino ad oggi)...... Non centra niente con quello che ho detto. Io mi baso solo su quello che vedo, ovvero un'imminente assenza di nvidia (240 e 310 non credo siano un must...) per Natale (a meno che tu non ne sappia di più) e ben 5 (C.I.N.Q.U.E) mesi di vendita (poco o molto che sia, dipendente o meno dal TSMC che sia) per Ati) e di progetazione in più a vantaggio di Ati, che può (se non fa lo stesso errore di Nvidia al tempo) dedicarsi a 6xxx.
Ma come dicevate voi tutti in coro all'epoca del megaFAKE del cinese, "ma suvvia, saranno poche settimane di ritardo..."
E la paura di Nvidia è tangibile in molti casi, non ultimo la "preghiera" agli utenti..
"Nvidia offrirà ai videogiocatori una grande esperienza nel 2010 con la linea di schede GeForce basate su Fermi. Posso assicurarvelo, pazientate e sarete ripagati"
http://www.tomshw.it/cont/news/geforce-fermi-per-i-videogiochi-attesa-ripagata/22892/1.html
con un bel "vi prego" alla Roger Rabbit
Ne riparliamo con qualcosa di certo a Pasqua, percentuale o no.... xD
Kharonte85
04-12-2009, 12:39
La notizia è vecchia ma mi pare interessante
November 18 2009 02:17AM GMT - Following our article, we were contacted by Mr. Andy Keane, General Manager of Tesla Business and Mr. Andrew Humber, Senior PR Manager for Tesla products. In a long discussion, we discussed the topics in this article and topics of Tesla business in general. First and foremost, Tesla is the slowest clocked member of Fermi-GPU architecture as it has to qualify for supercomputers. The way to win the HPC contract is more complex than the CPUs itself.
Bear in mind that Intel flew heads out of Oak Ridge with their otherwise superior Core 2 architecture after Woodcrest had a reject rate higher than 8% [the results of that Opteron vs. Xeon trial in 2006 are visible today, as Oak Ridge is the site of AMD-powered Jaguar, world's most powerful supercomputer].
In order to satisfy the required multi-year under 100% stress, nVidia Tesla C2050/2070 went through following changes when compared to the Quadro card [which again, will be downclocked from the consumer cards]:
* Memory vendor is providing specific ECC version of GDDR5 memory: ECC GDDR5 SDRAM
* ECC is enabled from both the GPU side and Memory side, there are significant performance penalties, hence the GFLOPS number is significantly lower than on Quadro / GeForce cards.
* ECC will be disabled on GeForce cards and most likely on Quadro cards
* The capacitors used are of highest quality
* Power regulation is completely different and optimized for usage in Rack systems - you can use either a single 8-pin or dual 6-pin connectors
* Multiple fault-protection
* DVI was brought in on demand from the customers to reduce costs
* Larger thermal exhaust than Quadro/GeForce to reduce the thermal load
* Tesla cGPUs differ from GeForce with activated transistors that significantly increase the sustained performance, rather than burst mode.
Since Andy is the General Manager for Tesla business, he has no contact with the Quadro Business or GeForce Business units, thus he was unable to answer what the developments are in those segments. We challenged nVidia over several issues and we'll see what the resolve of those open matters will be. In any case, we'll keep you informed.
http://www.brightsideofnews.com/news/2009/11/17/nvidia-nv100-fermi-is-less-powerful-than-geforce-gtx-285.aspx
Possibile davvero che non sappiano nulla dello sviluppo delle altre divisioni? Se così fosse confermerebbe ancora di più il sospetto che i dati in nostro possesso potrebbero essere parziali in quanto riferiti all'architettura Fermi in generale e non a gf100 in particolare il che potrebbe lasciare spazio ad altre sorprese (oltre a quella possibilità discussa sulle operazioni MAD <--> FMA)
halduemilauno
04-12-2009, 12:46
La notizia è vecchia ma mi pare interessante
Possibile davvero che non sappiano nulla dello sviluppo delle altre divisioni? Se così fosse confermerebbe ancora di più il sospetto che i dati in nostro possesso potrebbero essere parziali in quanto riferiti all'architettura Fermi in generale e non a gf100 in particolare il che potrebbe lasciare spazio ad altre sorprese (oltre a quella possibilità discussa sulle operazioni MAD <--> FMA)
gia postata e messa in evidenza proprio come hai fatto Te. E in un'altra dichiarazione un'altro dirigente Nvidia faceva notare le differenza fra le Tesla gt300 e le future GeForce basate sul gf100.
;)
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.