Annunciate le nuove specifiche Open GL 1.5

[fek]

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

[pg08x]

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.

[cdimauro]

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 ). Quindi dovrebbe essere semplice e non dovrebbe richiedere tanto tempo la stesura di codice per la GPU da parte di un programmatore.

[DoomIII]

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.

[DoomIII]

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.

[cionci]

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

[cionci]

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

[fek]

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

[fek]

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

[pg08x]

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

Correggimi se sbaglio .....

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

[pg08x]

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

[pg08x]

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.

[pg08x]

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.

[fek]

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.

[fek]

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

[fek]

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.

[pg08x]

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

[pg08x]

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

[pg08x]

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.