Link alla notizia: http://news.hwupgrade.it/10539.html

Nuovi tool di sviluppo disponibili per gli sviluppatori Open GL; introdotto l'OpenGL Shading Language come alternativa ai linguaggi shading specifici per API DirectX

Click sul link per visualizzare la notizia.

Non metterei sullo stesso piano cg con opengl o directx
Il cosidetto cg è stato un tentativo di produrre un compilatore in grado di generare del codice atto a colmare (fra l'altro) la carenza di performance dei pixel shader sulle schede nvidia di ultima generazione.
Certo queste "ottimizzazioni" spesso e volentieri sono legate a perdite qualitative come quando nvidia ha sostituito i pixel shader 2.0 del 3dmark 2003 (test mother nature) con una versione "proprietaria".

Se vi sembro polemico la pianto li subito, a me non ne viene niente...

uno risulta polemico quando si inventa o si arrampica sugli specchi :mc: pur di aver ragione, in questo caso come in altri hai detto solo la vrita', ed è giusto che tutti sappiano le verita'...almeno quelli meno informati;)

Concordo con te pg08x! CG è un mini linguaggio di programmazione, mentre DX e OpenGL sono delle interfacce(S.W.) grafiche...

non ci vedevo niente di male nel CG, è un linguaggio di programmazione free che magari dava una mano nell'ottimizzazione del codice, cosa che si fa già, peccato che le schede conil supporto al cg non fossero troppo valide.

Cg, a detta di Nvidia, non e' un linguaggio ma un toolset (compilatore e tool di supporto per i pacchetti di modellazione) che compila un linguaggio compatibile con HLSL. Di fatto, il linguaggio di programmazione e' proprio HLSL con qualche piccola aggiunta proprietaria.

Quello che ha detto pg08x e' sostanzialmente giusto a parte un'imprecisione: le ottimizzazioni che il compilatore nvidia e' in grado di effettuare non portano ad una perdita qualitativa dal lato visivo. Ad esempio, nvidia afferma che il compilatore Cg e' in grado di produrre codice che fa uso di meno registri temporanei, cosa che rende generalmente piu' veloce da eseguire il pixel shader.

non sono polemice, ma dati di fatto. I meno informati possono anche muovere il cul@ e controllare se dici il vero o il falso. :)

FALSO e certo che sono polemiche...!!!
mi verrebbe da chiedere se sapete leggere... o_O
Si parla di un nuovo linguaggio ad alto livello per lo shading introdotto nelle Open GL 1.5...
è questo linguaggio che viene paragonato (visto che ne condivide gli scopi) al Cg e al HLSL.
nessuno sta paragonando le OpenGL o le DX al CG e non c'è motivo di farlo... se non quello di essere ignoranti! e non è un offessa verso nessuno... è quella che può essere normale ignoranza di chi non sa cosa siano OpenGL, DX ed HLSL, Cg.... e che quindi fa un po di confusione...
non scateniamo quindi inutili polemiche ;)

io ho postato l'altro ieri la notizia sul forum ...
http://forum.hwupgrade.it/showthread.php?threadid=494770

... forse non interessa ancora questa release a nessuno :)

Originariamente inviato da DoomIII
FALSO e certo che sono polemiche...!!!
mi verrebbe da chiedere se sapete leggere... o_O
Si parla di un nuovo linguaggio ad alto livello per lo shading introdotto nelle Open GL 1.5...
è questo linguaggio che viene paragonato (visto che ne condivide gli scopi) al Cg e al HLSL.
nessuno sta paragonando le OpenGL o le DX al CG e non c'è motivo di farlo... se non quello di essere ignoranti! e non è un offessa verso nessuno... è quella che può essere normale ignoranza di chi non sa cosa siano OpenGL, DX ed HLSL, Cg.... e che quindi fa un po di confusione...
non scateniamo quindi inutili polemiche ;)

Mi sa che sei tu a fare confusione...
Stiamo parlando di un'evoluzione dello standard OpenGl.
Per mantenere OpenGl ai passi con i tempi un consorzio indipendente aveva sviluppato le estensioni Arb adesso l'openGl come standard è passato alla nuova versione 1.5 che oltre a includere le caratteristiche prima accessibili solo con Arb include diverse caratteristiche totalmente nuove.
A livello di API è stato sviluppato quindi un nuovo linguaggio per accedere a queste caratteristiche (linguaggio che rende obsolete le estensioni arb).
Morale della favola stiamo parlando di effetti 3d totalmente nuovi che andranno supportati via hardware dalla PROSSIMA GENERAZIONE di schede video.

Se leggi bene: "OpenGL 1.5, and the OpenGL Shading Language in particular, does for the next generation of graphics what OpenGL did for the first generation in the early '90s. It will fundamentally change the industry," said Shawn Underwood, director of marketing, Visual Systems Group, SGI"

Quindi così come adesso abbiamo delle schede video directX9 compliant in futuro avremo, ipotizzo, schede video directx10 ed OpenGl 1.5 compliant.

Come puoi vedere il cg non c'entra proprio niente !

Francamente nutro dei forti dubbi sulla "ottimizzazione" del codice effettuata del Cg: è comunque un compilatore ad alto livello, per cui il codice finale è quasi sempre meno "ottimizzato" dell'equivalente scritto da un programmatore "assembly/shader" esperto...

OpenGl 1.5 è un'evoluzione dello standard per supportare nuovi effetti che verranno implementati via hardware. cg è un compilatore ad alto livello nato per sfruttare alcune caratteristiche delle schede nvidia al fine di colmarne alcune carenze.

Alla fine fatemi capire, ho una scheda che fa l'OpenGL 2.0 e me ne serve una nuova per fare l'1.5 oppure sto dicendo cazzate?

Originariamente inviato da WarDuck
Alla fine fatemi capire, ho una scheda che fa l'OpenGL 2.0 e me ne serve una nuova per fare l'1.5 oppure sto dicendo cazzate?

L'OpenGl 2.0 è uno standard ancora in via di definizione. Le schede che supportano pixel shader e vertex shader programmabili saranno compatibili con tale standard attraverso un aggiornamento dei drivers ma suppongo si tratti di una sorta di "emulazione" non di un supporto per così dire "nativo".

Originariamente inviato da cdimauro
Francamente nutro dei forti dubbi sulla "ottimizzazione" del codice effettuata del Cg: è comunque un compilatore ad alto livello, per cui il codice finale è quasi sempre meno "ottimizzato" dell'equivalente scritto da un programmatore "assembly/shader" esperto...

Quello che dici e' parzialmente vero. In generale, un programmatore assembly esperto puo' sempre produrre codice migliore, sotto diversi punti di vista, di un qualunque compilatore perche' il programmatore ha accesso all'algoritmo che sta implementando e puo' sempre usare ottimizzazione ad hoc speculando proprio sull'algoritmo. Il compilatore non ha ovviamente accesso all'algoritmo nella testa del programmatore ma puo' solo cercare di "indovinarlo". Ha comunque una visione d'insieme piu' limitata. Il programmatore gioca in casa in questo caso.

Ma nel caso degli shader, la situazione e' un po' diversa, perche' il linguaggio ad alto livello (HLSL o quello di OpenGL15) e' molto specifico per la programmazione degli shader, per l'appunto, e lavora in un ambiente piu' ristretto e controllabile rispetto ad un generico compilatore. Ha inoltre accesso ad alcune informazioni specifiche dell'architettura hardware per la quale deve produrre codice, informazioni che non sono in possesso del programmatore, ad esempio perche' non sono rivelate da ATI e NVIDIA :)

Qual e' la migliore sequenza di istruzioni e il miglior ordine per effettuare l'operazione X sulla scheda Y? Normalmente il programmatore non puo' saperlo, mentre il compilatore si'.

Inoltre, una buona fetta delle ottimizzazioni in un pixel shader, ad esempio, si gioca sul numero di cosi' detti registri temporanei usati dallo shader. E' un vero incubo per un programmatore minimizzare il numero di registri temporanei in uso dall'algoritmo perche' il cervello umano fa molta fatica ad avere una visione d'insieme di tutte le istruzioni assembly di uno shader, mentre e' ottimo ad astrarre l'algoritmo. Per il compilatore e' il contrario: e' ottimo a tenere traccia delle istruzioni e dei registri che usano cosi' da minimizzarli, ma e' scarso, anzi gli e' impossibile, ad astrarre l'algoritmo.

In sintesi, nel caso degli shader, e' il compilatore a giocare in casa e spesso e volentieri riesce a produrre codice migliore di quello che puo' fare un programmatore anche esperto che decide di non spendere giorni interi nell'ottimizzare un singolo shader (anche perche' spesso non li ha), per poi trovarsi nella maggior parte dei casi con un codice equivalente a quello prodotto dal compilatore e molto raramente migliore. Il gioco non vale la candela.

Le performance delle geforce fx risentono pesantemente dell'ordine di utilizzo delle istruzioni dello shader, molto più di quanto avvenga per la concorrente che risulta essere decisamente più "flessibile".
Questo voler imporre i tapulli ai propri deficit progettuali e pubblicizzarli come un superpompato standard di programmazione (mi riferisco al cg) che debba essere usato da tutti mi sembra a dir poco arrogante.

La tua prima affermazione e' senz'altro vera, ma la seconda mi sembra una critica eccessiva.
Cg e' stato proposto da nvidia come un toolset, non certo come uno standard di programmazione (che per altro non e' e non vuole essere) e la trovo un'idea legittima, perche' effettivamente fa quello per il quale e' stato pensato: ottimizza shader scritti in hlsl meglio del compilatore ufficiale microsoft. Oltre a questo, nel toolset vengono forniti interessanti plugin per i piu' popolari pacchetti di modellazione per la preview di shader scritti in HLSL (preferisco sempre usare il nome HLSL perche' piu' corretto di Cg).

Ti posso dire che questi tool sono un ottimo e gratuito aiuto agli sviluppatori da parte di nvidia e ben vengano. Anche ATI fornisce un supporto agli sviluppatori simile, ma un po' piu' limitato, perche' preferisce concentrarsi piu' sullo standardo dettato da Microsoft (DirectX): una scelta che personalmente apprezzo perche' semplifica la vita a noi programmatori.

Riguardo la flessibilita' della quale parlavi, dal punto di vista puramente architetturale, l'implementazione dei pixel shader nvidia e' decisamente piu' flessibile di quella ati (supporto per i predicati, branch dinamico, 16/32 bit di precisione) e meno performante soprattutto a 32 bit di precisione.

Originariamente inviato da pg08x
Mi sa che sei tu a fare confusione...
Stiamo parlando di un'evoluzione dello standard OpenGl.
Per mantenere OpenGl ai passi con i tempi un consorzio indipendente aveva sviluppato le estensioni Arb adesso l'openGl come standard è passato alla nuova versione 1.5 che oltre a includere le caratteristiche prima accessibili solo con Arb include diverse caratteristiche totalmente nuove.
A livello di API è stato sviluppato quindi un nuovo linguaggio per accedere a queste caratteristiche (linguaggio che rende obsolete le estensioni arb).
Morale della favola stiamo parlando di effetti 3d totalmente nuovi che andranno supportati via hardware dalla PROSSIMA GENERAZIONE di schede video.

Se leggi bene: "OpenGL 1.5, and the OpenGL Shading Language in particular, does for the next generation of graphics what OpenGL did for the first generation in the early '90s. It will fundamentally change the industry," said Shawn Underwood, director of marketing, Visual Systems Group, SGI"

Quindi così come adesso abbiamo delle schede video directX9 compliant in futuro avremo, ipotizzo, schede video directx10 ed OpenGl 1.5 compliant.

Come puoi vedere il cg non c'entra proprio niente !

non c'entra con le OpenGL nel senso che non si può confrontare le Dx o le OpenGL con il Cg... :eek:

poi per quanto riguarda:
OpenGL Shading Language v. 1.0: as official extensions more specifically, shader objects, vertex shaders, and fragment shaders, all for use of programmable shader hardware


questo si che può essere paragonato al HLSL o Cg...

Originariamente inviato da fek
La tua prima affermazione e' senz'altro vera, ma la seconda mi sembra una critica eccessiva.
Cg e' stato proposto da nvidia come un toolset, non certo come uno standard di programmazione (che per altro non e' e non vuole essere) e la trovo un'idea legittima, perche' effettivamente fa quello per il quale e' stato pensato: ottimizza shader scritti in hlsl meglio del compilatore ufficiale microsoft. Oltre a questo, nel toolset vengono forniti interessanti plugin per i piu' popolari pacchetti di modellazione per la preview di shader scritti in HLSL (preferisco sempre usare il nome HLSL perche' piu' corretto di Cg).

Ti posso dire che questi tool sono un ottimo e gratuito aiuto agli sviluppatori da parte di nvidia e ben vengano. Anche ATI fornisce un supporto agli sviluppatori simile, ma un po' piu' limitato, perche' preferisce concentrarsi piu' sullo standardo dettato da Microsoft (DirectX): una scelta che personalmente apprezzo perche' semplifica la vita a noi programmatori.

Riguardo la flessibilita' della quale parlavi, dal punto di vista puramente architetturale, l'implementazione dei pixel shader nvidia e' decisamente piu' flessibile di quella ati (supporto per i predicati, branch dinamico, 16/32 bit di precisione) e meno performante soprattutto a 32 bit di precisione.

