Vertex Shader (&pixel)

[nik666]

Originally posted by "yossarian"



I compilatori sono in linguaggio macchina, che poi i programmi vengano fatti in linguaggi strutturati è un altro discorso. Inoltre VS e PS vengono programmati tranquillamente in C. Un programma in linguaggio macchina è una sequenza di 0 e 1. Dovevi arrivare tu a dirci che è più comodo programmare in C++ o Visual C anzichè scrivere una sequenza di 0 e 1. A parte il fatto che un chip non vede neppure gli 0 e gli 1 ma semplicemente due livelli di tensione (alto a cui corrisponde 1 e basso a cui corrisponde 0), se proprio vogliamo essere pignoli. Solo gli ignoranti confondono i bit con i volt

"...A parte il fatto che un chip non vede neppure gli 0 e gli 1 ma semplicemente due livelli di tensione (alto a cui corrisponde 1 e basso a cui corrisponde 0), se proprio vogliamo essere pignoli. Solo gli ignoranti confondono i bit con i volt.."

E' incredibile quanto sei intelligente e sapiente !
Ne ho sentite molte ma così mai !!
0 ed 1 non esistono, servono solo per rappresentare lo stato di tensione si e no.

".I compilatori sono in linguaggio macchina.."
TUTTO è in linguaggio macchina

"... Un programma in linguaggio macchina è una sequenza di 0 e 1 .."

Quanto hai studiato per dire questo ?
Il linguaggio macchina NON è una sequenza di 0 e 1 !!!!!
Il LM è ad un livello sopra agli 0 e 1 !!!!
0 e 1 è ad un livello sopra di Corrente SI', corrente NO.

Ad ogni istruzione, tipo MOV, CALL, REPNZ etc.., corrisponde un microcodice stampato nel silicio, quello è e quello rimane.

Lascia perdere

[DoomIII]

Originally posted by "yossarian"



Scusa tanto ma continui a fare confusione con i concetti matematici. Sai cos'è una funzione? Come fai a continuare a parlare di istruzioni e funzioni tenendo separate le due cose? Un circuito è in grado di "vedere" solo diversi livelli di tensione e non altro (non è in grado di "capire" un'istruzione). Sai su quali principi si basa un'elaborazione digitale di un segnale? Sai cos'è un segnale e come si rappresenta analiticamente? Conosci le differenze tra funzione e processo? Hai vagamente idea di cosa siano una matrice, un vettore o un tensore? Non esiste un circuito per ogni funzione (staremmo freschi, altro che 120 mln di transistor ci vorrebbero). Sai cosa è un set di equazioni parametriche?
Ti ripeto l'invito: non parlare solo per sentito dire o per aver letto qualche articolo che, per quanto apparentemente approfondito, non può, per ovvie ragioni (chi scrive deve fare informazione e rivolgersi a tutti, compresi coloro che non sono addetti ai lavori o appassionati), entrare nel dettaglio di determinate cose. Tu continui a parlare di aspetto "puramente SW"; bene, sappi che il SW non può prescindere dal'aspetto HW; di conseguenza se non conosci la struttura HW e il modo di poter comunicare con essa non puoi nemmeno capire come funziona il SW.

forse non hai capito... non parlo certo di funzioni matematiche...
è ovvio che uso termini riassuntivi visto quello che dovrebbe essere il succo del discorso... mi sembra che alzi solo polvere perchè citi argomenti che poco c'entrano con il discorso principale... :o

ripeto nuovamente:
con il T&L/FF i programmatori possono solo richiamare funzioni parametrizzabili (NB: non intendo funzioni matematiche lol...).
Queste funzioni per essere eseguite hanno una diretta corrispondente fisica... cribbio!!!!! il T&L/FF ha funzioni che eseguono operazioni ,come ho già detto più volte, hard-coded.
I programmatori non hanno a disposizione le singole istruzioni perchè difatti l'architettura hw delle schede o meglio dei chip T&L/FF non consente l'astrazione di queste istruzioni... il loro utilizzo o processo diretto... difatto queste istruzioni non ci sono, ma come già detto all'n^ potenza i programmatori hanno un set predeterminato di funzioni disponibili e richiamabili nei loro programmi.

Con il 'discorso shader' i programmatori 'le funzioni' se le devono programmare ,scrivendo ovviamente codice, utilizzando le istruzioni facenti parti del set shaders.

tu stesso facendo il professore dici:

Originally posted by "yossarian"



