View Full Version : Intervista a David Kirk: richiesta di domande
Paolo Corsini
01-07-2005, 17:46
Buonasera a tutti; Mercoledì prossimo David Kirk, Chif Scientist di NVIDIA, sarà a Milano per un incontro con la stampa e sarà presente anche io per intervistarlo.
Avendo qualche giorno di tempo a disposizione, vorrei cercare di raccogliere domande da parte vostra.
Per chi volesse ulteriori riferimento, a questo indirizzo:
http://www.hwupgrade.it/articoli/skvideo/1115/index.html
c'è una precedente intervista a David Kirk che ha fatto Raffaele lo scorso autunno.
Tnks ;)
Gabriyzf
01-07-2005, 17:54
Ciao Paolo: potresti chiedergli, a distanza di qualche mese, se effettivamente il chip video delle Geforce 6800 è fallato: voglio vedere se ha ancora il coraggio di dirti di no, grazie.
Paolo Corsini
01-07-2005, 17:55
Ciao Paolo: potresti chiedergli, a distanza di qualche mese, se effettivamente il chip video delle Geforce 6800 è fallato: voglio vedere se ha ancora il coraggio di dirti di no, grazie.
Con riferimento a pure video, in questo intendi "fallato"?
Gabriyzf
01-07-2005, 17:56
sì,sì, e per l'accelerazione hardware WMV.
A me piacerebbe sapere perchè non hanno implementato il 3dc nel nuovo g70.
zerothehero
01-07-2005, 18:26
adesso mi viene in mente qualcosa di molto banale tipo chiedere la tendenza generale nell'evoluzione delle schede video..e una sua impressione sulle nuove console (play3 in particolare)
farei qualche domandina anche su un eventuale supporto dell'agp.
mi interesserebbe molto anche a me sapere il motivo del mancato supporto del 3dc ati..
OvErClOck82
01-07-2005, 20:22
adesso mi viene in mente qualcosa di molto banale tipo chiedere la tendenza generale nell'evoluzione delle schede video..e una sua impressione sulle nuove console (play3 in particolare)
farei qualche domandina anche su un eventuale supporto dell'agp.
mi interesserebbe molto anche a me sapere il motivo del mancato supporto del 3dc ati..
sono della stessa opinione... :D :D
Caterpillar86
02-07-2005, 10:31
Uh cos'è questa storia della 6800 fallata? :mbe:
A me piacerebbe sapere perchè non hanno implementato il 3dc nel nuovo g70.
Perche' hanno implementato un loro formato per ragioni di marketing e la conversione avviene in maniera trasparente all'interno del driver.
Perche' hanno implementato un loro formato per ragioni di marketing e la conversione avviene in maniera trasparente all'interno del driver.
la conversione? vuoi dire che i giochi che ne fanno uso potranno sfruttare il 3dc anche su hardware nVidia?
bYeZ!
hackboyz
02-07-2005, 11:17
Si ma non è giusto fek ci toglie lo sfizio :asd:
Perche' hanno implementato un loro formato per ragioni di marketing e la conversione avviene in maniera trasparente all'interno del driver.
Wow,ma questa compressione,visto che avviene via driver,potrà essere sfrtuttata da tutte le schede Nvidia?
Sarebbe propio una bella cosa se fosse compatibile anche con la mia 6800 ultra :)
Certo che però rimarrebbe il problema di compatibilità con le normal map scritte per il 3dc,infatti mi sembra che la tecnica di compressione per funzionare debba essere prevista e implementata direttamente da voi programmatori gusto?
Tra l'altro,sai quando usciranno i driver che renderanno disponibile questo nuovo formato?
:)
Sarebbe interessante chiedere come consiglierebbe di spendere ad un videogiocatore i propri soldi: 400 Euro in PS3 o 400 Euro in G70?
io chiederei se in futuro spingeranno lo sli anche nell fascia medio bassa (si sta vedendo qualcosa con la 6600...)
Wow,ma questa compressione,visto che avviene via driver,potrà essere sfrtuttata da tutte le schede Nvidia?
Sarebbe propio una bella cosa se fosse compatibile anche con la mia 6800 ultra :)
Certo che però rimarrebbe il problema di compatibilità con le normal map scritte per il 3dc,infatti mi sembra che la tecnica di compressione per funzionare debba essere prevista e implementata direttamente da voi programmatori gusto?
Tra l'altro,sai quando usciranno i driver che renderanno disponibile questo nuovo formato?
:)
Poi serve che la GPU sia in grado di leggere e decomprimere il formato al momento dell'uso quindi sara' solo disponibile sulle GPU che lo supportano, G70 e derivati.
Paolo, ho una domanda alla quale a me non hanno risposto, magari sei piu' fortunato :)
Anzi, ho due domande, la prima risposta gia' prevedo sara' divertente.
1) Quali sono i vantaggi e gli svantaggi di usare Embedded RAM intelligente integrata nella GPU per il frame buffer, la soluzione dell'R500, che in linea teorica dovrebbe garantire un notevole risparmio in termini di consumo di banda sul bus interno verso la memoria video a vantaggio della banda a disposizione dei texture fetch. E se valuteranno una simile soluzione in futuro (Nove su dieci non ti risponde)
2) Quali sono i vantaggi e gli svantaggi di una soluzione a pipeline unificate che in linea teoria permetterebbe una notevole semplificazione del design, con conseguente risparmio in termini di transistor, ora che i modelli di programmazione di vertex e pixel shader si stanno unificando. Prevedono di usare questo design per future architetture? (Questa e' una domanda retorica, ma mi interessa quello che dice sui vantaggi e sugli svantaggi, perche' un anno fa lui era decisamente contro tale architettura)
edit: ma oggi sono dislessico
Uh cos'è questa storia della 6800 fallata? :mbe:
I chip NV40 (6800 in tutte le salse) venivano accreditati di possedere feature in grado di alleggerire il carico del processore (a dire il vero non solo questo ma voglio essere breve) durante la riproduzione di filmati in standard MPEG.
E benché la campagna pubblicitaria spingeva molto in tal senso, in realtà non è mai stato implementato, a causa di problemi di progettazione. Solo le revisioni che son venute fuori NV41 (ed ironia della sorte destinate alla fascia medio-bassa, le 6600) se ne avvantaggiano.
Però è un supporto monco, a mio modo di vedere le cose. Vediamo se questo nuovo G70 non sarà un nuovo buco nell'acqua, visto che si parla di fine anno per implementarlo nei driver. Io resto molto fiducioso nella soluzione analoga del futuro R520.
Io, io :D
Trend stimato della potenza consumata dalle schede video per il prossimo anno?
Future evoluzioni del clock gating?
Dark Schneider
02-07-2005, 15:31
Paolo io chiederei qlcsina riguardante la grandezza del Core. :)
Visto che nella rete ci sono discussioni riguardante la possibilità di alcune Pipeline disattivate in G70(anche se molto improbabile..ma tecnicamente "possibile").
Poi mi piacerebbe leggere qualcosa riguardante le architetture con unita vertex e pixel unificate. Ovviamente non mi aspetto che risponda "NV50". Però mi piacerebbe leggere cosa comporterà rispetto alle attuali architetture in generale. Bene o male so cosa comporterà, ma penso sia interessante sapere cosa ne pensa lui. :) Una domanda sul "futuro" ci vuole.
Poi mmmmm ci devo pensare.
Ma cmq imho farei fare qlc domanda a yoss. Così da poter ricavare informazioni "dirette". :sofico:
Dark Schneider
02-07-2005, 15:33
Paolo, ho una domanda alla quale a me non hanno risposto, magari sei piu' fortunato :)
2) Quali sono i vantaggi e gli svantaggi di una soluzione a pipeline unificate che in linea teoria permetterebbe una notevole semplificazione del design, con conseguente risparmio in termini di transistor, ora che i modelli di programmazione di vertex e pixel shader si stanno unificando. Prevedono di usare questo design per future architetture? (Questa e' una domanda retorica, ma mi interessa quello che dice sui vantaggi e sugli svantaggi, perche' un anno fa lui era decisamente contro tale architettura)
edit: ma oggi sono dislessico
fek stavo scrivendo le mie domande, poi ho letto questa tua domanda. Son daccordo. Son curioso anchio sull'unificazione e sulla differenza rispetto alle attuali architetture. :)
Ottime domande finora.
Aggiungo qualcosa (e' stato detto quasi tutto quindi sono a volte anche semi-copie di altre domande ... ^^ o questioni dalla risposta scontata ...):
Il team che ha sviluppato g70 e' lo stesso che ha lavorato sulla GPU della futura PS3 ? Caratteristiche simili/differenze tra le due ? (perdonatemi se e' gia' stato detto qualcosa sulla architettura di quella gpu, in questo caso m'e' sfuggito :)
Forceware 80.xx: in cosa consiste tecnicamente il supporto alle cpu dualcore ? Per sfruttarli in ogni caso dovremo aspettare giochi programmati "nativamente" o qualche miglioramento ci sara' fin dall'uscita in maniera retro-attiva ?
PCI Express 2: e' proprio necessario ? Se si, che tempi ci sono ? Che miglioramenti rispetto al primo ?
SLI 2: per controbattere a Crossfire o cmq per confermare la leadership, han detto che faranno un miglioramento dello SLI o ho capito male io ? Se si, che differenze (aridaje =) col primo ?
In futuro dobbiamo aspettarci schede video con sempre piu' memoria on board ? (1 GB+ O_o ?) E saranno sempre gddr3 o ci saranno le 4 ... xdr ... altro ?
Hanno gia' una roadmap con la previsione dell'uso di transistor a nanometri sempre piu' inferiori ? Prevede che ci saranno problemi di consumo o ci manterremo piu' o meno ai livelli di 6800 e g70 ? (edit: ok queste erano gia' state fatte ...)
Ci saranno in futuro GPU con supporto nativo alla gestione della fisica per sgravare il processore di questo pesante fardello ? O meglio ancora GPU che direttamente si affiancano all'elaborazione dei processori in qualsiasi campo (edit: ok anche questa era stata fatta, ma aveva detto "nella prossima generazione", su g70 c'e' gia' qualcosa di simile ? non mi pare ... quindi, per il futuro :) ?
Cosa ne pensa del raffreddamento rivoluzionario di Sapphire (metallo liquido, com'e' che si chiamava ...) ?
Novita' sul supporto nativo a Longhorn ? Quale sara' la prima scheda compatibile 100% alle api WGF 2.0 ? Sara' retrocompatibile con le "vecchie" dx ?
Boh non mi viene in mente altro :D
yossarian
02-07-2005, 16:54
ok, visto che le domande sull'architettura unificata sono già state fatte, si potrebbe chiedere, ad esempio, quanti sono i registri temporanei di vs e ps di RSX e, sempre relativamente a RSX, quante sono le flops stimate per alu, sia per i vs che per i ps.
Considerato che al 99% non risponderà, si potrebbe ripiegare su una, dall'apparenza più innocente:"quando uscirà il primo chip high end a 90 nm?".
:D
Caterpillar86
02-07-2005, 19:39
Ma quanti Watt consuma una 6800GT? Volevo metterne un'altra in SLI ma se consumano troppa corrente devo far prima due conti
OvErClOck82
02-07-2005, 19:45
chiedetegli se possono rimettere nalu come testimonial :Prrr:
voglio nalu :cry:
no, vabbè, a parte gli scherzi, anche a me piacerebbe sapere qualcosa su eventuali pipelines in più.
Athlon 64 3000+
03-07-2005, 00:38
La cosa che mi starebbe più a cuora,sapere se faranno in versione agp la Geforce 7800GTX.
Sono curioso di sapere anche io i vantaggi e svantaggi su le architetture WGF 2.0 con le unità shader unificate.
E poi mi piacerebbe sare se RSX e G70 saranno architteturalmente identiche o avranno delle differenze.
stesio54
04-07-2005, 15:47
io vorrei sapere perchè si è ritornati a proporre soluzioni con 2 vga anzichè potenziare/innovare una sola vga.
SilverXXX
04-07-2005, 18:02
Oltre a trovare valide tutte le domande (e ci mancherebbe, visto il posto in cui siamo :D), si potrebbe chiedergli (oltre al fatto se integreranno PPU in futuro), cosa ne pensa di quella che deve uscire, e se secondo lui è una soluzione per il futuro.
Io chiederei se hanno progetti per creare gpu dual core oppure continueranno ad aumentare il numero di pipeline.
project00
04-07-2005, 19:10
Io chiederei se hanno progetti per creare gpu dual core oppure continueranno ad aumentare il numero di pipeline.
Da "ingnorante" in materia quale sono mi sembra che parlare di gpu dual-core non abbia senso visto che la pipeline lavorano già "come dei core" in parallelo...
Crashman
04-07-2005, 21:05
Una domanda a cui molto probabilmente non risponderà:
Le differenze tra g70 e RSX, in virtù della collaborazione di quest'ultimo con il Cell, si limitano al FlexIO o c'è qualcosa di più?
Mi piacerebbe che fosse posta questa domanda: quanto c'è di 3dfx nelle nuove soluzioni 7800GTX e cosa ne pensa delle possibilità di integrazione di tale Gpu con soluzioni tipo AGEIA PhysX.
Nvidia ha mai pensato di integrare unità che calcolano la fisica direttamente nei propri chip?
Pk77
Poalo... sarò molto mento tecnico e acuto nella mia richiesta.
Gli chiedi perchè hanno scelto quel roito di taiwanese come rappresentante della serie 7 e del brand in generale, visto che è lì onnipresente nella loro homepage che ci fissa? :doh:
Il ragazzo panzone ancora ancora... :D è simpatico, dai ... ma quella :rolleyes:
:)
A me piacerebbe tanto verificare questa questione, nella quale mi sono imbattuto venerdi' scorso facendo dei test e che e' stata "verificata" anche da un altro sito :
http://www.nvitalia.com/stories.php?story=05/07/04/9020011
Ovvero, domanda "pelosa" e molto "segretosa" :
Come mai le 7800 GTX provate, alla partenza di un applicativo 3d risultano "auto overclockarsi" ulteriormente, rispetto ai dati del pannello di controllo delle frequenze clock? E' una feature "involontaria" (bug dei driver, o dei bios), oppure cio' che e' stato rilevato dal rivatuner di A. Unwinder e' la riprova che, come hanno ipotizzato alcuni siti, la 7800 gtx preveda internamente frequenze differenti per geometry engine e shaders?
Per chi e' curioso di saperne di piu' riguardo le prove fatte e cio' che e' emerso, seguite il link alla notizia che porta in primo luogo al sito estero e in secondo luogo al thread dove io analizzavo la cosa
Nvidia ha mai pensato di integrare unità che calcolano la fisica direttamente nei propri chip?
C'e' gia'. Una GPU moderna e' perfettamente in grado di fare calcoli di fisica piu' efficientemente di una CPU general purpose. L'unico limite e' la precisione a 24 o 32 bit per componente.
Dark Schneider
05-07-2005, 10:27
Si potrebbe chiedere anche perchè non hanno eliminato la dipendenza dell'alu dalla tmu.
Sempre cose che si sanno grazie a yoss, però una conferma diretta sarebbe interessante da leggere. Sicuro le prestazioni sarebbero state maggiori.
yossarian
05-07-2005, 11:13
Si potrebbe chiedere anche perchè non hanno eliminato la dipendenza dell'alu dalla tmu.
Sempre cose che si sanno grazie a yoss, però una conferma diretta sarebbe interessante da leggere. Sicuro le prestazioni sarebbero state maggiori.
perchè la logica di funzionamento dei chip NV prevede la lettura e il caricamento dei thread in maniera sequenziale, sostituendo quello esaurito con il successivo e decidendo di volta in volta l'allocazione delle risorse; nei chip ATi, invece, i thread sono letti e caricati tutti insieme; questo permette di liberare risorse e svincolare tmu e alu. D'altro canto, la capacità del registro in cui vengono scritti i thread da eseguire è limitata, per cui il vantaggio di nVIDIA è quello di poter eseguire teoricamente infiniti thread con l'unica perdita di tempo dovuta all'eliminazione di un elemento della coda e la sua sostituzione con un altro; nei chip ATi, invece, quando gli m thread della coda sono esauriti, si deve di nuovo compiere l'operazione di "leggere e selezionare" i successivi m thread da scrivere nel registro.
Insomma, due filosofie diverse che danno luogo a due architetture solo apparentemente uguali
perchè la logica di funzionamento dei chip NV prevede la lettura e il caricamento dei thread in maniera sequenziale, sostituendo quello esaurito con il successivo e decidendo di volta in volta l'allocazione delle risorse; nei chip ATi, invece, i thread sono letti e caricati tutti insieme; questo permette di liberare risorse e svincolare tmu e alu. D'altro canto, la capacità del registro in cui vengono scritti i thread da eseguire è limitata, per cui il vantaggio di nVIDIA è quello di poter eseguire teoricamente infiniti thread con l'unica perdita di tempo dovuta all'eliminazione di un elemento della coda e la sua sostituzione con un altro; nei chip ATi, invece, quando gli m thread della coda sono esauriti, si deve di nuovo compiere l'operazione di "leggere e selezionare" i successivi m thread da scrivere nel registro.
Insomma, due filosofie diverse che danno luogo a due architetture solo apparentemente uguali
Puoi elaborare un po' il discorso sul caricamento e la selezione dei thread? Mi fai anche un esempio pratico per favore? :)
Tipo, che accade quando mando due gruppi di tre vertici alla GPU con stati diversi? Come vengono divisi i frammenti in thread? A grandi linee.
OvErClOck82
05-07-2005, 12:53
una sulla 7800gt ?
Dark Schneider
05-07-2005, 14:46
perchè la logica di funzionamento dei chip NV prevede la lettura e il caricamento dei thread in maniera sequenziale, sostituendo quello esaurito con il successivo e decidendo di volta in volta l'allocazione delle risorse; nei chip ATi, invece, i thread sono letti e caricati tutti insieme; questo permette di liberare risorse e svincolare tmu e alu. D'altro canto, la capacità del registro in cui vengono scritti i thread da eseguire è limitata, per cui il vantaggio di nVIDIA è quello di poter eseguire teoricamente infiniti thread con l'unica perdita di tempo dovuta all'eliminazione di un elemento della coda e la sua sostituzione con un altro; nei chip ATi, invece, quando gli m thread della coda sono esauriti, si deve di nuovo compiere l'operazione di "leggere e selezionare" i successivi m thread da scrivere nel registro.
Insomma, due filosofie diverse che danno luogo a due architetture solo apparentemente uguali
Quindi diciamo che nei chip Ati c'è una sorta di scheduler che carica tutti i thread e poi li esegue. Mentre nei chip nVidia, lo scheduler carica e seleziona(con qlc decisione arbitraria presumo) uno alla volta. Il tempo "perso" per nVidia quindi avviene in 2 tempi: quando deve togliere l'elemento dalla coda e quando deve prendere la decisione sul quale elemento selezionare come sostituto.
Ma complessivamente alla fine ci mette meno Ati perchè fa tutto d'un colpo? L' operazione di leggere e selezionare tutto d'un colpo i thread cmq non dovrebbe richiedere abbastanza tempo?
Al di là dei due "approcci" diversi, penso che cmq tutto dipenda anche da altri fattori in termini di velocità, no?
Cmq secondo te l'approccio Ati è indubbiamente migliore oppure dipende cmq sempre da casi e casi? :)
C'e' gia'. Una GPU moderna e' perfettamente in grado di fare calcoli di fisica piu' efficientemente di una CPU general purpose. L'unico limite e' la precisione a 24 o 32 bit per componente.
Io intendo soluzioni sli o dual chip, Ppu-Gpu. Sulla carta Ageia dovrebbe essere in grado di calcolare la fisica, le variazioni morfologiche dell'ambiente, simulazioni di fluidi e particelle da 10 a 100 volte più efficacemente di qualsiasi cpu-gpu.
In fondo soluzioni specifiche sono state sempre il pallino di 3dfx (anche rampage doveva avere una sezione di T&L su una scheda separata) ed è per questo che mi interessa sapere se in futuro si intende supportare tale filosofia.
Unreal 3 poi dovrebbe essere una buona pubblicità oltre che il banco di prova di tali soluzioni.
Pk77
Io intendo soluzioni sli o dual chip, Ppu-Gpu. Sulla carta Ageia dovrebbe essere in grado di calcolare la fisica, le variazioni morfologiche dell'ambiente, simulazioni di fluidi e particelle da 10 a 100 volte più efficacemente di qualsiasi cpu-gpu.
Il discorso e' interessante. Dipende dall'algoritmo, ma io non sono d'accordo nel dire che il chip di Ageia sia tanto piu' veloce di una GPU high-end.
Ma poniamo il caso che lo sia.
Ora, poniamo il caso che sia in grado di calcolare in qualche modo la fisica su 30.000 oggetti; il tutto si riduce a calcolare la posizione di questi oggetti in funzione del tempo (e di un certo numero di altri ingressi, per ora ignoriamoli) per 30 volte al secondo.
Il problema che spesso si ignora e': una volta che questi dati sono calcolati, devono transitare attraverso qualche bus per poi finire alla GPU per il rendering.
Ora, senza alcuna tecnica di batching (Geometry Instancing) particolare, la CPU e' in grado di spedire alla GPU non piu' di 3/4 mila oggetti separati per frame saturandosi totalmente e senza fare altro. Si tratta di un fattore 10 in meno rispetto a quanto necessario per far transitare i dati calcolati di un eventuale chip fisico. Ti sei domandato perche' non ti fanno mai vedere una demo con 30 mila oggetti? ;)
Sto parlando di Direct3D qui, OpenGL e' un po' piu' veloce, ma il discorso sostanzialmente non cambia ed e' il motivo per il quale sono scettico riguardo a queste soluzioni.
E' piu' sensato a mio avviso fare i calcoli il piu' possibile in-place dove vengono usato, in questo caso nella GPU senza saturare i bus di connessione, che asintoticamente migliorano in prestazioni molto piu' lentamente di quanto cresca la potenza di calcolo.
yossarian
06-07-2005, 01:39
Puoi elaborare un po' il discorso sul caricamento e la selezione dei thread? Mi fai anche un esempio pratico per favore? :)
Tipo, che accade quando mando due gruppi di tre vertici alla GPU con stati diversi? Come vengono divisi i frammenti in thread? A grandi linee.
scusate il ritardo, ma ho avuto una giornata un po'...........impegnativa :cry:
hai ragione, sono stato molto pooooocoooooo prooofeeeeesssiooonaaaleeee, però andavo di fretta e spero vorrai scusarmi :)
Quello che intendevo è che, nei chip NV (parlo a livello di pixel shader), si fa ricorso a uno schema del tipo che segue; durante la prima fase, in base alle indicazioni del microcodice dell'istruzione da eseguire, sono configurate tmu e alu; quindi si rintracciano e si collegano tra loro tutti i quad presenti nella coda, ordinandoli in base a quanto indicato; quindi, il singolo quad entra nella pipeline, passando attraverso i vari stadi, fino ad elaborazione terminata. Mentre viene elaborato, genera un nuovo microcodice da inviare al controller che lo legge e organizza le operazioni relative al secondo quad che entra nella pipeline e così via (naturalmente l'ingresso del quad successivo non è subordinato all'uscita di quello precedente; in tal modo si può avere un gran numero di quad, almeno in teoria, che circolano all'interno della pipeline)
Nei chip ATi, invece, si ha qualcosa del genere: si collegano e si ordinano tutti i quad nella coda in base all'elaborazione da fare; si caricano nei registri delle texture le 8 texture che si prevede di usare per prime; tra queste si seleziona quella relativa al primo dato da elaborare; infine, vengono caricati tutti i dati relativi alle operazioni matematiche da eseguire (massimo 128); infine si procede all'elaborazione, adoperando i dati caricati nei registri, fino a svuotamento degli stessi.
Quello scelto da NV è un approccio di tipo dinamico (reso possibile anche dal controllo dinamico del flusso di dati), in cui ogni elaborazione fornisce indicazioni per l'elaborazione successiva; quello di ATi è un approccio "statico", in cui, una volta stabilito il dato da processare, si predispone tutto, caricando i registri costanti e assegnando gli indirizzi alle texture; in tal modo, quando parte l'elaborazione, è già tutto pronto, non solo per quanto riguarda il primo quad, ma anche i successivi, fino ad esaurimento della coda o allo svuotamento dei registri. In poche parole, secondo l'appoccio di ATi, nel momento in cui parte l'elaborazione, ogni stadio della pipeline "sa già cosa fare", mentre nel caso di nVIDIA, le operazioni vengono programmate di volta in volta.
L'approccio di ATi è migliore per quanto riguarda la gestione dei registri temporanei, richiede un minor numero di transistor (pipeline più corte) e permette di svincolare il texture processor dalle alu. Però è limitato dalla capacità dei registri costanti e quindi nel numero di elaborazioni dipendenti le une dalle altre (nel caso di nvidia si potrebbero avere, teoricamente, infinite elaborazioni l'una dipendente dall'altra, e mi riferisco in particolare alle texture, mentre per ATi il numero è limitato alla quantità di dati contenuti nelle cache: infatti, ad esempio, i chip R4x0 e R3x0, hanno 8 texture register da 16 bit per un totale di massimo 4 dependent texture read a 32 bit, anche se, stando a quanto detto da ATi, l'ideale, per avere le migliori prestazioni, si ha non superando le due; nel caso di NV40 non c'è un limite teorico alle operazioni di dependent texture read). OT (il texture processor di ATi lavora a 16 e 32 bit) FINE OT
ATi ha superato questo limite con il ricorso al'f-buffer, che però richiede l'impiego di ulteriori cicli di clock nella migliore delle ipotesi (quando si tratta di una cache on chip).
Per Dark Schneider
In assoluto l'approccio migliore non esiste; per shader molto lunghi e con molte istruzioni di tipo dependent read, è preferibile nVIDIA, per shader più corti, invece, meglio ATi.
hai ragione, sono stato molto pooooocoooooo prooofeeeeesssiooonaaaleeee, però andavo di fretta e spero vorrai scusarmi :)
Ma che poco professionale, sono io che non lo so e volevo egoisticamente che me lo spiegassi :p
In assoluto l'approccio migliore non esiste; per shader molto lunghi e con molte istruzioni di tipo dependent read, è preferibile nVIDIA, per shader più corti, invece, meglio ATi.
Speculazione: dici che nell'R520 hanno cambiato approccio?
yossarian
06-07-2005, 11:03
Ma che poco professionale, sono io che non lo so e volevo egoisticamente che me lo spiegassi :p
beh, anch'io ho egoisticamente approfittato di molti chiarimenti da parte tua e conto di continuare a farlo
:D
beh, anch'io ho egoisticamente approfittato di molti chiarimenti da parte tua e conto di continuare a farlo
:D
Smettila che arrossico :)
Oggi sono duro, scusami, la spiegazione sull'approccio NVIDIA non mi e' chiara.
Mi fai un esempio con un triangolo di 16 pixel?
Dunque, siamo all'albo dei tempi, la GPU e' vuota, configuro le texture, i render state, gli shader, parte il primo triangolo, viene rasterizzato in 4 quad. Entra il primo quad nella prima pipeline.
A questo punto? Dimmelo passetto per passetto immaginando che io non sappia nulla (che in questo caso non e' tanto lontano dalla realta' :D)
yossarian
06-07-2005, 11:13
Speculazione: dici che nell'R520 hanno cambiato approccio?
direi di si; i casi sono due: o hanno implementatio grandi quantitativi di cache da utilizzare come f-buffer on chip o per ampliare a dismisura i registri (e comunque, in quest'ultimo caso, il problema sarebbe solo "spostato un po' più in la", ossia fino al limite della capacità dei nuovi registri), oppure hanno modificato la logica di funzionamento; l'approccio attuale è mutuato da quello delle cpu e non è ideale per l'elaborazione di shader lunghi e complessi da dover elaborare necessariamente in multipass.
Secondo me (anche se non ho la sfera di cristallo e ciò che dico va preso moooolto col beneficio del dubbio) R520 sarà una sostanziosa evoluzione di R420 e non una semplice revisione
yossarian
06-07-2005, 12:07
Smettila che arrossico :)
Oggi sono duro, scusami, la spiegazione sull'approccio NVIDIA non mi e' chiara.
Mi fai un esempio con un triangolo di 16 pixel?
Dunque, siamo all'albo dei tempi, la GPU e' vuota, configuro le texture, i render state, gli shader, parte il primo triangolo, viene rasterizzato in 4 quad. Entra il primo quad nella prima pipeline.
A questo punto? Dimmelo passetto per passetto immaginando che io non sappia nulla (che in questo caso non e' tanto lontano dalla realta' :D)
Oddio, la cosa va immaginata con molto più di 4 quad, facenti parte di diversi frammenti e tutti presenti nella coda dei dati da elaborare; comunque, il primo quad arriva all'ingresso della pixel pipeline; passa attraverso un'unità che legge una sorta di microcodice recante informazioni sul tipo di elaborazione da fare; la pixel pipeline viene organizzata di conseguenza, predisponendo le alu e la tmu per quello specifico tipo di elaborazione. Ovvio che mi sto riferendo a elaborazioni che richiedono più cicli di clock (le altre sono molto poco interessanti); il microcodice contiene informazioni sul numero e sul tipo di operazioni che devono essere eseguite su quello specifico quad; quindi, ad esempio, se devono essere eseguiti calcoli che richiedono l'utilizzo della tmu per n volte con in più m calcoli matematici, si può partire, ipoteticamente, con un rapporto 1:1 tra math ops e texture fetch (ho sparato a caso, quindi potrebbe non essere così e, comunque, sicuramente, il rapporto iniziale è fortemente dipendente da quanto è grande m rispetto a n); una volta fatto ciò, il quad entra nella pipeline e inizia a essere elaborato; una volta che il quad 1 ha passato i primi stadi di elaborazione, entra il quad 2 e si ripete il procedimento; di conseguenza, il primo blocco di unità di calcolo viene riorganizzato per accogliere il secondo quad; questo procedimento si ripete fino al momento dell'uscita del quad 1 dalla pixel pipeline; a questo punto, il quad 1 è dirottata all'interno di un quad buffer (che si trova dentro la pixel pipeline) e viene messo in attesa; nel compiere le varie operazioni all'interno della pixel pipeline, il microcodice (che non è altro che un registro delle operazioni da eseguire e di quelle eseguite) viene aggiornato e le informazioni sono inviate all'ingresso della pixel pipeline, dove vengono confrontate con il microcodice del quad che si trova in quel momento, per la prima volta, all'ingresso della stessa. Dal confronto delle operazioni da eseguire immediatamente sui due quad e dai dati risultanti sullo stato di occupazione delle unità di calcolo all'interno della pipeline, nonchè del numero di quad che sono, in quel momento in elaborazione, un controller decide quale quad far entrare (se il n°1 per il secondo ciclo o quello che si è presentato in quel momento, per la prima volta, all'ingresso). In questo tipo di elaborazione, le unità di calcolo vengono ogni volta riconfigurate e lo stesso vale per i dati caricati all'interno dei registri.
Col metodo seguito da ATi, invece, l'analisi dei microcodici è fatta all'inizio, per tutti i quad che possono essere ospitati al'interno della pipeline; di conseguenza, anche il lavoro delle unità di calcolo e lo stato di occupazione dei registri di sola lettura e di lettura/scrittura sono organizzati, completamente, prima che il primo quad faccia il suo ingresso nella pixel pipeline. Ovviamente, una volta esaurita l'elaborazione degli n quad che le pipeline può ospitare, si azzera e si riconfigura tutto per il successivo gruppo di quad.
Stavolta spero di essere stato più chiaro
:)
Stavolta spero di essere stato più chiaro
:)
Chiaro! Grazie :D
Vediamo se ho capito.
Io ho uno shader con un certo elenco di istruzioni.
Esempio per semplificare:
fetch 1
alu 1
fetch 2
norm 2
fetch 1 e alu 1 sono raggruppati nel pass 1
fetch 2 e norm 2 sono raggruppati nel pass 2
Se non sbaglio, per l'NV40.
Entra il primo quad. La pipeline analizza il primo pass, si configura per eseguire un fetch e un alu e butta dentro il quad 1. Presumibilmente ad un certo stadio aspettera' che il fetch 1 prelevi e filtri il texel. Entra il secondo quad che deve eseguire sempre il pass 1 e la storia si ripete. Ad un certo punto immagino che quad 1 e quad 2 siano fermi e aspettino i loro relativi fetch. Il tempo passa e prima o poi arrivano i dati e i due quad escono dal primo pass nella pipeline.
Secondo pass, entra il quad 1, la pipeline si configura per un fetch e per una normalizzazione (sempre NV40) e si riparte per il secondo pass.
A parte gli errori e le imprecisioni, e' questa l'idea?
(Oggi ti sfrutto :D)
Aggiungo, immagino che ogni quad si porti dietro le informazioni su quale pass all'interno dello shader deve eseguire.
youthgonewild
06-07-2005, 12:46
Potresti fare una domanda del genere:
"Si parla spesso di imminente rivoluzione nel modo di concepire i futuri videogiochi sia nel campo delle console che in quello del personal computer.Quali sono i vosti progetti in merito?Siete convinti che sia necessario implementare sempre nuove istruzioni nelle gpu per dare maggior realismo alle scene 3d o sono i programmatori di software che secondo voi devono dare inizio a questa "svolta"?"
;)
yossarian
06-07-2005, 12:47
[QUOTE=fek]Chiaro! Grazie :D
Vediamo se ho capito.
Io ho uno shader con un certo elenco di istruzioni.
Esempio per semplificare:
fetch 1
alu 1
fetch 2
norm 2
fetch 1 e alu 1 sono raggruppati nel pass 1
fetch 2 e norm 2 sono raggruppati nel pass 2
Se non sbaglio, per l'NV40.
Entra il primo quad. La pipeline analizza il primo pass, si configura per eseguire un fetch e un alu e butta dentro il quad 1. Presumibilmente ad un certo stadio aspettera' che il fetch 1 prelevi e filtri il texel. Entra il secondo quad che deve eseguire sempre il pass 1 e la storia si ripete. Ad un certo punto immagino che quad 1 e quad 2 siano fermi e aspettino i loro relativi fetch. Il tempo passa e prima o poi arrivano i dati e i due quad escono dal primo pass nella pipeline.
Secondo pass, entra il quad 1, la pipeline si configura per un fetch e per una normalizzazione (sempre NV40) e si riparte per il secondo pass.
A parte gli errori e le imprecisioni, e' questa l'idea?
[QUOTE]
diciamo che, in teoria, la situazione di "attesa" non dovrebbe verificarsi, però può accadere (anzi, considerando che non ci si limita a soli due quad, succede sicuramente e il quad buffer è li anche per questo) che ci siano più pixel che stiano in attesa della stessa istruzione; questo rende inefficiente l'elaborazione, perchè non tutte le unità sono impiegate; inoltre, considerata la ridotta capacità del quad buffer, se in un qualunque punto x della pipeline si crea un ritardo nell'elaborazione, gli altri quad in ingresso vengono bloccati, finchè non riprende l'elaborazione di quelli già presenti all'interno.
Questi inconvenienti dovrebbero subire un drastico ridimensionamento con ladozione di unità di calcolo generiche, con un'organizzazione diversa dall'attuale (anche se, pure queste ultime, non raggiungeranno il 100% dell'efficienza di cui parla Richard Huddy)
yossarian
06-07-2005, 12:49
Aggiungo, immagino che ogni quad si porti dietro le informazioni su quale pass all'interno dello shader deve eseguire.
esatto: è il microcodice di cui parlavo prima; reca informazioni relative a tutto l'iter di quello specifico quad, passo per passo
yossarian
06-07-2005, 12:59
(Oggi ti sfrutto :D)
se mi licenziano per scarso rendimento ti mando il conto delle spese mediche...........di tutta la famiglia, gatto compreso
:D
se mi licenziano per scarso rendimento ti mando il conto delle spese mediche...........di tutta la famiglia, gatto compreso
:D
Ma chi ti licenzia ? ATI o nVidia ? :sofico:
te non la racconti giusta, chi sei davvero ? leva la maschera!! :mbe: :stordita:
Te lo svelo io, in realtà yoss è Gabe Newell.
Crashman
06-07-2005, 13:57
Te lo svelo io, in realtà yoss è Gabe Newell.
Lo sapevoooooo :eek:
diciamo che, in teoria, la situazione di "attesa" non dovrebbe verificarsi, però può accadere (anzi, considerando che non ci si limita a soli due quad, succede sicuramente e il quad buffer è li anche per questo) che ci siano più pixel che stiano in attesa della stessa istruzione; questo rende inefficiente l'elaborazione, perchè non tutte le unità sono impiegate; inoltre, considerata la ridotta capacità del quad buffer, se in un qualunque punto x della pipeline si crea un ritardo nell'elaborazione, gli altri quad in ingresso vengono bloccati, finchè non riprende l'elaborazione di quelli già presenti all'interno.
Ma le latenze dei texture fetch non sono inevitabili?
Quando un quad si blocca su un fetch non viene messo in una specie di coda d'attesa che il fetch si completi per far posto ad altri quad di passaggio?
Almeno so che l'R500 fa qualcosa di simile, scambiando thread in attesa di fetch con thread che hanno tutti i dati a disposizione per l'esecuzione.
yossarian
06-07-2005, 14:41
Ma le latenze dei texture fetch non sono inevitabili?
Quando un quad si blocca su un fetch non viene messo in una specie di coda d'attesa che il fetch si completi per far posto ad altri quad di passaggio?
Almeno so che l'R500 fa qualcosa di simile, scambiando thread in attesa di fetch con thread che hanno tutti i dati a disposizione per l'esecuzione.
si, ma la coda d'attesa è limitata; il problema sorge quando più pixel sono in attesa dello stesso tipo di operazioni; in R500 le cache interne sono di dimensioni decisamente più generose e l'architettura stessa del chip prevede la possibilità di ridurre al minimo il rischio che ci siano più quad in attesa dello stesso fetch. R500 è dotata di una crossbar connection tra le texture unit e i 48 gruppi di alu generiche (raggruppate a 16 a 16); la logica è molto simile (e c'è un arbiter o controller che dir si voglia, che si occupa di "dirigere il traffico"; sono i mezzi tecnici che sono diversi (parcheggi più ampi e più vie di rifornimento per R500) e rendono l'architettura di R500 molto più efficiente.
Tra l'altro, e qui dovrei rig... :rolleyes: , informarmi meglio :D , il quad buffer interno alla pixel pipeline dovrebbe essere di tipo FIFO
PER I TRE SPIRITOSONI (Maury, DjLode e Crashman): si Gabe Newell con 70 Kg di meno :Prrr: :D
http://games.tiscali.cz//images/black&white2/bfgf.jpg
Con Ageia cose del genere saranno all'ordine del giorno?
yossarian
06-07-2005, 14:59
http://games.tiscali.cz//images/black&white2/bfgf.jpg
Con Ageia cose del genere saranno all'ordine del giorno?
fek, tu ne sai niente di quell'immagine?
:D
http://games.tiscali.cz//images/black&white2/bfgf.jpg
Con Ageia cose del genere saranno all'ordine del giorno?
Ooops, cose del genere girano sul mio PC senza Ageia :D
(yoss, quella e' la mia acquetta, Raffaele non svelare il trucco delle normali)
si, ma la coda d'attesa è limitata; il problema sorge quando più pixel sono in attesa dello stesso tipo di operazioni; in R500 le cache interne sono di dimensioni decisamente più generose e l'architettura stessa del chip prevede la possibilità di ridurre al minimo il rischio che ci siano più quad in attesa dello stesso fetch.
Mi stai riempendo di info. Grazie!
yossarian
06-07-2005, 15:16
Ooops, cose del genere girano sul mio PC senza Ageia :D
(yoss, quella e' la mia acquetta, Raffaele non svelare il trucco delle normali)
la domanda era retorica; non vedo l'ora di sciacquettare anch'io
:D
yossarian
06-07-2005, 15:16
Mi stai riempendo di info. Grazie!
prego, avrai modo di ricambiare, magari svelando qualche trucco (per esempio quello delle normali :D )
prego, avrai modo di ricambiare, magari svelando qualche trucco (per esempio quello delle normali :D )
Facile. Sono tirate a caso. Non c'e' nulla di vagamente plausibile dal punto di vista fisico, ho tipo tre normali diverse che rappresentano cose che non so in quello shader. Pero' il risultato e' carino, quindi mi va bene :)
Sono 60 istruzioni, 18 passate nel G70.
yossarian
06-07-2005, 15:27
Facile. Sono tirate a caso. Non c'e' nulla di vagamente plausibile dal punto di vista fisico, ho tipo tre normali diverse che rappresentano cose che non so in quello shader. Pero' il risultato e' carino, quindi mi va bene :)
Sono 60 istruzioni, 18 passate nel G70.
lo sai che con me, di queste cose, devi parlare in maniera terra terra :D
Sono tre normali tirate a caso una volta per tutte o tre normali in modalità random per ogni singola elaborazione?
Le istruzioni sono di tipo vettoriale completo oppure ci sono anche scalari o vettoriali non full, oltre che texture fetch e normalizzazioni?
Questo R500 mi sembra davvero un gran progetto, e poi si parla di un'ATI in crisi ... :)
Crashman
06-07-2005, 15:31
E' l'OT più interessante che abbia mai letto. Se smettette vi faccio licenziare con l'accusa di aver infranto tonnellate di NDA :Prrr:
lo sai che con me, di queste cose, devi parlare in maniera terra terra :D
Sono tre normali tirate a caso una volta per tutte o tre normali in modalità random per ogni singola elaborazione?
Le istruzioni sono di tipo vettoriale completo oppure ci sono anche scalari o vettoriali non full, oltre che texture fetch e normalizzazioni?
Calcolo una normale per pixel a partire da due normal map, piu' altra roba per evitare che quando la telecamera si allontana dall'acqua si vedano ripetizioni nel pattern. In realta' non e' proprio una normale nel vero senso della parola. Per tirare a caso intendo che da quella normale calcolo altre due normali mettendo a caso dei numeri che danno un bel risultato ma che non hanno significato fisico.
Fra le istruzioni c'e' un po' di tutto, vettoriali, scalari, miste, normalizzazioni, fetch dipendenti, dynamic branch, tutto quello che mi capitava fra le mani :)
yoss, OT per OT, ne ho una per te.
Lo shader sono 18 passate del G70. Dai profiling so che ogni frammento dell'acqua viene mediamente elaborato in poco piu' di un colpo di clock dal G70. 18 passate, esce un frammento ogni colpo di clock, significa che mediamente il G70 macina 18 frammenti in contemporanea. Sono quasi 18 pipeline, secondo te le 6 che "mancano" a che cosa sono dovute? Stalli nella pipeline? So che ho un 17% di texture cache miss rate. Ha senso quello che ho scritto?
(Ti divertiresti un mondo con questi profiling)
yossarian
06-07-2005, 15:52
Calcolo una normale per pixel a partire da due normal map, piu' altra roba per evitare che quando la telecamera si allontana dall'acqua si vedano ripetizioni nel pattern. In realta' non e' proprio una normale nel vero senso della parola. Per tirare a caso intendo che da quella normale calcolo altre due normali mettendo a caso dei numeri che danno un bel risultato ma che non hanno significato fisico.
Fra le istruzioni c'e' un po' di tutto, vettoriali, scalari, miste, normalizzazioni, fetch dipendenti, dynamic branch, tutto quello che mi capitava fra le mani :)
ora si che sei stato chiaro :)
denghiu (come direbbe l'Aldobiscardi nazionale)
:D
Ooops, cose del genere girano sul mio PC senza Ageia :D
(yoss, quella e' la mia acquetta, Raffaele non svelare il trucco delle normali)
Ma di fatto Ageia non inventa la fisica ma teoricamente dovrebbe renderla più fruibile su diversi livelli: morfologico, sui personaggi, sugli oggetti e elevare il numero e la qualità degli effetti particellari.
Bisogna vedere quanto le "tue" creazioni incidono sul frame rate e quanto ciò influisca sul processo creativo (cioè quante componenti dinamiche si possono inserire).
Pk77
Ma di fatto Ageia non inventa la fisica ma teoricamente dovrebbe renderla più fruibile su diversi livelli: morfologico, sui personaggi, sugli oggetti e elevare il numero e la qualità degli effetti particellari.
Bisogna vedere quanto le "tue" creazioni incidono sul frame rate e quanto ciò influisca sul processo creativo (cioè quante componenti dinamiche si possono inserire).
Pk77
E' questo il punto del discorso. Non credo che serva un chip fisico anche per il discorso sul trasporto dei dati che ho fatto prima. Per rispondere meglio alla tua domanda, quelle scene sono all'ordine del giorno oggi senza Ageia.
A riprova, la scena che hai riportato gira oggi tranquillamente su un PC di fascia medio/alta senza bisogno di coprocessori fisici.
Ti posso anche dare dati piu' precisi: la simulazione dell'acqua al momento prende una percentuale variabile fra il 3 e il 10% del frametime in una scena come quella. Anche supponendo che un chip fisico mi dimezzi questo tempo (e so che non ci riuscirebbe), sei disposto a spendere 100/150 euro per guadagnare da 1 a 3 frame al secondo?
Apriamo un thread e ne parliamo li'?
yossarian
06-07-2005, 20:43
yoss, OT per OT, ne ho una per te.
Lo shader sono 18 passate del G70. Dai profiling so che ogni frammento dell'acqua viene mediamente elaborato in poco piu' di un colpo di clock dal G70. 18 passate, esce un frammento ogni colpo di clock, significa che mediamente il G70 macina 18 frammenti in contemporanea. Sono quasi 18 pipeline, secondo te le 6 che "mancano" a che cosa sono dovute? Stalli nella pipeline? So che ho un 17% di texture cache miss rate. Ha senso quello che ho scritto?
(Ti divertiresti un mondo con questi profiling)
cosa intendi per 18 passate? 18 colpi di clock per completare tutto lo shader? Perchè, se così è, significa che tutte e 24 le pipeline lavorano, compiendo, ognuna, un ciclo di clock, fino ad arrivare a 18 cicli complessivi; il che significherebbe, 18 (cicli) x 24 (pipeline) x n (con n che è il totale di operazioni compiute, per clock, dalle unità di calcolo di una pipeline).
cosa intendi per 18 passate? 18 colpi di clock per completare tutto lo shader? Perchè, se così è, significa che tutte e 24 le pipeline lavorano, compiendo, ognuna, un ciclo di clock, fino ad arrivare a 18 cicli complessivi; il che significherebbe, 18 (cicli) x 24 (pipeline) x n (con n che è il totale di operazioni compiute, per clock, dalle unità di calcolo di una pipeline).
Loro li chiamano "pass", quindi mi dicono che uno shader e' formato da n passate nella pipeline. Quindi direi che un frammento che entra nella pipeline esce n colpi di clock dopo, nel mio caso 18. Dal profiling so che elabora circa un frammento per colpo di colpo.
Questo che cosa ti suggerisce?
edit: mi suggerisce che sto scrivendo un mare di idiozie.
yossarian
06-07-2005, 22:34
Loro li chiamano "pass", quindi mi dicono che uno shader e' formato da n passate nella pipeline. Quindi direi che un frammento che entra nella pipeline esce n colpi di clock dopo, nel mio caso 18. Dal profiling so che elabora circa un frammento per colpo di colpo.
Questo che cosa ti suggerisce?
edit: mi suggerisce che sto scrivendo un mare di idiozie.
non è molto chiara come definizione; la singola "passata" può essere composta da più cicli di clock (con le odierne pipeline lo è quasi sempre). Da come te l'hanno descritta, sembrerebbe che la "passata" sia, invece, identificabile con il ciclo di clock.
Se così fosse, molto dipende dal tipo di operazioni svolte; ad esempio, con G70, un texture fetch, una MAD vettoriale, una normalizzazione, due MAD scalari e un'operazione di branch sono compiute in un unico ciclo, però un pixel che entra nella pipeline, se attraversa tutti questi stadi esce dopo 10 cicli di clock (il texture fetch e una delle MAD scalari e la MAD vettoriale e l'altra MAD scalare sono operazioni parallele), calcolati senza tener conto dei cicli spesi per leggere e scrivere dati da e nei registri. Nell'uscire dalla pipeline, il pixel ha però compiuto un single pass.
Se, però, per pass intendono, come nell'accezione comune, un percorso completo entro la pipeline, allora i 18 pass sono riferiti a 18 giri completi all'interno della pipeline. Così, a occhio, la singola pixel pipeline di G70 può contenere almeno 3/4 pixel (con istruzioni full vect) in circolo, più quelli contenuti nel quad buffer (probabilmente altri 2 quad pari a 8 pixel). Questo significa che le 18 passate sono riferite ad ogni gruppo di 3 o 4 quad che circolano all'interno di ogni pixel pipeline. Questo dovrebbe significare che tutte e 24 le pixel pipeline sono piene e ogni quad deve compiere 18 cicli entro la sua pipeline. Quindi, a partire dall'inizio dell'elaborazione, dopo 18 cicli, si avranno in output i primi 24 pixel appartenenti ai primi 24 quad pronti ad uscire dalla pixel pipeline.
Facile. Sono tirate a caso. Non c'e' nulla di vagamente plausibile dal punto di vista fisico, ho tipo tre normali diverse che rappresentano cose che non so in quello shader. Pero' il risultato e' carino, quindi mi va bene :)
Sono 60 istruzioni, 18 passate nel G70.
E pensare che c'è gente che viene pagata per sparare i numeri a caso :D
Scherzi a parte... definirle normali non ha alcun senso a questo punto visto che non si sa normali di che sono :D Chiamiamoli vettori random e amen :)
E' interessante vedere come la programmazione della grafica 3D in tempo reale sia pura illusione. Uno si aspetta alle sue spalle modelli matematici che tengano conto della fisica ottica e chiacchiere varie e poi saltano fuori le normali che non sono normali :D Semplicemente meraviglioso :)
Tutto cio' non e' normale :D
Comunque ho come il sospetto che non sia solo un caso isolato, potrebbe anche darsi che la maggior parte (tutti i giochi ?) abbiano soluzioni piu' o meno simili. Random mode rulez :D
Se, però, per pass intendono, come nell'accezione comune, un percorso completo entro la pipeline, allora i 18 pass sono riferiti a 18 giri completi all'interno della pipeline. Così, a occhio, la singola pixel pipeline di G70 può contenere almeno 3/4 pixel (con istruzioni full vect) in circolo, più quelli contenuti nel quad buffer (probabilmente altri 2 quad pari a 8 pixel). Questo significa che le 18 passate sono riferite ad ogni gruppo di 3 o 4 quad che circolano all'interno di ogni pixel pipeline. Questo dovrebbe significare che tutte e 24 le pixel pipeline sono piene e ogni quad deve compiere 18 cicli entro la sua pipeline. Quindi, a partire dall'inizio dell'elaborazione, dopo 18 cicli, si avranno in output i primi 24 pixel appartenenti ai primi 24 quad pronti ad uscire dalla pixel pipeline.
Mi sembra piu' logica questa seconda interpretazione e butterei il mio discorso sui colpi di clock.
E' interessante vedere come la programmazione della grafica 3D in tempo reale sia pura illusione. Uno si aspetta alle sue spalle modelli matematici che tengano conto della fisica ottica e chiacchiere varie e poi saltano fuori le normali che non sono normali :D Semplicemente meraviglioso :)
Tutto cio' non e' normale :D
Comunque ho come il sospetto che non sia solo un caso isolato, potrebbe anche darsi che la maggior parte (tutti i giochi ?) abbiano soluzioni piu' o meno simili. Random mode rulez :D
Si', tutti i giochi sono cosi', ma c'e' un motivo logico: non c'e' abbastanza potenza elaborativa per implementare modelli piu' complicati e accurati. E non ci sara' ancora per qualche anno. Immagina un modello di Global Illumination qualunque (photon mapping ad esempio), per non tirare in ballo modelli di Radiosity complessi.
Se tu ci pensi bene, anche il famoso modello di illuminazione di phong non e' neppure vicino ad essere fisicamente plausibile, perche' non rispetta un principio abbastanza basilare: la conservazione dell'energia. Se fai l'integrale dell'energia entrante su una superficie a seguito del modello di phong e l'integrale dell'energia uscente scopri che... sono diversi :)
Pero' il modello e' semplice da implementare, fornisce un risultato visivo convincente, e' un buon valore per i soldi spesi. Nella grafica in tempo reale abbiamo un detto: "If it looks good, it's good enough".
Sparare normali a caso da un buon risultato allora e' un metodo abbastanza buono :)
Al prossimo giro ho piu' potenza, e provero' qualche modello piu' avanzato; ne ho gia' un paio in mente.
Dark Schneider
07-07-2005, 13:34
Per Dark Schneider
In assoluto l'approccio migliore non esiste; per shader molto lunghi e con molte istruzioni di tipo dependent read, è preferibile nVIDIA, per shader più corti, invece, meglio ATi.
Come immaginavo. :)
Sei stato chiarissimo yoss. :)
Si', tutti i giochi sono cosi', ma c'e' un motivo logico: non c'e' abbastanza potenza elaborativa per implementare modelli piu' complicati e accurati. [cut] Sparare normali a caso da un buon risultato allora e' un metodo abbastanza buono :)
Scherzando scherzando c'ho preso ^^
Mi ricorda molto ai tempi del c128 quando avevo scritto un programmino in basic che generava forme d'onda/suoni assolutamente a caso. Se ne sentivo uno bello, potevo salvare i parametri. Altri tempi, a quanto pare sempre attuali pero' :D
Dark Schneider
07-07-2005, 14:53
L'articolo dell'intervista quando uscirà? :)
Paolo Corsini
07-07-2005, 15:16
L'articolo dell'intervista quando uscirà? :)
Sto rileggendo in questo momento
Sto rileggendo in questo momento
:ave:
Dark Schneider
07-07-2005, 15:58
Sto rileggendo in questo momento
Perfetto. Me lo voglio gustare. :D :)
Athlon 64 3000+
07-07-2005, 16:36
appena esce me la leggerò molto volentieri
Paolo Corsini
07-07-2005, 17:07
http://www.hwupgrade.it/articoli/skvideo/1318/index.html
zerothehero
07-07-2005, 17:57
http://www.hwupgrade.it/articoli/skvideo/1318/index.html
stranamente è le risposte sono anche interessanti da leggere..in genere danno sempre risposte molto diplomatiche e di protocollo..non è questo il caso. :)
stranamente è le risposte sono anche interessanti da leggere..in genere danno sempre risposte molto diplomatiche e di protocollo..non è questo il caso. :)
E' interessantissima. Quello che mi piace dell'intervista e' che non sono d'accordo con tutto quello che dice, ma si vede che ogni affermazione e' pesata, ha un ragionamento preciso sotto ed e' frutto di scelte ponderate. Non e' puro marketing.
Crashman
07-07-2005, 18:04
Sono molto interessanti le sue dichiarazioni riguardo l'edram e l'architettura unificate. Ma intendeva fare pubblicità alla console Ms???? :sofico: :sofico:
Caterpillar86
07-07-2005, 19:08
Non mi è piaciuta tanto questa intervista
Sono molto interessanti le sue dichiarazioni riguardo l'edram e l'architettura unificate. Ma intendeva fare pubblicità alla console Ms???? :sofico: :sofico:
in effetti era intrippato :p
Non mi è piaciuta tanto questa intervista
Per le risposte o per come e' stata condotta da Paolo e colleghi ? :confused:
Bell'intervista, peccato un po' corta e poco "sbottonata"... :(
Caterpillar86
07-07-2005, 21:22
Per le risposte o per come e' stata condotta da Paolo e colleghi ? :confused:
Domande abbastanza scontate e che non stimolano la curiosità :D
Paolo Corsini
07-07-2005, 21:37
Domande abbastanza scontate e che non stimolano la curiosità :D
Oltre a questo, hai a questo punto da suggerire qualcosa di più costruttivo, tipo delle domande non scontate?
Ovviamente, questa mia è una domanda molto scontata ;)
Caterpillar86
07-07-2005, 21:47
Mi sarebbe piaciuta qualche delucidazione in più sulle future tecnologie che verranno usate in ambito 3D e fra quanti anni si potrà iniziare a parlare di fotorealismo
Athlon 64 3000+
07-07-2005, 21:47
la cosa più curiosa è che Kirk ha detto che continueranno ha fare architettura a shader separati anche con l'avvento delle WGF 2.0,quindi solo a livello software l'eventuale NV50 o G80 avrà gli shader unificati e non metterà nella gpu quella parcticolare memoria che ci sarà in Ati R500.
Una cosa davvero stranissima perchè sicuramente la prossima gpu di ati dopo R520 alias R600 sarà sicuramente WGF 2.0 sia software che hardware.
Per me comuunque se fosse verò la scelta di Nvidia proprio non la capirei.
Mi sarebbe piaciuta qualche delucidazione in più sulle future tecnologie che verranno usate in ambito 3D e fra quanti anni si potrà iniziare a parlare di fotorealismo
Se leggessi bene l'intervista invece di criticare troveresti le risposte ad entrambi i quesiti :rolleyes:
Caterpillar86
07-07-2005, 22:10
Se leggessi bene l'intervista invece di criticare troveresti le risposte ad entrambi i quesiti :rolleyes:
Bè allora saresti così gentile da quotarmi il pezzo dove parla di fotorealismo? :rolleyes:
Bè allora saresti così gentile da quotarmi il pezzo dove parla di fotorealismo? :rolleyes:
Niente da fare,stasera non mi sento gentile per niente :O
Caterpillar86
07-07-2005, 22:16
:mc: :ubriachi:
:D
Va beh dai,accennava alla complessità delle scene 3d qui:
Pensare che l'evoluzione nella grafica 3D possa fermarsi nel momento in cui sia possibile generare scene completamente raytraced, così da ottenere una rappresentazione che sia la più fedele possibile al mondo reale, è purtroppo una illusione. La teoria, infatti, non prevedo possa essere in qualche modo realizzabile in tempi accettabili, anche nell'ordine della decina di anni
Per l'altro tuo dubbio invece ne ha parlato un po in tutto l'articolo del futuro dei motori 3d...dall'architettura unificata allo sviluppo della fisica...poi ovvio che non potesse raccontarci per filo e per segno i loro progetti :)
Caterpillar86
07-07-2005, 22:25
Per l'altro tuo dubbio invece ne ha parlato un po in tutto l'articolo del futuro dei motori 3d...dall'architettura unificata allo sviluppo della fisica...poi ovvio che non potesse raccontarci per filo e per segno i loro progetti :)
Sisi son d'accordo ma alla fine son notizie che già erano nell'aria... Cioè quasi la scoperta dell'acqua calda :D
Per certi versi in fatto di motori grafici facevi prima a fare un'intervista a Carmack, ovvio che però se alla fine vai a parlare di hardware...
Beh,tu evidentemente sei più informato di me,perchè l'affermazione che per le wgf 2.0 non serve un'architettura hardware a shader unificati,e che probabilmente il prossimo chip nvidia non lo sarà,per me è stata una sorpresa.
Poi comunque quello che sapevi erano solo voci,e il solo fatto di avere confermati e fare chiarezza sui vari roumors non è cosa da poco IMHO
Caterpillar86
07-07-2005, 22:36
E' stata interessante l'affermazione sulla grafica del Longhorn anche se alla fine Windows mi disgusta abbastanza, visto che più vanno avanti e peggio sono gli OS Microsoft...
Tu sei uno che vede il bicchiere sempre mezzo pieno,a quanto ho capito :D
Comunque se sei un videogiocatore (e se ti interessi degli ultimi sviluppi delle schede video,dovresti rientrare in questa categoria)volente o nolente windows è una scelta obbligata.
Ciao ;)
E' stata interessante l'affermazione sulla grafica del Longhorn anche se alla fine Windows mi disgusta abbastanza, visto che più vanno avanti e peggio sono gli OS Microsoft...
Vabbe' abbiamo capito con chi abbiamo a che fare ... a proposito, sei ancora con il Win 3.1 se non ho capito male (il miglior OS della Microsoft ebbene si !) ? :mc:
yossarian
07-07-2005, 23:11
in particolare non sono d'accordo con questo (ma mi pare non lo sia, nei fatti, neppure nVIDIA)
Per meglio capire i benefici o i limiti di un'architettura a shader unificati bisogna premettere che tipo di carico ed elaborazioni vengano svolte dagli shader:
vertex shader: si tratta di operazioni soprattutto in floating point
pixel shader: buona parte del workload è legato alle textures
Le due tipologie di operazioni sono quindi molto diverse tra di loro; un'architettura unificata permette di ottenere, sia per pixel che per vertex shader, dei valori prestazionali di picco che sono più elevati rispetto ad un'architettura con shader separati. La spiegazione è ovvia: c'è un'unica risorsa hardware per elaborare pixel e vertex shader, di potenza complessivamente più elevata rispetto a quanto singolarmente sono in grado di elaborare i singoli pixel pipeline e vertex pipeline di un'architettura non unificata.
anche nei pixel shader, la parte relativa ai calcoli matematici e, in particolare, ai calcoli fp, sta assumendo sempre più importanza; una dimostrazione la si ha proprio seguendo l'elaborazione dei chip NV.
Tralasciando architatture precedenti, NV30 aveva una sola unità fp per pipeline e, per giunta, non indipendente dal texture processor; NV35 aveva un'unità fp (non indipendente) più due combiner fp per pipeline (la dove NV30 aveva due minialu fx); NV40 aveva due unità fp (di cui una non indipendente), con architettura superscalare, e con un circuito di normalizzazione per i calcoli in fp16. In G70 sono state aumentate le capacità della prima delle due ALU, ne sono state aggiunte altre due scalari e presenta sempre il circuito di normalizzazione a fp16. Di contro, il numero di TMU per pipeline è sceso da 2 a 1.
Riguardo alla seconda parte, con un'architettura a shader unificati, la probabilità di avere unità di calcolo inattive è estremamente bassa, al contrario di quanto accade con le pipeline tradizionali; invece sono scettico sull'organizzazione e l'efficienza di pipeline a unità separate, quando si tratta di elaborare codice unificato.
Infine, immaginavo che non avrebbe risposto alla domanda sul chip a 0,09; ma tanto il suo silenzio equivale ad una quasi risposta :D
Paolo Corsini
08-07-2005, 06:54
la cosa più curiosa è che Kirk ha detto che continueranno ha fare architettura a shader separati anche con l'avvento delle WGF 2.0,quindi solo a livello software l'eventuale NV50 o G80 avrà gli shader unificati e non metterà nella gpu quella parcticolare memoria che ci sarà in Ati R500.
Una cosa davvero stranissima perchè sicuramente la prossima gpu di ati dopo R529 alias R600 sarà sicuramente WGF 2.0 sia software che hardware.
Per me comuunque se fosse verò la scelta di Nvidia proprio non la capirei.
Ciao,
WGF 2.0 parla di programmazione unificata, ma non dice che gli shader debbano venir processati in modo unificato in hardware. Quindi, Microsoft indica le linee guida dal lato programmazione, ma non dice come i produttori di architetture video debbano implementare le proprie pipeline.
Embedded RAM: anche ATI ha dichiarato più volte che questa tecnica, a loro modo di vedere le cose, è una valida scelta in presenza di console, ma molto difficilmente ne vedranno l'utilizzo in architetture per PC.
Mi sarebbe piaciuta qualche delucidazione in più sulle future tecnologie che verranno usate in ambito 3D e fra quanti anni si potrà iniziare a parlare di fotorealismo
Credo che sia impossibile rispondere a questa domanda anche per persone del calibro di Kirk. L'evoluzione delle schede grafiche e' imho ben poco prevedibile e il tempo per avvicinarsi al fotorealismo e' ancora molto. Anche perche' credo si debba parlare anche di relativita' del fotorealismo: fino a pochi anni fa vedere giochi come Quake2 ci faceva gridare al miracolo e per i tempi quello gia' poteva essere una sorta di fotorealismo. Ora per curiosita' ci giochi e ti pare che siano passati 200 anni vista l'evoluzione dei titoli odierni. Lo stesso pero' succedera' con quelli odierni e cosi' via. Questo mi ha sempre fatto pensare che "in teoria" non ci avvicineremo mai al fotorealismo: per quanti siano gli sforzi, riuscirai sempre a distinguere quella sorta di "finzione" che c'e' anche in un'immagine in CG fatta con mappe HDR ecc. ecc.
Ora noi guardiamo gli screenshots dell' Unreal Engine 3.. ci sembrano spaventosi rispetto agli odierni. Gia mi immagino pero' quando saremo nel (esempio) 2008/2009 e diremo "ormai il motore dell'U3 e' obsoleto e bla bla bla..."
La realta', quella che i giochi cercano sempre piu' di imitare e' troppo complessa per essere scambiata facilmente con un gioco.
Paolo Corsini
08-07-2005, 06:57
Mi sarebbe piaciuta qualche delucidazione in più sulle future tecnologie che verranno usate in ambito 3D e fra quanti anni si potrà iniziare a parlare di fotorealismo
Fotorealismo: la risposta è mai. La complessità delle scene 3D aumenta ogni generazione, grazie sia alle risorse hardware che alle tecniche per generare scene. Ma in ogni caso, seguardi una scena 3D generata in tempo reale ora, come tra 10 anni, vedrai chiaramente passi in avanti incredibili ma comunque qualcosa che in termini di interazione con l'ambiente non sarà "reale" nel pieno senso del termine. Pensa solo alle sorgenti luminose che attraversano la finestra di una stanza, e come queste abbiano riflesi di vario livello sugli oggetti in essa contenuti: guarda la stanza dove ti trovi in questo momento e prova a pensarla rappresentana in 3D con tutta la sua complessità su uno schermo.
Se per fotorealismo intendi qualcosa che "sembri" reale, allora alcuni esempi li hai anche adesso. Se invece intendi una rappresentazione che sia indistinguibile con la realtà che ti circonda, il percorso è così lungo che diventa realmente inutile cercare di fissare delle date, in termini di anni, nelle quali quell'obiettivo verrà raggiunto.
Future tecnologie in ambito 3D: se puoi essere più specifico mi aiuti a capire meglio cosa vorresti.
Fotorealismo: la risposta è mai. La complessità delle scene 3D aumenta ogni generazione, grazie sia alle risorse hardware che alle tecniche per generare scene. Ma in ogni caso, seguardi una scena 3D generata in tempo reale ora, come tra 10 anni, vedrai chiaramente passi in avanti incredibili ma comunque qualcosa che in termini di interazione con l'ambiente non sarà "reale" nel pieno senso del termine. Pensa solo alle sorgenti luminose che attraversano la finestra di una stanza, e come queste abbiano riflesi di vario livello sugli oggetti in essa contenuti: guarda la stanza dove ti trovi in questo momento e prova a pensarla rappresentana in 3D con tutta la sua complessità su uno schermo.
Se per fotorealismo intendi qualcosa che "sembri" reale, allora alcuni esempi li hai anche adesso. Se invece intendi una rappresentazione che sia indistinguibile con la realtà che ti circonda, il percorso è così lungo che diventa realmente inutile cercare di fissare delle date, in termini di anni, nelle quali quell'obiettivo verrà raggiunto.
Future tecnologie in ambito 3D: se puoi essere più specifico mi aiuti a capire meglio cosa vorresti.
Esattamente quello che volevo dire con il mio post precedente.
Paolo Corsini
08-07-2005, 07:00
....Infine, immaginavo che non avrebbe risposto alla domanda sul chip a 0,09; ma tanto il suo silenzio equivale ad una quasi risposta :D
Ciao,
la sua risposta è stata, con un sorriso:
"once it's done"
e io ho replicato:
"ok, I see...like Microsoft with Longhorn, then"
e bella risata da parte di entrambi ;)
Athlon 64 3000+
08-07-2005, 08:25
in particolare non sono d'accordo con questo (ma mi pare non lo sia, nei fatti, neppure nVIDIA)
Per meglio capire i benefici o i limiti di un'architettura a shader unificati bisogna premettere che tipo di carico ed elaborazioni vengano svolte dagli shader:
vertex shader: si tratta di operazioni soprattutto in floating point
pixel shader: buona parte del workload è legato alle textures
Le due tipologie di operazioni sono quindi molto diverse tra di loro; un'architettura unificata permette di ottenere, sia per pixel che per vertex shader, dei valori prestazionali di picco che sono più elevati rispetto ad un'architettura con shader separati. La spiegazione è ovvia: c'è un'unica risorsa hardware per elaborare pixel e vertex shader, di potenza complessivamente più elevata rispetto a quanto singolarmente sono in grado di elaborare i singoli pixel pipeline e vertex pipeline di un'architettura non unificata.
anche nei pixel shader, la parte relativa ai calcoli matematici e, in particolare, ai calcoli fp, sta assumendo sempre più importanza; una dimostrazione la si ha proprio seguendo l'elaborazione dei chip NV.
Tralasciando architatture precedenti, NV30 aveva una sola unità fp per pipeline e, per giunta, non indipendente dal texture processor; NV35 aveva un'unità fp (non indipendente) più due combiner fp per pipeline (la dove NV30 aveva due minialu fx); NV40 aveva due unità fp (di cui una non indipendente), con architettura superscalare, e con un circuito di normalizzazione per i calcoli in fp16. In G70 sono state aumentate le capacità della prima delle due ALU, ne sono state aggiunte altre due scalari e presenta sempre il circuito di normalizzazione a fp16. Di contro, il numero di TMU per pipeline è sceso da 2 a 1.
Riguardo alla seconda parte, con un'architettura a shader unificati, la probabilità di avere unità di calcolo inattive è estremamente bassa, al contrario di quanto accade con le pipeline tradizionali; invece sono scettico sull'organizzazione e l'efficienza di pipeline a unità separate, quando si tratta di elaborare codice unificato.
Infine, immaginavo che non avrebbe risposto alla domanda sul chip a 0,09; ma tanto il suo silenzio equivale ad una quasi risposta :D
Sono d'accordo con te perchè non mi pare molto condivisibile la scelta di nvidia di voler fare una gpu WGF 2.0 ancora con unità shader separate.
Io mi immagino che Ati con le gpu WGF 2.0 sarà in vantaggio perchè primo ha già un'archiettura pronta (come è R500 di Xbox360 da cui nascerà R600) e secondo sarà più avantaggiato tecnologicamente di nvidia
Ho anche l sensazione che lo scontro G80 vs R600 mi ricorderà da un certo punto di visto lo scontro R3xx vs NV3x dove l'architettura Ati sarà più flessibilie e efficiente di quella nvidia.
Con questo però non voglio dire che eventualmente G80 sarà un porcheria di gpu come è stato NV30
Athlon 64 3000+
08-07-2005, 08:26
Ciao,
la sua risposta è stata, con un sorriso:
"once it's done"
e io ho replicato:
"ok, I see...like Microsoft with Longhorn, then"
e bella risata da parte di entrambi ;)
:rotfl: :rotfl: :rotfl: :rotfl: :rotfl: :rotfl: :rotfl: :rotfl: :rotfl: :rotfl: :sofico:
yossarian
08-07-2005, 10:02
Sono d'accordo con te perchè non mi pare molto condivisibile la scelta di nvidia di voler fare una gpu WGF 2.0 ancora con unità shader separate.
Io mi immagino che Ati con le gpu WGF 2.0 sarà in vantaggio perchè primo ha già un'archiettura pronta (come è R500 di Xbox360 da cui nascerà R600) e secondo sarà più avantaggiato tecnologicamente di nvidia
Ho anche l sensazione che lo scontro G80 vs R600 mi ricorderà da un certo punto di visto lo scontro R3xx vs NV3x dove l'architettura Ati sarà più flessibilie e efficiente di quella nvidia.
Con questo però non voglio dire che eventualmente G80 sarà un porcheria di gpu come è stato NV30
non è detto che un'architettura a shader separati sia necessariamente una "porcheria". Una mezza idea di come si potrebbe realizzarla ce l'avrei pure, però devo consultarmi con fek, per sapere come cambierà il modo di scrivere codici con le wgf2.0.
Per quanto riguarda R500, la sua architettura è perfettamente integrabile in ambito pc; il problema resta sempre legato a come sarà scritto il SW. SM2.0 e SM3.0 sono ideati per unità separate e la loro resa su un'architettura unificata potrebbe non essere ottimale.
Infine non credo proprio che ATi, avendo a disposizione un'architettura WGF2.0 (anche se per consolle), si metta a lavorare su una terza architettura pseudo-WGF2.0 a shader separati.
Caterpillar86
08-07-2005, 10:09
Tu sei uno che vede il bicchiere sempre mezzo pieno,a quanto ho capito :D
Comunque se sei un videogiocatore (e se ti interessi degli ultimi sviluppi delle schede video,dovresti rientrare in questa categoria)volente o nolente windows è una scelta obbligata.
Ciao ;)
Bè se giochi su internet ad esempio con i giochi della Id Software come tutte le serie di Quake, non c'è bisogno di Windows...
Caterpillar86
08-07-2005, 10:10
Vabbe' abbiamo capito con chi abbiamo a che fare ... a proposito, sei ancora con il Win 3.1 se non ho capito male (il miglior OS della Microsoft ebbene si !) ? :mc:
Prego? Con chi avete a che fare? Dai per favore basta col sarcasmo facile, uso XP SP2 come tutti voi (insieme a Linux ke sto rimettendo su questo pc nuovo) e ho notato che non è che brilli certo di stabilità e sicurezza, no? E' un reato ammettere ciò?
Mi sarebbe piaciuta qualche delucidazione in più sulle future tecnologie che verranno usate in ambito 3D e fra quanti anni si potrà iniziare a parlare di fotorealismo
Mai, perche' il fotorealismo come concetto non ha alcun senso nella grafica in tempo reale. Il discorso sulle future tecnologie e' stato affrontato parlando di eRAM e pipeline unificate. Per le tecnologie aliene dovremo aspettare qualche anno.
Beh,tu evidentemente sei più informato di me,perchè l'affermazione che per le wgf 2.0 non serve un'architettura hardware a shader unificati,e che probabilmente il prossimo chip nvidia non lo sarà,per me è stata una sorpresa.
Non ha detto una cosa simile. Diciamo che non poteva dirla :)
Ha detto che per il momento anche se i modelli di programmazione si stanno avvicinando, non sarebbe preferibile su PC un'architettura unificata per i motivi che ha spiegato. (Sui quali non sono totalmente d'accordo).
anche nei pixel shader, la parte relativa ai calcoli matematici e, in particolare, ai calcoli fp, sta assumendo sempre più importanza; una dimostrazione la si ha proprio seguendo l'elaborazione dei chip NV.
Yoss, e' esattamente il motivo per il quale non sono d'accordo con questa valutazione :)
Il trend e' di privilegiare l'aritmetica ai texture fetch, seguendo il trend che la potenza elaborativa cresce piu' velocemente di quanto diminuisce la latenza degli accessi alla memoria. Se si ignora per un momento il caso dei filtri, pixel e vertex shader stanno convergendo anche dal punto di vista del bilanciamento delle operazioni di fetch e delle operazioni aritmetiche; nei vertex shader salgono le prime, nei pixel shader le seconde.
Prego? Con chi avete a che fare? Dai per favore basta col sarcasmo facile, uso XP SP2 come tutti voi (insieme a Linux ke sto rimettendo su questo pc nuovo) e ho notato che non è che brilli certo di stabilità e sicurezza, no? E' un reato ammettere ciò?
Non e' un reato, e' solo una fesseria :)
yossarian
08-07-2005, 10:34
Yoss, e' esattamente il motivo per il quale non sono d'accordo con questa valutazione :)
Il trend e' di privilegiare l'aritmetica ai texture fetch, seguendo il trend che la potenza elaborativa cresce piu' velocemente di quanto diminuisce la latenza degli accessi alla memoria. Se si ignora per un momento il caso dei filtri, pixel e vertex shader stanno convergendo anche dal punto di vista del bilanciamento delle operazioni di fetch e delle operazioni aritmetiche; nei vertex shader salgono le prime, nei pixel shader le seconde.
infatti, il motivo per cui non condivido questa parte dell'analisi è proprio nel fatto che le operazioni relative a ps e vs stanno diventando sempre più "simili" tra loro e l'evoluzione naturale di questo processo non può che essere un'architettura di tipo unificato, che garantisce il massimo parallelismo possibile e il miglior sfruttamento delle risorse.
Tra l'altro, volevo un po' di informazioni sulle differenze tra programmi per architetture unificate e programmi per architetture a shader separati
Tra l'altro, volevo un po' di informazioni sulle differenze tra programmi per architetture unificate e programmi per architetture a shader separati
Qui non e' facile rispondere perche' non ho un'architettura unificata fra le mani ancora e non so quali siano le pratiche migliori in questo caso.
Posso tirare a indovinare. Diciamo che una pipelien Deferred dove prima prepari la geometria per il rendering, quindi lavorano i vertex shader, e poi illumini il risultato con diverse passate in cui lavorano i pixel shader potrebbe essere una mossa vincente. E' la prima che mi viene in mente. Passate per inizializzare lo zbuffer potrebbero divenire la norma. In genere direi tutte quelle situazioni in cui vertex o pixel shader sono sbilanciati l'uno rispetto all'altro. E' interessante anche il commento di Kirk riguardo all'R500 usato principalmente come pixel processor, calcolando la geometria in uno dei core della CPU e spedendola attraverso il sistema di streaming dedicato alla GPU.
yossarian
08-07-2005, 11:01
Qui non e' facile rispondere perche' non ho un'architettura unificata fra le mani ancora e non so quali siano le pratiche migliori in questo caso.
Posso tirare a indovinare. Diciamo che una pipelien Deferred dove prima prepari la geometria per il rendering, quindi lavorano i vertex shader, e poi illumini il risultato con diverse passate in cui lavorano i pixel shader potrebbe essere una mossa vincente. E' la prima che mi viene in mente. Passate per inizializzare lo zbuffer potrebbero divenire la norma. In genere direi tutte quelle situazioni in cui vertex o pixel shader sono sbilanciati l'uno rispetto all'altro. E' interessante anche il commento di Kirk riguardo all'R500 usato principalmente come pixel processor, calcolando la geometria in uno dei core della CPU e spedendola attraverso il sistema di streaming dedicato alla GPU.
gVazie caVo :D
gVazie caVo :D
Tu ti stai prendendo troppe liberta' :vicini:
Caterpillar86
08-07-2005, 11:40
Non e' un reato, e' solo una fesseria :)
Cosa? E' una fesseria dire che XP non è un OS sicuro? :sbonk:
Dai magari mi son sbilanciato sulla stabilità, ma XP non è per niente sicuro
Cosa? E' una fesseria dire che XP non è un OS sicuro? :sbonk:
Dai magari mi son sbilanciato sulla stabilità, ma XP non è per niente sicuro
Tu pensa a tenerlo aggiornato e vedrai che è sicuro. ;)
Caterpillar86
08-07-2005, 11:58
Vabbè non andiamo off topic, siamo evidentemente di idee troppo diverse, poi facciamo solo flame
Cosa? E' una fesseria dire che XP non è un OS sicuro? :sbonk:
Si'.
Caterpillar86
08-07-2005, 12:01
Si'.
Vabbè sicuramente Linux è più sicuro e su questo non ci piove
@ fek e Yossarian:
Complimenti... ogni volta che nasce una discussione tecnica per me, è sempre un piacere stare a leggere.
Potrei dire che è quasi come seguire una lezione all'uni, durante la quale ascoltando il prof poi è molto più semplice studiare sui libri. Con voi è più meno la stessa cosa, infatti dopo aver letto una vostra discussione su un determinato argomento, poi andare ad approfondire presso altre fonti diventa più semplice. :)
SilverXXX
08-07-2005, 12:08
La sicurezza è molto relativa a come sono configurati i sistemi (un sistema ben configurato è sicuro, uno configurato male non lo è, a prescindere da win o *nix ). E c'entra poco con l'intervista :D
@ fek e Yossarian:
Complimenti... ogni volta che nasce una discussione tecnica per me, è sempre un piacere stare a leggere.
Potrei dire che è quasi come seguire una lezione all'uni, durante la quale ascoltando il prof poi è molto più semplice studiare sui libri. Con voi è più meno la stessa cosa, infatti dopo aver letto una vostra discussione su un determinato argomento, poi andare ad approfondire presso altre fonti diventa più semplice. :)
Troppo gentile :)
Io leggo quello che scrive yoss, assimilo, poi quando mi capita di parlare con NVIDIA e ATI in un qualche meeting faccio i figuroni e fra me e me penso: "se so come funziona una crossbar lo devo a yoss ihihi".
yossarian
08-07-2005, 13:31
Tu ti stai prendendo troppe liberta' :vicini:
:Prrr:
E' interessante anche il commento di Kirk riguardo all'R500 usato principalmente come pixel processor, calcolando la geometria in uno dei core della CPU e spedendola attraverso il sistema di streaming dedicato alla GPU.
Così facendo non si otterrebbe un aumento esponenziale della potenza grafica ? L'R500 impegnato solo con i pixel senza perdere potenza per i vertex, interessante davvero questa visione. :eek:
E' interessante anche il commento di Kirk riguardo all'R500 usato principalmente come pixel processor, calcolando la geometria in uno dei core della CPU e spedendola attraverso il sistema di streaming dedicato alla GPU.
Questa è un'operazione che a quanto so viene effettuata anche oggi con alcune GPU NVIDIA. I prossimi driver ForceWare dovrebbero appunto ottimizzare le prestazioni con le CPU dual core proprio in questo ambito: fare elaborare le geometrie dai vertex shader tramite CPU.
Così facendo non si otterrebbe un aumento esponenziale della potenza grafica ? L'R500 impegnato solo con i pixel senza perdere potenza per i vertex, interessante davvero questa visione. :eek:
Esatto. Tra l'altro in un motore grafico con pipeline di tipo deferred shading R500 dovrebbe essere velocissimo in quanto, a parte la prima passata per inizializzare le z-buffer, le successive sono concentrate al 99% in operazioni sui pixel shaders.
Così facendo non si otterrebbe un aumento esponenziale della potenza grafica ? L'R500 impegnato solo con i pixel senza perdere potenza per i vertex, interessante davvero questa visione. :eek:
Ma da qualche parte i vertici devono essere generati e si tratterebbe di usare uno dei core della CPU per un'operazione per la quale le pipeline della GPU sarebbero piu' adatte. Non saprei, solo provando entrambi gli approcci si puo' dire dove e quando questa soluzione e' un vantaggio.
Questa è un'operazione che a quanto so viene effettuata anche oggi con alcune GPU NVIDIA. I prossimi driver ForceWare dovrebbero appunto ottimizzare le prestazioni con le CPU dual core proprio in questo ambito: fare elaborare le geometrie dai vertex shader tramite CPU.
Il principio e' il medesimo ma l'implementazione sull'X360 e' piu' interessante e non e' possibile replicarla su PC perche' richiede un supporto hardware.
L'idea e' di configuare alcune linee della cache della CPU non come cache, ma come memoria FIFO di transito diretto verso la GPU. Un core della CPU scrive un vertice nella memoria FIFO, la prende il primo vertice disponibile, e cosi' via.
Ma da qualche parte i vertici devono essere generati e si tratterebbe di usare uno dei core della CPU per un'operazione per la quale le pipeline della GPU sarebbero piu' adatte. Non saprei, solo provando entrambi gli approcci si puo' dire dove e quando questa soluzione e' un vantaggio.
Ieri leggevo una dichiarazione di un responsabaile del team Ninja, (Dead Or Alive 4 su 360), diceva che molti Team faticheranno ad usare tutti e 3 i core, e che uno basta e avanza :)
Penso che un core solo per la geometria garantisca già grandi cose :)
Ieri leggevo una dichiarazione di un responsabaile del team Ninja, (Dead Or Alive 4 su 360), diceva che molti Team faticheranno ad usare tutti e 3 i core, e che uno basta e avanza :)
Penso che un core solo per la geometria garantisca già grandi cose :)
"640k basteranno per tutti" :)
Dark Schneider
24-07-2005, 21:07
Un po' in ritardo, ma nelle settimane passate ho avuto troppo da fare.
Questo non mi ha impedito di leggere l'intervista a David Kirk.
Innanzitutto come persona mi piace un sacco, mi pare molto simpatica, disponibile e gentile.
Poi ha proprio ragione Corsini nell'introduzione: è in grado di spiegare in maniera davvero semplicissima anche i concetti più complessi.
Interessantissime le risposte all'Embedded Ram e alle schede unificate.
Praticamente ha escluso intanto l'uso di tale ram nei prossimi anni.
L'unica cosa che mi fa pensare è la risposta all'architettura unificata. Sinceramente a me piace e affascina moltissimo questo tipo di architettura. Però mi pare che voglia far capire che il prossimo chip video nVidia, NV50 non lo sarà in maniera hardware. :(
Oddio in realtà alla fine finchè non ci sono i risultati è inutile capire cosa è meglio. Però boh mi sa che sarò più curioso del chip Ati che di quello nVidia tra un anno. Mi sa.
In realtà si parla sempre di R500, però Kirk cita che ci vorrà del tempo prima di poter usufruire i benefici dell'architettura unificata e parla anche di chip video per console...dice che ha già più senso nelle console l'architettura unificata visto che cmq la console vive 5 anni. Un tempo molto lungo.
Questo mi fa pensare che è possibile che nemmeno Ati con R620 immetterà un chip video con architettura unificata in maniera hardware. Forse anche Ati per il PC inizialmente continuerà soluzioni non unificate...ma unificate solo nella programmazione, che è poi quello che è rischiesto.
Cmq ha dato una bella anticipazione in pratica. Il prossimo chip nVidia(sicuramente NV50) avrà 500 milioni di transistor. :D
Insomma chi vivrà vedrà. :)
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.