Riguardo alla "flessibilità" non mi riferivo alla quantità di istruzioni non richieste e non standard implementate dall'hardware, cosa me ne faccio se poi le performance "crollano" quando lo shader non viene scritto tenendo conto di 1000 assurdi parametri legati a quella specifica gpu.

Il cg, questo "toolset", ha lo scopo unico di fare sviluppare codice che favorisca le schede nvidia, a danno delle altre, se in nvidia non si fossero trovati costretti a tentare questo approccio per incoraggiare gli sviluppatori verso un'ottimizzazione altrimenti complicatissima e lunghissima da implementare non avrebbero cercato di abbellire con varie features lo strumentino ne tantomeno lo avrebbero reso disponibile, per non parlare di farlo "gratuitamente".

(prova ad andare a dire al responsabile commerciale che il tuo team è indietro di mesi in un progetto)

L'unico modo per favorire la vita a noi programmatori è quello di concentrarsi sullo standard come fa ATI e sono felice che anche tu lo apprezzi.

Immagina un po se ci fossero 5 produttori di schede video sul mercato ognuno con un 20% dell'utenza e tutti e 5 si comportassero come stà facendo adesso nvidia.

Per sviluppare un titolo impiegheresti molto più tempo e spenderesti molto più denaro/ risorse.

L'allontanarsi dagli standard è un grave limite allo sviluppo di una vera concorrenza, a danno degli utenti finali e di chi sviluppa software.

Questo fregarsene dello standard a mio avviso è stato addirittura voluto, se nvidia fosse riuscita ad avere pronto il progetto geforce fx in un momento in cui fosse stata leader indiscussa del mercato avrebbe dettato lo standard a proprio uso e consumo per tutti gli anni a venire rendendo di fatto inattaccabile una propria posizione di monopolio.

ciao fek, sono massimo , giocavo negli FC di bf un po di tempo fa, ti ricordi :) ?


comunque io avevo sentito che su 3dmark2003 il problema è che il pixel shader di nvidia funziona appunto a 16 o 32 bit di precisione (come ha detto fek), mentre gli shader di 3dmark richiedono "solo" 24 bit di precisione.

le radeon supportano 24 bit e quindi lavorano a 24 bit di precisione, mentre nvidia non supportando 24 bit di precisione, per far andare 3dmark è costretta a fare andare le fx a 32 bit di precisione, sacrificando ovviamente le prestazioni.


era vera questa storia ?

Originariamente inviato da pg08x
Il cg, questo "toolset", ha lo scopo unico di fare sviluppare codice che favorisca le schede nvidia, a danno delle altre, se in nvidia non si fossero trovati costretti a tentare questo approccio per incoraggiare gli sviluppatori verso un'ottimizzazione altrimenti complicatissima e lunghissima da implementare non avrebbero cercato di abbellire con varie features lo strumentino ne tantomeno lo avrebbero reso disponibile, per non parlare di farlo "gratuitamente".

Ma e' nel pieno diritto di nvidia rilasciare un compilatore HLSL che produce codice migliore per la piattaforma e ne sono felice! Ancora di piu' se questo viene messo a disposizione gratuitamente. Non vedo tutta questa malafede che vedi tu, e' un tool in piu' messo a disposizione, il linguaggio non cambia (e qui direi che cadono tutte le altre critiche che hai portato) quindi non e' un vero e proprio allontanarsi dallo standard HLSL, ma semplicemente fornire un supporto ulteriore. Io programmatore scrivo il mio shader in HLSL e lo posso compilare con il compilatore interno fornito con le DX9 oppure con il compilatore fornito con Cg. In entrambi i casi quello che compilo funziona su schede nvidia. Ben altro discorso sarebbe stato se nvidia non avesse permesso al compilatore nelle DX9 di produrre codice per il suo chipset. Questo sarebbe stato un allontanarsi dallo standard, mentre Cg e' solo uno strumento in piu' messo a disposizione. E come strumento in piu' non puo' far altro che rendermi felice, poi sta al programmatore usarlo o meno (io ad esempio non lo supporto al momento :)).

Tornando al discorso OpenGL, non ho ancora capito se questo linguaggio ad alto livello che sara' introdotto e' sintatticamente compatibile con HLSL o meno, se non lo fosse, allora sarebbe il momento di lanciare queste tue critiche sull'allontanamento dallo standard verso chi sta standardizzando OpenGL: sarebbero azzeccatissime.

x Massimo, si', e' vero quello che dici, il 3DMark usa i pixel shader a 32 bit sull'NV30 quindi i risultati non sono assolutamente paragonabili. Un altro motivo per reputare i benchmark perfettamente inutili e poco indicativi. Ciao :D

Originariamente inviato da fek
Ma e' nel pieno diritto di nvidia rilasciare un compilatore HLSL che produce codice migliore per la piattaforma e ne sono felice! Ancora di piu' se questo viene messo a disposizione gratuitamente. Non vedo tutta questa malafede che vedi tu, e' un tool in piu' messo a disposizione, il linguaggio non cambia (e qui direi che cadono tutte le altre critiche che hai portato) quindi non e' un vero e proprio allontanarsi dallo standard HLSL, ma semplicemente fornire un supporto ulteriore. Io programmatore scrivo il mio shader in HLSL e lo posso compilare con il compilatore interno fornito con le DX9 oppure con il compilatore fornito con Cg. In entrambi i casi quello che compilo funziona su schede nvidia. Ben altro discorso sarebbe stato se nvidia non avesse permesso al compilatore nelle DX9 di produrre codice per il suo chipset. Questo sarebbe stato un allontanarsi dallo standard, mentre Cg e' solo uno strumento in piu' messo a disposizione. E come strumento in piu' non puo' far altro che rendermi felice, poi sta al programmatore usarlo o meno (io ad esempio non lo supporto al momento :)).

Tornando al discorso OpenGL, non ho ancora capito se questo linguaggio ad alto livello che sara' introdotto e' sintatticamente compatibile con HLSL o meno, se non lo fosse, allora sarebbe il momento di lanciare queste tue critiche sull'allontanamento dallo standard verso chi sta standardizzando OpenGL: sarebbero azzeccatissime.


Ma chi vuoi prendere in giro !!!

HLSL è un linguaggio di programmazione Microsoft per GPU in DirectX9 che supporta la costruzione degli shaders con una sintassi simile al C.
HLSL è stato sviluppato come l'OpenGl 1.5 di cui tratta questo articolo per lo sviluppo degli shaders in real time su moderne GPU.
HLSL è limitato solo alle piattaforme Microsoft, OpenGl è open platform.

Il cg di nvidia NON E' come dici tu un compilatore che riceve in input codice HLSL.

Il compilatore cg riceve in input un sorgente che deve essere scritto con una sintassi ad alto livello per gli shader sviluppata da NVIDIA.

In pratica io sviluppatore devo scrivere codice con una sintassi proprietaria nvidia passarlo ad un compilatore di alto livello per trasformarlo in codice compatibile OpenGL 1.4 (o superiore) oppure DirectX8.0 (o superiore)

Scusa tanto ma io il mio codice me lo scrivo direttamente senza passare da questo "compilatore per il compilatore" che mi genera, e qui stà l'arroganza di nvidia, un sorgente che dovrei far girare su tutte le schede, anche quelle ATI, con ovvie perdite di performance.

all'età di 11 scrissi un Assemblatore in Basic su uno ZX spectrum che mi portò mio padre dall'Inghilterra, in Italia non era ancora uscito. Ero un bambino ma mi resi conto già allora (più di 20 anni fa) dei limiti dei linguaggi ad alto livello, limiti che evidentemente tu non riesci a capire.

Originariamente inviato da fek
Ma nel caso degli shader, la situazione e' un po' diversa, perche' il linguaggio ad alto livello (HLSL o quello di OpenGL15) e' molto specifico per la programmazione degli shader, per l'appunto, e lavora in un ambiente piu' ristretto e controllabile rispetto ad un generico compilatore. Ha inoltre accesso ad alcune informazioni specifiche dell'architettura hardware per la quale deve produrre codice, informazioni che non sono in possesso del programmatore, ad esempio perche' non sono rivelate da ATI e NVIDIA :)

Inoltre, una buona fetta delle ottimizzazioni in un pixel shader, ad esempio, si gioca sul numero di cosi' detti registri temporanei usati dallo shader. E' un vero incubo per un programmatore minimizzare il numero di registri temporanei in uso dall'algoritmo perche' il cervello umano fa molta fatica ad avere una visione d'insieme di tutte le istruzioni assembly di uno shader, mentre e' ottimo ad astrarre l'algoritmo. Per il compilatore e' il contrario: e' ottimo a tenere traccia delle istruzioni e dei registri che usano cosi' da minimizzarli, ma e' scarso, anzi gli e' impossibile, ad astrarre l'algoritmo.

Fammi capire: perché un compilatore come il Cg può accedere alle informazioni dell'architettura di una GPU e un programmatore no? Mettiamo il caso che esca una nuova GPU DirectX 9 compliant: bisognerà aspettare una nuova versione delle DirectX, dei suoi driver, e/o del compilatore per poterla sfuttare appieno?


In sintesi, nel caso degli shader, e' il compilatore a giocare in casa e spesso e volentieri riesce a produrre codice migliore di quello che puo' fare un programmatore anche esperto che decide di non spendere giorni interi nell'ottimizzare un singolo shader (anche perche' spesso non li ha),

Quello della mancanza di tempo è il male comune dei programmatori... ;)

per poi trovarsi nella maggior parte dei casi con un codice equivalente a quello prodotto dal compilatore e molto raramente migliore. Il gioco non vale la candela.

Non ho esperienza in merito, ma nutro qualche dubbio che ti espongo, sperando di arrivare a chiarirlo.

1) Il "compilatore" delle DirectX 9 e il Cg debbono comunque accedere in qualche modo alle informazioni sull'architettura, per cui dovrebbe essere possibile anche per un programmatore

2) Gli shader in genere sono degli algoritmi abbastanza semplici da implementare, per cui un programmatore abbastanza esperto non dovrebbe avere difficoltà nello scrivere codice per la GPU target, per quanto possa sembrare complicata la sua architettura.

3) Più è lungo il codice degli shader, più tempo sarà necessario per la sua esecuzione (ovvio), per cui è sempre meglio limitarne la dimensione (altrimenti si finisce come con Tomb Raider 4 :D). Quindi dovrebbe essere semplice e non dovrebbe richiedere tanto tempo la stesura di codice per la GPU da parte di un programmatore.

Originariamente inviato da pg08x
...
...
...
In pratica io sviluppatore devo scrivere codice con una sintassi proprietaria nvidia passarlo ad un compilatore di alto livello per trasformarlo in codice compatibile OpenGL 1.4 (o superiore) oppure DirectX8.0 (o superiore)

Scusa tanto ma io il mio codice me lo scrivo direttamente senza passare da questo "compilatore per il compilatore" che mi genera, e qui stà l'arroganza di nvidia, un sorgente che dovrei far girare su tutte le schede, anche quelle ATI, con ovvie perdite di performance.

all'età di 11 scrissi un Assemblatore in Basic su uno ZX spectrum che mi portò mio padre dall'Inghilterra, in Italia non era ancora uscito. Ero un bambino ma mi resi conto già allora (più di 20 anni fa) dei limiti dei linguaggi ad alto livello, limiti che evidentemente tu non riesci a capire.

ti posso dire più che volentieri BRAVO :)
...ma non mi piace quando il discorso diventa: "io so fare questo e quest'altro ho fatto questo e quest'altro ed allora la mia opinione conta di più..."
perchè di opinioni si tratta... se a te da fastidio che nVidia abbia fatto il Cg è una tua rispettabile opinione come quella di un'altro...
ovviamente se sei una persona coerente se ti irrita che nVidia possa fare il Cg similmente ti irrita che faccia dei driver appositi per le sue schede grafiche... è arrogante anche li vero? o forse non sei coerente? ;)

...e vi ricordo che il Cg è stato il primo tra i 'linguaggi ad alto livello' dedicati agli shaders ad essere uscito e nessuno obbliga nessuno ad utilizzarlo.... ricordando anche che gli shader introdotti dalle DX8 in poi (NV20) sono 'brevetto' nVidia... non vedo la sua arroganza nel fornire uno strumento opzionale a disposizione di chi lo desidera...
NB: vorrei anche ricordarvi che il Cg è utilizzato anche per programmare l'Xbox compilando il codice in modo da sfruttare/avvalersi della sua architettura.

Originariamente inviato da cdimauro
Fammi capire: perché un compilatore come il Cg può accedere alle informazioni dell'architettura di una GPU e un programmatore no? Mettiamo il caso che esca una nuova GPU DirectX 9 compliant: bisognerà aspettare una nuova versione delle DirectX, dei suoi driver, e/o del compilatore per poterla sfuttare appieno?
...
..
...


dipende dai punti di vista. :)
non è che un programmatore non può accedervi... anche se certe spec. potrebbero essere celate...
in generale però in questo modo (con il compilatore) cambiando chip o anche tramite driver dando nuove spec/ottimizzazioni su uno stesso chip ricompilare senza modifiche il codice porta a dei benefici poichè il compilatore si assume la responsabilità di ottimizzare andando ad esempio a sfruttare nuovi registri ecc...
altrimenti un programmatore se vuole fare queste ottimizzazioni deve modificare il codice.

