Vertex Shader (&pixel)

[DoomIII]

continuo qui una discussione inizata su un altro post e rispondo tra gli altri a yossarian.... quoto e rispondo riassumento l'argomento come shader poichè sono state dette alcune inesattezze

(ultimamente per motivo vari non ho avuto occasione di leggere e continuare la discussione quindi lo riprendo qui)

Originally posted by "yossarian"

Per DoomIII
Vorrei chiarire (se mi riesce), la questione su cosa sono questi benedetti shader di cui si parla tanto (forse pure troppo).
I chip fino alla generazione DX7 non avevano unità per il calcolo dei vertici ma solo pipelines per l'applicazione delle textures. Queste pipelines erano strutturate in modo da poter eseguire solo determinate operazioni in virgola fissa.

hmm... ti riferisci al multitexturing? (DX 6 e 7) per cronaca trattasi di fixed-function poi sostituite da pixel-shader(dal NV20 Dx8) che rappresentano un unità programmabile che opera appunto a livello di pixel.

ad ogni modo la tua affermazione è sbagliata poichè da DX7 era inclusa un unità che operava sui vertici e questo è il T&L. Si tratta di fixed-function parametrizzabili che operano appunto sui vertici e permettono di ottenere in maniera veloce (a carico della GPU) le basilari operazioni di traformazione ed illuminazione. Precedentemente questo carico era della CPU mentre dalle DX7 è passato a carico della GPU con il suo T&L.

Originally posted by "yossarian"


Col passaggo alla generazione DX8 le pipelines per l'elaborazione dei pixels sono state modificate e rese in grado di eseguire anche operazioni in virgola mobile, con una determinata approssimazione; di conseguenza è anche cresciuto il numero delle operazioni che queste pipelines erano in grado di compiere oltre, naturalmente, alla precisione di calcolo.

hmm... scusa ma il discorso è campato in aria... adesso capisco il tuo modo di vedere NV30 e l'R300...
questi numeri su cui ti fissi hanno ben poco significato nel contesto... non è il poter eseguire i calcoli in virgola mobile o meno a fare la differenza tra fixed-function o shader...
Dalle Dx8 (Nv20) è stata sviluppata una vera GPU programmabile che sostituisce e non è compatibile con la precedente architettura T&L(le fixed--function) per la parte vertici e multitexturing per i pixel o texel.
A motivo di questa incompatibilità nella Gef3 è stato incluso il motore T&L cioè le vecchie fixed-function o meglio il core NV15.

Originally posted by "yossarian"



Questa però non rappresenta una particolare innovazione, ma semplicemente un'evoluzione della precedente generazione di pipelines. La vera novità è stata l'introduzione di una pipeline (nell'NV20) per il calcolo dei vertici, operazione che prima era eseguita dalla cpu.

il calcolo dei vertici era possibile farlo eseguire dalle schede grafiche proprio tramite il T&L cioè le fixed-function... dall'NV20 invece con gli shader si è iniziato a parlare di programmabilità.
Quindi punto di forze del Geforce(DX7) è stato proprio il passaggio da cpu e gpu per i calcoli ai vertici(cioè le trasformazioni T&L a mezzo di fixed-function).

Originally posted by "yossarian"

Si è quindi iniziato a parlare di PS e VS che altro non sono se non i programmi a basso livello delle pipelines che si occupano di textures e vertici. I giochi DX6 o DX7 che non avevano il supporto VS, continuavano ad utilizzare, per il calcolo dei vertici, la cpu; pertanto l'unità VS restava inoperosa.
Con la successiva generazione, si è abbandonato definitivamente il supporto al TL "statico".

dipende dai punti di vista... a livello software OK, i PS e VS sono programmi ma non assolutamente delle pipelines...
a livello hardware sono circuiti come quelli che si trovano nella CPU e proprio per questo si parla di vera GPU poichè è programmabile.
Non ci sono le fixed-function ma circuiti che permettono l'esecuzione di istruzioni... queste istruzioni operano sui vertici (Vertex-shader) o sui pixel(Pixel-shader) e la sequenza di questa istruzioni determina il comportamento con infinite 'funzioni' finali... nel senso che a seconda del programma i programmatori ottengono quello che vogliono.... mentre con le fixed-function le funzioni erano appunto fisse mentre adesso con gli shader queste funzioni vanno programmate.

Originally posted by "yossarian"


Questo non vuol dire che le schede video di questa e delle generazioni future non sono compatibili con le DX6 o le 7; significa semplicemente una maggior flessibilità di calcolo da parte delle pipelines deputate al calcolo delle textures che sono in grado di eseguire sia le fixed function che quelle "programmabili"; per quanto riguarda i vertex engine, ovviamente un gioco DX7 continuerà a non utilizzarli e a far ricorso alla cpu (con tutti i limiti qualitativi e velocistici che da ciò derivano).
Quindi non è assolutamente vero che un chip più è avanzato e più ha problemi con il SW vecchio, e noon è neppure vero che all'interno degli attuali chip (escluso l'NV30 a sentire Doom III) ci siano una o più unità TL "statiche". Insomma, una situazione del tipo R300 con 8 unità PS, 4 unità VS, 8 pipelines TL statiche, ossia 8 unità TL, è del tutto improponibile.

un gioco DX7 non farà ricorso alla CPU ma al T&L cioè i circuiti fixed-function presenti nella scheda... e come ho già detto dal Gef3 (NV20) è stato incluso per compatibilità il core NV15(T&L e multitexturing).

In realtà attualmente non c'è quasi niente che sfrutti gli shader... sopratutto i vertex-shader... per molto tempo non c'è stato niente e pur avvantaggiandosi della nuova architettura (frequenze maggiori, ottimizzazioni ecc...) ottentendo performance più elevate il software continuava ad essere T&L ed a non sfruttare gli shader. Col tempo alcuni titoli hanno inizato a sfruttare parzialmente gli shader... i vertex shader con semplice conversione di fixed-function a programma shader equivalente ed i pixel shader per ottenere alcuni effetti in più non disponibili a chi non aveva l'hw adeguato.
Ad oggi la situazione non è cambiata di molto e titoli shader-oriented sono ancora purtroppo solo prossimi e futuri...



Saluti

[DoomIII]

hmm.... uppete che nn so se yossarian ha letto

[yossarian]

Originally posted by "DoomIII"

continuo qui una discussione inizata su un altro post e rispondo tra gli altri a yossarian.... quoto e rispondo riassumento l'argomento come shader poichè sono state dette alcune inesattezze

(ultimamente per motivo vari non ho avuto occasione di leggere e continuare la discussione quindi lo riprendo qui)




hmm... ti riferisci al multitexturing? (DX 6 e 7) per cronaca trattasi di fixed-function poi sostituite da pixel-shader(dal NV20 Dx8) che rappresentano un unità programmabile che opera appunto a livello di pixel.