Tu continui a parlare di aspetto "puramente SW"; bene, sappi che il SW non può prescindere dal'aspetto HW; di conseguenza se non conosci la struttura HW e il modo di poter comunicare con essa non puoi nemmeno capire come funziona il SW.

allora inizia tu a ragionare sul fatto che ho detto sopra ed a quella che è la differenza principale di programmazione tra FF e shaders... visto che appunto con le FF si richiamano funzioni e non si hanno a disposizione il tuo presunto set di istruzioni... poi ovviamente tu non rispondi più direttamente ma alzi fumo... questo è il punto... adesso a te... vero o falso? e perchè?

[yossarian]

Originally posted by "nik666"



"...A parte il fatto che un chip non vede neppure gli 0 e gli 1 ma semplicemente due livelli di tensione (alto a cui corrisponde 1 e basso a cui corrisponde 0), se proprio vogliamo essere pignoli. Solo gli ignoranti confondono i bit con i volt.."

E' incredibile quanto sei intelligente e sapiente !
Ne ho sentite molte ma così mai !!
0 ed 1 non esistono, servono solo per rappresentare lo stato di tensione si e no.

".I compilatori sono in linguaggio macchina.."
TUTTO è in linguaggio macchina

"... Un programma in linguaggio macchina è una sequenza di 0 e 1 .."

Quanto hai studiato per dire questo ?
Il linguaggio macchina NON è una sequenza di 0 e 1 !!!!!
Il LM è ad un livello sopra agli 0 e 1 !!!!
0 e 1 è ad un livello sopra di Corrente SI', corrente NO.

Ad ogni istruzione, tipo MOV, CALL, REPNZ etc.., corrisponde un microcodice stampato nel silicio, quello è e quello rimane.

Lascia perdere

Il tuo intervento è del tutto inutile. A meno che non intendi dimostrare di aver iniziato a seguire un corso di fondamenti di informatica (se così è hai ancora molto da studiare: se il linguaggio macchina è ad un livello superiore ai bit, per quale motivo si chiama LINGUAGGIO MACCHINA? E dove collochiamo i linguaggi assemblatori o assembler che dir si voglia?). Già il fatto che parli di corrente SI corrente NO così come pure di "microcodice stampato nel silicio (poi spiegherai come si fa a stampare qualcosa nel silicio, ammesso che tu sappia cosa sia il silicio), qualificano il tuo livello di preparazione, mentre il tuo modo di interloquire quantifica il tuo livello di intelligenza

[DoomIII]

Originally posted by "nik666"


...
...
Ad ogni istruzione, tipo MOV, CALL, REPNZ etc.., corrisponde un microcodice stampato nel silicio, quello è e quello rimane.

Lascia perdere

OK non scaldiamoci tanto... ho abbiamo bisogno anche noi di una ventolina??

Forse non è il caso di essere sottiliosi su certi termini... sono cmq nel linguaggio comune... un programmatore che dice: io programmo in C++ non dice mica un'eresia...

Quello che dici tu in ciò che ho quotato, ovviamente esatto, oltre alla CPU si applica anche alla GPU programmabile... voglio dire che con gli shaders si programma con il set di istruzioni della GPU per il quale c'è hard-coded(cmq set SIMD per gli shaders). (poi ok, c'è il discorso CG di nVidia e HLSL di Microsoft)

Con il vecchio T&L/FF invece l'hard-coded era/è a livello di funzioni... quelle che i programmatori avevano a sisposizione come set predefinito.

[yossarian]

Originally posted by "DoomIII"



forse non hai capito... non parlo certo di funzioni matematiche...
è ovvio che uso termini riassuntivi visto quello che dovrebbe essere il succo del discorso... mi sembra che alzi solo polvere perchè citi argomenti che poco c'entrano con il discorso principale... :o

ripeto nuovamente:
con il T&L/FF i programmatori possono solo richiamare funzioni parametrizzabili (NB: non intendo funzioni matematiche lol...).
Queste funzioni per essere eseguite hanno una diretta corrispondente fisica... cribbio!!!!! il T&L/FF ha funzioni che eseguono operazioni ,come ho già detto più volte, hard-coded.
I programmatori non hanno a disposizione le singole istruzioni perchè difatti l'architettura hw delle schede o meglio dei chip T&L/FF non consente l'astrazione di queste istruzioni... il loro utilizzo o processo diretto... difatto queste istruzioni non ci sono, ma come già detto all'n^ potenza i programmatori hanno un set predeterminato di funzioni disponibili e richiamabili nei loro programmi.