E' lo stesso discorso delle SSE2 sui P4... Il compilatore Intel genera quasi sempre codice migliore di quello programmato direttamente in assembler perchè "conosce" la sequenza migliore di istruzioni per avere il minor numero di wait state...
Non so se avete visto il codice SSE2 generato dal compialtore Intel... E' di una complessità assurda eppure è comunque più veloce di quello scritto a mano proprio perchè può sfruttare tutte le possibilità di ottimizzazione...

Se poi ATi rende bene anche su codice non ottimizzato per ATi (come è stato detto precedentemente), mentre nVidia rende al massimo su codice generato da Cg...allora perchè non sfruttare Cg per generare codice che funzioni bene su entrambe le architetture ?
In fondo a chi scrive il codice dovrebbe interessare solamente che si ottenga un prodotto che funzioni bene su qualsiasi scheda video ed ottenerlo nel minor tempo possibile...e Cg mi sembra che faccia questo ;)

Originariamente inviato da pg08x
Ma chi vuoi prendere in giro !!!

HLSL è un linguaggio di programmazione Microsoft per GPU in DirectX9 che supporta la costruzione degli shaders con una sintassi simile al C.
HLSL è stato sviluppato come l'OpenGl 1.5 di cui tratta questo articolo per lo sviluppo degli shaders in real time su moderne GPU.
HLSL è limitato solo alle piattaforme Microsoft, OpenGl è open platform.

Il cg di nvidia NON E' come dici tu un compilatore che riceve in input codice HLSL.

Il compilatore cg riceve in input un sorgente che deve essere scritto con una sintassi ad alto livello per gli shader sviluppata da NVIDIA.

Non capisco tutto questo astio sinceramente. Non me ne viene in tasca nulla a prendere in giro qualcuno, piuttosto questo e' il mio lavoro e mi fa piacere ogni tanto raccontare quello che imparo anche stando molto a contatto con gli ingegneri sia di nvidia sia di ati.

Il compilatore Cg e' in grado di compilare codice HLSL ed accetta anche una sintassi estesa dettata da nvidia.
E' come un compilatore C++ che compila codice scritto in C++ ma accetta eventualmente estensioni al linguaggio dettata dal produttore (i primi esempi che mi vengono in mente sono il VC.net di Microsoft e il CodeWarrior di Metrowerks). Non per questo si dice che Microsoft e Metrowerks stiano producendo compilatori per i loro linguaggi :)


In pratica io sviluppatore devo scrivere codice con una sintassi proprietaria nvidia passarlo ad un compilatore di alto livello per trasformarlo in codice compatibile OpenGL 1.4 (o superiore) oppure DirectX8.0 (o superiore)

No. Lo sviluppatore puo' scrivere codice HLSL e compilarlo con Cg oppure usare le estensioni fornite.


Scusa tanto ma io il mio codice me lo scrivo direttamente senza passare da questo "compilatore per il compilatore" che mi genera, e qui stà l'arroganza di nvidia, un sorgente che dovrei far girare su tutte le schede, anche quelle ATI, con ovvie perdite di performance.

E' un compilatore nvidia, e' ovvio che produca codice migliore per le sue piattaforme :)
Qui c'e' una considerazione interessante da fare: il compilatore Cg e' open source, sono disponibili i sorgenti, quindi qualunque produttore puo' in teoria estenderlo per produrre codice specifico per la propria piattaforma. ATI ha preferito non percorrere questa strada ed uniformarsi al compilatore standard Microsoft. Una scelta che personalmente condivido.

Per riassumere, lo sviluppatore scrive il suo shader in HLSL e puo' compilarlo con il compilatore fornito con le DX9.
Se vuole spremere qualche ciclo in meno alle piattaforme nvidia, puo' compilare lo stesso codice non modificato con il compilatore Cg fornito con il toolkit nvidia.
Se vuole spremere ancora qualcosina puo' usare le estensioni al linguaggio nvidia che gli permettono di avere piu' controllo sulla dimensione delle variabile (16 o 32 bit).


all'età di 11 scrissi un Assemblatore in Basic su uno ZX spectrum che mi portò mio padre dall'Inghilterra, in Italia non era ancora uscito. Ero un bambino ma mi resi conto già allora (più di 20 anni fa) dei limiti dei linguaggi ad alto livello, limiti che evidentemente tu non riesci a capire.

Dai, ora non stiamo qui ad elencare la propria storia come programmatori per favore. Anch'io ho la mia anche se non capisco i limiti dei linguaggi ad alto livello :)

Originariamente inviato da cdimauro
Fammi capire: perché un compilatore come il Cg può accedere alle informazioni dell'architettura di una GPU e un programmatore no? Mettiamo il caso che esca una nuova GPU DirectX 9 compliant: bisognerà aspettare una nuova versione delle DirectX, dei suoi driver, e/o del compilatore per poterla sfuttare appieno?


Mi sono spiegato male prima, scusami. A volte do' troppe cose per scontate.
Il programmatore e' teoricamente in grado di accedere alle informazioni sull'architettura di una GPU esattamente come il compilatore. Come hai scritto giustamente tu in seguito, entrambi lavorano sullo stesso hardware e software.
Ma c'e' un problema: queste informazioni non sono pubblicate dagli hardware vendor (nvidia o ati), sono coperte da copyright e interne, per ragioni ovvie.
Anche se teoricamente posso scrivere lo stesso codice di un compilatore e, spendendoci molto tempo, codice anche migliore, in pratica io non conoscero' mai quei dettagli sull'architettura e di fatto non saro' mai in grado di scrivere quel codice.
Chi scrive il compilatore, in realta' per precisione dovrei dire chi scrive la porzione di codice che emette le istruzioni assembly, e' un dipendente nvidia o ati quindi ha accesso a quelle informazioni e puo' usarle, anzi, le usa :)



Non ho esperienza in merito, ma nutro qualche dubbio che ti espongo, sperando di arrivare a chiarirlo.

1) Il "compilatore" delle DirectX 9 e il Cg debbono comunque accedere in qualche modo alle informazioni sull'architettura, per cui dovrebbe essere possibile anche per un programmatore

2) Gli shader in genere sono degli algoritmi abbastanza semplici da implementare, per cui un programmatore abbastanza esperto non dovrebbe avere difficoltà nello scrivere codice per la GPU target, per quanto possa sembrare complicata la sua architettura.

3) Più è lungo il codice degli shader, più tempo sarà necessario per la sua esecuzione (ovvio), per cui è sempre meglio limitarne la dimensione (altrimenti si finisce come con Tomb Raider 4 :D). Quindi dovrebbe essere semplice e non dovrebbe richiedere tanto tempo la stesura di codice per la GPU da parte di un programmatore.

1) teoricamente si', in pratica no

2) si', gli algoritmi non sono particolarmente complicati, ma la loro scrittura in assembly spesso diventa piuttosto rognosa, soprattutto la gestione dei registri temporanei che come ho scritto prima non e' un'operazione che il cervello umano gestisce comodamente. Paradossalmente e' piu' facile per un compilatore ottimizzare un algoritmo semplice (ma direi meglio specifico) di uno complicato perche' su un algoritmo semplice ha bisogno di fare meno "speculazioni" e gli e' piu' facile avvicinarsi al pensiero del programmatore. Il modello di programmazione degli shader e' piuttosto semplice e specifico (non e' un linguaggio generico), quindi il compilatore gioca in casa

3) verissimo... e ti assicuro che e' molto piu' veloce e comodo scriverlo in HLSL :)

C'e' una cosa interessante da dire sul discorso assembly contro hlsl: scrivo il mio shader in assembly, funziona, e' stra ottimizzato, sono felicissimo, dopo un mese devo modificarlo leggermente perche' ho bisogno di qualcosa di leggermente diverso, guardo il codice in assembly e penso: "che e' sta roba qui?" :D

Allora fek è meglio che metti le cose in chiaro per non confondere (volutamente?) le cose.

Correggimi se sbaglio .....

E' vero o no che cg è un "layer", uno strato al di sopra di directX (se uno vuole usare DirectX) o di OpenGl (se uno vuole usare OpenGl) ?
Vuoi forse negare che non rimpiazza affatto DirectX oppure OpenGl ma anzi l'output del compilatore contiene di queste chiamate ?
Anche quello di decidere se usare 16 o 32 bit non è forse vero che lo standard directx9 prevede 24bit di precisione e che usando 16 bit avresti una perdita qualitativa (a 16 bit uno shader dovrebbe non essere directX9 compliant ? e che se cg me lo lascia fare, e solo su piattaforma nvidia, è una truffa bella e buona ?)
Non è forse vero che del codice cg ha performance PEGGIORI su schede ati di un codice che fa le stesse cose scritto dallo stesso programmatore impiegando lo stesso tempo senza utilizzare cg ?
Non è forse vero che anche se hlsl compatibile cg ti spinge a programmare in cg ?

E' ben diverso dal discorso delle SSE2 di Intel.
In quel caso il codice assembler generato ha una corrispondenza diretta con il set di istruzioni SSE2 di Intel (codice macchina dei p4).
Mentre quello che compili per sfruttare le SSE2 lo fai girare solo su piattaforme Intel la presunzione di nvidia è quella che l'output del compilatore cg ti dicono di farlo girare su qualsiasi gpu directX 8 oppure opengl 1.4 compatibile portando solo svantaggi sui prodotti della concorrenza !!!

In pratica l'output di CG su schede ati non porta benefici, anzi peggiora le performance, mentre su schede nvidia contiene del codice specifico per quelle gpu, codice che può essere utilizzato ad esempio per avere la precisione a 16 bit (contro lo standard che è 24) ed ottenere quindi performance migliori.

Originariamente inviato da DoomIII
ti posso dire più che volentieri BRAVO :)
...ma non mi piace quando il discorso diventa: "io so fare questo e quest'altro ho fatto questo e quest'altro ed allora la mia opinione conta di più..."
perchè di opinioni si tratta... se a te da fastidio che nVidia abbia fatto il Cg è una tua rispettabile opinione come quella di un'altro...
ovviamente se sei una persona coerente se ti irrita che nVidia possa fare il Cg similmente ti irrita che faccia dei driver appositi per le sue schede grafiche... è arrogante anche li vero? o forse non sei coerente? ;)

...e vi ricordo che il Cg è stato il primo tra i 'linguaggi ad alto livello' dedicati agli shaders ad essere uscito e nessuno obbliga nessuno ad utilizzarlo.... ricordando anche che gli shader introdotti dalle DX8 in poi (NV20) sono 'brevetto' nVidia... non vedo la sua arroganza nel fornire uno strumento opzionale a disposizione di chi lo desidera...
NB: vorrei anche ricordarvi che il Cg è utilizzato anche per programmare l'Xbox compilando il codice in modo da sfruttare/avvalersi della sua architettura.

A me non irrita che nvidia abbia fatto il cg, mi dispiace per te, sembra che ti abbiano preso in giro al punto da farti credere che questo cg sia qualcosa di confrontabile con le estensioni ARB oppure con il directX9.
Mentre tu parli del 'primo tra i linguaggi ad alto livello dedicati agli shaders', dall'altra parte fek si ostina a sostenere che questo cg è ne più ne meno di un compilatore per il linguaggio HLSL (linguaggio di Intel, standard per la programmazione degli shaders in directx).
Morale della storia e sei libero di credermi oppure no, nvidia esercita una grossa influenza "commerciale" cui chi sviluppa software per il 3d non può sottrarsi per non rischiare ad esempio di fare la fine dei programmatori di madonion che si sono presi delle botte di incompetenti da quelli di nvidia solo perchè in madonion volevano un bench imparziale.
Nvidia ha bisogno di codice fortemente ottimizzato per stare al passo con ATI e dato che ci sono un gran numero di schede nvidia nelle case dei gamers questo fatto non può essere ingorato.

Originariamente inviato da pg08x
E' vero o no che cg è un "layer", uno strato al di sopra di directX (se uno vuole usare DirectX) o di OpenGl (se uno vuole usare OpenGl) ?
Vuoi forse negare che non rimpiazza affatto DirectX oppure OpenGl ma anzi l'output del compilatore contiene di queste chiamate ?
Anche quello di decidere se usare 16 o 32 bit non è forse vero che lo standard directx9 prevede 24bit di precisione e che usando 16 bit avresti una perdita qualitativa (a 16 bit uno shader dovrebbe non essere directX9 compliant ? e che se cg me lo lascia fare, e solo su piattaforma nvidia, è una truffa bella e buona ?)
Non è forse vero che del codice cg ha performance PEGGIORI su schede ati di un codice che fa le stesse cose scritto dallo stesso programmatore impiegando lo stesso tempo senza utilizzare cg ?
Non è forse vero che anche se hlsl compatibile cg ti spinge a programmare in cg ?