ad ogni modo la tua affermazione è sbagliata poichè da DX7 era inclusa un unità che operava sui vertici e questo è il T&L. Si tratta di fixed-function parametrizzabili che operano appunto sui vertici e permettono di ottenere in maniera veloce (a carico della GPU) le basilari operazioni di traformazione ed illuminazione. Precedentemente questo carico era della CPU mentre dalle DX7 è passato a carico della GPU con il suo T&L.





hmm... scusa ma il discorso è campato in aria... adesso capisco il tuo modo di vedere NV30 e l'R300...
questi numeri su cui ti fissi hanno ben poco significato nel contesto... non è il poter eseguire i calcoli in virgola mobile o meno a fare la differenza tra fixed-function o shader...
Dalle Dx8 (Nv20) è stata sviluppata una vera GPU programmabile che sostituisce e non è compatibile con la precedente architettura T&L(le fixed--function) per la parte vertici e multitexturing per i pixel o texel.
A motivo di questa incompatibilità nella Gef3 è stato incluso il motore T&L cioè le vecchie fixed-function o meglio il core NV15.


il calcolo dei vertici era possibile farlo eseguire dalle schede grafiche proprio tramite il T&L cioè le fixed-function... dall'NV20 invece con gli shader si è iniziato a parlare di programmabilità.
Quindi punto di forze del Geforce(DX7) è stato proprio il passaggio da cpu e gpu per i calcoli ai vertici(cioè le trasformazioni T&L a mezzo di fixed-function).


dipende dai punti di vista... a livello software OK, i PS e VS sono programmi ma non assolutamente delle pipelines...
a livello hardware sono circuiti come quelli che si trovano nella CPU e proprio per questo si parla di vera GPU poichè è programmabile.
Non ci sono le fixed-function ma circuiti che permettono l'esecuzione di istruzioni... queste istruzioni operano sui vertici (Vertex-shader) o sui pixel(Pixel-shader) e la sequenza di questa istruzioni determina il comportamento con infinite 'funzioni' finali... nel senso che a seconda del programma i programmatori ottengono quello che vogliono.... mentre con le fixed-function le funzioni erano appunto fisse mentre adesso con gli shader queste funzioni vanno programmate.



un gioco DX7 non farà ricorso alla CPU ma al T&L cioè i circuiti fixed-function presenti nella scheda... e come ho già detto dal Gef3 (NV20) è stato incluso per compatibilità il core NV15(T&L e multitexturing).

In realtà attualmente non c'è quasi niente che sfrutti gli shader... sopratutto i vertex-shader... per molto tempo non c'è stato niente e pur avvantaggiandosi della nuova architettura (frequenze maggiori, ottimizzazioni ecc...) ottentendo performance più elevate il software continuava ad essere T&L ed a non sfruttare gli shader. Col tempo alcuni titoli hanno inizato a sfruttare parzialmente gli shader... i vertex shader con semplice conversione di fixed-function a programma shader equivalente ed i pixel shader per ottenere alcuni effetti in più non disponibili a chi non aveva l'hw adeguato.
Ad oggi la situazione non è cambiata di molto e titoli shader-oriented sono ancora purtroppo solo prossimi e futuri...



Saluti

Punto primo: il TL DX7 opera sui vertici ma solo con operazioni di traslazione e rotazione e sulla costruzione dei poligoni. La differenza con un motore programmabile è che quest'ultimo è in grado di svolgere anche le operazioni suddette, oltre ad altre non previste dal T&L "statico".
Visto che parli di innovazioni portate da nVIDIA e di programmabilità (e dimostri di apprezzare queste cose), dovresti apprezzare il fatto che il Radeon 256 riproduceva funzioni, quali la keyframe interpolation e il morphing, proprie di un chip con motore VS e successivamente riprese e sviluppate da nVIDIA con l'NV20 (questo oltre ad avere la possibilità di applicare 3 textures psp ne facevano un chip che andava ben oltre le DX7, al contrario della GF2).
Per quale motivo un'unità VS non dovrebbe essere compatibile con le operazioni di rotazione e traslazione di un poligono?
Le funzioni finali ottenibili non sono infinite nel modo più assoluto. Un'nità "programmabile" non è altro che un'unità in grado di eseguire operazioni di tipo più complesso rispetto a semplici operazioni lineari, ma da qui a dire che le funzioni ottenibili sono infinite ce ne corre (salvo ricorrere all'utilizzo di algoritmi di interpolazione che permettono di APPROSSIMARE la quasi totalità delle funzioni, con perdita, però, di precisione).
La presunta inclusione del motore Fixed Function nell'NV20 non è altro che un'estensione delle operazioni che il motore VS è in grado di compiere: oltre alle operazioni di traslazione e rotazione (lineari) il motore VS dell'NV20 ne poteva compiere altre più complesse (di tipo non lineare). Quindi quanto sostieni sulla presunta incompatibilità non ha alcun senso. Nell'NV25, rispetto all'NV20 è stata aggiunta una seconda unità VS (identica alla prima).
Ps: fixed function sta a significare semplicemente che le operazioni svolte non modificano forma e dimensione dei triangoli (le operazioni di rotazione e traslazione si limitano ad effettuare delle operazioni di spostamento di un intero poligono senza modificare le posizioni dei vertici uno rispetto all'altro). Introducendo operazioni di trasformazione non lineare è possibile, invece, cambiare le posizioni dei vertici di un triangolo, modificando la forma del triangolo stesso (cosa che con le trasformazioni lineari non avviene. Un chip DX8 deve essere in grado di svolgere sia le operazioni lineari che quelle non lineari, pichè entrambe le categorie sono necessarie alla costruzione di una scena 3D).


P.s. mi pare che sei l'unico che ancora difenda la presunta superiorità dall'NV30 e speri ancora in una release di drivers che, miracolosamente, faccia andare l'FX molto più veloce senza abbassare la qualità (ormai pure nVIDIA ha smesso di credere in questo chip e sta già pensando a come sostituirlo nella maniera, per lei più indolore, con l'NV35).
Complimenti per la tenacia, un po' meno per la preparazione tecnica



Ciao

[yossarian]

Originally posted by "DoomIII"




un gioco DX7 non farà ricorso alla CPU ma al T&L cioè i circuiti fixed-function presenti nella scheda... e come ho già detto dal Gef3 (NV20) è stato incluso per compatibilità il core NV15(T&L e multitexturing).

In realtà attualmente non c'è quasi niente che sfrutti gli shader... sopratutto i vertex-shader... per molto tempo non c'è stato niente e pur avvantaggiandosi della nuova architettura (frequenze maggiori, ottimizzazioni ecc...) ottentendo performance più elevate il software continuava ad essere T&L ed a non sfruttare gli shader. Col tempo alcuni titoli hanno inizato a sfruttare parzialmente gli shader... i vertex shader con semplice conversione di fixed-function a programma shader equivalente ed i pixel shader per ottenere alcuni effetti in più non disponibili a chi non aveva l'hw adeguato.
Ad oggi la situazione non è cambiata di molto e titoli shader-oriented sono ancora purtroppo solo prossimi e futuri...



Saluti

quoto questa parte per mettere in evidenza il fatto che tu abbia poche idee (solo gli shader) ma ben confuse

Secondo te, allora, i giochi DX7 come girerebbero su chip DX9? In base al tuo discorso l'R300 o avrebbe solo pipelines fixed function o avrebbe un motore per il TL statico oltre alle unità PS e VS (stesso discorso per l'NV30, ovviamente). E magari con un "circuito discriminatore di DX"

