View Full Version : Vertex Shader (&pixel)
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 :rolleyes:
hmm.... uppete che nn so se yossarian ha letto :rolleyes: :D :cool:
yossarian
03-05-2003, 11:00
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 :rolleyes:
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).
:D
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à :mc: (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
:sofico:
Ciao
yossarian
03-05-2003, 11:09
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 :rolleyes:
quoto questa parte per mettere in evidenza il fatto che tu abbia poche idee (solo gli shader) ma ben confuse :rolleyes:
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" :eek:
Siamo seri
:D
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.
:rolleyes:
;)
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 :D
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"
:rolleyes:
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).
:D
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à :mc: (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
:sofico:
Ciao
mai sentito parlare del vertex-blendig? sai è T&L/FF.... DX7 ;) :D
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 :cool:
Originally posted by "yossarian"
quoto questa parte per mettere in evidenza il fatto che tu abbia poche idee (solo gli shader) ma ben confuse :rolleyes:
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" :eek:
Siamo seri
:D
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.
:rolleyes:
;)
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... :D
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 :p ;)
yossarian
03-05-2003, 19:23
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... :D
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 :p ;)
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. :mc:
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 :D
:D
yossarian
03-05-2003, 19:27
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 :cool:
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 :D
yossarian
03-05-2003, 19:30
Originally posted by "DoomIII"
Bè, come punto primo già parti sbagliando :D
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 :cool:
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) :pig:
yossarian
03-05-2003, 19:40
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... :D
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 :p ;)
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
:D
yossarian
03-05-2003, 19:43
Originally posted by "DoomIII"
Bè, come punto primo già parti sbagliando :D
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"
:rolleyes:
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 ;) :D
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 :cool:
Grazie per la spiegazione, ne avevo bisogno. :cry:
Evitiamo di scendere troppo sul tecnico perchè altrimenti non ci capiresti niente.
:D
"..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 !
:D :D :D :D :D
yossarian
03-05-2003, 19:58
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 :rolleyes:
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
03-05-2003, 20:00
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 !
:D :D :D :D :D
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
:D
Originally posted by "yossarian"
Grazie per la spiegazione, ne avevo bisogno. :cry:
Evitiamo di scendere troppo sul tecnico perchè altrimenti non ci capiresti niente.
:D
lol, questa era simpatica :) :D :o
yossarian
03-05-2003, 22:09
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"
:rolleyes:
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 ;) :D
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 :cool:
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
:sofico:
:D
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? ;) :D
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
:sofico:
:D
bè, si sei stato chiaro :o :D
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.
yossarian
04-05-2003, 16:18
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? ;) :D
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 :D
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
04-05-2003, 16:27
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)
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
:D
"...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 !! :eek:
0 ed 1 non esistono, servono solo per rappresentare lo stato di tensione si e no. :D
".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 ;)
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... :D
è 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 :D ;)
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è? :rolleyes: :cool:
yossarian
04-05-2003, 17:45
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 !! :eek:
0 ed 1 non esistono, servono solo per rappresentare lo stato di tensione si e no. :D
".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 :cry:
:D
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?? ;) :D
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.
:cool:
yossarian
04-05-2003, 18:01
Originally posted by "DoomIII"
forse non hai capito... non parlo certo di funzioni matematiche... :D
è 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 :D ;)
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è? :rolleyes: :cool:
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
04-05-2003, 18:47
venghino signori e signori a capire finalmente cosa sono in realta i pixel e vertex shader! :o :muro:
ma perchè fate tutto sto casino? solo per dire che nvidia è meglio di ati? :rolleyes:
yossarian
04-05-2003, 18:54
Originally posted by "Hanamichi"
venghino signori e signori a capire finalmente cosa sono in realta i pixel e vertex shader! :o :muro:
ma perchè fate tutto sto casino? solo per dire che nvidia è meglio di ati? :rolleyes:
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)
:D
Hanamichi
04-05-2003, 18:56
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)
:D
ma nn ho capito quale diavolo è il problema!!! forse gli shader ++ di NVIDIA? :confused: :muro:
Originally posted by "Hanamichi"
ma nn ho capito quale diavolo è il problema!!! forse gli shader ++ di NVIDIA? :confused: :muro:
Le istruzioni ++ di nvidia e le +++ di ATI e poi si ricomincia il giro :D
Hanamichi
04-05-2003, 19:14
Originally posted by "pandyno"
Le istruzioni ++ di nvidia e le +++ di ATI e poi si ricomincia il giro :D
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 :muro:
yossarian
04-05-2003, 20:47
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 :muro:
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 :confused: 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 :rolleyes: (non si sa bene se stampati o meno nel silicio, stavolta o da qualche altra parte, forse sul giornale) che permettono una programmazione illimitata :eek: 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?
:D
kirk tempo fa disse che le le FF delle dx7 erano gestite come un vertex program
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
04-05-2003, 21:46
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
04-05-2003, 21:56
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
04-05-2003, 22:01
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
:)
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 :D ) 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 :D ) 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
04-05-2003, 22:37
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 :D ) 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 :D ) 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
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... :rolleyes: cambiamo termine :D )
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
04-05-2003, 22:54
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... :rolleyes: cambiamo termine :D )
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 :muro:
:D
yossarian
04-05-2003, 23:00
p.s. per evitarmi confusioni ulteriori, ti dispiace se in futuro, se dovessimo discutere ancora di queste cose, invece di FF e shaders li chiamassimo, che so, Paperino e Paperoga?
Ciao
Originally posted by "yossarian"
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).
Originally posted by "yossarian"
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).
e questo che c'entra? se tu facessi le ricerche potresti informarti invece che inventarti le cose e capire le differenze tra FF e shader.
Inoltre l'Nv20 non è l'Nv25 o l'R300... quindi se dico che nel NV20 è incluso in hw il T&L del NV15 non lamerare e se vuoi informarti informati su quello e no su NV25 o R300 di cui nel caso specifico non sto parlando.
Originally posted by "yossarian"
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).
cioè? vorresti che ti do lezioni spiegandoti le funzioni FF a disposizione dei programmatori? Puoi trovare facilmente documentazione in merito se ti interessa programmare... ma in tal caso ti consiglierei di lasciar perdere e studiare direttamente gli 'shader'.... anche se sinceramente constando che non sai neanche cosa sia una funzione... avresti altre cose da studiare prima. :rolleyes:
Originally posted by "yossarian"
Hai sostenuto che l'architettura dell'NV30 è superiore e più avanzata; ti ho chiesto perchè allora è uscito overclockato di fabbrica e non hai risposto.
hmm... veramente mi sembra di essermi limitato a parlare della differenza tra T&L/FF e shader e la nostra contesa verte su questo...
secondo te gli shader sono le FF con in più ancora altre operazioni... per dimostrare questo hai cercato di arrampicarti sugli specchi con discorsi fuorvianti...
Originally posted by "yossarian"
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
bè , la confusione che fai con le funzioni... non la trovo proprio divertente... prima si perchè pensavo tu scherzassi apposta...
certo che diventa noisa... l'argomento è da poche righe e verte sulla differenza tra FF e shader e sul fatto che secondo te le FF sono un sottoinsieme degli shader.
secondo te con le FF i programmatori hanno delle funzioni matematiche con le quali possono fare diverse cose... e sempre secondo te con gli shader i programmatori hanno le stesse funzioni matematiche delle FF più ancora altre... TUTTA QUESTA TUA OPINIONE PERSONALE è SBAGLIATA!!!!
Con le FF i programmatori hanno dei comandi con i quali far eseguire sui vertici delle operazioni fisse... esite cioè un set fisso di operazioni.
Con gli shader i programmatori hanno una sorta di linguaggio assembler con il quale scrivere dei 'programmini' per eseguire operazioni personalizzate sui vertici.
Questi sono i fatti... e poi ci sei tu che alzi fumo...
yossarian
04-05-2003, 23:05
Originally posted by "DoomIII"
e questo che c'entra? se tu facessi le ricerche potresti informarti invece che inventarti le cose e capire le differenze tra FF e shader.
Inoltre l'Nv20 non è l'Nv25 o l'R300... quindi se dico che nel NV20 è incluso in hw il T&L del NV15 non lamerare e se vuoi informarti informati su quello e no su NV25 o R300 di cui nel caso specifico non sto parlando.
Faresti bene a parlarne invece perchè la stessa incompatibilità di cui vai cianciando esiste anche, allora per l'NV25 ecc. ecc.
Originally posted by "DoomIII"
cioè? vorresti che ti do lezioni spiegandoti le funzioni FF a disposizione dei programmatori? Puoi trovare facilmente documentazione in merito se ti interessa programmare... ma in tal caso ti consiglierei di lasciar perdere e studiare direttamente gli 'shader'.... anche se sinceramente constando che non sai neanche cosa sia una funzione... avresti altre cose da studiare prima. :rolleyes:
Preferisco evitare altre "lezioni" da parte tua. Non ti ho chiesto di elencarmi le FF a disposizione dei programmatori (quelle già le conosco). Ti ho chiesto qualche esempio concreto per vedere dove vuoi andare a parare. Ti sembra troppo? Illuminami maestro! :D
Originally posted by "DoomIII"
hmm... veramente mi sembra di essermi limitato a parlare della differenza tra T&L/FF e shader e la nostra contesa verte su questo...
secondo te gli shader sono le FF con in più ancora altre operazioni... per dimostrare questo hai cercato di arrampicarti sugli specchi con discorsi fuorvianti...
Ti consiglio di rileggere tutti i tuoi interventi, in questa discussione, dall'inizio (del thread originario)
Originally posted by "DoomIII"
bè , la confusione che fai con le funzioni... non la trovo proprio divertente... prima si perchè pensavo tu scherzassi apposta...
certo che diventa noisa... l'argomento è da poche righe e verte sulla differenza tra FF e shader e sul fatto che secondo te le FF sono un sottoinsieme degli shader.
secondo te con le FF i programmatori hanno delle funzioni matematiche con le quali possono fare diverse cose... e sempre secondo te con gli shader i programmatori hanno le stesse funzioni matematiche delle FF più ancora altre... TUTTA QUESTA TUA OPINIONE PERSONALE è SBAGLIATA!!!!
Con le FF i programmatori hanno dei comandi con i quali far eseguire sui vertici delle operazioni fisse... esite cioè un set fisso di operazioni.
Con gli shader i programmatori hanno una sorta di linguaggio assembler con il quale scrivere dei 'programmini' per eseguire operazioni personalizzate sui vertici.
Questi sono i fatti... e poi ci sei tu che alzi fumo...
Gli shader vengono programmati in C e non in assembler. Le FF sono tranquillamente rappresentabili tramite shaders (quindi non esiste incompatibilità), ma non ne sono un sottoinsieme. Ho tentato di spiegartelo ma le tue nozioni tecniche sono veramente meno di zero. Se non sai cos'è una funzione, cosa vuol dire lineare, cos'è un'equazione parametrica, credo sia una battaglia persa in partenza. A proposito, visto che parli di CG, ti faccio presente che il suo significato è C for Graphic (visto che parli di assembler per la programmazione degli shader).
Domanda di rito: quanti anni hai e che studi hai fatto?
Originally posted by "yossarian"
Faresti bene a parlarne invece perchè la stessa incompatibilità di cui vai cianciando esiste anche, allora per l'NV25 ecc. ecc.
hmm... hai presente quei bei giochini di una volta da sala giochi? sarebbe bello giocarci su PC... però non sono compatibili... ooooo esiste il mame...
l'incompatibilità di cui parlo resta ed è evidente perchè in un contesto shader un'instruzione FF è incompatibile. Questo ovviamente non significa che io non possa uscire da quel contesto e difatti per questo parlo di differenza tra FF e shader riferita alla programmazione...
in un programma shader non inserirai chiamate a funzioni FF... per quanto nel gioco poi ci possano effettivamente essere.
Originally posted by "yossarian"
Preferisco evitare altre "lezioni" da parte tua. Non ti ho chiesto di elencarmi le FF a disposizione dei programmatori (quelle già le conosco). Ti ho chiesto qualche esempio concreto per vedere dove vuoi andare a parare. Ti sembra troppo? Illuminami maestro! :D
non vado a parare da nessuna parte... ho sempre parlato di funzioni FF richiamate dai programmatori... le ho chiamate anche in altro modo dicendo che sono comandi ecc...
visto che dici di conoscere le funzioni FF dovresti sapere che sono ben diverse dalle istruzioni shader e che ad esempio ad una funzione FF può corrispondere un programma shader.
Le FF danno a disposizione delle funzioni fisse per operare sui vertici.
Gli shader danno a disposizione un set di istruzioni cioè un linguaggio con il quale realizzare le funzioni necessarie.
Visto che conosci le funzioni FF... e dai l'impressione di essere così esperto... richiama nella tua mente le istruzioni necessarie per attivare via T&L/FF una banale luce direzionale.
D3DLIGHTx light; //x perchè è FF e può essere dalla v.7 in poi...
light.Diffuse.r = 1.0f;
light.Diffuse.g = 1.0f;
light.Diffuse.b = 1.0f;
light.Range = 500.0f;
ilpuntatorealdevice_d3d->SetLight( 0, &light );
ilpuntatorealdevice_d3d->LightEnable( 0, TRUE);
Con quelle istruzioni tramite funzioni FF utilizzi una luce direzionale... dovresti sapere che sono fisse... il set di luci è quello... puoi parametrizzare ma devi accettare il set-predefinito di funzioni. (ricordati di impostare il Render State per l'illuminazioe a TRUE :D ... perchè ovviamente se utilizzi shader sarà a FALSE ad indicare che non utilizziamo il vecchio T&L/FF incompatibile con gli shader)
Con gli shader, per quanto ottenere questo tipo di luce sia 'semplice', la situazione diventa ben diversa...
...
...
dp3 r1, v1,c7 //dot product,il 7 mi stava simpatico e usiamo quello
//per la direzione della luce :D
mul oD0,r1.x,v7 //moltiplicazione per il colore... diciamo che
//dagli stream ci arriva nel registro v7 il colore della luce
...
...
ovviamente mancano pezzi in entrambe la parti... ma penso sia già troppo giusto per far rendere l'idea del differente approccio... nel primo caso le luci esistono già... sono quelle le possiamo utilizzare e basta... nel secondo non ci sono e dobbiamo farcele(con il vantaggio di poterle avere come vogliamo).
Originally posted by "yossarian"
Ti consiglio di rileggere tutti i tuoi interventi, in questa discussione, dall'inizio (del thread originario)
Gli shader vengono programmati in C e non in assembler. Le FF sono tranquillamente rappresentabili tramite shaders (quindi non esiste incompatibilità), ma non ne sono un sottoinsieme. Ho tentato di spiegartelo ma le tue nozioni tecniche sono veramente meno di zero.
SBAGLIATO, gli shader vengono programmati in assembler oppure in Cg o HLSL ;inizialmente solo in assembler poichè solo sucessivamente sono usciti Cg e HLSL... ma resta una scelta al programmatore...
perchè invece di inventarti le cose non ti documenti? Per molto tempo gli shader venivano programmati in assembler perchè non c'era altra possibilità... adesso è possibile scegliere ma ciò non toglie che gli shader sono programmati in Assembler ed anche in Cg e HLSL...
Originally posted by "yossarian"
Se non sai cos'è una funzione, cosa vuol dire lineare, cos'è un'equazione parametrica, credo sia una battaglia persa in partenza. A proposito, visto che parli di CG, ti faccio presente che il suo significato è C for Graphic (visto che parli di assembler per la programmazione degli shader).
vertamente sei tu che non sai cosa sia una funzione... e che mentre parlo di programmazione e di funzioni FF a disposizione confondi con tutt'altro...
Cosa sia il Cg lo so molto bene... ma ti ripeto che sono una possibilità di programmazione per gli shader... poi per carità... se vuoi fare il sapientone dimostrando di sapere il significato di Cg... lol...
Originally posted by "yossarian"
Domanda di rito: quanti anni hai e che studi hai fatto?
sinceramente questo non dovrebbe avere nessuna importanza... non mi piace questo cercare un confronto su 'etichette'... ad ogni modo su questi forum cerco di non andare mai sul personale... famiglia&lavoro&studi&amici&ecc...
[EDIT] ops... la formattazione :D
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
Esatto....la incornicerei.
In pratica le ultime schede video uscite servono a far girare come si deve i giochi che finalmente saranno full Dx8.1...e nient'altro.
In Dx9 al massimo ci gira Dawn nuda....perchè se parliamo di giochi DX9 full ci passano altre 2 generazioni di sk video per vederli girare decentemente.
Originally posted by "R@nda"
Esatto....la incornicerei.
In pratica le ultime schede video uscite servono a far girare come si deve i giochi che finalmente saranno full Dx8.1...e nient'altro.
In Dx9 al massimo ci gira Dawn nuda....perchè se parliamo di giochi DX9 full ci passano altre 2 generazioni di sk video per vederli girare decentemente.
non ho mai detto di essere contrario...
da DX7 a 8 però... cioè da T&L/FF a shader c'è un grande passo... e ci sono molte differenze...
la situazione attuale di software non permette cmq di poter valutare la bontà di una scheda grafica su questo profilo...
Del resto per quanto riguarda NV30 o R300 ho sempre detto che da utenti se non si ha la stretta necessità di cambiare scheda video in questo momento non c'è proprio motivo per farlo... visto che software appropriato non c'è.
Però è anche insulso giudicare queste nuove schede basandosi principalmente su software non shader-oriented.
yossarian
05-05-2003, 02:06
Originally posted by "DoomIII"
non vado a parare da nessuna parte... ho sempre parlato di funzioni FF richiamate dai programmatori... le ho chiamate anche in altro modo dicendo che sono comandi ecc...
visto che dici di conoscere le funzioni FF dovresti sapere che sono ben diverse dalle istruzioni shader e che ad esempio ad una funzione FF può corrispondere un programma shader.
Le FF danno a disposizione delle funzioni fisse per operare sui vertici.
Gli shader danno a disposizione un set di istruzioni cioè un linguaggio con il quale realizzare le funzioni necessarie.
Visto che conosci le funzioni FF... e dai l'impressione di essere così esperto... richiama nella tua mente le istruzioni necessarie per attivare via T&L/FF una banale luce direzionale.
D3DLIGHTx light; //x perchè è FF e può essere dalla v.7 in poi...
light.Diffuse.r = 1.0f;
light.Diffuse.g = 1.0f;
light.Diffuse.b = 1.0f;
light.Range = 500.0f;
ilpuntatorealdevice_d3d->SetLight( 0, &light );
ilpuntatorealdevice_d3d->LightEnable( 0, TRUE);
Ovviamente immagino che sai bene che tipo di istruzione sia questa (o meglio che set di istruzioni rappresenti). Dovresti sapere che allo stesso modo si possono ottenere anche forme geometriche oltre che colorazioni (tramite banale regolazione delle impostazioni RGB e della luminanza). E sai che queste non sono altro che la traduzione di parametri matematici?
Ora, per rappresentare la stessa cosa posso utilizzare questi parametri o un set di funzioni (sempre matematiche) da cui posso, a derminate condizioni, ricavare i suddetti parametri. Diciamo che la FF sono i parametri e gli shader le funzioni. Nota bene: dalle funzioni ricavo i parametri. Le DX7 permettevano di operare solo in maniera parametrica, mentre le DX8 permettono di operare utilizzando le funzioni da cui i parametri si ricavano. Una funzione permette di ottenere infiniti set di parametri, semplicemente variando le condizioni al contorno. La differenza è tutta qui. Esiste però anche la possibilità di ricostruire, dai parametri, la funzione che li genera: questo è compito dell'HDL.
Originally posted by "DoomIII"
hmm... hai presente quei bei giochini di una volta da sala giochi? sarebbe bello giocarci su PC... però non sono compatibili... ooooo esiste il mame...
l'incompatibilità di cui parlo resta ed è evidente perchè in un contesto shader un'instruzione FF è incompatibile. Questo ovviamente non significa che io non possa uscire da quel contesto e difatti per questo parlo di differenza tra FF e shader riferita alla programmazione...
in un programma shader non inserirai chiamate a funzioni FF... per quanto nel gioco poi ci possano effettivamente essere.
non vado a parare da nessuna parte... ho sempre parlato di funzioni FF richiamate dai programmatori... le ho chiamate anche in altro modo dicendo che sono comandi ecc...
visto che dici di conoscere le funzioni FF dovresti sapere che sono ben diverse dalle istruzioni shader e che ad esempio ad una funzione FF può corrispondere un programma shader.
Le FF danno a disposizione delle funzioni fisse per operare sui vertici.
Gli shader danno a disposizione un set di istruzioni cioè un linguaggio con il quale realizzare le funzioni necessarie.
Visto che conosci le funzioni FF... e dai l'impressione di essere così esperto... richiama nella tua mente le istruzioni necessarie per attivare via T&L/FF una banale luce direzionale.
D3DLIGHTx light; //x perchè è FF e può essere dalla v.7 in poi...
light.Diffuse.r = 1.0f;
light.Diffuse.g = 1.0f;
light.Diffuse.b = 1.0f;
light.Range = 500.0f;
ilpuntatorealdevice_d3d->SetLight( 0, &light );
ilpuntatorealdevice_d3d->LightEnable( 0, TRUE);
Con quelle istruzioni tramite funzioni FF utilizzi una luce direzionale... dovresti sapere che sono fisse... il set di luci è quello... puoi parametrizzare ma devi accettare il set-predefinito di funzioni. (ricordati di impostare il Render State per l'illuminazioe a TRUE :D ... perchè ovviamente se utilizzi shader sarà a FALSE ad indicare che non utilizziamo il vecchio T&L/FF incompatibile con gli shader)
Con gli shader, per quanto ottenere questo tipo di luce sia 'semplice', la situazione diventa ben diversa...
...
...
dp3 r1, v1,c7 //dot product,il 7 mi stava simpatico e usiamo quello
//per la direzione della luce :D
mul oD0,r1.x,v7 //moltiplicazione per il colore... diciamo che
//dagli stream ci arriva nel registro v7 il colore della luce
...
...
ovviamente mancano pezzi in entrambe la parti... ma penso sia già troppo giusto per far rendere l'idea del differente approccio... nel primo caso le luci esistono già... sono quelle le possiamo utilizzare e basta... nel secondo non ci sono e dobbiamo farcele(con il vantaggio di poterle avere come vogliamo).
Visto che siamo in vena di numeri
dp4 oPos.x, v0, c[2]
dp4 oPos.y, v0, c[3]
dp4 oPos.z, v0, c[4]
dp4 oPos.w, v0, c[5]
mov oT0.xy, v2
ecc. ecc.
Sai di cosa stiamo parlando? Di vettori. Sai cos'è un vettore? Sai che i vertici di un triangolo possono essere definiti sia tramite FF (dandone semplicemente le coordinate) sia tramite vettori? E sai che per due punti di un piano passa una sola retta? Di conseguenza sai che dalle coordinate dei punti è possibile ottenere i vettori passanti per i punti stessi (fornendo due soli altri parametri, ossia intensità e verso). Quindi sai che dalle FF e possibile ricostruire quelli che continui, pomposamente a chiamare shader?
yossarian
05-05-2003, 02:36
Originally posted by "DoomIII"
SBAGLIATO, gli shader vengono programmati in assembler oppure in Cg o HLSL ;inizialmente solo in assembler poichè solo sucessivamente sono usciti Cg e HLSL... ma resta una scelta al programmatore...
perchè invece di inventarti le cose non ti documenti? Per molto tempo gli shader venivano programmati in assembler perchè non c'era altra possibilità... adesso è possibile scegliere ma ciò non toglie che gli shader sono programmati in Assembler ed anche in Cg e HLSL...
Ok genio, mi definisci cosa sono CG e HLSL? E mi dici che tipo di linguaggi sono, o meglio da quale linguaggio derivano? Ti risparmio la fatica: dal C++. L'HSLS è di Microsoft e serve per la programmazione delle GPU DX9 e utilizza una sintassi di tipo C; il CG lo dice il nome stesso. Sai che puoi programmare qualunque cosa in qualunque linguaggio, purchè si abbia a disposizione un interprete o un compilatore? E sai che il C e i suoi derivati sono i linguaggi più usati dai programmatori di tutto il mondo? E ne conosci anche il motivo? Inoltre CG e HLSL non sono alternativi l'uno all'altro ma l'interprete HLSL è già incluso nelle DX9 e il CG si interfaccia con esso. Inoltre dovresti conoscere anche Rendermonkey, sviluppato da ATI e 3DLabs, che opera sugli shader, in ambito OpenGL, in maniera analoga a quanto fa il CG.
Ti sei preparato su Topolino?
Originally posted by "DoomIII"
vertamente sei tu che non sai cosa sia una funzione... e che mentre parlo di programmazione e di funzioni FF a disposizione confondi con tutt'altro...
Cosa sia il Cg lo so molto bene... ma ti ripeto che sono una possibilità di programmazione per gli shader... poi per carità... se vuoi fare il sapientone dimostrando di sapere il significato di Cg... lol...
Meno male. Ti sto chiedendo da un secolo di parlarmi di queste benedette funzioni e tu continui con queste menate sugli shader e sulle FF senza definirmi né gli uni né le altre (salvo dire che non sono funzioni matematiche). Mi sembri uno dei nostri bravi politici che continuano a dire "non siamo questo, non siamo quello" ma non dicono mai cosa sono :D
Originally posted by "DoomIII"
sinceramente questo non dovrebbe avere nessuna importanza... non mi piace questo cercare un confronto su 'etichette'... ad ogni modo su questi forum cerco di non andare mai sul personale... famiglia&lavoro&studi&amici&ecc...
Scusami se ho urtato la tua suscettibilità; era soltanto per valutare il tuo tipo di preparazione (che non mi sembra di stampo scientifico)
Originally posted by "DoomIII"
hmm... hai presente quei bei giochini di una volta da sala giochi? sarebbe bello giocarci su PC... però non sono compatibili... ooooo esiste il mame...
l'incompatibilità di cui parlo resta ed è evidente perchè in un contesto shader un'instruzione FF è incompatibile. Questo ovviamente non significa che io non possa uscire da quel contesto e difatti per questo parlo di differenza tra FF e shader riferita alla programmazione...
in un programma shader non inserirai chiamate a funzioni FF... per quanto nel gioco poi ci possano effettivamente essere.
Questa me la sono lascita per ultima. Ti ripeto: sull'NV25 è stato eliminato il T&L statico (che non esiste più neppure sull'R300 e sull'NV30): come fanno questi chip a far girare giochi DX7, visto l'incompatibilità esistente tra FF e shaders? Se invece, l'unità T&L ce l'hanno tutte (FX compresa) allora come mai le prestazioni sono tanto diverse (al massimo possono avere un'unità T&L ciascuno per non occupare troppo spazio con cose inutili o quasi)? Inoltre, se anche l'FX ha un'unità T&L e, ovviamente, tutti i chip DX8 e DX9 hanno anche le unità shaders oriented (al pari dell'FX), dove starebbe tutta quest'innovazione introdotta dall'NV30 (che avrebbe un'architettura esattamente identica agli altri)?
Almeno a una domanda cerca di rispondere!
:D
yossarian
05-05-2003, 03:23
Originally posted by "DoomIII"
non ho mai detto di essere contrario...
da DX7 a 8 però... cioè da T&L/FF a shader c'è un grande passo... e ci sono molte differenze...
la situazione attuale di software non permette cmq di poter valutare la bontà di una scheda grafica su questo profilo...
Del resto per quanto riguarda NV30 o R300 ho sempre detto che da utenti se non si ha la stretta necessità di cambiare scheda video in questo momento non c'è proprio motivo per farlo... visto che software appropriato non c'è.
Però è anche insulso giudicare queste nuove schede basandosi principalmente su software non shader-oriented.
E' esattamente da qui che sei partito. Nei test con SW shader oriented (gli advanced PS e VS di 3DMark) i risultati parlano fin troppo chiaro.
La necessità di cambiare scheda video, in realtà non esisterebbe quasi mai se ci si basasse sul SW (a detta tua, non essendoci titoli shader oriented, una scheda DX7 va ancora più che bene, anche se poi, all'atto pratico, non è così).
Ma anche a quest'ora state a scannarvi su ste cose??? ma cazzarola...
abbassiamo di una tacca il livello di aggressività delle discussione.. tnx
>bYeZ<
voglio il numero di telefono del vostro pusher!!! :)
:)
yossarian
05-05-2003, 11:46
Originally posted by "FreeMan"
Ma anche a quest'ora state a scannarvi su ste cose??? ma cazzarola...
abbassiamo di una tacca il livello di aggressività delle discussione.. tnx
>bYeZ<
Un altro nottambulo?
Benvenuto nel club
:D
Comunque hai ragione, anzi, ti dirò, per quanto mi riguarda, questa discussione si può anche chiudere qui, tanto non ha senso continuarla.
Originally posted by "YURE"
voglio il numero di telefono del vostro pusher!!! :)
:)
basta avere il fisico...
http://forum.ngi.it/images/smilies/gmorning.gif .. http://smilies.sofrayt.com/%5E/l0/redeyes.gif ..pork
:D
>bYeZ<
Originally posted by "yossarian"
Ok genio, mi definisci cosa sono CG e HLSL? E mi dici che tipo di linguaggi sono, o meglio da quale linguaggio derivano? Ti risparmio la fatica: dal C++. L'HSLS è di Microsoft e serve per la programmazione delle GPU DX9 e utilizza una sintassi di tipo C; il CG lo dice il nome stesso. Sai che puoi programmare qualunque cosa in qualunque linguaggio, purchè si abbia a disposizione un interprete o un compilatore? E sai che il C e i suoi derivati sono i linguaggi più usati dai programmatori di tutto il mondo? E ne conosci anche il motivo? Inoltre CG e HLSL non sono alternativi l'uno all'altro ma l'interprete HLSL è già incluso nelle DX9 e il CG si interfaccia con esso. Inoltre dovresti conoscere anche Rendermonkey, sviluppato da ATI e 3DLabs, che opera sugli shader, in ambito OpenGL, in maniera analoga a quanto fa il CG.
Ti sei preparato su Topolino?
...
...
...
Almeno a una domanda cerca di rispondere!
:D
visto che alzi solo polvere... è inutile che tu cerchi di fare il saputello... il punto è che tu hai detto che gli shader non si possono programmare e non si programmano in assembler ma in C.
HAI SBAGLIATO!!! adesso non serve che ti arrampichi sugli specchi o che tu faccio considerazioni varie... i fatti restano e gli shader come ho detto io si programmano in una sorta di assembler oppure in Cg o tramite HLSL.
Sei tu quello che non risponde perchè in errore svii sempre l'argomento alzando polvere e seppur dimostrando una certa conoscenza la usi soltanto per deviare l'argomento dagli errori che dici.
Occorre scrivete tutte queste righe per cercare di mascherare il fatto che hai sbagliato? Gli shader se un programmatore vuole li programma in assembler ( e fino a poco tempo fa non aveva altra scelta).
Originally posted by "yossarian"
...
...
Diciamo che la FF sono i parametri e gli shader le funzioni. Nota bene: dalle funzioni ricavo i parametri. Le DX7 permettevano di operare solo in maniera parametrica, mentre le DX8 permettono di operare utilizzando le funzioni da cui i parametri si ricavano. Una funzione permette di ottenere infiniti set di parametri, semplicemente variando le condizioni al contorno. La differenza è tutta qui.
...
...
E smetti di fantasticare :D :)
Le FF sono le funzioni parametrizzabili a disposizione dei programmatori.
Gli shader sono le istruzioni con i quali potersi costruire le funzioni necessarie.
inutile che ci giri attorno... chiunque può fare una ricerca su internet e verificare che le cose stanno così... indipendetemente da ciò che tu scrivi cercando di mettere in luce una tua profonda conoscenza sull'argomento.
Originally posted by "yossarian"
Questa me la sono lascita per ultima. Ti ripeto: sull'NV25 è stato eliminato il T&L statico (che non esiste più neppure sull'R300 e sull'NV30): come fanno questi chip a far girare giochi DX7, visto l'incompatibilità esistente tra FF e shaders? Se invece, l'unità T&L ce l'hanno tutte (FX compresa) allora come mai le prestazioni sono tanto diverse (al massimo possono avere un'unità T&L ciascuno per non occupare troppo spazio con cose inutili o quasi)? Inoltre, se anche l'FX ha un'unità T&L e, ovviamente, tutti i chip DX8 e DX9 hanno anche le unità shaders oriented (al pari dell'FX), dove starebbe tutta quest'innovazione introdotta dall'NV30 (che avrebbe un'architettura esattamente identica agli altri)?
Almeno a una domanda cerca di rispondere!
:D
questo è il fumo che tu alzi... io dico che nel NV20 è stato incluso il T&L/FF per compatibilità e tu rispondi: noo, non è vero nel NV25 è stato tolto... :D
allora, hmm... diciamo un programmini piccolo piccolo e banalissimo in visualbasic... funziona lo stesso codice in c++?
no, no sono compatibili però posso ottenere lo stesso identico risultato... il fatto che abbia 2 programmi che eseguono la stessa identica cosa significa che i 2 linguaggi corrispondenti sono compatibili? assolutamente no...
il nostro bel pc è compatibile con i vecchi giochi arcade del mame? o con altre console... snes... play1 ecc....?
no, eppure posso farci girare lo stesso il software...
sono compatibili? no, ci faccio girare un'emulatore... ma questo non cambia la sostanza...
similmente tra vecchio T&L/FF e shader non c'è compatibilità hw... ma le funzioni che FF da a disposizione agli sviluppatori possono ovviamente essere scritte come shader... cioè sequenza di istruzioni con lo scopo di eseguire lo stesso risultato che si otteneva con l'FF.
yossarian
05-05-2003, 12:31
Originally posted by "DoomIII"
visto che alzi solo polvere... è inutile che tu cerchi di fare il saputello... il punto è che tu hai detto che gli shader non si possono programmare e non si programmano in assembler ma in C.
HAI SBAGLIATO!!! adesso non serve che ti arrampichi sugli specchi o che tu faccio considerazioni varie... i fatti restano e gli shader come ho detto io si programmano in una sorta di assembler oppure in Cg o tramite HLSL.
Sei tu quello che non risponde perchè in errore svii sempre l'argomento alzando polvere e seppur dimostrando una certa conoscenza la usi soltanto per deviare l'argomento dagli errori che dici.
Occorre scrivete tutte queste righe per cercare di mascherare il fatto che hai sbagliato? Gli shader se un programmatore vuole li programma in assembler ( e fino a poco tempo fa non aveva altra scelta).
Non ho mai detto che NON SI POSSONO PROGRAMMARE IN ASSEMBLER ma semplicemente CHE SI PROGRAMMANO IN C: non è la stessa cosa.
Originally posted by "yossarian"
E' esattamente da qui che sei partito. Nei test con SW shader oriented (gli advanced PS e VS di 3DMark) i risultati parlano fin troppo chiaro.
La necessità di cambiare scheda video, in realtà non esisterebbe quasi mai se ci si basasse sul SW (a detta tua, non essendoci titoli shader oriented, una scheda DX7 va ancora più che bene, anche se poi, all'atto pratico, non è così).
per primo ricordo che ho sempre parlato di opinione personale e non ho mai detto comperate l'NV30 perchè l'R300 fa schifo... ed ho sempre detto che la mia preferenza NV30 non è certo da 'normale utente'...
da qui quello che ho detto indicando come non mi sembra il caso in questo momento, salvo se c'è la stretta necessità o la possibilità, di acquistare una nuova scheda grafica.
Ho già detto come sono stati principalmente i pixel shader ad essere sfruttati (effetti non disponibili a chi non ha l'hw)... e il tuo generalizzare non ha senso... se dico che IMHO adesso chi non ha bisogno di cambiare scheda grafica farebbe meglio ad aspettare... non puoi 'accusarmi' di dire che secondo me bastano ancora le schede DX7.
Per quanto riguardo il tuo caro 3DMark... personalmente lo ritengo semplicemente insulso... ma anche buono...
buono perchè presenta test in grado di valutare il sotware attuale...
insulso perchè per valutare il software attuale non mi serve un 3DMark in quanto il software essendo attuale è li a disposizione e posso vedere direttamente quello come gira...
insulso perchè non serve a valutare le potenzialità nuove delle schede grafiche...
tutto rigorosamente IMHO
yossarian
05-05-2003, 12:41
Originally posted by "DoomIII"
questo è il fumo che tu alzi... io dico che nel NV20 è stato incluso il T&L/FF per compatibilità e tu rispondi: noo, non è vero nel NV25 è stato tolto... :D
allora, hmm... diciamo un programmini piccolo piccolo e banalissimo in visualbasic... funziona lo stesso codice in c++?
no, no sono compatibili però posso ottenere lo stesso identico risultato... il fatto che abbia 2 programmi che eseguono la stessa identica cosa significa che i 2 linguaggi corrispondenti sono compatibili? assolutamente no...
il nostro bel pc è compatibile con i vecchi giochi arcade del mame? o con altre console... snes... play1 ecc....?
no, eppure posso farci girare lo stesso il software...
sono compatibili? no, ci faccio girare un'emulatore... ma questo non cambia la sostanza...
similmente tra vecchio T&L/FF e shader non c'è compatibilità hw... ma le funzioni che FF da a disposizione agli sviluppatori possono ovviamente essere scritte come shader... cioè sequenza di istruzioni con lo scopo di eseguire lo stesso risultato che si otteneva con l'FF.
Se tu fossi meno presuntuoso presteresti ascolto alle parole altrui.
Dovresti sapere, visto che parli di C e VB qual è la differenza tra un interprete ed un compilatore.
In secondo luogo, mentre io ti rispondo, e lo faccio ancora, tu eviti di farlo perchè non sai cosa dire.
Nell'NV20 è stato incluso un TL statico semplicemente perchè le DX8 prevedevano inizialmente la programmabilità dei soli PS e VS, lasciando il resto inalterato. Il motivo principale dell'inserimento del TL statico è che l'NV20 ha un solo VS, quindi per avere la possibilità di far girare, senza perdita di prestazioni, rispetto ai chip della precedente generazione, titoli DX7, si è utilizzato un motore dello stesso tipo di quello della precedente generazioni. Nell'NV25, oltre all'aggiunta di una seconda unità VS è stato aggiunto un piccolo circuito che funziona da emulatore; questo affarino, non fa altro che trasformare, una volta opportunamente programmato, i codici FF in codici VS: in parole povere trasforma delle coordinate in vettori (visto che il VS opera appunto con dei vettori). Questo perchè la matematica non c'entra nulla con la programmazione.
Con questo ho veramente concluso.
Resta pure con le tue convinzioni.
Ciao
yossarian
05-05-2003, 12:45
Originally posted by "DoomIII"
per primo ricordo che ho sempre parlato di opinione personale e non ho mai detto comperate l'NV30 perchè l'R300 fa schifo... ed ho sempre detto che la mia preferenza NV30 non è certo da 'normale utente'...
da qui quello che ho detto indicando come non mi sembra il caso in questo momento, salvo se c'è la stretta necessità o la possibilità, di acquistare una nuova scheda grafica.
Ho già detto come sono stati principalmente i pixel shader ad essere sfruttati (effetti non disponibili a chi non ha l'hw)... e il tuo generalizzare non ha senso... se dico che IMHO adesso chi non ha bisogno di cambiare scheda grafica farebbe meglio ad aspettare... non puoi 'accusarmi' di dire che secondo me bastano ancora le schede DX7.
Per quanto riguardo il tuo caro 3DMark... personalmente lo ritengo semplicemente insulso... ma anche buono...
buono perchè presenta test in grado di valutare il sotware attuale...
insulso perchè per valutare il software attuale non mi serve un 3DMark in quanto il software essendo attuale è li a disposizione e posso vedere direttamente quello come gira...
insulso perchè non serve a valutare le potenzialità nuove delle schede grafiche...
tutto rigorosamente IMHO
Il 3DMark valuta il SW del futuro non quello attuale. Il 2003 è poco dipendente dalla cpu (come dovrebbe essere utilizzando una gpu per la sottosezione grafica), mentre il SW attuale dipende fortemente da questa.
Originally posted by "DoomIII"
E smetti di fantasticare :D :)
Le FF sono le funzioni parametrizzabili a disposizione dei programmatori.
Gli shader sono le istruzioni con i quali potersi costruire le funzioni necessarie.
inutile che ci giri attorno... chiunque può fare una ricerca su internet e verificare che le cose stanno così... indipendetemente da ciò che tu scrivi cercando di mettere in luce una tua profonda conoscenza sull'argomento.
beh ma da questo concetto yossarian dice che attraverso gli shader liberamente programmabili possono essere ricostruite anche le ff.
E a livello di pura logica, seguendo il vostro discorso, niente impedisce ad un "motore" (non saprei come altro chiamarlo) completamente programmabile di replicare una funzione fissa.
E per funzione qui intendo sia la funzione matematica di cui parla yossarian e di cui condivido il concetto di fondo per il quale ogni passaggio di programmazione che riguardi qualunque cosa è matematica, sia la funzione intesa nella sua accezione di "fungere per uno scopo, fare qualcosa per ottenere un risultato" su cui, a quanto ho capito, fa leva doom iii.
Milio
Ps. non posso, con rammarico, entrare nel merito di questa discussione che comunque vi assicuro è molto interessante anche se contiene tecnicismi a me incomprensibili; per questo, se possibile, non rispondetemi con tecnicismi troppo spintii.
Originally posted by "yossarian"
Non ho mai detto che NON SI POSSONO PROGRAMMARE IN ASSEMBLER ma semplicemente CHE SI PROGRAMMANO IN C: non è la stessa cosa.
OK, chiedo scusa... e che come dici giustamente tu io non capisco niente... pensa che sono così stupido che da quello che hai scritto qui
Originally posted by "yossarian"
Gli shader vengono programmati in C e non in assembler.
avevo capito tu stessi dicendo che gli shader non vengono programmati in assembler. :o :rolleyes:
Originally posted by "yossarian"
Non ho mai detto che NON SI POSSONO PROGRAMMARE IN ASSEMBLER ma semplicemente CHE SI PROGRAMMANO IN C: non è la stessa cosa.
Originally posted by "yossarian"
Gli shader vengono programmati in C e non in assembler.
:D :D :p
P.S.
vergogna... vabbè, almeno adesso lo sai come vengono programmati... è già un passo in più. :sofico:
Originally posted by "yossarian"
Comunque hai ragione, anzi, ti dirò, per quanto mi riguarda, questa discussione si può anche chiudere qui, tanto non ha senso continuarla.
E' un peccato yossarian.
Personalmente la trovo molto interessante, illuminante per alcuni versi :)
Milio
Originally posted by "Milion"
beh ma da questo concetto yossarian dice che attraverso gli shader liberamente programmabili possono essere ricostruite anche le ff.
E a livello di pura logica, seguendo il vostro discorso, niente impedisce ad un "motore" (non saprei come altro chiamarlo) completamente programmabile di replicare una funzione fissa.
Ciao :) e benvenuto ;)
Questo che dici è giusto... e l'ho sempre detto ma è a livello software non hardware.
Sono io che sto dicendo che con gli shader tramite il linguaggio di programmazione si possono realizzare 'varie funzioni' che operano ai vertici e logicamente si possono anche realizzare le stesse delle FF.
Ma la similitudine è nel risultato... in uno shader chiamate a funzioni FF non si possono fare...
Secondo yossarian gli shader hanno funzioni, hanno le stesse funzioni del FF più ancora altre.
Questo non è vero poichè gli shader hanno istruzioni con le quali comporre le 'funzioni' che si desiderano.
con FF abbiamo invece a disposizione un set precostituito di funzioni di tipo hard-coded(codificate nel silicio).
Originally posted by "Milion"
E per funzione qui intendo sia la funzione matematica di cui parla yossarian e di cui condivido il concetto di fondo per il quale ogni passaggio di programmazione che riguardi qualunque cosa è matematica, sia la funzione intesa nella sua accezzione di "fungere per uno scopo, fare qualcosa per ottenere un risultato" su cui, a quanto ho capito, fa leva doom iii.
Milio
Ps. non posso, con rammarico, entrare nel merito di questa discussione che comunque vi assicuro è molto interessante anche se contiene tecnicismi a me incomprensibili; per questo, se possibile, non rispondetemi con tecnicismi troppo spintii.
:cool: hhmm.. tranquillo... termini spinti non li usa nessuno... cmq la risposta è facile ... basta fare una ricerca in internet e vedrai che ho ragione :D
Originally posted by "yossarian"
...
...
Nell'NV25, oltre all'aggiunta di una seconda unità VS è stato aggiunto un piccolo circuito che funziona da emulatore; questo affarino, non fa altro che trasformare, una volta opportunamente programmato, i codici FF in codici VS: in parole povere trasforma delle coordinate in vettori (visto che il VS opera appunto con dei vettori). Questo perchè la matematica non c'entra nulla con la programmazione.
Con questo ho veramente concluso.
Resta pure con le tue convinzioni.
Ciao
fa molto ridere che questa tua risposta sia in risposta a questo mio post
Originally posted by "DoomIII"
il nostro bel pc è compatibile con i vecchi giochi arcade del mame? o con altre console... snes... play1 ecc....?
no, eppure posso farci girare lo stesso il software...
sono compatibili? no, ci faccio girare un'emulatore... ma questo non cambia la sostanza...
similmente tra vecchio T&L/FF e shader non c'è compatibilità hw... ma le funzioni che FF da a disposizione agli sviluppatori possono ovviamente essere scritte come shader... cioè sequenza di istruzioni con lo scopo di eseguire lo stesso risultato che si otteneva con l'FF.
cmq con quello che hai detto finalmente hai cambiato idea ed hai capito come stanno le cose... esattamente come per il discorso programmazione assembler...
con ciò che hai detto sopra ammetti che fisicamente in hw shader e T&L non sono direttamente compatibili... e quindi mi dai ragione visto che tu sostenevi il contrario.
yossarian
05-05-2003, 13:02
Originally posted by "DoomIII"
OK, chiedo scusa... e che come dici giustamente tu io non capisco niente... pensa che sono così stupido che da quello che hai scritto qui
avevo capito tu stessi dicendo che gli shader non vengono programmati in assembler. :o :rolleyes:
:D :D :p
P.S.
vergogna... vabbè, almeno adesso lo sai come vengono programmati... è già un passo in più. :sofico:
Ti ripeto che gli shader vengono programmati in C e non in assembler perchè il C è un linguaggio molto semplice (con poca sintassi) ed estremamente flessibile (permette di importare o di definire nuove funzioni).
Se poi qualcuno vuole programmare in assembler, sapendo che comunque anche l'assembler dovrà essere tradotto in LM è liberissimo di farlo.
Si può anche andare da Roma a Milano passando per Palermo
Originally posted by "yossarian"
Ti ripeto che gli shader vengono programmati in C e non in assembler perchè il C è un linguaggio molto semplice (con poca sintassi) ed estremamente flessibile (permette di importare o di definire nuove funzioni).
Se poi qualcuno vuole programmare in assembler, sapendo che comunque anche l'assembler dovrà essere tradotto in LM è liberissimo di farlo.
Si può anche andare da Roma a Milano passando per Palermo
per cortesia... ti stai semplicemente rendendo ridicolo...
Originally posted by "yossarian"
Non ho mai detto che NON SI POSSONO PROGRAMMARE IN ASSEMBLER ma semplicemente CHE SI PROGRAMMANO IN C: non è la stessa cosa.
Originally posted by "yossarian"
Gli shader vengono programmati in C e non in assembler.
Originally posted by "yossarian"
Ti ripeto che gli shader vengono programmati in C e non in assembler
ma lol :D :D :D :D
P.S.
senti dacci un taglio... la gente presuntuosa come te è un'insulto all'intelligenza... solo perchè lo dici tu tutti dovrebbero smettere di programmare gli shader in assembler?
ci sono programmatori che programmano gli shader in assembler...
a dimostrazione che sei nel torto chiunque può fare una ricerca in internet e scaricare dei sorgenti... vi troverà il codice scritto in assembler.
Logicamente ci saranno anche altri in Cg ecc...
perchè come ho detto io si programma in : assembler, Cg e HLSL.
Questo lo decide il singolo programmatore e non certo tu universalmente.
yossarian
05-05-2003, 13:08
Originally posted by "DoomIII"
fa molto ridere che questa tua risposta sia in risposta a questo mio post
cmq con quello che hai detto finalmente hai cambiato idea ed hai capito come stanno le cose... esattamente come per il discorso programmazione assembler...
con ciò che hai detto sopra ammetti che fisicamente in hw shader e T&L non sono direttamente compatibili... e quindi mi dai ragione visto che tu sostenevi il contrario.
Non mi pare di aver cambiato idea. Il problema è che tu continuavi a capire che un programma scritto utilizzando le coordinate dei vertici e le normali ai lati di un triangolo girassero senza modifiche su un circuito progettato per lavorare con i vettori. Credo sia colpa mia che davo per scontato che tu avessi familiarità con questi concetti matematici.
Quello che ti contestavo era semplicemente il discorso secondo il quale sembrava necessario avere un'unità T&L di tipo tradizionale anche sui chip di ultima generazione, per poter far girare programmi DX7. Adesso capisco anche perchè non mi rispondevi alla domanda : come fanno i giochi DX7 a girare su NV25 o R300 o NV30 che non hanno il TL "statico"?
yossarian
05-05-2003, 13:10
Originally posted by "DoomIII"
per cortesia... ti stai semplicemente rendendo ridicolo...
ma lol :D :D :D :D
P.S.
senti dacci un taglio... la gente presuntuosa come te è un'insulto all'intelligenza... .
Di quale intelligenza parli?
:D
yossarian
05-05-2003, 13:13
Originally posted by "DoomIII"
per cortesia... ti stai semplicemente rendendo ridicolo...
ma lol :D :D :D :D
P.S.
senti dacci un taglio... la gente presuntuosa come te è un'insulto all'intelligenza... solo perchè lo dici tu tutti dovrebbero smettere di programmare gli shader in assembler?
ci sono programmatori che programmano gli shader in assembler...
a dimostrazione che sei nel torto chiunque può fare una ricerca in internet e scaricare dei sorgenti... vi troverà il codice scritto in assembler.
Logicamente ci saranno anche altri in Cg ecc...
perchè come ho detto io si programma in : assembler, Cg e HLSL.
Questo lo decide il singolo programmatore e non certo tu universalmente.
C'è anche chi programma in LM (per fortuna)
Vedo che hai esaurito gli argomenti e sei passato alle offese. Bene, buon segno. :D
Però non continuare a ripetere sempre le stesse cose: sei noioso!!!!!!!!!
:D
p.s. se vai a farti un giro dalle parti di Microsoft puoi trovare sorgenti DX8 scritte in C++
yossarian
05-05-2003, 13:25
Originally posted by "Mecoita"
kirk tempo fa disse che le le FF delle dx7 erano gestite come un vertex program
Originally posted by "yossarian"
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).
Ti quoto semplicemente questi due post, di molto precedenti al tuo discorso sugli emulatori.
Per la cronaca, Kirk non è J T Kirk, capitano dell'USS Enterprise, ma David Kirk, capo progettista di nVIDIA.
Ora unisci questi alla domanda (sempre senza risposta) perchè l'NV25 non ha il T&L "statico" e trai le tue conclusioni.
Buon lavoro Sherlock Holmes, un saluto a Watson
:D
Originally posted by "yossarian"
C'è anche chi programma in LM (per fortuna)
Vedo che hai esaurito gli argomenti e sei passato alle offese. Bene, buon segno. :D
Però non continuare a ripetere sempre le stesse cose: sei noioso!!!!!!!!!
:D
p.s. se vai a farti un giro dalle parti di Microsoft puoi trovare sorgenti DX8 scritte in C++
non è colpa mia se cambi idea ad ogni post :D
e basta con ste alzate di fumo... capisco che siano il tuo stile ma non servono a niente se non a confondere l'idee di chi legge...
con queste alzate di fumo cerchi solo di dimostrare arrampicandoti sugli specchi di avere ragione... questo è il tuo modo di fare... si parla di una cosa dove non siamo d'accordo e tu poi applichi la tua opinione su altri argomenti non pertinenti...
io ho parlato di shader... in un programma(game o quello che si vuole) gli shader possono essere programmati in assembler oppure Cg o HLSL.
Poi il gioco può essere c++, visualbasic ecc... appoggiarsi alle DX o alle OpenGL... ma gli shader saranno scritti come ho indicato sopra.
Si parla di shader, non dimostri niente dicendo che ci sono programmi scritti in c++.
le macchine hanno le ruote, i mouse tasti e rotelline ed i programmi/giochi/ecc... sono scritti in vari linguaggi... ma questo non c'entra nulla con gli shader che sono scritti in Assembler, Cg o HLSL.
Originally posted by "yossarian"
Non mi pare di aver cambiato idea. Il problema è che tu continuavi a capire che un programma scritto utilizzando le coordinate dei vertici e le normali ai lati di un triangolo girassero senza modifiche su un circuito progettato per lavorare con i vettori....
...
...
basta leggere il primo post di questo thread e le cose che ti contesto... quello è l'argomento...
yossarian
05-05-2003, 13:36
Originally posted by "DoomIII"
non è colpa mia se cambi idea ad ogni post :D
e basta con ste alzate di fumo... capisco che siano il tuo stile ma non servono a niente se non a confondere l'idee di chi legge...
con queste alzate di fumo cerchi solo di dimostrare arrampicandoti sugli specchi di avere ragione... questo è il tuo modo di fare... si parla di una cosa dove non siamo d'accordo e tu poi applichi la tua opinione su altri argomenti non pertinenti...
io ho parlato di shader... in un programma(game o quello che si vuole) gli shader possono essere programmati in assembler oppure Cg o HLSL.
Poi il gioco può essere c++, visualbasic ecc... appoggiarsi alle DX o alle OpenGL... ma gli shader saranno scritti come ho indicato sopra.
Si parla di shader, non dimostri niente dicendo che ci sono programmi scritti in c++.
le macchine hanno le ruote, i mouse tasti e rotelline ed i programmi/giochi/ecc... sono scritti in vari linguaggi... ma questo non c'entra nulla con gli shader che sono scritti in Assembler, Cg o HLSL.
Di la verità hai studiato a memoria e ci hai capito poco!
Capita non te la prendere :D
Stavolta ti saluto proprio e definitivamente
Buona :mc:
:D
Hanamichi
05-05-2003, 13:37
Originally posted by "yossarian"
Di la verità hai studiato a memoria e ci hai capito poco!
Capita non te la prendere :D
Stavolta ti saluto proprio e definitivamente
Buona :mc:
:D
finalmente è finita! :D
li volevo svincolare in un altro discorso con il mio intervento quasi ot.. ma sono ricaduti nel girone infernale della cocciutagine orgogliosa :sofico:
mmazza che ho scritto? :confused: :sofico:
Originally posted by "yossarian"
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 :cry:
:D
"..se il linguaggio macchina è ad un livello superiore ai bit, per quale motivo si chiama LINGUAGGIO MACCHINA?.."
Certo che mi fai veramente :D !
Ma diavolo scrivi !!!
un susseguirsi di 0 e 1 NON è un linguaggio !!!! Se si chiama LINGUAGGIO MACCHINA allora non lavoro con 0 ed 1 !!!!!!
Pensa bene a quel che dici. :eek:
"..E dove collochiamo i linguaggi assemblatori o assembler che dir si voglia?).."
L'assembler è ad un livello sopra il LM.
LM :
mov eax,0201
mov ecx,1
mov edx,8
jmp 0Df0
ASM
mov eax, valore_1
mov ecx, valore_1+valore_2
mov edx, valore_3*2
jmp label_1
Esempio molto semplificato. In ASM posso usare label, macro, procedure etc.. un compilatore ed successivamente un linker mi genera il codice in puro LINGUAGGIO MACCHINA !
comprendi ?
"..Già il fatto che parli di corrente SI corrente NO.."
preferisci due livelli di tensione differenti ? Oppure tensione a 1mv e una a prossima a 0 ? Dimmi tu.
"..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).."
ok non è stampato nel silicio, ammetto che è un grossolano errore.
So perfettamente cos'è il silicio non ti impapocchiare :)
"..qualificano il tuo livello di preparazione.."
Beh ! Direi che ci vuole un grosso applauso ! Sei grande !!!
"... mentre il tuo modo di interloquire quantifica il tuo livello di intelligenza.."
Sei sicuro non parlare di te stesso ? Ho visto cervelli più grandi rispetto al tuo a forma di testa di chiodino. ( non ho iniziato io )
Comunque non venirmi ad insegnare cosa sia l'assembler , lascia perdere ;) .
yossarian
05-05-2003, 17:18
Originally posted by "nik666"
"..se il linguaggio macchina è ad un livello superiore ai bit, per quale motivo si chiama LINGUAGGIO MACCHINA?.."
Certo che mi fai veramente :D !
Ma diavolo scrivi !!!
un susseguirsi di 0 e 1 NON è un linguaggio !!!! Se si chiama LINGUAGGIO MACCHINA allora non lavoro con 0 ed 1 !!!!!!
Pensa bene a quel che dici. :eek:
"..E dove collochiamo i linguaggi assemblatori o assembler che dir si voglia?).."
L'assembler è ad un livello sopra il LM.
LM :
mov eax,0201
mov ecx,1
mov edx,8
jmp 0Df0
ASM
mov eax, valore_1
mov ecx, valore_1+valore_2
mov edx, valore_3*2
jmp label_1
Esempio molto semplificato. In ASM posso usare label, macro, procedure etc.. un compilatore ed successivamente un linker mi genera il codice in puro LINGUAGGIO MACCHINA !
comprendi ?
"..Già il fatto che parli di corrente SI corrente NO.."
preferisci due livelli di tensione differenti ? Oppure tensione a 1mv e una a prossima a 0 ? Dimmi tu.
"..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).."
ok non è stampato nel silicio, ammetto che è un grossolano errore.
So perfettamente cos'è il silicio non ti impapocchiare :)
"..qualificano il tuo livello di preparazione.."
Beh ! Direi che ci vuole un grosso applauso ! Sei grande !!!
"... mentre il tuo modo di interloquire quantifica il tuo livello di intelligenza.."
Sei sicuro non parlare di te stesso ? Ho visto cervelli più grandi rispetto al tuo a forma di testa di chiodino. ( non ho iniziato io )
Comunque non venirmi ad insegnare cosa sia l'assembler , lascia perdere ;) .
Dopo Gianni rispunta pure Pinotto
Ti faccio copia/incolla da un corso di programmazione
Linguaggi interpretati e linguaggi compilati
I linguaggi di programmazione tendono ad assomigliare ai linguaggi naturali (quelli usati dall'uomo) proprio per rendere più facile la programmazione del computer. Il computer invece "capisce" un suo linguaggio fatto esclusivamente da numeri, anzi, da sequenze di cifre binarie 1 e 0.
Questo linguaggio binario si chiama "linguaggio macchina" e all'uomo risulterebbe difficilissimo da imparare.
10010111011100011101110010110001001111110010111101000101
facile no?
I primi computer, si basavano esclusivamente sul linguaggio macchina e il loro schermo era un piccolo led che mostrava dei "pacchetti" di cifre binarie. Il programmatore utilizzava una tabella che serviva per tradurre i comandi nella serie corrispondente di cifre binarie da inserire. Un lavoraccio da certosini. E bastava sbagliare una cifra per mettere in crisi tutto il sistema. I giochini per computer non se li immaginavano nemmeno!
questo è un estratto da un altro corso di programmazione
La programmazione
Storicamente, quando nacquero gli elaboratori, l'unico modo di far comprendere loro un programma era quello di specificarlo nel loro stesso linguaggio, cioè il "linguaggio macchina": un linguaggio fatto solo di bit e di byte, in cui ogni operazione aveva un codice binario di identificazione e in cui ogni quantità, numerica o alfabetica, doveva essere caratterizzata dall'indirizzo dei byte di memoria centrale che la contenevano. Questo rendeva la programmazione un lavoro da specialisti. Il linguaggio macchina è il linguaggio programmativo della 1° generazione.
Ben presto si passò ai linguaggi della 2° generazione, cioè ai cosiddetti "linguaggi simbolici". Ai byte si sostituirono dei codici convenzionali, diversi a seconda del ruolo svolto: ad esempio se il byte {01010101} denotava la somma, esso si indicò con il codice ADD, facile da ricordare. I linguaggi simbolici snellirono di molto la programmazione ed in effetti sono talvolta usati ancora oggi; di solito sono detti "linguaggi assemblatori" ed essendo analoghi al linguaggio macchina permettono una programmazione particolarmente efficiente. Anche questi linguaggi sono comunque linguaggi da specialisti mentre gli elaboratori avevano sempre più l'esigenza di rivolgersi anche a persone non specialiste del settore.
Si arrivò così ai linguaggi della terza generazione, detti "linguaggi algebrici", che possono essere utlizzati anche da persone senza una profonda conoscenza dell'informatica. Il nome di questi linguaggi deriva dal fatto che in essi è possibile scrivere un'espressione quasi come si scrive in algebra e che l'elaboratore è in grado di riconoscere e tradurre nel proprio linguaggio macchina. I linguaggi algebrici sono quelli a tutt'oggi più usati, anche se sono stati sviluppati i linguaggi della 4° e della 5° generazione.
Inoltre ti comunico di aver personalmete scritto programmi in linguaggio macchina; di conseguenza le tue lezioni valle a impartire a chi è più ignorante di te (e non giocare con le correnti....pardon le tensioni, soprattutto con la 220 V alternata) :sofico:
Infine di linguaggi assemblatori non ne esiste uno solo, ma qualcuno di più, mentre di LM ce nìè uno (tutti gli altri son nessuno :pig: ): Comunque bel pasticcio di esempio che hai fatto!
Con questo concludo anche con te (puoi sempre continuare la discussione con DoomIII, penso che assumerebbe toni interessanti)
:D
Direi che il binario della discussione è completamente andato a quel paese...
CLOSED!!!
>bYeZ<
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.