No. Cg non e' uno strato sopra le DirectX o OpenGL ma e' un compilatore (piu' un set di tool) che compila shader ad alto livello scritti in HLSL. L'output del compilatore e' codice assembly (come ogni compilatore che si rispetti). Poi e' possibile usare questo output e chiamare di proprio pugno le funzioni DX8/9 (OpenGL) che assemblano gli shader oppure farlo fare automaticamente alla libreria che viene fornita con il compilatore.
Lo standard DX9 prevede i 24 bit, l'architettura dell'NV30 e' in grado di gestire i pixel shader a 16 o 32 bit (quindi e' perfettamente in linea con lo standard): il programmatore puo' scegliere la soluzione che preferisce per raggiungere il desiderato bilanciamento fra velocita' d'esecuzione e qualita' visiva. Non ci vedo alcuna truffa.
Il compilatore Cg produce codice ottimizzato per piattaforme nvidia; anche questo mi sembra perfettamente naturale come e' naturale che ATI scelga di non volere implementare il backend che produrrebbe codice ottimizzato per il suo hardware, nonostante ne abbia la possibilita' (il compilatore Cg e' fornito con i sorgenti ed e' di pubblico dominio).
Ovviamente usare le estensioni proprietarie porta dei benefici altrimenti non esisterebbero.

Originariamente inviato da pg08x
E' vero o no che cg è un "layer", uno strato al di sopra di directX (se uno vuole usare DirectX) o di OpenGl (se uno vuole usare OpenGl) ?
Vuoi forse negare che non rimpiazza affatto DirectX oppure OpenGl ma anzi l'output del compilatore contiene di queste chiamate ?
Anche quello di decidere se usare 16 o 32 bit non è forse vero che lo standard directx9 prevede 24bit di precisione e che usando 16 bit avresti una perdita qualitativa (a 16 bit uno shader dovrebbe non essere directX9 compliant ? e che se cg me lo lascia fare, e solo su piattaforma nvidia, è una truffa bella e buona ?)
Non è forse vero che del codice cg ha performance PEGGIORI su schede ati di un codice che fa le stesse cose scritto dallo stesso programmatore impiegando lo stesso tempo senza utilizzare cg ?
Non è forse vero che anche se hlsl compatibile cg ti spinge a programmare in cg ?

Originariamente inviato da pg08x
In pratica l'output di CG è una collezione di chiamate opengl o directx standard che su schede ati non porta benefici, anzi peggiora le performance, mentre su schede nvidia contiene del codice specifico per quelle gpu, codice che può essere utilizzato ad esempio per avere la precisione a 16 bit (contro lo standard che è 24) ed ottenere quindi performance migliori.


No alla prima e No alla seconda. L'output del compilatore e' lo shader in codice assembly, visto che e' un compilatore e come tutti i compilatori traduce da un linguaggio ad alto livello ad uno a basso livello :)

Credo tu ti stia probabilmente confondendo fra il compilatore Cg (che e' una cosa) e la libreria runtime che viene fornita assieme al compilatore (che e' tutta un'altra cosa).

Originariamente inviato da pg08x
Mentre tu parli del 'primo tra i linguaggi ad alto livello dedicati agli shaders', dall'altra parte fek si ostina a sostenere che questo cg è ne più ne meno di un compilatore per il linguaggio HLSL (linguaggio di Intel, standard per la programmazione degli shaders in directx).

Visto che e' un compilatore HLSL non vedo perche' non debba ostinarmi a definirlo tale :)

Non capisco il motivo di tanto astio.

Does Cg replace OpenGL?
No, Cg operates as a layer above OpenGL. Cg Compilers output assembly code in the formats defined by OpenGL extensions such as ARB_vertex_program, ARB_fragment_program and NV_vertex_program, and in the format defined by OpenGL 1.4.

Fonte nvidia

Does Cg replace DirectX?
No, this language operates as a layer above the DirectX vertex and pixel shader APIs, and creates the shader code necessary to run standard vertex and pixel shaders for DirectX 8.0 and DirectX 9.0.

Fonte nvidia

Originariamente inviato da fek
Visto che e' un compilatore HLSL non vedo perche' non debba ostinarmi a definirlo tale :)

Non capisco il motivo di tanto astio.

Cg è un linguaggio ad alto livello per programmare le gpu.
Le specifiche del cg per quanto riguarda l'implementazione degli shaders sono compatibili HLSL ma da questo a dire che il cg è solo un compilatore HLSL mi sembra un po RIDUTTIVO e sarebbe il male minore.

Non si tratta affatto di astio ma per favore smettila di prenderci in giro facendo disinformazione.

Ok, non sono io a fare disinformazione (anzi) ma sei tu a far finta di non capire, pazienza. E' inutile riscrivere le stesse cose ancora una volta. Se ci credi bene, se non ci credi ti vai ad informare :)

Per porre la parola fine alla questione (visto che non vuoi credere a me :p):


1.1: What's the difference between nVidia's Cg and Microsoft's HLSL
(High Level Shading Language)?

A: Cg and HLSL are actually the same language! Cg/HLSL was co-developed
by nVidia and Microsoft. They have different names for branding
purposes. HLSL is part of Microsoft's DirectX API and only compiles
into DirectX code, while Cg can compile to DirectX and OpenGL.

In this FAQ, Cg and HLSL can be used interchangably.


Tratto da qui:
http://www.fusionindustries.com/content/lore/code/articles/fi-faq-cg.php3

Il link proviene da qui:
http://www.cgshaders.org

Che poi e' nient'altro che quello che ho cercato di dirti fino a ora :)

Originariamente inviato da fek
Ok, non sono io a fare disinformazione (anzi) ma sei tu a far finta di non capire, pazienza. E' inutile riscrivere le stesse cose ancora una volta. Se ci credi bene, se non ci credi ti vai ad informare

Non si tratta affatto di astio ma smettila con questa disinformazione, l'implementazione degli shaders con cg è compatibile hlsl (al fine di invogliare gli sviluppatori) per cui cg è in grado di compilare codice hlsl (a tutto vantaggio delle gpu nvidia) ma questo non cambia il fatto che cg è un linguaggio completo ed aggiunge un sacco di comandi appositamente studiati per generare codice fortemente ottimizzato per gpu nvidia ed a danno della concorrenza.

Abbiamo visto progetti come "Gun Metal" come girano bene su schede concorrenti...

La faq che hai citato prova solo che gli shaders scritti con cg sono compatibili hlsl ma cg è un linguaggio completo e ti cito nvidia che mi sembra la fonte + attendibile (visto che l'han fatto loro)

http://www.nvidia.com/object/cg_faq.html

What is Cg?
C for Graphics. Cg is the high-level language for programming GPUs, developed by NVIDIA in close collaboration with Microsoft.

Who maintains the Cg Language Specification?
NVIDIA maintains the Cg Language Specification and will continue to work with Microsoft to maintain compatibility with the DirectX High Level Shading Language (HLSL).

Is Cg proprietary?
The Cg Language Specification is published and open in the sense that other vendors may implement products based on it. To encourage this, NVIDIA open sourced the Cg Compiler technology under a nonrestrictive, free license.

Vendor implementations of Cg Compilers are typically proprietary and owned by their creators. NVIDIA has developed and owns the NVIDIA Cg Compiler, and other vendors are expected and encouraged to develop their own Cg Compiler products.

Does Cg replace OpenGL?
No, Cg operates as a layer above OpenGL. Cg Compilers output assembly code in the formats defined by OpenGL extensions such as ARB_vertex_program, ARB_fragment_program and NV_vertex_program, and in the format defined by OpenGL 1.4.

Does Cg replace DirectX?
No, this language operates as a layer above the DirectX vertex and pixel shader APIs, and creates the shader code necessary to run standard vertex and pixel shaders for DirectX 8.0 and DirectX 9.0.

How does it compare to Microsoft HLSL?
The Cg Language Specification is compatible with Microsoft's High Level Shading Language

cg è il "contentino" che Microsoft ha dato ad nvidia per la collaborazione al progetto xbox, ed il codice scritto con cg gira male su gpu non nvidia da questo a paragonarmelo con OpenGl o DirectX ce ne passa...

Un qualsiasi programmatore esempio Carmach che stà sviluppando il suo DoomIII con openGL + estensioni ARB per gli shaders sa che il gioco che stà sviluppando avrebbe performance fortemente penalizzate su schede nvidia (per via di come nvidia ha implementato gli shaders via hardware).

Dato che queste schede nvidia sono molto diffuse per vendere il suo gioco si vede costretto a riprogrammare tutti gli shaders con cg e nel suo programma ad adottare path differenti (vale a dire se la scheda è nv20 fai il rendering utilizzando questo codice, se la scheda è nv30 utilizza questo altro sentiero, vale a dire altro codice).
E questo rallenta di molto i tempi di sviluppo ed i costi di realizzazione

Mentre con schede ati Carmach usa codice standard (ma l'esempio può essere esteso) con schede nvidia non può perchè il processo di ottimizzazione sarebbe troppo complicato e deve affidarsi a questi strumenti messi a disposizione da nvidia, strumenti che nvidia vorrebbe che fossero usati per produrre codice che giri anche su schede ati o matrox etx ma che qualsiasi programmatore saggio sa che così facendo otterrebbe (su schede non nvidia) risultati peggiori rispetto a quelli ottenibili con codice directx o opengl standard.
...Per cui la strada percorsa da Carmach (non usare cg per produrre codice che giri su schede non nvidia) è l'unica applicabile per ottenere risultati migliori ma al prezzo di un allungamento notevole dei tempi di sviluppo... (che nvidia ha ripagato con un forte finanziamento per il porting verso xbox)

La cosa grave, a mio avviso è anche questa:

Adesso OpenGl è giunto alla versione 1.5 dello standard uno sviluppatore che scriva codice con i nuovi "comandi" opengl avrà performance buone su schede ATI e performance ridotte della metà su schede nvidia.

Questo rappresenta a mio avvioso un serio OSTACOLO al diffondersi di nuovi standard perchè fino a quando nvidia non avrà adattato cg alle nuove estensioni dell'opengl 1.5 nessuno mai userà opengl 1.5 su schede nvidia, per non vedersi costretto ad ottimizzare a mano e, quando nvidia finalmente avrà, se mai lo farà, adattato cg a opengl15 un programmatore dovrà comunque usare cg per schede nvidia, sarà il compilatore cg a generare codice assembly.

In pratica dato che lo sviluppo di cg si adatterà quello di hlsl di microsoft, questo può rappresentare la fine di OpenGl o di altri standard potenzialmente migliori.

Nvidia stà facendo forti pressioni perchè si utilizzi cg anche per creare il codice per schede non nvidia in questo modo in nvidia avrebbero il controllo dell'ordine di utilizzo degli shaders su schede ati o matrox. A me sembra un tantino grave la cosa ed è questo il motivo per cui perdo il mio prezioso tempo a denunciarla... ;)

Una azienda media che deve rispettare dei tempi stretti di sviluppo è portata ad usare solo cg quindi a favorire nvidia a danno della concorrenza.

Poi ognuno la giudichi come meglio crede...

Direi che il discorso su Cg e HLSL e sul loro rapporto e' definitivamente chiarito. Come ti avevo detto e come e' confermato dai due link che abbiamo fornito, non sono altro che lo stesso linguaggio compilati con compilatori differenti.

Non sono linguaggi differenti come sostenevi all'inizio accusandomi di fare cattiva informazione ;)

Originariamente inviato da pg08x
Un qualsiasi programmatore esempio Carmach che stà sviluppando il suo DoomIII con openGL + estensioni ARB per gli shaders sa che il gioco che stà sviluppando avrebbe performance fortemente penalizzate su schede nvidia (per via di come nvidia ha implementato gli shaders via hardware).

Ma stai solo affermando delle ovvieta' :)
E' risaputo che l'architettura NV30 richiede di ottimizzare gli shader ad hoc per ottenere le migliori prestazioni e in questo non c'e' nulla di male. E' una scelta di progetto del tutto legittima che si puo' riassumere in:

- ATI e' andata verso l'implementazione del modello di shader piu' efficente
- NVIDIA e' andata verso l'implementazione del modello di shader piu' ricca di funzionalita'

Su architettura NV3X, ad esempio, e' possibile implementare effetti che su architettura R3X0 sarebbero fortemente penalizzati. Ad esempio ho scritto uno shader che gestisce 4 luci + stencil shadow associate e su R300 non avevo abbastanza istruzioni quindi ho dovuto limitare il numero di luci a 2 (su R350 la situazione e' un po' diversa, posso aumentare il numero di luci sfruttando l'f-buffer ma a forte scapito delle prestazioni). Questo e' un esempio. Ho, invece, uno shader per una sola luce + stencil buffer e HDR che e' una scheggia su R300 e fa fatica anche sull'NV35.

NVIDIA ha dei driver robustissimi e ben implementati, i driver ATI sono spesso quasi inusabili: mi ritrovavo a riportare un bug al giorno di media al team di sviluppo dei Catalyst, ormai Richard Huddy mi sognava la notte nei suoi peggiori incubi :D

L'R300 e' un missile quando si e' fillrate bound e macina pixel shader come un carroarmato. Sull'NV30 posso implementare in una sola passata effetti che sull'R300 ne richiederebbero due o tre. E cosi' via. Potrei andare avanti a lungo ed annoiarvi a morte :)

Il problema e' che fai affermazioni generali (e a senso unico), ma senza avere l'esperienza sul campo per capire che la situazione non e' cosi' semplice e monocromatica come la descrivi come fosse il mondo delle favole dei buoni verso i cattivi.