Siamo seri



Pps visto che ti sei preso la briga di riaprire questa discussione, cerca un post in cui ti facevo una serie di domande, sull'NV30 e sul comportamento di nVIDIA, a cui ti sei ben guardato dal rispondere.

[DoomIII]

Originally posted by "yossarian"



Punto primo: il TL DX7 opera sui vertici ma solo con operazioni di traslazione e rotazione e sulla costruzione dei poligoni. La differenza con un motore programmabile è che quest'ultimo è in grado di svolgere anche le operazioni suddette, oltre ad altre non previste dal T&L "statico".

Bè, come punto primo già parti sbagliando
ricordiamo che per il T&L si tratta di operazioni hard-coded(codificate nel silicio quindi come si diceva macro funzioni per le quali esiste un corrispondente circuito fisico).
L'errore che fai è che un motore programmabile non può 'gestire' le Fixed-function o T&L statico... i 2 non sono compatibili.
Questo ovviamente non significa che un motore programmabile (gli shader) non possano adempiere agli stessi risultati... ma le operazioni sono diverse...
per le FF i programmatori parametrizzano e richiamano la funzione interessata(che per la scheda grafica significa: esegui questo circuito fisico)
Per gli shader significa che i programmatori devono scrivere un programma, cioè una sequenza di istruzioni (tra quelle a disposizione della GPU) per eseguire l'operazione richiesta.
Se ad una GPU programmabile (shader) arriva la chiamata ad una funzione FF(T&L) ... ERROR!!! non funziona, non è compatibile!!!
proprio per questo nella Gef3 è stato incluso per compatibilità il vecchio T&L/FF... cosa che chiunque può trovare facendo una ricersa su internet in merito al Gef3... quindi potresti farla anche tu evitando di scrivere qui tue teorie...

Sbagli totalmente quindi quando dici che il VS esegue le fuznioni FF più altre... il VS non esegue nessuna funzione me istruzioni, cioè programmi scritti nel linguaggio assembler della GPU... le funzioni poi dipendono dai programmatori che se le devono programmare.

P.S.
per il vecchio T&L/FF oltre a rotazione e traslazione non dimenticare l'illuminazione e poi ci sarebbero anche altre cosette...

Originally posted by "yossarian"


Visto che parli di innovazioni portate da nVIDIA e di programmabilità (e dimostri di apprezzare queste cose), dovresti apprezzare il fatto che il Radeon 256 riproduceva funzioni, quali la keyframe interpolation e il morphing, proprie di un chip con motore VS e successivamente riprese e sviluppate da nVIDIA con l'NV20 (questo oltre ad avere la possibilità di applicare 3 textures psp ne facevano un chip che andava ben oltre le DX7, al contrario della GF2).

veramente sto parlando di shader... e li reputo senz'altro una grande innovazione... e non sono l'unico a considerarla uno dei passi fondamentali nella computer-grafix.
cmq non sono proprie di un motore VS... è la programmabilità stessa del VS rende attuabile la keyframe-interpolation... il morphing ecc...
non ci sono ovviamente FF ad eseguire tali operazioni nel VS...

Originally posted by "yossarian"


Per quale motivo un'unità VS non dovrebbe essere compatibile con le operazioni di rotazione e traslazione di un poligono?

Stai facendo un po di confusione... se le operazioni di traslazione e rotazione sono richiamate nel programma tramite Fixed-Function un'unità VS non sa cosa farsene...
l'ho già detto le FF non sono compatibili con gli shaders... difatti le procedure sono parallele... se un gioco va in modalità T&L il VS è disabilitato e viceversa... sono fisicamente 2 blocchi di silicio diversi ed il T&L esiste solo per compatibilià e proprio perchè il VS non sa cosa farsene.
Quindi in un programma/gioco che utilizza gli shader le operazioni come traslazione e rotazione sono eseguite con programmi shader.

Originally posted by "yossarian"


Le funzioni finali ottenibili non sono infinite nel modo più assoluto. Un'nità "programmabile" non è altro che un'unità in grado di eseguire operazioni di tipo più complesso rispetto a semplici operazioni lineari, ma da qui a dire che le funzioni ottenibili sono infinite ce ne corre (salvo ricorrere all'utilizzo di algoritmi di interpolazione che permettono di APPROSSIMARE la quasi totalità delle funzioni, con perdita, però, di precisione).

logico... ma non credo serva fare cosi il puntiglioso... nemmeno sui PC con le CPU i programmi sono infiniti... però si può parlare genericamente di infinità poichè un programmatore si mette li e siccome ha la possibilità di programmare tramite istruzione può realizzare ciò che vuole. (logico +o- )
Questa è una delle principali differenze rispetto al T&L dove invece le possibilità erano fisse poichè i programmatori potevano solo richiamare funzioni già fatte per ottenere risultati/effetti prestabiliti.

Gli shader sono una GPU corrispondente ad una CPU... solo che le istruzioni che può eseguire sono pensate per la computer grafica con tutte le ottimizzazioni del caso per ottenere buone performance con la CG in real-time come obiettivo.

Il discorso invece sull'approssimazione non sta nè in cielo nè in terra e non c'entra proprio niente... la differenza tra FF e Shader e tutt'altra...

Originally posted by "yossarian"


La presunta inclusione del motore Fixed Function nell'NV20 non è altro che un'estensione delle operazioni che il motore VS è in grado di compiere: oltre alle operazioni di traslazione e rotazione (lineari) il motore VS dell'NV20 ne poteva compiere altre più complesse (di tipo non lineare). Quindi quanto sostieni sulla presunta incompatibilità non ha alcun senso.

Assolutamente no... il motore VS per esattezza non esegue operazioni di traslazione e rotazione... questo è il tuo modo di vedere le cose alla vecchia cioè sei rimasto di qualche anno indietro... questo si applica al T&L/FF dove si potevano/possono richiamare le funzioni per eseguire delle operazioni fisse o prestabilite ai vertici.
Con il VS si hanno delle istruzioni con le quali scrivere un programma con il quale ogni vertice viene poi processato (in pratica SIMD)... con la sequenza di queste istruzioni si possono realizzare N^ operazioni ai vertici tra le queli rotazioni ecc... ma è questione di programmazione.
ES:
A) equivalente di T&L/FF= esiste un programma il quale presenta alcuni bottoni e noi clikkando possiamo ottenere dei risultati, ad esempio clikkando il pulsante A otteniamo un messaggio a video "Ciao".

