Vertex Shader (&pixel)

[yossarian]

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

[DoomIII]

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.

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]

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.

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!

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?

[DoomIII]

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!

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 ... 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
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

[R@nda]

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.

[DoomIII]

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]

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 ... 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
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]

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

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!

[yossarian]

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ì).

[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<

[YURE]

voglio il numero di telefono del vostro pusher!!!

[yossarian]

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



Comunque hai ragione, anzi, ti dirò, per quanto mi riguarda, questa discussione si può anche chiudere qui, tanto non ha senso continuarla.

[FreeMan]

Originally posted by "YURE"

voglio il numero di telefono del vostro pusher!!!

basta avere il fisico...

.. ..pork



>bYeZ<

[DoomIII]

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!

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).

[DoomIII]

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

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.

[DoomIII]

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!

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...

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]

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.

[DoomIII]

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]

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...

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]

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.