L'architettura ATI ha dei vantanggi, quella NVIDIA degl'altri. NVIDIA mette a disposizione un compilatore che promette di produrre codice migliore. Sta allo sviluppatore supportarlo o meno sapendo che puo' usare il compilatore DX9 oppure OpenGL ed ottenere comunque prestazioni accettabilissime.

A questo proposito c'e' da sfatare subito un mito: qui non si parla di differenze abissali nell'ordine delle decine di fps, ma di differenze di prestazioni minime, nella stragrande maggioranza dei casi del tutto trascurabili. Nel 99% dei casi anche straottimizzando a mano un pixel shader oppure usando Cg al posto del compilatore DX9, nel momento in cui si lancia il gioco non ci si accorge della differenza. Sono talmente tanti i parametri in gioco che determinano le prestazioni di un motore 3d che il pixel shader compilato con le DX9 o con Cg e' davvero uno degl'ultimi fattori. Solo in caso una scena sia fillrate bound, tutto il resto sia stato ottimizzato a dovere, un particolare shader sia usato in maniera molto intensiva, lo shader sia particolarmente lungo e complesso, allora, forse, ottimizzarlo puo' portare dei benefici. In tutti gli altri casi e' tempo sprecato... Le ottimizzazioni da fare sono altre e a piu' alto livello :)

Il che ci porta al discorso su Carmack: e' un programmatore 3d geniale, si e' inventato un sacco di roba interessante, ma e' opionione comune fra gli sviluppatori che come Software Engineer sia scarsino, decisamente peggio che come PR di se stesso ;)

La scelta che ha fatto tre anni fa di implementare diversi code path per ogni modello di shader che aveva in mente (ARB, NV20, NV30, R200, R300) e' disastrosa in termini ingegneristici. Non per nulla ci sta mettendo una vita :p
Adesso ci sono modelli di design decisamente piu' efficenti, come shader library basate sul fallback degli shader (senza scendere troppo nel particolare, io scelgo un effetto da applicare ad un modello, questo effetto contiene al suo interno diverse tecniche per implementarlo, la shader library sceglie automaticamente quella migliore per l'hardware sul quale sta girando; normalmente si implementa sempre una tecnica base che e' in grado di girare su tutti gli hardware). Dal punto di vista teorico questa soluzione e' meno ottimizzata di quella di Carmack di implementare diversi code path, ma alla fine della fiera questa differenza di prestazioni e' totalmente irrilevante dal lato pratico ed il risparmio di tempo in fase di sviluppo e' enorme. Come vedi non e' colpa di NVIDIA se i tempi di sviluppo sono eonici :)
(Meglio che cambio argomento, che dove lavoro ora non sono famosissimi per sviluppare giochi in poco tempo :p)

C'e' anche da dire che quando Carmack fece R&D per il motore di Doom3 questo nuovo modello non era stato ancora inventato, quindi non aveva molte scelte a parte l'implementare diversi code path ed ora si sta portando dietro questo errore, mentre tutti gli altri (me compreso) usiamo una shader lib con fallback. Nessuno piu' scrive diversi code path come per Doom3.


La cosa grave, a mio avviso è anche questa:

Adesso OpenGl è giunto alla versione 1.5 dello standard uno sviluppatore che scriva codice con i nuovi "comandi" opengl avrà performance buone su schede ATI e performance ridotte della metà su schede nvidia.

Questo rappresenta a mio avvioso un serio OSTACOLO al diffondersi di nuovi standard perchè fino a quando nvidia non avrà adattato cg alle nuove estensioni dell'opengl 1.5 nessuno mai userà opengl 1.5 su schede nvidia, per non vedersi costretto ad ottimizzare a mano e, quando nvidia finalmente avrà, se mai lo farà, adattato cg a opengl15 un programmatore dovrà comunque usare cg per schede nvidia, sarà il compilatore cg a generare codice assembly ricco di chiamate all'opengl 1.5.


Qui stai facendo molta confusione. Un compilatore di shader produce codice assembly, non fa alcuna chiama a OpenGL o DX se non per assemblare il risultato della compilazione. Non fa chiamate all'ARB ad esempio, non setta stati di rendering, non usa estensioni (se non quella per assemblare lo shader). In poche parole non c'e' nulla da adattare alle nuove estensioni OGL15. Che poi non c'e' alcuna nuova estensione, sono solo state rese standard estensioni gia' esistenti e proprietarie.
Il codice assembly non chiama opengl ma viene eseguito dalla GPU.

Nvidia stà facendo forti pressioni perchè si utilizzi cg anche per creare il codice per schede non nvidia in questo modo in nvidia avrebbero il controllo dell'ordine di utilizzo degli shaders su schede ati o matrox. A me sembra un tantino grave la cosa ed è questo il motivo per cui perdo il mio prezioso tempo a denunciarla... ;)

Stai basando queste tue accuse su considerazioni tecniche assolutamente campate in aria (tipo il codice assembly che fa chiamate opengl che non vuol dire assolutamente nulla :p) e sarebbe meglio che perdessi piuttosto il tuo prezioso tempo ad informarti meglio sulle questioni tecniche che stai cercando di affrontare in maniera un po' approssimativa ;)


Una azienda media che deve rispettare dei tempi stretti di sviluppo è portata ad usare solo cg quindi a favorire nvidia a danno della concorrenza.

Poi ognuno la giudichi come meglio crede...

Falsissimo. Un'azienda media che deve rispettare dei tempi stretti non guarda Cg neppure di striscio e si butta su DX9 piano, lo standard.

qua ci vorrebbe un giudice, un giudice con cognizione di causa, ma credo che sara' impossibile trovarlo...
una cosa è certa, da profano, giochi sporchi nvidia ne ha fatto, non mi stupirei se con questo cg cercasse di farne un altro a discapito di ati e matrox, in ogni caso la verita' credo non si sapra' mai, sarebbe troppo grave...

Originariamente inviato da pg08x
Un qualsiasi programmatore esempio Carmach che stà sviluppando il suo DoomIII con openGL + estensioni ARB per gli shaders sa che il gioco che stà sviluppando avrebbe performance fortemente penalizzate su schede nvidia (per via di come nvidia ha implementato gli shaders via hardware).

Dato che queste schede nvidia sono molto diffuse per vendere il suo gioco si vede costretto a riprogrammare tutti gli shaders con cg e nel suo programma ad adottare path differenti (vale a dire se la scheda è nv20 fai il rendering utilizzando questo codice, se la scheda è nv30 utilizza questo altro sentiero, vale a dire altro codice).
E questo rallenta di molto i tempi di sviluppo ed i costi di realizzazione

Mentre con schede ati Carmach usa codice standard (ma l'esempio può essere esteso) con schede nvidia non può perchè il processo di ottimizzazione sarebbe troppo complicato e deve affidarsi a questi strumenti messi a disposizione da nvidia, strumenti che nvidia vorrebbe che fossero usati per produrre codice che giri anche su schede ati o matrox etx ma che qualsiasi programmatore saggio sa che così facendo otterrebbe (su schede non nvidia) risultati peggiori rispetto a quelli ottenibili con codice directx o opengl standard.
...Per cui la strada percorsa da Carmach (non usare cg per produrre codice che giri su schede non nvidia) è l'unica applicabile per ottenere risultati migliori ma al prezzo di un allungamento notevole dei tempi di sviluppo... (che nvidia ha ripagato con un forte finanziamento per il porting verso xbox)
...
...
...

ma che lamer... ma che cavolo di storielle per allocchi vi inventate?

se ne era già parlato a suo tempo... vai un po a vedere cosa significa usare le varie estensioni... e smettiamola con queste lamerate di disinformazione mirate...

ma che discorsi sono? intanto vai a vedere di cosa si parla con estensioni ARB ecc.... parliamo di precisione ed al riguardo non c'è molto tempo di ottimizzazione richiesto... e se fosse questione di Cg... basterebbe solo compilare poichè l'ottimizzazione sarebbe a carico del compilatore e non del programmatore...
ma le ottimizzazioni sono altrove non in un paio di righe necessarie ad impostare un livello di precisione o l'altro...
voler adesso portare la morale a condannare nVidia perchè per colpa sua ci sono ritardi su DoomIII è semplicemente da ignoranti... DoomIII non è in ritardo visto che date non ci sono state... ed il lavoro verte sul design realizzazione degli schemi...
e ottimizzazioni del motore son ben altra cosa (lo ripeto) rispetto all'impostare un livello di precisione... che se fosse Cg sarebbe tutto a carico suo.

dici solo assurdità... nVidia non ha pagato nessun finanziamento per porting su XboX... è M$ che voleva l'esclusiva... DoomIII è stato DA SUBITO!!! concepito per XboX (su ammissione dello stesso J.C. che ha contribuito molto nello sviluppo stesso della X e che fa parte degli sviluppatori della stessa)


ah... cosa significa che con Ati utilizza codice standard?
standard di che? shader standard? e chi ha inventato lo standard? chi ha i brevetti sugli shaders?
semplice.... è nVidia...

ah... approposito di diversità:

Why do you have NV30-specific code paths and none for the R300?

There aren't any R300-specific fragment extensions, so I really can't make an R300-specific back end. I do support their two sided stencil extension (unfortunately, slightly different than NVIDIA's...), which is orthogonal to the back end selection
J.Carmack

Originariamente inviato da pg08x
A me non irrita che nvidia abbia fatto il cg, mi dispiace per te, sembra che ti abbiano preso in giro al punto da farti credere che questo cg sia qualcosa di confrontabile con le estensioni ARB oppure con il directX9.
Mentre tu parli del 'primo tra i linguaggi ad alto livello dedicati agli shaders', dall'altra parte fek si ostina a sostenere che questo cg è ne più ne meno di un compilatore per il linguaggio HLSL (linguaggio di Intel, standard per la programmazione degli shaders in directx).
Morale della storia e sei libero di credermi oppure no, nvidia esercita una grossa influenza "commerciale" cui chi sviluppa software per il 3d non può sottrarsi per non rischiare ad esempio di fare la fine dei programmatori di madonion che si sono presi delle botte di incompetenti da quelli di nvidia solo perchè in madonion volevano un bench imparziale.
Nvidia ha bisogno di codice fortemente ottimizzato per stare al passo con ATI e dato che ci sono un gran numero di schede nvidia nelle case dei gamers questo fatto non può essere ingorato.

preso in giro? scusa... ma sai leggere? l'ho detto e stradetto e penso sia chiaro ciò che penso... e cioè che il Cg è un linguaggio ad alto livello per la creazione di shaders... le DX sono tutt'altra cosa... quindi non ha senso confrarle e ciò che dici risulta semplicemente insulso. :O

nVidia esercita una grossa influenza commerciale?
ovvio... non ho capito scusa... ma come potrebbe essere altrimenti? vuoi che facciamo io e te una scheda grafica e poi che pretendiamo di imporre standard?

gli shaders sono uno standard/brevetto nVidia ed assieme alla percentuale di penetrazione nel mercato è più che ovvio che abbiano una certa influenza e non ci vedo niente di strano o immorale... se poi si vuole parlare di come questa influenza viene sfruttata... l'argomento non mi interessa poichè non credo la sfrutti diversamente da quanto farebbe una qualsiasi altra azienda o da come non faccia Ati... e cioè per i proprio interessi e non certo per elemosinare in giro.

nVidia ha bisogno di codice ottimizzato? ma con questa storia smettiamola... dimostra solo che sei di parte e ragioni Ati-oriented...
secondo te Ati è lo standard... ottimizzare per Ati è normale mentre ottimizzare per nVidia è scandaloso perchè , sempre secondote, dimostra che nVidia necessità di codice suo...
tu dici... con le ottimizzazioni Ati (che per te sono lo standard) su schede nVidia si hanno meno performance e quindi vai contro ad nVidia dicendo che ha bisogno di sue ottimizzazioni..

invece perchè non ribalti il discorso?
il codice nVidia è lo standard e il codice nVidia su Ati come gira?
come come? ti lamenti dicendo che non è giusto che ci siano ottimizzazioni nVidia perchè vanno a scapito di Ati?
va bene... ok... ma perchè allora possono esserci ottimizzazioni Ati che non vanno bene su nVidia?
semplice... perchè soggettivamente per te Ati è lo standard...
mentre in realtà obiettivamente si può confutare che ciascuna ha bisogno delle sue specifiche ottimizzazioni...
però a questo si può aggiungere ancora una cosetta...
che "lo standard è nVidia visto che gli shader son suoi..." :D

Originariamente inviato da $!/\/\o
qua ci vorrebbe un giudice, un giudice con cognizione di causa, ma credo che sara' impossibile trovarlo...
una cosa è certa, da profano, giochi sporchi nvidia ne ha fatto, non mi stupirei se con questo cg cercasse di farne un altro a discapito di ati e matrox, in ogni caso la verita' credo non si sapra' mai, sarebbe troppo grave...

Oddio, credo di parlare con un po' di cognizione di causa visto che faccio il programmatore 3d per lavoro :p

nessuno metteva in dubbio la tua competenza;) parlavo di un terzo elemento imparziale e competente:-p

sorry :D

Un articolo preso a caso, evidentemente non sono l'unico ad avere dei sospetti:

On the other hand, Cg could bring us one step closer to an NVIDIA-dominated world. What happens if developers choose not to dedicate enough time to ensure that non-NVIDIA cards work well with their Cg-compiled code, or aren’t optimized for the best performance? Fortunately, Cg is 100% compatible with Microsoft’s recently announced high level shading language for DirectX 9 (as well as OpenGL) and its open-sourced roots will hopefully keep scenarios such as this to a minimum, but it doesn’t take a conspiracy theorist to see that this possibility could become a reality in the near future. Only time will tell how this aspect of the story develops.

Originariamente inviato da fek
Direi che il discorso su Cg e HLSL e sul loro rapporto e' definitivamente chiarito. Come ti avevo detto e come e' confermato dai due link che abbiamo fornito, non sono altro che lo stesso linguaggio compilati con compilatori differenti.

Non sono linguaggi differenti come sostenevi all'inizio accusandomi di fare cattiva informazione ;)


Invece ne stai (o forse devo dire state) facendo cattiva informazione è come dire che c, c++, c# sono tutti lo stesso linguaggio.


Ma stai solo affermando delle ovvieta' :)
E' risaputo che l'architettura NV30 richiede di ottimizzare gli shader ad hoc per ottenere le migliori prestazioni e in questo non c'e' nulla di male. E' una scelta di progetto del tutto legittima...

Quelle che per te sono ovvietà in realtà sono il fulcro della questione, tutte queste belle "funzionalità" come le chiami tu in realtà non servono ad altro che a raggiungere una efficienza altrimenti non raggiungibile con le schede nvidia.
A cosa mi serve un alto livello di programmabilità della gpu se poi il framerate non è all'altezza ?


L'architettura ATI ha dei vantanggi, quella NVIDIA degl'altri. NVIDIA mette a disposizione un compilatore che promette di produrre codice migliore. Sta allo sviluppatore supportarlo o meno sapendo che puo' usare il compilatore DX9 oppure OpenGL ed ottenere comunque prestazioni accettabilissime.


Accettabili ma non allineate a quelle della concorrenza, quindi l'uso del cg è fortemente pompato da quelli di nvidia


Qui stai facendo molta confusione. Un compilatore di shader produce codice assembly, non fa alcuna chiama a OpenGL o DX se non per assemblare il risultato della compilazione. Non fa chiamate all'ARB ad esempio, non setta stati di rendering, non usa estensioni (se non quella per assemblare lo shader). In poche parole non c'e' nulla da adattare alle nuove estensioni OGL15. Che poi non c'e' alcuna nuova estensione, sono solo state rese standard estensioni gia' esistenti e proprietarie.
Il codice assembly non chiama opengl ma viene eseguito dalla GPU.
Stai basando queste tue accuse su considerazioni tecniche assolutamente campate in aria (tipo il codice assembly che fa chiamate opengl che non vuol dire assolutamente nulla) e sarebbe meglio che perdessi piuttosto il tuo prezioso tempo ad informarti meglio sulle questioni tecniche che stai cercando di affrontare in maniera un po' approssimativa ;)

E' ovvio che un compilatore che genera codice assembly specifico per l'unità shader programmabile di una gpu genera del codice che fisicamente "gira" sulla gpu in oggetto (e che non "esce" dal suo mondo).
Mi sono spiegato male, e tu subito ne approfitti, ma quello che volevo dire è che

***
1) l'oggetto di questo articolo è "The OpenGL® 1.5 specification includes the revolutionary OpenGL® Shading Language, official ARB extensions that are expected to form the foundation of the upcoming OpenGL® 2.0 version of this cross-platform, open-standard API for advanced 3D graphics"