B) equivalente di 'Shader' = abbiamo un linguaggio di programmazione, questo non ci permette con un tasto di avere il messaggio a video però possiamo programmare e quindi fare quello che vogliamo... come ad esempio scrivere una sequenza di istruzioni che poi presenterà a video il messaggio "Ciao"



Spero sia chiaro...
con A) abbiamo dei bottoni esattamente come con il T&L/FF abbiamo delle funzioni richiamabili... quelle sono e quelle restano.
con B) possiamo programmare ed ottenere l'effetto che vogliamo proprio come gli shader che hanno un loro linguaggio di programmazione.

Originally posted by "yossarian"


Nell'NV25, rispetto all'NV20 è stata aggiunta una seconda unità VS (identica alla prima).
Ps: fixed function sta a significare semplicemente che le operazioni svolte non modificano forma e dimensione dei triangoli (le operazioni di rotazione e traslazione si limitano ad effettuare delle operazioni di spostamento di un intero poligono senza modificare le posizioni dei vertici uno rispetto all'altro). Introducendo operazioni di trasformazione non lineare è possibile, invece, cambiare le posizioni dei vertici di un triangolo, modificando la forma del triangolo stesso (cosa che con le trasformazioni lineari non avviene. Un chip DX8 deve essere in grado di svolgere sia le operazioni lineari che quelle non lineari, pichè entrambe le categorie sono necessarie alla costruzione di una scena 3D).


P.s. mi pare che sei l'unico che ancora difenda la presunta superiorità dall'NV30 e speri ancora in una release di drivers che, miracolosamente, faccia andare l'FX molto più veloce senza abbassare la qualità (ormai pure nVIDIA ha smesso di credere in questo chip e sta già pensando a come sostituirlo nella maniera, per lei più indolore, con l'NV35).
Complimenti per la tenacia, un po' meno per la preparazione tecnica



Ciao

mai sentito parlare del vertex-blendig? sai è T&L/FF.... DX7
cmq hai sbagliato... solitamente per motivi vari (performance in primis) nei titoli che sfruttano il T&L si hanno per lo più trasformazioni che non modificano la 'struttura' di una mesh... ma questo non significa che non sia possibile... già ad esempio un banale scaling modifica la distanza tra i vertici di una mesh...


non sto parlande del NV30 nè tanto meno difendendolo.. cosa che non ho mai fatto e non nè vedo il motivo... anzi proprio io ho sempre parlato del NV35... ad ogni modo sto parlando di shader... per NV30 mi piacciono alcune evoluzioni apportate agli shader... e come ho sempre detto tutto in IMHO non capisco dove tu voglia arrivare cercando di processarmi se trovo per dei mei motivi l'NV30 (e quindi e sopratutto i progressi che anticipa) entusiasmante.

Saluti

[DoomIII]

Originally posted by "yossarian"



quoto questa parte per mettere in evidenza il fatto che tu abbia poche idee (solo gli shader) ma ben confuse

Secondo te, allora, i giochi DX7 come girerebbero su chip DX9? In base al tuo discorso l'R300 o avrebbe solo pipelines fixed function o avrebbe un motore per il TL statico oltre alle unità PS e VS (stesso discorso per l'NV30, ovviamente). E magari con un "circuito discriminatore di DX"

Siamo seri



Pps visto che ti sei preso la briga di riaprire questa discussione, cerca un post in cui ti facevo una serie di domande, sull'NV30 e sul comportamento di nVIDIA, a cui ti sei ben guardato dal rispondere.

visto che non hai nemmeno capito quello che ho scritto... mi sembra che sia tu quello che di shader ne sa ancora meno di quanto sperassi...

dici cose che non ho mai detto e che non c'entrano nulla con le differenze tra T&L/FF e Shader...

Se vuoi un consiglio fatti qualche ricerca... non ci vuole poi molto per capirci almeno qualcosa da comune utente.


P.S.
non so bene a cosa ti riferisci... proverò ad andare a vedere, se è quello che immagino ti posso solo dire che non ho interesse in questo forum a fare argomentazioni del genere... annoierebbe i più e non sarebbe fruttuoso... già questo argomento è 'spesso' per dei 'comuni utenti' come è logico ci siano in questo forum... figurati se mi metto qui a discutere su cosa mi piace di singole istruzione degli shader ecc....
già qui abbiamo scritto molto e fin troppo per una cosa stupida che per me è assolutamente elementare... sorry ma non ci penso nemmeno di entrare qui nei meriti della programmazione di una GPU.

queste discussioni ho già con chi farle che spesso se la ride con me per la convinzione nell'ignoranza con cui vengono date certe risposte in forum vari... o il max è stato quando qualcuno ha citato il fatto di essere programmatore per innalzarsi non si sa dove e voler indicare con quello di avere più voce in capitolo e capirci di più di shader, computer grafica ecc... lol...

preferisco attenermi ad argomentazioni semplici che qualunque utente può capire o ha la possibilità di fare una ricerca su internet per avere informazioni e verificare che ho ragione... ed in questo caso tu torto

[yossarian]

Originally posted by "DoomIII"



visto che non hai nemmeno capito quello che ho scritto... mi sembra che sia tu quello che di shader ne sa ancora meno di quanto sperassi...

dici cose che non ho mai detto e che non c'entrano nulla con le differenze tra T&L/FF e Shader...

Se vuoi un consiglio fatti qualche ricerca... non ci vuole poi molto per capirci almeno qualcosa da comune utente.


P.S.
non so bene a cosa ti riferisci... proverò ad andare a vedere, se è quello che immagino ti posso solo dire che non ho interesse in questo forum a fare argomentazioni del genere... annoierebbe i più e non sarebbe fruttuoso... già questo argomento è 'spesso' per dei 'comuni utenti' come è logico ci siano in questo forum... figurati se mi metto qui a discutere su cosa mi piace di singole istruzione degli shader ecc....
già qui abbiamo scritto molto e fin troppo per una cosa stupida che per me è assolutamente elementare... sorry ma non ci penso nemmeno di entrare qui nei meriti della programmazione di una GPU.

queste discussioni ho già con chi farle che spesso se la ride con me per la convinzione nell'ignoranza con cui vengono date certe risposte in forum vari... o il max è stato quando qualcuno ha citato il fatto di essere programmatore per innalzarsi non si sa dove e voler indicare con quello di avere più voce in capitolo e capirci di più di shader, computer grafica ecc... lol...