Con il 'discorso shader' i programmatori 'le funzioni' se le devono programmare ,scrivendo ovviamente codice, utilizzando le istruzioni facenti parti del set shaders.

tu stesso facendo il professore dici:


allora inizia tu a ragionare sul fatto che ho detto sopra ed a quella che è la differenza principale di programmazione tra FF e shaders... visto che appunto con le FF si richiamano funzioni e non si hanno a disposizione il tuo presunto set di istruzioni... poi ovviamente tu non rispondi più direttamente ma alzi fumo... questo è il punto... adesso a te... vero o falso? e perchè?

Veramente sei tu che continui a non rispondere alle domande. Dici che alzo fumo e che quello che dico non c'entra niente con l'argomento principale? E quest'argomento sarebbe costituito da funzioni non matematiche (ma di non precisata natura) che sarebbero eseguite da strutture fisiche rigide, preposte ognuna a "rispondere ad un determinato input".
Continui a parlare di FF paragonandole, metaforicamente, a bottoni che vengono spinti in una sorta di meccanismo di azione/reazione, differenziandole dagli shader (che quindi non sarebbero soggetti ad un tale tipo di meccanismo). Peccato che non esista un circuito "intelligente", ma si basino tutti sul meccanismo input/output (ti sembrerà strano ma anche gli studi sull'IA si scontrano con questo principio limitante e persino il cervello umano non sfugge a questa legge). I programmi non sono altro che istruzioni e rappresentano funzioni matematiche, in forma più o meno complessa, tradotte in un linguaggio tale da poter essere compresi da un circuito. Gli shader non fanno eccezione. Ovviamente, a seconda dell'output che vogliamo ottenere dovremo scrivere l'input in un determinato modo e disegnare il circuito in modo tale che possa soddisfare le aspettative. Il funzionamento di un chip dipende in primo luogo dalla sua struttura fisica, in secondo luogo da come questa struttura è fatta funzionare (HDL). I componenti del circuito fisico si basano su principi ben determinati (un transistor un mosfet, una resistenza un codensatore, un diodo, non funzionano diversamente se il programma è una funzione trascendente o lineare; può accadere che un determinato circuito possa funzionare solo con la seconda e non con la prima, ma difficilmente si progetta un circuito in grado di funzionare solo con funzioni complicate).

Vorrei invitarti a fare degli esempi di FF hard coded (e poi a contare quanti ne vengono fuori e, di conseguenza, quanti circuiti servono per far funzionare un chip). Ti faccio presente che, col tuo esempio, che prescinde dall'uso di funzioni matematiche, una semplice operazione di scaling equivale a infinite istruzioni (una per ogni distanza reciproca tra i vertici di ogni singolo triangolo)

[Hanamichi]

venghino signori e signori a capire finalmente cosa sono in realta i pixel e vertex shader! :o
ma perchè fate tutto sto casino? solo per dire che nvidia è meglio di ati?

[yossarian]

Originally posted by "Hanamichi"

venghino signori e signori a capire finalmente cosa sono in realta i pixel e vertex shader! :o
ma perchè fate tutto sto casino? solo per dire che nvidia è meglio di ati?

Oddio, questo dovresti chiederlo a DoomIII che ha preso così a cuore questi benedetti shader (manco fossero un suo brevetto) e l'NV30 (manco fosse un suo prodotto)

[Hanamichi]

Originally posted by "yossarian"



Oddio, questo dovresti chiederlo a DoomIII che ha preso così a cuore questi benedetti shader (manco fossero un suo brevetto) e l'NV30 (manco fosse un suo prodotto)

ma nn ho capito quale diavolo è il problema!!! forse gli shader ++ di NVIDIA?

[pandyno]

Originally posted by "Hanamichi"



ma nn ho capito quale diavolo è il problema!!! forse gli shader ++ di NVIDIA?

Le istruzioni ++ di nvidia e le +++ di ATI e poi si ricomincia il giro

[Hanamichi]

Originally posted by "pandyno"



Le istruzioni ++ di nvidia e le +++ di ATI e poi si ricomincia il giro

ah ho capito...


LO VOLETE CAPIRE CHE è INUTILE PARLARE DI STE COSE? ++ o -- è uguale! TANTO NN LE USERANNO MAI! perchè usare delle direct x che verranno usate da poche schede? tanto vale basarsi sugli standard delle direct x 9!

scusate lo sfogo

[yossarian]

Originally posted by "Hanamichi"



ah ho capito...


LO VOLETE CAPIRE CHE è INUTILE PARLARE DI STE COSE? ++ o -- è uguale! TANTO NN LE USERANNO MAI! perchè usare delle direct x che verranno usate da poche schede? tanto vale basarsi sugli standard delle direct x 9!

scusate lo sfogo

In realtà il tutto era nato perchè DoomIII sosteneva che l'architettura dell'NV30 non si adatta bene alle applicazioni DX7 poichè ha una particolare architettura "shader oriented", mentre invece l'R300 è più veloce con le attuali applicazioni perchè ha un'architettura più tradizionale.
Ho cercato di farmi spiegare come, secondo lui, l'NV30 riesca a funzionare con applicazioni DX7 (visto che sostiene che un'architettura shader oriented è incompatibile con le FF); mi sarebbe piaciuto anche sapere come fanno tutte le architetture vecchie (non tipo NV30) a funzionare con gli shader (mi pare che l'R300 se la cavi fin troppo bene con PS e VS, pur non avendo (?) un'architettura ad hoc). Ho tentato di farmi spiegare cosa siano queste FF (che non sono funzioni matematiche ma, come ha detto qualcuno, stampate nel silicio. Infine ho tentato di farmi spiegare cosa siano questi shader, ma le uniche cose che sono emerse sono che si tratta di programmi ma anche di particolari circuiti (non si sa bene se stampati o meno nel silicio, stavolta o da qualche altra parte, forse sul giornale) che permettono una programmazione illimitata della GPU e non sono compatibili con le FF (pare che dia errore). Poi è arrivato qualcun altro che ha tentato disperatamente di comunicare che è meglio programmare usando un linguaggio strutturato piuttosto che i bit (che non sono linguaggio macchina, perchè quello è ad un livello superiore e sotto ai bit ci sono le correnti (del golfo)).
Infine sei arrivato tu e hai chiesto di cosa stessimo parlando, affermando, inoltre che erano discorsi inutili perchè tanto le estensione DX+++++ non saranno mai usate (e hai ragione).
Insomma ti sembra che ti si possano dare spiegazioni?

Sono stato chiaro?

[Mecoita]

kirk tempo fa disse che le le FF delle dx7 erano gestite come un vertex program

[DoomIII]

allora, brevemente l'argomento è questo:
fisicamente T&L/FF e shaders non sono direttamente compatibili e nel NV20 ne era stato incluso il core per compatibilità.

Per i programmatori si tratta di scegliere se programmare in FF o sfruttando gli shader.

Programmando con le vecchie pipeline (FF) si tratta di richiamare funzioni hard-coded(codificate nel silicio). Schede grafiche con chip T&L/FF(Fixed Function) 'danno a disposizione' degli sviluppatori un set fisso di funzioni parametrizzabili e richiamabili per ottenere "l'accellerazione" di appunto Trasform e Lighting... cioè operazioni ai vertici.
Ripetendo queste operazioni ai vertici sono fisse cioè tramite una funzione si può richiamare un tipo di operazione.

Con una GPU programmabile e parliamo di shaders, i programmatori hanno a disposizione un linguaggio di programmazione o meglio un set di istruzioni (SIMD) tramite le quali comporre la funzione che gli serve.

(Lo stesso discorso vale per il multitexturing sostituito dal pixel shaders)


Le 2 cose non sono direttamente compatibili e cioè a differenza di quanto cerchi di sostenere yossarian gli shader non sono un'estensione compatibile delle FF.
Secondo yossarian gli shader sono le FF + altre funzioni... questo non è vero poichè programmando gli shader non si possono richiamare anche le funzioni T&L.
Un programmatore decide se programmare a mezzo di FF o shader(o in entrambi i modi andando a fare un test sull'hw in modo che se non c'è GPU-programmabile venga utilizzato il T&L/FF). Il codice in questo caso è diverso e non compatibile.


La programmazione FF è caraterizzata dal richiamo di funzioni o macrofunzioni preimpostate... e difatti si programma il gioco ma non la funzione che appunto esiste già e la si può solo richiamare.
Con gli shader invece anche la funzione va programata poichè appunto esiste una GPU programmabile che da a disposizione del programmatore un set di istruzioni con il quale lo stesso può comporre dei programmi(o funzioni che dir si voglia...) con i quali 'processare' i vertici (o i pixel/texel nel Pixel shader).

P.S.
ovviamente penso basti fare una qualsiasi ricerca su internet sull'argomento per vedere le differenze tra FF e Shaders.

[yossarian]

Originally posted by "Mecoita"

kirk tempo fa disse che le le FF delle dx7 erano gestite come un vertex program

Stai parlando di David Kirk, presumo.
E' quello che stavo cercando di spiegare a DoomIII. Un chip in grado di operare con funzioni più complicate, ossia dotato di una maggior flessibilità in fatto di programmazione, è in grado, altresì, di gestire anche le funzioni semplici, come quelle lineari, al pari delle altre. Ovviamente sarà diverso l'approccio, poichè utilizzerà algoritmi che siano compatibili anche con le funzioni non lineari. In parole povere, esistono tanti modi per rappresentare una retta o definire un punto nello spazio: un chip in grado di operare solo con le FF lavorerà esclusivamente con funzioni di primo grado (e neanche con tutti i tipi) e solo con quelle e utilizzerà, per rappresentare una retta, la sua equazione geometrica (ovviamente traducendo il funzionamento di un chip in un linguaggio più comprensibile a noi), lavorando con parametri rappresentati dai coefficienti dell'equazione della stessa retta e dall'eventuale termine noto: Ad un livello superiore, possiamo pensare a rappresentare una retta mediante, ad esempio, la formula di Taylor (tanto per dirne una), fermandosi alle derivate del primo ordine. Ovviamente nel caso della retta si riotterrà l'equazione stessa della retta, così com'è; il vantaggio è che attraverso lo stesso procedimento si possono ottenere svariate altre funzioni non lineari, con approssimazione tanto migliore quanto più si riduce il resto (o errore). Quindi, all'atto pratico, quelle che erano considerate FF sono di fatto un vertex program (solo più semplice). E' un po' come il rapporto tra spazio complesso e spazio reale. Noi siamo abituati a rappresentare il secondo in un determinato modo (e a considerarlo in un determinato modo), semplicemente perchè facciamo un'operazione di estrapolazione dallo spazio complesso. Nel momento in cui operiamo con lo spazio complesso quella che cambia è semplicemente la rappresentazione dello spazio reale (che non diventa un'altra cosa, addirittura incompatibile con quanto è in un riferimento diverso).

[yossarian]

Originally posted by "DoomIII"

allora, brevemente l'argomento è questo:
fisicamente T&L/FF e shaders non sono direttamente compatibili e nel NV20 ne era stato incluso il core per compatibilità.

Per i programmatori si tratta di scegliere se programmare in FF o sfruttando gli shader.

Programmando con le vecchie pipeline (FF) si tratta di richiamare funzioni hard-coded(codificate nel silicio). Schede grafiche con chip T&L/FF(Fixed Function) 'danno a disposizione' degli sviluppatori un set fisso di funzioni parametrizzabili e richiamabili per ottenere "l'accellerazione" di appunto Trasform e Lighting... cioè operazioni ai vertici.
Ripetendo queste operazioni ai vertici sono fisse cioè tramite una funzione si può richiamare un tipo di operazione.

Con una GPU programmabile e parliamo di shaders, i programmatori hanno a disposizione un linguaggio di programmazione o meglio un set di istruzioni (SIMD) tramite le quali comporre la funzione che gli serve.

(Lo stesso discorso vale per il multitexturing sostituito dal pixel shaders)


Le 2 cose non sono direttamente compatibili e cioè a differenza di quanto cerchi di sostenere yossarian gli shader non sono un'estensione compatibile delle FF.
Secondo yossarian gli shader sono le FF + altre funzioni... questo non è vero poichè programmando gli shader non si possono richiamare anche le funzioni T&L.
Un programmatore decide se programmare a mezzo di FF o shader(o in entrambi i modi andando a fare un test sull'hw in modo che se non c'è GPU-programmabile venga utilizzato il T&L/FF). Il codice in questo caso è diverso e non compatibile.


La programmazione FF è caraterizzata dal richiamo di funzioni o macrofunzioni preimpostate... e difatti si programma il gioco ma non la funzione che appunto esiste già e la si può solo richiamare.
Con gli shader invece anche la funzione va programata poichè appunto esiste una GPU programmabile che da a disposizione del programmatore un set di istruzioni con il quale lo stesso può comporre dei programmi(o funzioni che dir si voglia...) con i quali 'processare' i vertici (o i pixel/texel nel Pixel shader).

P.S.
ovviamente penso basti fare una qualsiasi ricerca su internet sull'argomento per vedere le differenze tra FF e Shaders.

Mi sa che non hai capito niente di quello che ho detto finora.
Ci sono vari modi di arrivare allo stesso risultato. Negli attuali chip non esiste un circuito FF. I programmatori possono programmare come vogliono, poichè tra SW e chip esistono altre interfacce (HDL e drivers, oltre alle stesse DX o OpenGL che dir si voglia).
Puoi fare tutte le ricerche che vuoi e non troverai da nessuna parte che sull'R300 ci siano pipelines FF (così come non ci sono sullNV25).
Poi ti sarei grato se rispondessi a qualcuna delle domande che ti si fanno, visto che mi accusi di glissare le tue. Ad esempio, specifica la natura delle macrofunzioni di cui parli (visto che non si tratta di funzioni matematiche). Hai sostenuto che l'architettura dell'NV30 è superiore e più avanzata; ti ho chiesto perchè allora è uscito overclockato di fabbrica e non hai risposto. E potrei andare avanti ancora per molto ma non ne vale la pena. Ti ho già detto che se si andasse sul piano tecnico non ci capiresti molto (l'hai trovato divertente ma non era una battuta).
Puoi tranquillamente restare con le tue convinzioni, tanto sinceramente la cosa non mi interessa e questa discussione, oltre che sterile, sta diventando noiosa.

Ciao

[yossarian]

Originally posted by "DoomIII"

allora, brevemente l'argomento è questo:
fisicamente T&L/FF e shaders non sono direttamente compatibili e nel NV20 ne era stato incluso il core per compatibilità.

Per i programmatori si tratta di scegliere se programmare in FF o sfruttando gli shader.

Programmando con le vecchie pipeline (FF) si tratta di richiamare funzioni hard-coded(codificate nel silicio). Schede grafiche con chip T&L/FF(Fixed Function) 'danno a disposizione' degli sviluppatori un set fisso di funzioni parametrizzabili e richiamabili per ottenere "l'accellerazione" di appunto Trasform e Lighting... cioè operazioni ai vertici.
Ripetendo queste operazioni ai vertici sono fisse cioè tramite una funzione si può richiamare un tipo di operazione.

Con una GPU programmabile e parliamo di shaders, i programmatori hanno a disposizione un linguaggio di programmazione o meglio un set di istruzioni (SIMD) tramite le quali comporre la funzione che gli serve.

(Lo stesso discorso vale per il multitexturing sostituito dal pixel shaders)


Le 2 cose non sono direttamente compatibili e cioè a differenza di quanto cerchi di sostenere yossarian gli shader non sono un'estensione compatibile delle FF.
Secondo yossarian gli shader sono le FF + altre funzioni... questo non è vero poichè programmando gli shader non si possono richiamare anche le funzioni T&L.
Un programmatore decide se programmare a mezzo di FF o shader(o in entrambi i modi andando a fare un test sull'hw in modo che se non c'è GPU-programmabile venga utilizzato il T&L/FF). Il codice in questo caso è diverso e non compatibile.


La programmazione FF è caraterizzata dal richiamo di funzioni o macrofunzioni preimpostate... e difatti si programma il gioco ma non la funzione che appunto esiste già e la si può solo richiamare.
Con gli shader invece anche la funzione va programata poichè appunto esiste una GPU programmabile che da a disposizione del programmatore un set di istruzioni con il quale lo stesso può comporre dei programmi(o funzioni che dir si voglia...) con i quali 'processare' i vertici (o i pixel/texel nel Pixel shader).

P.S.
ovviamente penso basti fare una qualsiasi ricerca su internet sull'argomento per vedere le differenze tra FF e Shaders.

Sull'NV20 ti ho già risposto; pazienza, lo faccio di nuovo: il problema non era la compatibilità ma il fatto che era presente una sola unità VS; questo, in alcuni casi, avrebbe rallentato l'elaborazione rispetto ad un motore FF o avrebbe obbligato i tecnici nVIDIA a scrivere drivers specifici che facessero da interfaccia tra chip e SW (e all'epoca non valeva la pena, poichè i SW che facevano uso di VS erano pressochè prossimi allo zero): In altre parole l'NV20 è stato un esperimento; già nell'NV25, con 2 motori VS e drivers ad hoc, il motore FF era sparito.

Accelerazione si scrive con una l (te lo segnalo perchè è un errore tipico di molti di coloro che non hanno fatto studi tecnici)

I PS non hanno sostituito il multitexturing che vuol semplicemente dire "applicazione di più textures su un singolo pixel", e non specifica la natura delle textures in questione.

Con questo, per quanto mi riguarda, ho esaurito l'argomento, anche perchè, come ho già detto, questa discussione sta diventando troppo ripetitiva e di conseguenza noiosa.

Con questo ti saluto

[AMDman]

secondo me da quello che ho capito.. e vedendo la cosa da un altro punto di vista... mi meraviglierei che nvidia pensasse a fare un chip così avanzato da poterlo paragonare "il fururo della grafica" quando poi è stata sempre nvidia a sfornare chipset (e driver ) con un esagerata ottimizzazzioni per gli attuali titoli in commercio..

anche ati ha sempre sviluppato tecnologie nuove come il keyframe interpolation ecc.. all'epoca dell'Radeon256 che competeva con il GTS che all'epoca aveva la peggior qualità 2d (ATI e suoi colori ) la peggior qualità d'immagine in 3d (ricordatevi la l''AA dell'altro concorrente Voodoo5) però aveva maggiore velocità.. quindi io ho sempre visto nvidia dalla parte della "praticità"

a questo mi punto mi chiedo.. perchè ,visto il modo di fare di nvidia, dovremmo credere che abbia fatto un chip così tecnologicamente avanzato da non essere apprezzato per quello che è attualmente.. e poi io penso che la tecnologia e una cosa che serve al presente e non ad un funturo che verrà....

ciao

[yossarian]

Originally posted by "AMDman"

secondo me da quello che ho capito.. e vedendo la cosa da un altro punto di vista... mi meraviglierei che nvidia pensasse a fare un chip così avanzato da poterlo paragonare "il fururo della grafica" quando poi è stata sempre nvidia a sfornare chipset (e driver ) con un esagerata ottimizzazzioni per gli attuali titoli in commercio..

anche ati ha sempre sviluppato tecnologie nuove come il keyframe interpolation ecc.. all'epoca dell'Radeon256 che competeva con il GTS che all'epoca aveva la peggior qualità 2d (ATI e suoi colori ) la peggior qualità d'immagine in 3d (ricordatevi la l''AA dell'altro concorrente Voodoo5) però aveva maggiore velocità.. quindi io ho sempre visto nvidia dalla parte della "praticità"


a questo mi punto mi chiedo.. perchè ,visto il modo di fare di nvidia, dovremmo credere che abbia fatto un chip così tecnologicamente avanzato da non essere apprezzato per quello che è attualmente.. e poi io penso che la tecnologia e una cosa che serve al presente e non ad un funturo che verrà....

ciao

Anche nVIDIA ha introdotto importanti novità e si è fatta promotrice, insieme a S3 di una battaglia per poter arrivare ad ottennere che l'intero processo di creazine di scenari 3D fosse interamente a carico della scheda video (ipotesi a cui si sono sempre opposti AMD e Intel e che ha visto Microsoft, con le sue DX, stare nella posizione intermedia di quello che dà un colpo alla botte ed uno al cerchio.
Però come hai giustamente detto e come ha sostenuto anche qualcun altro (non ricordo chi, purtroppo), l'NV30, se da un lato propone delle interessanti novità, almeno nelle intenzioni, dall'altro denuncia vizi dovuti a scelte conservative (tipiche, quando si parla di architettura HW, di nVIDIA) e cioè le 4 pipelines e il bus a 128 bit.
La tecnologia deve servire all'oggi, con uno sguardo al futuro e, da questo punto di vista, l'NV30 non è la rivoluzione che hanno voluto far credere (ma i primi a non crederci sono stati proprio quelli di nVIDIA, come testimoniano tutta una serie di scelte quantomeno discutibili: dall'overclock di fabbrica ai drivers che peggioravano la qualità migliorando il framerate, all'abbandono definitivo, con l'NV35, almeno del bus a 128 bit).
Inoltre, come ha detto Hanamici, non solo le estensioni DX+++++ non saranno mai usate, ma queste attuali schede video, pur essendo sulla carta full DX9, avrebbero seri problemi a far girare fluidamente un'applicazione realmente DX9 (magari con l'applicazione di 16 textures per pixel p.s.p.); e questo vale per l'NV30, per l'NV35, per l'R300 e per l'R350, senza distinzione

[DoomIII]

no, è sbagliato quanto yossarian continua testardamente ad insinuare.

Funzioni matematiche semplici... complicate e bla bla bla ecc... ecc...
non c'entrano niente... queste sono corrispondenti di istruzioni... istruzioni disponibili ai programmatori tramite gli shader , o meglio il set di istruzioni della GPU...
con queste istruzioni si scrivono programmi per eseguire FUNZIONI o Programmi o algoritimi o chiamali come vuoi che sono tutti in questo caso sinonimi ma non confondiamoli ignorantemente con le funzioni matematiche. (NB: pensavo tu scherzassi e lo facessi apposta e confondere le funzioni matematiche con quelle che sono funzioni di un programma... invece mi sa che fai confusione d'avvero)

Allora diciamo che con le FF si hanno a disposizione dei comandi che eseguono degli algoritmi FISSI e preimpostati per i quali ci sono dei diretti circuiti che li eseguono... tanto che i programmatori non posson fare altro che richiamare questi algoritmi con l'apposito comando. (in realtà per un programmatore si tratta appunto di richiamare una funzione... ma visto che il caro amico fa confusione... cambiamo termine )

Con gli shader si ha a disposizione un set di istruzioni con le quali programmare l'algoritmo che serve o si vuole realizzare.

ES:
il lighting è stato sfruttato poco o niente proprio per questo motivo... trattandosi di FF le operazioni erano fisse... e spesso non soddisfacevano gli sviluppatori poichè non erano corrispondenti all'effetto che volevano realizzare... quindi non gli restava altro ,se volevano ottenere l'effetto, che scrivere una funzione... ehhh, una sequenza di istruzioni per eseguire un'operazione, da far eseguire ovviamente alla CPU (con ovvi cali di performance). Con gli shader invece possono scrivere codice per ottenere l'effetto che vogliono via GPU.


P.S.
Vi ricordo infatti che nel NV20 oltre agli shader c'era anche l'unita hw T&L del NV15 inclusa proprio per compatibilità.

[yossarian]

Originally posted by "DoomIII"

no, è sbagliato quanto yossarian continua testardamente ad insinuare.

Funzioni matematiche semplici... complicate e bla bla bla ecc... ecc...
non c'entrano niente... queste sono corrispondenti di istruzioni... istruzioni disponibili ai programmatori tramite gli shader , o meglio il set di istruzioni della GPU...
con queste istruzioni si scrivono programmi per eseguire FUNZIONI o Programmi o algoritimi o chiamali come vuoi che sono tutti in questo caso sinonimi ma non confondiamoli ignorantemente con le funzioni matematiche. (NB: pensavo tu scherzassi e lo facessi apposta e confondere le funzioni matematiche con quelle che sono funzioni di un programma... invece mi sa che fai confusione d'avvero)

Allora diciamo che con le FF si hanno a disposizione dei comandi che eseguono degli algoritmi FISSI e preimpostati per i quali ci sono dei diretti circuiti che li eseguono... tanto che i programmatori non posson fare altro che richiamare questi algoritmi con l'apposito comando. (in realtà per un programmatore si tratta appunto di richiamare una funzione... ma visto che il caro amico fa confusione... cambiamo termine )

Con gli shader si ha a disposizione un set di istruzioni con le quali programmare l'algoritmo che serve o si vuole realizzare.

ES:
il lighting è stato sfruttato poco o niente proprio per questo motivo... trattandosi di FF le operazioni erano fisse... e spesso non soddisfacevano gli sviluppatori poichè non erano corrispondenti all'effetto che volevano realizzare... quindi non gli restava altro ,se volevano ottenere l'effetto, che scrivere una funzione... ehhh, una sequenza di istruzioni per eseguire un'operazione, da far eseguire ovviamente alla CPU (con ovvi cali di performance). Con gli shader invece possono scrivere codice per ottenere l'effetto che vogliono via GPU.


P.S.
Vi ricordo infatti che nel NV20 oltre agli shader c'era anche l'unita hw T&L del NV15 inclusa proprio per compatibilità.

Tutto quanto hai citato, parametri, algoritmi, funzioni (FF) o funzioni di programma o come le vuoi chiamare, ha a che fare con la matematica. La famosa unità T&L HW non è stata inclusa nell'NV25 né nell'R300, né nell'NV30: vuol dire che su questi chip non girano giochi DX7?
Quando in un linguaggio strutturato chiami la funzione (di programmazione) cos(x), o SQR(X), di cosa credi si tratti? Chiamale funzioni preimpostate ma ti assicuro che lo stesso calcolo si può fare in tanti modi diversi, e sempre di funzioni matematiche si tratta. Ora le FF fanno riferimenti a vertici e triangoli (sai perchè si sono scelti i triangoli e non, ad esmpio, gli esagoni e i pentagoni regolari come sui palloni da calcio?); vuoi che non siano funzioni matematiche?

Comunque ti ringrazio per avermi chiarito determinati concetti. Pensavo di avere una certa familiarità con essi, sai com'è, dato anche il lavoro che facevo fino a un po' di mesi fa. Ma evidentemente mi sbagliavo, si vede che ci avevo sempre capito poco