a) Il benlodato cg è compatibile con OpenGl 1.4
b) tu stesso ammetti che "E' risaputo che l'architettura NV30 richiede di ottimizzare gli shader ad hoc"
c) tu dici: "non c'e' nulla da adattare alle nuove estensioni OGL15"

Allora cg è compatibile OpenGl 1.5 ?
direi proprio di no !!!
Allora chi userebbe opengl 1.5 se "E' risaputo che l'architettura NV30 richiede di ottimizzare gli shader ad hoc"?
Come puoi ben vedere cg uccide lo standard !!!

Quindi è ovvio e ripeto: "Questo rappresenta a mio avvioso un serio OSTACOLO al diffondersi di nuovi standard perchè fino a quando nvidia non avrà reso compatibile cg con opengl 1.5 e 2.0 nessuno mai userà opengl 1.5 o 2.0 su schede nvidia, per non vedersi costretto ad ottimizzare a mano e, quando nvidia finalmente darà la compatibilità gli shaders dovranno comunque essere scritti in cg per avere performance migliori"


***
2) come puoi fidarti al punto da demandare ad un compilatore nvidia la creazione di codice specifico per una gpu ati ? (perchè ovviamente il set di istruzioni delle varie gpu è differente)



Falsissimo. Un'azienda media che deve rispettare dei tempi stretti non guarda Cg neppure di striscio e si butta su DX9 piano, lo standard.

Speriamo allora che non facciano la ca**ata di dare a mente ad nvidia. Ma cg e l'hlsl integrato in directx9 non erano la stessa cosa ?

Vedi che ti smentisci ;)

Sarei curioso di sapere se quello che ha fornito questa sua opinione ha mai scritto uno shader in vita sua.

La verita' e' che tutte le ditte si dirigono prima verso lo standard (DX9) e poi, se c'e' tempo, supportano Cg. Quindi non avete nulla di cui preoccuparvi :)

PS... l'HLSL "recently announced" e' di almeno un anno fa, questo articolo e' vecchiotto assai.

Originariamente inviato da fek
Sarei curioso di sapere se quello che ha fornito questa sua opinione ha mai scritto uno shader in vita sua.

La verita' e' che tutte le ditte si dirigono prima verso lo standard (DX9) e poi, se c'e' tempo, supportano Cg. Quindi non avete nulla di cui preoccuparvi :)

PS... l'HLSL "recently announced" e' di almeno un anno fa, questo articolo e' vecchiotto assai.

Quando non hai più argomenti ti attacchi anche all'HLSL "recently announced" ?
Ce ne sono migliaia di articoli ma i fatti non li cambi caro mio ;)

Originariamente inviato da pg08x
Invece ne stai (o forse devo dire state) facendo cattiva informazione è come dire che c, c++, c# sono tutti lo stesso linguaggio.

Si', stiamo facendo tutti cattiva informazione a parte te :)

Ho spiegato chiaramente che la differenza sono alcune estensioni al linguaggio proprietarie nvidia, un po' come le estensioni che un qualunque compilatore C++ introduce al C++ stesso e nessuno si sogna dire che stanno implementando un nuovo linguaggio.

Mi sembrava di essere stato molto chiaro su questo punto: era difficile fare confusione con le differenze fra C# e C++. Decisamente due linguaggi diversi.

Pensavo ti fossi chiarito le idee su questo punto e avessi accettato che sono lo stesso linguaggio.


Quelle che per te sono ovvietà in realtà sono il fulcro della questione, tutte queste belle "funzionalità" come le chiami tu in realtà non servono ad altro che a raggiungere una efficienza altrimenti non raggiungibile con le schede nvidia.
A cosa mi serve un alto livello di programmabilità della gpu se poi il framerate non è all'altezza ?

Anche qui ho spiegato piuttosto diffusamente che le differenze in termini di frame rate sono trascurabili nel 99% dei casi. Il frame rate non all'altezza e' una tua invenzione corroborata da nessun fatto.



a) Il benlodato cg è compatibile con OpenGl 1.4
b) tu stesso ammetti che "E' risaputo che l'architettura NV30 richiede di ottimizzare gli shader ad hoc"
c) tu dici: "non c'e' nulla da adattare alle nuove estensioni OGL15"

Allora cg è compatibile OpenGl 1.5 ?
direi proprio di no !!!
Allora chi userebbe opengl 1.5 se "E' risaputo che l'architettura NV30 richiede di ottimizzare gli shader ad hoc"?
Come puoi ben vedere cg uccide lo standard !!!

Quanta confusione che stai facendo. E' tutto molto piu' semplice: il compilatore Cg produce uno shader in assembly secondo le specifiche ARB (1.4 e ora 1.5). Quel codice assembly non fa alcuna chiamata a OpenGL (al contrario di come pensavi), quindi non c'e' assolutamente nulla da adattare. Questo discorso non c'entra nulla con il fatto che NV30 richieda piu' ottimizzazioni specifiche. E' un discorso totalmente slegato.

Spero di essere stato piu' chiaro questa volta.


Quindi è ovvio e ripeto: "Questo rappresenta a mio avvioso un serio OSTACOLO al diffondersi di nuovi standard perchè fino a quando nvidia non avrà reso compatibile cg con opengl 1.5 e 2.0 nessuno mai userà opengl 1.5 o 2.0 su schede nvidia, per non vedersi costretto ad ottimizzare a mano e, quando nvidia finalmente darà la compatibilità gli shaders dovranno comunque essere scritti in cg per avere performance migliori"

No. E non so piu' come scrivertelo. Mi viene il sospetto che tu non legga quello che scriviamo, perche' non te l'ho ripetuto solo io. Lo standard e' HLSL, Cg compila codice HLSL e produce assembly ottimizzato per le piattaforme NVIDIA. Nessuno e' costretto a scrivere in Cg. Si puo' scrivere HLSL e decidere con quale compilatore compilare il codice a seconda delle sue esigenze. Non c'e' alcuna costrizione, solo possibilita' in piu'.

E' come se io decidessi di compilare un programma C++ con il compilatore C++ Intel: su piattaforme Intel (ovviamente) questo produce codice migliore del compilatore Microsoft (altrettanto ovviamente). Il compilatore C++ Intel introduce alcune estensioni al linguaggio C++ ma nessuno accusa Intel di forzare gli sviluppatori a scrivere nel suo linguaggio. E' una situazione perfettamente analoga.



***
2) come puoi fidarti al punto da demandare ad un compilatore nvidia la creazione di codice specifico per una gpu ati ? (perchè ovviamente il set di istruzioni delle varie gpu è differente)


Se non ti fidi, compili con il compilatore DX9, il codice dello shader rimane uguale. E anche qui l'ho gia' scritto 10 volte :)




Speriamo allora che non facciano la ca**ata di dare a mente ad nvidia. Ma cg e l'hlsl integrato in directx9 non erano la stessa cosa ?

Vedi che ti smentisci ;)

No, sei tu che non hai capito :)
Le ditte useranno il compilatore DX9 perche' e' standard.

Originariamente inviato da pg08x
Quando non hai più argomenti ti attacchi anche all'HLSL "recently announced" ?
Ce ne sono migliaia di articoli ma i fatti non li cambi caro mio ;)

A me sembra che stai vivendo in un mondo tutto tuo :)
Piu' che altro fai enorme confusione fra i vari concetti e come ho detto trai conclusioni del tutto campate in aria. Altro che fatti, diciamocelo, non sai di che stai parlando ma cerchi di avere ragione a tutti i costi ;)

Guarda che non mi costa nulla darti ragione...

[QUOTE]Originariamente inviato da DoomIII
ma che lamer... ma che cavolo di storielle per allocchi vi inventate?

se ne era già parlato a suo tempo... vai un po a vedere cosa significa usare le varie estensioni... e smettiamola con queste lamerate di disinformazione mirate...

------------------------------------------------------------------------------------

Se fossi in te non parlerei molto di disinformazione mirate, se c'è qualcuno che fa disinformazioni mirate quello sei proprio tu e fek. O forse la tua è semplice ignoranza?
pg08x ha confermato le sue idee sul proposito riportando anche voci ufficiali nVidia (che riportano quanto da lui detto).
Quindi prima di offendere e accusare ingiustamente gli altri guardati prima per te. Mi sembri del tutto oscurato dalla opprimente figura di nVidia che cerca di imporre al mercato il suo volere.
Almeno gli altri, nVidia, li paga per farsi dire quello che vuole che li sia detto, te no.

Tanti saluti,

Originariamente inviato da Ywes
pg08x ha confermato le sue idee sul proposito riportando anche voci ufficiali nVidia (che riportano quanto da lui detto).

Guarda che proprio i quote di nvidia che ha riportato lo smentiscono completamente.

Ragazzi, seriamente, pg e' simpatico ma non non e' questione di fare disinformazione mirata da parte sua, e' proprio che non sa di che cosa sta parlando e fa un sacco di confusione fra i concetti, per poi trarne le conclusioni che vuole lui.

Ad esempio, dire che il codice assembly compilato fa chiamate opengl per poi affermare che il linguaggio Cg (aridaje) e' incompatibile con OpenGL 1.5 e' una fesseria ai confini della realta'. E' come se io mi mettessi a parlare di calcio con un giocatore e gli andassi a dire che a calcio si gioca con le racchette da tennis. E pretendessi pure di aver ragione! :D

Originariamente inviato da fek
Ad esempio, dire che il codice assembly compilato fa chiamate opengl per poi affermare che il linguaggio Cg (aridaje) e' incompatibile con OpenGL 1.5 e' una fesseria ai confini della realta'. E' come se io mi mettessi a parlare di calcio con un giocatore e gli andassi a dire che a calcio si gioca con le racchette da tennis. E pretendessi pure di aver ragione! :D