preferisco attenermi ad argomentazioni semplici che qualunque utente può capire o ha la possibilità di fare una ricerca su internet per avere informazioni e verificare che ho ragione... ed in questo caso tu torto

Ok, continua pure con questa serie di scempiaggini. Se ne sei convinto (e credo che sia l'unico), puoi anche ritenere che le "operazioni statiche" che dimostri di non conoscere affatto, non siano compatibili con la programabilità; puoi inoltre continuare a considerare i PS e VS dei circuiti fisici (tanto per fortuna non sei tu a dover progettare un chip) e puoi continuare a sperare che escano titoli che esltino l'infinita (?) programmabilità dell'NV30.

Come ho detto: poche idee (anzi solo una) e molto ben confuse.
In quanto all'annoiare, mi pare che tu sia abbastanza noioso già con queste argomentazioni, quindi hai ragione, non tentare di cercarne altre

[yossarian]

Originally posted by "DoomIII"





non sto parlande del NV30 nè tanto meno difendendolo.. cosa che non ho mai fatto e non nè vedo il motivo... anzi proprio io ho sempre parlato del NV35... ad ogni modo sto parlando di shader... per NV30 mi piacciono alcune evoluzioni apportate agli shader... e come ho sempre detto tutto in IMHO non capisco dove tu voglia arrivare cercando di processarmi se trovo per dei mei motivi l'NV30 (e quindi e sopratutto i progressi che anticipa) entusiasmante.

Saluti

Forse io non capisco quello che scrivi; ma neppure tu capisci quello che scrivi, il che è più grave. Riguardati tutti i tuoi post precedenti

extra LOL

[yossarian]

Originally posted by "DoomIII"



Bè, come punto primo già parti sbagliando
ricordiamo che per il T&L si tratta di operazioni hard-coded(codificate nel silicio quindi come si diceva macro funzioni per le quali esiste un corrispondente circuito fisico).
L'errore che fai è che un motore programmabile non può 'gestire' le Fixed-function o T&L statico... i 2 non sono compatibili.
Questo ovviamente non significa che un motore programmabile (gli shader) non possano adempiere agli stessi risultati... ma le operazioni sono diverse...
per le FF i programmatori parametrizzano e richiamano la funzione interessata(che per la scheda grafica significa: esegui questo circuito fisico)
Per gli shader significa che i programmatori devono scrivere un programma, cioè una sequenza di istruzioni (tra quelle a disposizione della GPU) per eseguire l'operazione richiesta.
Se ad una GPU programmabile (shader) arriva la chiamata ad una funzione FF(T&L) ... ERROR!!! non funziona, non è compatibile!!!
proprio per questo nella Gef3 è stato incluso per compatibilità il vecchio T&L/FF... cosa che chiunque può trovare facendo una ricersa su internet in merito al Gef3... quindi potresti farla anche tu evitando di scrivere qui tue teorie...

Sbagli totalmente quindi quando dici che il VS esegue le fuznioni FF più altre... il VS non esegue nessuna funzione me istruzioni, cioè programmi scritti nel linguaggio assembler della GPU... le funzioni poi dipendono dai programmatori che se le devono programmare.

P.S.
per il vecchio T&L/FF oltre a rotazione e traslazione non dimenticare l'illuminazione e poi ci sarebbero anche altre cosette...



Saluti

Ottimo, non solo dimostri di non conoscere cosa sia e come si rappresenti una funzione, ma dimostri di avere ben poche nozioni di HW. Cosa c'entra poi l'illuminazione con i VS (mistero della fede). Parli di assembler senza sapere neppure cosa sia. Un chip non si programma in assembler ma in linguaggio macchina (che solo gli ignoranti confondono con l'assembler) ig:

[yossarian]

Originally posted by "DoomIII"



visto che non hai nemmeno capito quello che ho scritto... mi sembra che sia tu quello che di shader ne sa ancora meno di quanto sperassi...

dici cose che non ho mai detto e che non c'entrano nulla con le differenze tra T&L/FF e Shader...

Se vuoi un consiglio fatti qualche ricerca... non ci vuole poi molto per capirci almeno qualcosa da comune utente.


P.S.
non so bene a cosa ti riferisci... proverò ad andare a vedere, se è quello che immagino ti posso solo dire che non ho interesse in questo forum a fare argomentazioni del genere... annoierebbe i più e non sarebbe fruttuoso... già questo argomento è 'spesso' per dei 'comuni utenti' come è logico ci siano in questo forum... figurati se mi metto qui a discutere su cosa mi piace di singole istruzione degli shader ecc....
già qui abbiamo scritto molto e fin troppo per una cosa stupida che per me è assolutamente elementare... sorry ma non ci penso nemmeno di entrare qui nei meriti della programmazione di una GPU.

queste discussioni ho già con chi farle che spesso se la ride con me per la convinzione nell'ignoranza con cui vengono date certe risposte in forum vari... o il max è stato quando qualcuno ha citato il fatto di essere programmatore per innalzarsi non si sa dove e voler indicare con quello di avere più voce in capitolo e capirci di più di shader, computer grafica ecc... lol...

preferisco attenermi ad argomentazioni semplici che qualunque utente può capire o ha la possibilità di fare una ricerca su internet per avere informazioni e verificare che ho ragione... ed in questo caso tu torto

Non sta a me prendere le difese di altri utenti. Posso dirti solo una cosa: continua a parlare per sentito dire o in base alle tue interpretazioni di qualche articolo che ti troverai sempre bene (ma continuerai a parlare da solo o con qualche altro ignorante). Dopo che avrai visto come è fatto un chip (intendo dal punto di vista fisico) e dopo che ti sarai fatto una cultura su cosa sia una funzione e su come essa si possa rappresentare, innanzitutto dal punto di vista matematico (dove mi sembri piuttosto carente), allora forse riprenderemo la discussione.
Se poi vuoi aver ragione a tutti i costi.......beh che ti devo dire













Hai torto

[yossarian]

Originally posted by "DoomIII"



Bè, come punto primo già parti sbagliando
ricordiamo che per il T&L si tratta di operazioni hard-coded(codificate nel silicio quindi come si diceva macro funzioni per le quali esiste un corrispondente circuito fisico).
L'errore che fai è che un motore programmabile non può 'gestire' le Fixed-function o T&L statico... i 2 non sono compatibili.
Questo ovviamente non significa che un motore programmabile (gli shader) non possano adempiere agli stessi risultati... ma le operazioni sono diverse...
per le FF i programmatori parametrizzano e richiamano la funzione interessata(che per la scheda grafica significa: esegui questo circuito fisico)
Per gli shader significa che i programmatori devono scrivere un programma, cioè una sequenza di istruzioni (tra quelle a disposizione della GPU) per eseguire l'operazione richiesta.
Se ad una GPU programmabile (shader) arriva la chiamata ad una funzione FF(T&L) ... ERROR!!! non funziona, non è compatibile!!!
proprio per questo nella Gef3 è stato incluso per compatibilità il vecchio T&L/FF... cosa che chiunque può trovare facendo una ricersa su internet in merito al Gef3... quindi potresti farla anche tu evitando di scrivere qui tue teorie...

Sbagli totalmente quindi quando dici che il VS esegue le fuznioni FF più altre... il VS non esegue nessuna funzione me istruzioni, cioè programmi scritti nel linguaggio assembler della GPU... le funzioni poi dipendono dai programmatori che se le devono programmare.

P.S.
per il vecchio T&L/FF oltre a rotazione e traslazione non dimenticare l'illuminazione e poi ci sarebbero anche altre cosette...




veramente sto parlando di shader... e li reputo senz'altro una grande innovazione... e non sono l'unico a considerarla uno dei passi fondamentali nella computer-grafix.
cmq non sono proprie di un motore VS... è la programmabilità stessa del VS rende attuabile la keyframe-interpolation... il morphing ecc...
non ci sono ovviamente FF ad eseguire tali operazioni nel VS...


Stai facendo un po di confusione... se le operazioni di traslazione e rotazione sono richiamate nel programma tramite Fixed-Function un'unità VS non sa cosa farsene...
l'ho già detto le FF non sono compatibili con gli shaders... difatti le procedure sono parallele... se un gioco va in modalità T&L il VS è disabilitato e viceversa... sono fisicamente 2 blocchi di silicio diversi ed il T&L esiste solo per compatibilià e proprio perchè il VS non sa cosa farsene.
Quindi in un programma/gioco che utilizza gli shader le operazioni come traslazione e rotazione sono eseguite con programmi shader.



logico... ma non credo serva fare cosi il puntiglioso... nemmeno sui PC con le CPU i programmi sono infiniti... però si può parlare genericamente di infinità poichè un programmatore si mette li e siccome ha la possibilità di programmare tramite istruzione può realizzare ciò che vuole. (logico +o- )
Questa è una delle principali differenze rispetto al T&L dove invece le possibilità erano fisse poichè i programmatori potevano solo richiamare funzioni già fatte per ottenere risultati/effetti prestabiliti.

Gli shader sono una GPU corrispondente ad una CPU... solo che le istruzioni che può eseguire sono pensate per la computer grafica con tutte le ottimizzazioni del caso per ottenere buone performance con la CG in real-time come obiettivo.

Il discorso invece sull'approssimazione non sta nè in cielo nè in terra e non c'entra proprio niente... la differenza tra FF e Shader e tutt'altra...





Assolutamente no... il motore VS per esattezza non esegue operazioni di traslazione e rotazione... questo è il tuo modo di vedere le cose alla vecchia cioè sei rimasto di qualche anno indietro... questo si applica al T&L/FF dove si potevano/possono richiamare le funzioni per eseguire delle operazioni fisse o prestabilite ai vertici.
Con il VS si hanno delle istruzioni con le quali scrivere un programma con il quale ogni vertice viene poi processato (in pratica SIMD)... con la sequenza di queste istruzioni si possono realizzare N^ operazioni ai vertici tra le queli rotazioni ecc... ma è questione di programmazione.
ES:
A) equivalente di T&L/FF= esiste un programma il quale presenta alcuni bottoni e noi clikkando possiamo ottenere dei risultati, ad esempio clikkando il pulsante A otteniamo un messaggio a video "Ciao".

B) equivalente di 'Shader' = abbiamo un linguaggio di programmazione, questo non ci permette con un tasto di avere il messaggio a video però possiamo programmare e quindi fare quello che vogliamo... come ad esempio scrivere una sequenza di istruzioni che poi presenterà a video il messaggio "Ciao"



