Annunciate le nuove specifiche Open GL 1.5

[Redazione di Hardware Upg]

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.

[pg08x]

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

[$!/\/\o]

uno risulta polemico quando si inventa o si arrampica sugli specchi 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

[Aryan]

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

[lingie]

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.

[fek]

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.

[KAISERWOOD]

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

[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

[Jack Ryan]

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

... forse non interessa ancora questa release a nessuno

[pg08x]

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 !

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

[pg08x]

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.

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

[pg08x]

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

[fek]

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.

[pg08x]

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.

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

[DoomIII]

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

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

[pg08x]

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.

[massimomarc]

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 ?