Ma non sai proprio più a cosa attaccarti ?
riguardo al discorso delle chiamate ti riporto testualmente quanto ho scritto pochi post prima:

"E' ovvio che un compilatore che genera codice assembly specifico per l'unità shader programmabile di una gpu genera del codice che fisicamente "gira" sulla gpu in oggetto...."

Ma tu quante volte ancora vuoi :mc: con questa storia delle chiamate openGl ? mi sembra proprio che non è la prima volta :O (e poi Arb non diventerà forse parte integrante di OpenGL) ?

Riguardo all'utilizzo di OpenGl mi "sembra" che ci sia scritto 1.4 non 1.5 !
Come fa un linguaggio ideato un anno fa (cg) a generare già adesso, senza modifiche, un codice che sfrutti uno standard annunciato oggi ? (opengl 1.5)

Cg Compilers output assembly code in the formats defined by OpenGL extensions such as ARB_vertex_program, ARB_fragment_program and NV_vertex_program, and in the format defined by OpenGL 1.4.

Fonte nvidia:O

Fek invece di cercare il pelo nell'uovo (come quella dell'articolo che muove giuste critiche e tu neanche consideri giudicandolo ormai "vecchio" solo perchè ti fa comodo) perchè non capisci qual'è il "vero" punto della discussione ?

Con che arroganza nvidia (produttore di gpu) si da la pena di ideare e fornire gratuitamente agli sviluppatori un compilatore in grado di generare codice per gli shaders che "gira" sulle gpu della concorrenza ?
E stiamo parlando di gpu che hanno un set di istruzioni per gestire gli shaders Totalmente differente.

Avrebbero fatto molto + bella figura a fare un compilatore che generasse codice solo per gpu nvidia. :(

E' vero che nessuno ti obbliga a usare il compilatore cg ma se lo usi non credo proprio che poi vai a testare il tipo di gpu installata e se non è nvidia fai girare codice scritto con i compilatori standard.

Le tue critiche a Carmack mi confermano appunto questo.

Infine non fa ne caldo ne freddo se ti riempi la bocca più e più volte scrivendo "io sono un programmatore 3d" cosa che pure appare in coda a molti dei tuoi messaggi... oppure "ho scritto lo shader" (che poi sono piccole routine con una sintassi simile al c)... io non mi sono mai vantato della posizione che ricopro o di quali siano le mie responsabilità nel team di sviluppo e mai ti ho attaccato dicendo che "fai confusione" o peggio.

Originariamente inviato da pg08x
Riguardo all'utilizzo di OpenGl mi "sembra" che ci sia scritto 1.4 non 1.5 !
Come fa un linguaggio ideato un anno fa (cg) a generare già adesso, senza modifiche, un codice che sfrutti uno standard annunciato oggi ? (opengl 1.5)

Cg Compilers output assembly code in the formats defined by OpenGL extensions such as ARB_vertex_program, ARB_fragment_program and NV_vertex_program, and in the format defined by OpenGL 1.4.

Fonte nvidia:O

Guarda che OpenGL 1.5 non e' nient'altro che la standardizzazione delle estensioni ARB :)
Ovvio che se genera codice per le estensioni ARB e queste sono incorporate in 1.5 (non sono piu' estensioni ma parte integrante dello standard opengl) allora il codice e' compatibile. Mi sembrava una cosa talmente banale da non meritare neppure di essere puntualizzata.

Suvvia, questo e' proprio l'ABC...

Originariamente inviato da pg08x
Fek invece di cercare il pelo nell'uovo (come quella dell'articolo che muove giuste critiche e tu neanche consideri giudicandolo ormai "vecchio" solo perchè ti fa comodo) perchè non capisci qual'è il "vero" punto della discussione ?


Qui non e' cercare il pelo nell'uovo ma far notare come quello che ha scritto l'articolo non sa di che cosa sta parlando e si basa su informazioni vecchie, addirittura risalenti a prima che DX9 beta uscisse. Voglio capire come puoi basare le tue considerazioni su cio' che scrive qualcuno che evidentemente non sa di che cosa sta parlando e fa speculazioni inesatte su qualcosa che ancora non e' uscito. Tu mi insegni che all'attuale ritmo di sviluppo della grafica in tempo reale, un anno non e' propriamente un lasso di tempo trascurabile.


Con che arroganza nvidia (produttore di gpu) si da la pena di ideare e fornire gratuitamente agli sviluppatori un compilatore in grado di generare codice per gli shaders che "gira" sulle gpu della concorrenza ?
E stiamo parlando di gpu che hanno un set di istruzioni per gestire gli shaders Totalmente differente.


Incommentabile. Con che arroganza nvidia mette a disposizione un tool totalmente gratuito, open source che ogni programmatore e' libero di usare se ha il tempo e la voglia di farlo? Con che arroganza Linus Torvald a messo a disposizione linux in foruma di open source :rolleyes:


Avrebbero fatto molto + bella figura a fare un compilatore che generasse codice solo per gpu nvidia. :(

E' vero che nessuno ti obbliga a usare il compilatore cg ma se lo usi non credo proprio che poi vai a testare il tipo di gpu installata e se non è nvidia fai girare codice scritto con i compilatori standard.

Le tue critiche a Carmack mi confermano appunto questo.

Finalmente hai cambiato idea e ti sei convinto che nessuno obbliga nessuno ad usare Cg :)

Poi, credo invece che vai proprio a testare su quale GPU sta girando il codice (sono due righe di codice) e poi scegli il codepath specifico oppure, in un sistema con fallback, ci basi la validazione dello shader; ovviamente posso decidere di non validare uno shader compilato con Cg su piattaforma ATI e fare il fallback verso lo stesso shader compilato con DX9. Anche qui sono due righe di codice (una volta che l'architettura della shaderlib e' in piedi, queste non sono due righe di codice :p)

Come ti ho detto sei simpatico, ma oggettivamente non sai di che cosa stai parlando.

Originariamente inviato da pg08x
Infine non fa ne caldo ne freddo se ti riempi la bocca più e più volte scrivendo "io sono un programmatore 3d" cosa che pure appare in coda a molti dei tuoi messaggi... oppure "ho scritto lo shader" (che poi sono piccole routine con una sintassi simile al c)... io non mi sono mai vantato della posizione che ricopro o di quali siano le mie responsabilità nel team di sviluppo e mai ti ho attaccato dicendo che "fai confusione" o peggio.

Dai, adesso non buttarla sul personale :)
Non mi sono mai vantato di essere un programmatore 3d (oddio, come se ci fosse qualcosa di cui vantarsi nell'esserlo). E' solo per dire che essendo il mio lavoro qualcosa di attendibile credo di saperlo come sono certissimo che tu sei assolutamente attendibile nel campo in cui sviluppi.
Mi scuso se quel "fai confusione" suona come un attacco ma non vuole assolutamente esserlo. Vuole sottolineare dove effettivamente stai facendo confusione fra vari concetti e dove le tue conclusioni sono viziate da questa "ignoranza" (nel senso buono del termine, non mi fraintendere) su alcuni aspetti della programmazione 3d.
Con tutta la simpatia, hai una discreta infarinatura generale sull'argomento ma quando scendi nei dettagli spari roba fuori dai satelliti, dimostrando di saperne quasi nulla dal lato pratico e teorico. Come io certamente non so assolutamente nulla riguardo a quello di cui ti occupi tu.
Per questo a volte mi permetto di correggerti sugli errori davvero macroscopici, ti prego di non prenderla come una mancanza di rispetto, non vuole esserlo. E' solo perche' mi diverto molto a parlare di questa roba e mi piace raccontare quello che so a riguardo in maniera precisa. Su tutto il resto me ne sto zitto :p

clap clap :) farplay mode on;)

Cos'è "farpaly"? Scusate l'ignoranza! ;)

Originariamente inviato da Ywes
[QUOTE]Originariamente inviato da DoomIII
ma che lamer... ma che cavolo di storielle per allocchi vi inventate?

se ne era già parlato a suo tempo... vai un po a vedere cosa significa usare le varie estensioni... e smettiamola con queste lamerate di disinformazione mirate...

------------------------------------------------------------------------------------

Se fossi in te non parlerei molto di disinformazione mirate, se c'è qualcuno che fa disinformazioni mirate quello sei proprio tu e fek. O forse la tua è semplice ignoranza?
pg08x ha confermato le sue idee sul proposito riportando anche voci ufficiali nVidia (che riportano quanto da lui detto).
Quindi prima di offendere e accusare ingiustamente gli altri guardati prima per te. Mi sembri del tutto oscurato dalla opprimente figura di nVidia che cerca di imporre al mercato il suo volere.
Almeno gli altri, nVidia, li paga per farsi dire quello che vuole che li sia detto, te no.

Tanti saluti,

Scusa quale disinformazione mirata stiamo facendo?
Solo perchè non vi diamo ragione in questa morale seconda la quale nVidia ha tutte le colpe del mondo.. immagino anche l'inquinamento la poverta ecc... siano tutte colpe sue... mentre Ati è la salvatrice del mondo vero? :rolleyes:
come ti permetti di tirare in ballo discorsi del tipo: "nVidia paga ma a voi non vi paga?"
pagarmi per cosa? per difendarla? non sto mica difendando... a differenza di pg che considera Ati salvatore del mondo ho detto la mia opinione... sono azienze ed hanno TUTTE lo stesso obiettivo... FATTURARE!!!!
e commentare dicendo cosa sia Cg, DX ecc... a chi non lo sa e fa confusione non significa certo difendere nVidia... :confused:

opinioni diverse si possono avere... ma poi ci sono cose che sono dati di fatto... e su queste cose non si può sparare a 0 o inventarsi proprie fantasie... arrivanda ad esempio ad inventarsi i motivi per cui DoomIII sarebbe in ritando amputando ad nVidia la colpa... ma dai....

Originariamente inviato da fek
Guarda che OpenGL 1.5 non e' nient'altro che la standardizzazione delle estensioni ARB :)
Ovvio che se genera codice per le estensioni ARB e queste sono incorporate in 1.5 (non sono piu' estensioni ma parte integrante dello standard opengl) allora il codice e' compatibile. Mi sembrava una cosa talmente banale da non meritare neppure di essere puntualizzata.

Suvvia, questo e' proprio l'ABC...

Non credo affatto che Opengl1.4 sia proprio identico a OpenGl1.5 tu ne sei assolutamente sicuro ?
E poi che dire di OpenGl 2.0 ? il discorso si ripete anzi, si amplifica.


Qui non e' cercare il pelo nell'uovo ma far notare come quello che ha scritto l'articolo non sa di che cosa sta parlando e si basa su informazioni vecchie, addirittura risalenti a prima che DX9 beta uscisse. Voglio capire come puoi basare le tue considerazioni su cio' che scrive qualcuno che evidentemente non sa di che cosa sta parlando e fa speculazioni inesatte su qualcosa che ancora non e' uscito. Tu mi insegni che all'attuale ritmo di sviluppo della grafica in tempo reale, un anno non e' propriamente un lasso di tempo trascurabile.

Quell'articolo muove delle giuste critiche, inutile negarlo.


Incommentabile. Con che arroganza nvidia mette a disposizione un tool totalmente gratuito, open source che ogni programmatore e' libero di usare se ha il tempo e la voglia di farlo? Con che arroganza Linus Torvald a messo a disposizione linux in foruma di open source :rolleyes:

Adesso vuoi mettere sullo stesso piano il lavoro, nato quasi per gioco di Linus Torvalds con la manovra commerciale di una multinazionale come nvidia... ma ti rendi conti di quello di cui stai parlando !
In che mondo vivi ? non ti regala niente nessuno !
cg è nato per invogliare gli sviluppatori ad ottimizzare gli shaders su piattaforme nvidia a danno delle altre, a meno che non usino path differenti cosa che hai ammesso più volte è poco praticabile.
Su una cosa mi sento in accordo con DoomIII: "sono azienze ed hanno TUTTE lo stesso obiettivo... FATTURARE!!!! "


Finalmente hai cambiato idea e ti sei convinto che nessuno obbliga nessuno ad usare Cg :)

Non ho affatto cambiato idea, nvidia "spinge" gli sviluppatori ad usare cg, se li obbligasse anche ci sarebbero gli estremi per una denuncia !

Dai, adesso non buttarla sul personale :)
Non mi sono mai vantato di essere un programmatore 3d (oddio, come se ci fosse qualcosa di cui vantarsi nell'esserlo). E' solo per dire che essendo il mio lavoro qualcosa di attendibile credo di saperlo come sono certissimo che tu sei assolutamente attendibile nel campo in cui sviluppi.
Mi scuso se quel "fai confusione" suona come un attacco ma non vuole assolutamente esserlo. Vuole sottolineare dove effettivamente stai facendo confusione fra vari concetti e dove le tue conclusioni sono viziate da questa "ignoranza" (nel senso buono del termine, non mi fraintendere) su alcuni aspetti della programmazione 3d.
Con tutta la simpatia, hai una discreta infarinatura generale sull'argomento ma quando scendi nei dettagli spari roba fuori dai satelliti, dimostrando di saperne quasi nulla dal lato pratico e teorico. Come io certamente non so assolutamente nulla riguardo a quello di cui ti occupi tu.
Per questo a volte mi permetto di correggerti sugli errori davvero macroscopici, ti prego di non prenderla come una mancanza di rispetto, non vuole esserlo. E' solo perche' mi diverto molto a parlare di questa roba e mi piace raccontare quello che so a riguardo in maniera precisa. Su tutto il resto me ne sto zitto :p
L'impressione che ho avuto è stata quella che tu, per avvalorare la tua tesi secondo cui questo cg risulta essere "bello, buono e giusto" ti sei attaccato a delle inezie (quella dell'articolo datato e quella storia delle chiamate OpenGl) che di fatto non cambiano assolutamente nulla.
Vorrei chiarire la cosa con un piccolo esempio:
Cammini per la strada e vedi una cacca di cane, incontri un tuo amico spendi parole su parole per discutere se questa cacca ha un colore marrone più o meno chiaro ma sono dettagli... resterà sempre una cacca, non ne cambi la natura !