Spero sia chiaro...
con A) abbiamo dei bottoni esattamente come con il T&L/FF abbiamo delle funzioni richiamabili... quelle sono e quelle restano.
con B) possiamo programmare ed ottenere l'effetto che vogliamo proprio come gli shader che hanno un loro linguaggio di programmazione.



mai sentito parlare del vertex-blendig? sai è T&L/FF.... DX7
cmq hai sbagliato... solitamente per motivi vari (performance in primis) nei titoli che sfruttano il T&L si hanno per lo più trasformazioni che non modificano la 'struttura' di una mesh... ma questo non significa che non sia possibile... già ad esempio un banale scaling modifica la distanza tra i vertici di una mesh...


non sto parlande del NV30 nè tanto meno difendendolo.. cosa che non ho mai fatto e non nè vedo il motivo... anzi proprio io ho sempre parlato del NV35... ad ogni modo sto parlando di shader... per NV30 mi piacciono alcune evoluzioni apportate agli shader... e come ho sempre detto tutto in IMHO non capisco dove tu voglia arrivare cercando di processarmi se trovo per dei mei motivi l'NV30 (e quindi e sopratutto i progressi che anticipa) entusiasmante.

Saluti

Grazie per la spiegazione, ne avevo bisogno.

Evitiamo di scendere troppo sul tecnico perchè altrimenti non ci capiresti niente.

[nik666]

"..Parli di assembler senza sapere neppure cosa sia. Un chip non si programma in assembler ma in linguaggio macchina (che solo gli ignoranti confondono con l'assembler)..."

Bellissimo quello che leggo !!

UN CHIP NON SI PROGRAMMA IN ASSEMBLER MA IN LINGUAGGIO MACCHINA.

E' meraviglioso !

L'assembler alza solamente il livello di programmazione.
Per poterlo eseguire occorre compilarlo/linkarlo e quindi ottenere il TUO BEL LINGUAGGIO MACCHINA.

E' più comodo usare un linguaggio ad "alto livello" e poi con compilatori/linker farcelo tradurre in linguaggio di basso livello.

Se proprio volgliamo dirla tutta un CHIP si programma a 01000101110 ( bit ) perchè non lo capisce il linguaggio macchina !
solo gli ignoranti confondono il linguaggio macchina con BIT !

[yossarian]

Originally posted by "DoomIII"






hmm... scusa ma il discorso è campato in aria... adesso capisco il tuo modo di vedere NV30 e l'R300...
questi numeri su cui ti fissi hanno ben poco significato nel contesto... non è il poter eseguire i calcoli in virgola mobile o meno a fare la differenza tra fixed-function o shader...
Dalle Dx8 (Nv20) è stata sviluppata una vera GPU programmabile che sostituisce e non è compatibile con la precedente architettura T&L(le fixed--function) per la parte vertici e multitexturing per i pixel o texel.
A motivo di questa incompatibilità nella Gef3 è stato incluso il motore T&L cioè le vecchie fixed-function o meglio il core NV15.



Saluti

L'incompatibilità di cui parli è del tutto inesistente. Se nella GF3 è stato mantenuto il T&L statico è stato solo per avere una maggior velocità di elaborazione nelle operazioni di trasformazioni lineari. Dal momento in cui alla prima unità VS ne è stata affiancata una seconda quest'esigenza è sparita. Nell'NV25 non è presente alcun T&L statico, così come non esiste sull'R300 e sull'NV30.

[yossarian]

Originally posted by "nik666"

"..Parli di assembler senza sapere neppure cosa sia. Un chip non si programma in assembler ma in linguaggio macchina (che solo gli ignoranti confondono con l'assembler)..."

Bellissimo quello che leggo !!

UN CHIP NON SI PROGRAMMA IN ASSEMBLER MA IN LINGUAGGIO MACCHINA.

E' meraviglioso !

L'assembler alza solamente il livello di programmazione.
Per poterlo eseguire occorre compilarlo/linkarlo e quindi ottenere il TUO BEL LINGUAGGIO MACCHINA.

E' più comodo usare un linguaggio ad "alto livello" e poi con compilatori/linker farcelo tradurre in linguaggio di basso livello.

Se proprio volgliamo dirla tutta un CHIP si programma a 01000101110 ( bit ) perchè non lo capisce il linguaggio macchina !
solo gli ignoranti confondono il linguaggio macchina con BIT !

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

[DoomIII]

Originally posted by "yossarian"



Grazie per la spiegazione, ne avevo bisogno.

Evitiamo di scendere troppo sul tecnico perchè altrimenti non ci capiresti niente.

lol, questa era simpatica :o

[yossarian]

Originally posted by "DoomIII"



Questa è una delle principali differenze rispetto al T&L dove invece le possibilità erano fisse poichè i programmatori potevano solo richiamare funzioni già fatte per ottenere risultati/effetti prestabiliti.

Gli shader sono una GPU corrispondente ad una CPU... solo che le istruzioni che può eseguire sono pensate per la computer grafica con tutte le ottimizzazioni del caso per ottenere buone performance con la CG in real-time come obiettivo.

Il discorso invece sull'approssimazione non sta nè in cielo nè in terra e non c'entra proprio niente... la differenza tra FF e Shader e tutt'altra...

Assolutamente no... il motore VS per esattezza non esegue operazioni di traslazione e rotazione... questo è il tuo modo di vedere le cose alla vecchia cioè sei rimasto di qualche anno indietro... questo si applica al T&L/FF dove si potevano/possono richiamare le funzioni per eseguire delle operazioni fisse o prestabilite ai vertici.
Con il VS si hanno delle istruzioni con le quali scrivere un programma con il quale ogni vertice viene poi processato (in pratica SIMD)... con la sequenza di queste istruzioni si possono realizzare N^ operazioni ai vertici tra le queli rotazioni ecc... ma è questione di programmazione.
ES:
A) equivalente di T&L/FF= esiste un programma il quale presenta alcuni bottoni e noi clikkando possiamo ottenere dei risultati, ad esempio clikkando il pulsante A otteniamo un messaggio a video "Ciao".

B) equivalente di 'Shader' = abbiamo un linguaggio di programmazione, questo non ci permette con un tasto di avere il messaggio a video però possiamo programmare e quindi fare quello che vogliamo... come ad esempio scrivere una sequenza di istruzioni che poi presenterà a video il messaggio "Ciao"



Spero sia chiaro...
con A) abbiamo dei bottoni esattamente come con il T&L/FF abbiamo delle funzioni richiamabili... quelle sono e quelle restano.
con B) possiamo programmare ed ottenere l'effetto che vogliamo proprio come gli shader che hanno un loro linguaggio di programmazione.



mai sentito parlare del vertex-blendig? sai è T&L/FF.... DX7
cmq hai sbagliato... solitamente per motivi vari (performance in primis) nei titoli che sfruttano il T&L si hanno per lo più trasformazioni che non modificano la 'struttura' di una mesh... ma questo non significa che non sia possibile... già ad esempio un banale scaling modifica la distanza tra i vertici di una mesh...


Saluti

E' ovvio che il discorso sulle approssimazioni non sta né in cielo né in terra (dal tuo punto di vista). Il motivo è semplicemente che non lo hai capito.
Prima di riempirti la bocca con concetti come i PS e i VS, la programmabilità e le FF, dovresti conoscere, almeno in parte i principi analitici su cui questi concetti sono basati (ossia devi conoscere la matematica). Le FF non sono altro che trasformazioni lineari che non richiedono complessi calcoli e soprattutto possono essere rappresentate in maniera più che soddisfacente, operando in virgola fissa. Le trasformazioni lineari su un poligono, però non prevedono che vengano alterati i rapporti tra le varie grandezze dello stesso (lo scaling lascia i rapporti inalterati, e così pure la traslazione e la rotazione e tutte le altre operazioni lineari). Discorso completamente diverso quando si passa a rappresentare funzioni di tipo diverso (goniometriche, trascendenti, ecc., o semplicemente non lineari). In tal caso, il ricorso a calcoli in virgola mobile (FP) è necessario, pena la perdita di precisione. Teoricamente è possibile rappresentare buona parte delle funzioni non lineari o, più generalmente, di tipo complesso (inteso come estensione del tipo reale), mediante approssimazioni, al limite anche lineari (basta dare un'occhiata alla formule di interpolazione proprie dell'analisi numerica), ma questo, se da un lato semplifica notevolmente i calcoli (basta effettuare operazioni di derivazione), dall'altro comporta una perdita di precisione, in alcuni casi, notevole. Per questo motivo (proprio perchè in realtà quando viene calcolata una funzione cos(x), tanto per fare un esempio, i calcoli vengono eseguiti utilizzando algoritmi di interpolazione, è importante che la precisione sia la più accurata possibile: di conseguenza i calcoli non possono essere eseguiti in virgola fissa, né, in molti casi, ci si può fermare ad algoritmi del primo grado; non entro nel merito dei criteri di valutazione sulla stima degli errori per non complicare le cose).
Un motore VS è in grado di eseguire sia calcoli complessi che calcoli più semplici (di tipo lineare). E' ovvio che in quest'ultimo caso, il procedimento adottato non è uguale a quello di un motore che esegue solo calcoli di tipo lineare, per il semplice motivo che mentre un motore che esegue calcoli solo lineari opera esclusivamente con delle rette, un motore che esegue calcoli complessi opera con algoritmi di interpolazione che, a seconda dei casi, possono approssimare una retta, una parabola, un'iperbole, un generico polinomio di grado n, una funzione goniometrica, ecc, semplicemente effettuando calcoli differenziali e minimizzando i resti ottenuti.
Spero di essere stato chiaro. Mi sono tenuto molto sullo gerico, senza andare su un livello troppo tecnico per non annoiare chi legge