Originariamente inviato da pg08x
Non credo affatto che Opengl1.4 sia proprio identico a OpenGl1.5 tu ne sei assolutamente sicuro ?
E poi che dire di OpenGl 2.0 ? il discorso si ripete anzi, si amplifica.


Non e' assolutamente identico a OpenGL 1.4 :)
E sostanzialmente OpenGL 1.4 + ARB + tweak all'interfaccia qui e la (aaaah i bei tempi delle estensioni opengl)...


Adesso vuoi mettere sullo stesso piano il lavoro, nato quasi per gioco di Linus Torvalds con la manovra commerciale di una multinazionale come nvidia... ma ti rendi conti di quello di cui stai parlando !
In che mondo vivi ? non ti regala niente nessuno !
cg è nato per invogliare gli sviluppatori ad ottimizzare gli shaders su piattaforme nvidia a danno delle altre, a meno che non usino path differenti cosa che hai ammesso più volte è poco praticabile.
Su una cosa mi sento in accordo con DoomIII: "sono azienze ed hanno TUTTE lo stesso obiettivo... FATTURARE!!!! "

Ovvio che non li metto sullo stesso piano, ho detto che se per te e' una mossa sporca e riprovevole distribuire un compilatore open source come ha fatto nvidia dovresti giudicare altrettanto riprovevole il buon Linus che ha fatto uscire un intero sistema operativo free e, ovviamente, spingerebbe tutti per usarlo ;)

E ci manca solo che non lo facesse...

Originariamente inviato da pg08x
L'impressione che ho avuto è stata quella che tu, per avvalorare la tua tesi secondo cui questo cg risulta essere "bello, buono e giusto" ti sei attaccato a delle inezie (quella dell'articolo datato e quella storia delle chiamate OpenGl) che di fatto non cambiano assolutamente nulla.

Piaaaaaaaaaaaaaaaaaano. Io non ho mai detto che Cg e' "bello, buono e giusto" anzi, ho addirittura detto che personalmente non lo supporto (e se all'nvidia non si sbrigano a dirmi perche' non mi riconosce il vertex format Black&White 2 uscira' 100% Cg-free :p).
Ma qui sembra veramente che se non si dice peste e corna di nvidia per te automaticamente la si sta difendendo a spada tratta.
Invece ho cercato di dire le cose piu' o meno come stanno, senza entrare troppo nei particolari perche' tanto non interessano quasi a nessuno (ma se vuoi via mail scendo in tutti i particolari che ti possono interessare tanto mi diverto :p).

Ed infine, questa concorrenza fra nvidia e ati e' una manna dal cielo per noi sviluppatori (e quindi anche per gli utenti :p) perche' siamo coccolatissimi da entrambe, entrambe producono molti tool free e forniscono valanghe di documentazione (per non parlare delle conferenze con tonnellate di cibo e donnine seminude! :D). Dal mio punto di vista, forse, preferisco un filo le developer relation di nvidia, mi sembrano un po' piu' puntuali, mentre dal punto di vista hardware preferisco ati: c'e' poco da fare, quando c'e' da farle camminare per bene, viaggia di piu' e l'architettura e' una bellezza.
Dove nvidia surclassa nettamente ati e' il marketing: li' non c'e' paragone, nvidia ha i contratti migliori con svariate aziende e distributori (EA in primis).

Ok, la smetto altrimenti andrei avanti per paginate... :)

Originariamente inviato da fek
Ovvio che non li metto sullo stesso piano, ho detto che se per te e' una mossa sporca e riprovevole distribuire un compilatore open source come ha fatto nvidia dovresti giudicare altrettanto riprovevole il buon Linus che ha fatto uscire un intero sistema operativo free e, ovviamente, spingerebbe tutti per usarlo ;)

Per nvidia era una necessità, per Linus un gioco. C'è una bella differenza.


(per non parlare delle conferenze con tonnellate di cibo e donnine seminude! :D). Dal mio punto di vista, forse, preferisco un filo le developer relation di nvidia, mi sembrano un po' piu' puntuali, mentre dal punto di vista hardware preferisco ati: c'e' poco da fare, quando c'e' da farle camminare per bene, viaggia di piu' e l'architettura e' una bellezza.
Dove nvidia surclassa nettamente ati e' il marketing: li' non c'e' paragone, nvidia ha i contratti migliori con svariate aziende e distributori (EA in primis).

Ti posso capire ma preferisco 1000 volte chi si concentra più sull'hardware e sugli standard a chi investe così tanto sul marketing, augurati solo che di ditte come nvidia non ne spuntino altre 2 o 3 altrimenti, tempo tiranno, saresti costretto a concentrarti solo per una di esse...

Riguardo alle coccole con il tempo ti renderai conto che sono tutte falsità te le fanno perchè li fai guadagnare...

PS: Comunque è stata una gran bella chiaccherata ;)

Originariamente inviato da pg08x
Per nvidia era una necessità, per Linus un gioco. C'è una bella differenza.

Non e' una neccessita'. Ti ho descritto come queste ottimizzazioni sono perfettamente inutili nel 99% dei casi pratici. E' solo una possibilita' in piu' che viene offerta agli sviluppatori (ben vengano, poi tocca a noi scegliere quella che piu' si adatta alle esigenze che sono sempre diverse e quindi richiedono soluzioni diverse!).

Riguardo alle coccole con il tempo ti renderai conto che sono tutte falsità te le fanno perchè li fai guadagnare...

Ma mi prendi per uno sprovveduto? :D

(Sapessi le cose che accadono di davvero sporco nell'industry... *cough* Sony *cough* )


PS: Comunque è stata una gran bella chiaccherata ;)

Yup :D

Originariamente inviato da DoomIII
dipende dai punti di vista. :)

Quasi... ;)


non è che un programmatore non può accedervi... anche se certe spec. potrebbero essere celate...
in generale però in questo modo (con il compilatore) cambiando chip o anche tramite driver dando nuove spec/ottimizzazioni su uno stesso chip ricompilare senza modifiche il codice porta a dei benefici poichè il compilatore si assume la responsabilità di ottimizzare andando ad esempio a sfruttare nuovi registri ecc...

Per fare ciò, però, si deve comunque aggiornare il generatore di codice del compilatore per supportare le caratteristiche delle nuove architetture. E se non lo fa nessuno? Il suo uso sarebbe inutile.

L'interesse dovrebbe essere delle case madri: se queste si affidano alle specifiche standard, come fanno in molti, che senso ha utilizzare un compilatore a più alto livello e tenerlo aggiornato?


altrimenti un programmatore se vuole fare queste ottimizzazioni deve modificare il codice.

In ogni caso dovrebbe ricompilare il codice, e data la (piccola) dimensione di uno shader, si potrebbe anche pensare di dargli una sistemata per renderlo più veloce sulla nuova architettura. Se poi quest'ultima è standard, il discorso non si pone nemmeno...

Comunque capisco che potrebbe essere particolarmente rognoso, nel caso di differenze marcate, andare a scrivere del codice dedicato (vedi messaggi di Fek in proposito... :))

Originariamente inviato da fek
Mi sono spiegato male prima, scusami. A volte do' troppe cose per scontate.

Non ti preoccupare, capita spesso anche a me... :P


Il programmatore e' teoricamente in grado di accedere alle informazioni sull'architettura di una GPU esattamente come il compilatore. Come hai scritto giustamente tu in seguito, entrambi lavorano sullo stesso hardware e software.
Ma c'e' un problema: queste informazioni non sono pubblicate dagli hardware vendor (nvidia o ati), sono coperte da copyright e interne, per ragioni ovvie.
Anche se teoricamente posso scrivere lo stesso codice di un compilatore e, spendendoci molto tempo, codice anche migliore, in pratica io non conoscero' mai quei dettagli sull'architettura e di fatto non saro' mai in grado di scrivere quel codice.

E' anche vero, però, come dicevo a DoomIII, che ciò implica un costante aggiornamento del back-end del compilatore per supportare le nuove architetture, con tutte le conseguenze che ho rilevato.

D'altra parte, se proprio si vogliono conoscere i dettagli di un'architettura, si possono realizzare degli opportuni shader e andare a vedere il codice assembly generato dal compilatore per risalire a quelle informazioni... ;) Un lavoraccio, e per gente che ha parecchia esperienza di reverse enginering, ma pur sempre fattibile...

Comunque, nelle ipotesi da te riportate, molto probabilmente il gioco non vale la candela: ci sarebbe troppo tempo da perdere...


Chi scrive il compilatore, in realta' per precisione dovrei dire chi scrive la porzione di codice che emette le istruzioni assembly, e' un dipendente nvidia o ati quindi ha accesso a quelle informazioni e puo' usarle, anzi, le usa :)

Appunto, e anche da qui si potrebbe analizzare e ricostruire le informazioni di cui sopra... ;) Ma è pur sempre troppo laborarioso e ostico... :P


2) si', gli algoritmi non sono particolarmente complicati, ma la loro scrittura in assembly spesso diventa piuttosto rognosa, soprattutto la gestione dei registri temporanei che come ho scritto prima non e' un'operazione che il cervello umano gestisce comodamente.

Dipende dal loro numero e soprattutto dalla complessità dello shader. Ma da quel che scrivi capisco che lavorarci dev'essere veramente impensabile se non si vuole arrivare ai tempi di Doom III per lo sviluppo e la commercializzazione di un prodotto...

Paradossalmente e' piu' facile per un compilatore ottimizzare un algoritmo semplice (ma direi meglio specifico) di uno complicato perche' su un algoritmo semplice ha bisogno di fare meno "speculazioni" e gli e' piu' facile avvicinarsi al pensiero del programmatore. Il modello di programmazione degli shader e' piuttosto semplice e specifico (non e' un linguaggio generico), quindi il compilatore gioca in casa

Sicuramente. Il vantaggio dell'essere umano è che, avendo una visione d'insieme/astratta di un algoritmo, può arrivare a scrivere del codice che nessun compilatore sarebbe in grado di generare "automaticamente" (neppure il compilatore della Intel per le SSE2... :))


3) verissimo... e ti assicuro che e' molto piu' veloce e comodo scriverlo in HLSL :)

Non lo metto in dubbio, visto che ci lavori... ;) A me interessava capire alcune cose che mi erano oscure o su cui avevo dei dubbi, e per questo ti ringrazio...


C'e' una cosa interessante da dire sul discorso assembly contro hlsl: scrivo il mio shader in assembly, funziona, e' stra ottimizzato, sono felicissimo, dopo un mese devo modificarlo leggermente perche' ho bisogno di qualcosa di leggermente diverso, guardo il codice in assembly e penso: "che e' sta roba qui?" :D

Questo, però, è un problema comune dei programmatori svogliati o che non hanno il tempo di scrivere commenti (in particolare di questi ultimi... ;)) E' per questo che preferisco un linguaggio Pascal-like, qual è Delphi, perché mi consente di perdere meno tempo nel ricordare il funzionamento di un programma che non tocco anche da anni, sempre tenendo un certo stile e l'uso di nomi auto-esplicativi per gli identificatori... :D

Comunque, capisco bene quel che dici, perché i sorgenti assembly che ho scritto in questi vent'anni per diverse architetture, pur se usciti dalle miei mani e scritti con un certo criterio/stile, risultano abbastanza ostici alla loro lettura: è un problema intriseco del classico codice assembly, purtroppo :( (ed è anche il motivo per cui ho scritto dei compilatori di medio-alto livello che mi permettono di stendere codice effeciente quanto l'assembly, ma leggibile quasi quanto un linguaggio di alto livello... :))

Infine, proprio perché ho finalmente chiari alcuni elementi, non posso che essere d'accordo con te per quanto riguarda la diatriba sorta con pg08x sull'utilizzo e il funzionamento del Cg rispetto alle specifiche DirectX e OpenGL: il compilatore svolge un ruolo che nulla ha a che vedere con queste ultime, né le "usa", se non in funzione degli standard/sintassi che questi impongono per il codice assembly da generare, né può prendere il loro posto. Si può considerare un sostituto, eventualmente, soltanto della parte delle DirectX/OpenGL per quanto riguarda la generazione del codice assembly a partire dal sorgente scritto in linguaggio ad alto livello (HLSL o ABR).

Per me il discorso è fin troppo chiaro, forse perché ho anche esperienza nel campo della scrittura di compilatori...

P.S. I compilatori poi non è detto che generino codice assembly: possono anche generare direttamente gli eseguibili/binarii, come fanno tutti quelli che ho scritto... ;)