[DoomIII]

Originally posted by "yossarian"


...
Le FF non sono altro che trasformazioni lineari che non richiedono complessi calcoli e soprattutto possono essere rappresentate in maniera più che soddisfacente, operando in virgola fissa.

si ma per un programmatore sono semplicemente delle funzioni richiamabili e parametrizzabili... non è possibile con il T&L/FF avere a disposizione le istruzioni dei singoli calcoli quindi è inutile in questo contesto (FF) arrivare a livello di calcoli/istruzioni.

Originally posted by "yossarian"


Le trasformazioni lineari su un poligono, però non prevedono che vengano alterati i rapporti tra le varie grandezze dello stesso (lo scaling lascia i rapporti inalterati, e così pure la traslazione e la rotazione e tutte le altre operazioni lineari).

hmmm, mai sentito parlare di vertex/blending?

Originally posted by "yossarian"


Un motore VS è in grado di eseguire sia calcoli complessi che calcoli più semplici (di tipo lineare).

Si, ma non c'entra... tu usi questo per dire che il VS è compatibile con il T&L/FF... invece non c'entra nulla poichè il VS ha un set di istruzioni che può eseguire in base al programma shader scritto dal programmatore.
Per ogni istruzione esiste un circuito(per dirlo un po brutalmente ma il senso è quello)...
Nel T&L/FF queste istruzioni non ci sono ma ci sono direttamente delle funzioni/algoritmi. Qui per ogni funzione esiste un circuito...

Originally posted by "yossarian"


...
...
...E' ovvio che in quest'ultimo caso, il procedimento adottato non è uguale a quello di un motore che esegue solo calcoli di tipo lineare, per il semplice motivo che mentre un motore che esegue calcoli solo lineari opera esclusivamente con delle rette, un motore che esegue calcoli complessi opera con algoritmi di interpolazione che, a seconda dei casi, possono approssimare una retta, una parabola, un'iperbole, un generico polinomio di grado n, una funzione goniometrica, ecc, semplicemente effettuando calcoli differenziali e minimizzando i resti ottenuti.
Spero di essere stato chiaro. Mi sono tenuto molto sullo gerico, senza andare su un livello troppo tecnico per non annoiare chi legge

bè, si sei stato chiaro :o
l'origine del mio punto di vista è puramente software... cioè programmer-oriented... ok per quello che hai detto... ma parliamo in un certo senso di 2 cose diverse... io mi riferisco al fatto che un motore shader o che esegue calcoli complessi esegue algoritmi che sono composti da sequenze di istruzioni scritte dal programmatore... in questo modo un programmatore può realizzare l'algoritmo/funzione che gli serve per operare come crede sui vertici o pixel(a secoda dello shader)... il 'motore shader' quindi esegue istruzioni.

Nel T&L/FF questi algoritmi invece sono operazioni hard-coded(codificate nel silicio) cioè funzioni per le quali esiste un corrispondente circuito.

Per questo considero il discorso 'precisione' non competente ed ininfluente ai termini del paragone T&L/FF e shaders...

Tu parli di calcoli o singole operazioni che sono praticamente istruzioni... ma nel T&L/FF non ci sono calcoli/singole_operazioni/istruzioni... ma funzioni... per un programmatore lo shader ha istruzioni mentre FF ha funzioni... quindi non ha senso il tuo cercare di considerare il parco istruzioni T&L/FF come un sottoinsieme delle istruzioni shaders... proprio perchè non c'è un parco istruzioni T&L/FF.

[Redvex]

[yossarian]

Originally posted by "DoomIII"


si ma per un programmatore sono semplicemente delle funzioni richiamabili e parametrizzabili... non è possibile con il T&L/FF avere a disposizione le istruzioni dei singoli calcoli quindi è inutile in questo contesto (FF) arrivare a livello di calcoli/istruzioni.


hmmm, mai sentito parlare di vertex/blending?



Si, ma non c'entra... tu usi questo per dire che il VS è compatibile con il T&L/FF... invece non c'entra nulla poichè il VS ha un set di istruzioni che può eseguire in base al programma shader scritto dal programmatore.
Per ogni istruzione esiste un circuito(per dirlo un po brutalmente ma il senso è quello)...
Nel T&L/FF queste istruzioni non ci sono ma ci sono direttamente delle funzioni/algoritmi. Qui per ogni funzione esiste un circuito...



bè, si sei stato chiaro :o
l'origine del mio punto di vista è puramente software... cioè programmer-oriented... ok per quello che hai detto... ma parliamo in un certo senso di 2 cose diverse... io mi riferisco al fatto che un motore shader o che esegue calcoli complessi esegue algoritmi che sono composti da sequenze di istruzioni scritte dal programmatore... in questo modo un programmatore può realizzare l'algoritmo/funzione che gli serve per operare come crede sui vertici o pixel(a secoda dello shader)... il 'motore shader' quindi esegue istruzioni.

Nel T&L/FF questi algoritmi invece sono operazioni hard-coded(codificate nel silicio) cioè funzioni per le quali esiste un corrispondente circuito.

Per questo considero il discorso 'precisione' non competente ed ininfluente ai termini del paragone T&L/FF e shaders...

Tu parli di calcoli o singole operazioni che sono praticamente istruzioni... ma nel T&L/FF non ci sono calcoli/singole_operazioni/istruzioni... ma funzioni... per un programmatore lo shader ha istruzioni mentre FF ha funzioni... quindi non ha senso il tuo cercare di considerare il parco istruzioni T&L/FF come un sottoinsieme delle istruzioni shaders... proprio perchè non c'è un parco istruzioni T&L/FF.

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.

[yossarian]

Originally posted by "DoomIII"





Si, ma non c'entra... tu usi questo per dire che il VS è compatibile con il T&L/FF... invece non c'entra nulla poichè il VS ha un set di istruzioni che può eseguire in base al programma shader scritto dal programmatore.
Per ogni istruzione esiste un circuito(per dirlo un po brutalmente ma il senso è quello)...
Nel T&L/FF queste istruzioni non ci sono ma ci sono direttamente delle funzioni/algoritmi. Qui per ogni funzione esiste un circuito...

In base al tuo discorso in ogni chip, che sia DX7, DX8, DX9, DX25, esiste un T&L statico, oltre ai motori VS e PS. Se così è, per quale motivo nelle applicazioni DX7 non vanno tutti alla stessa maniera ma ci sono chip più veloci ed altri più lenti (questa è la prima domanda, seppure terra terra, che sorge spontanea). A cosa sono dovute le differenze nella velocità di elaborazione con applicazioni FF? Non certo alla frequenza di clock (visto che abbiamo esempi di chip con frequenze simili che hanno prestazioni molto diverse e chip con frequenze molto diverse che vanno alla stessa maniera)