Microsoft spiega il futuro della tecnologia DirectX

[-fidel-]

Originariamente inviato da eltalpa

Questa cosa è "curiosa", ma l'ho notato anche io: è l'hardware (schede video), che si adatta al software (dx)... ne consegue anche che è OVVIO che MS sia più avanti, proprio per il fatto che è lei a decidere le specifiche delle nuove schede video (vedi la storia degli shader unificati). Una posizione indubbiamente vantaggiosa, in questa maniera qualsiasi altra libreria grafica si troverà sempre un passo indietro...

Potenza di un'azienda in posizione di monopolio e con atteggiamenti monopolistici. In queste condizioni, tutto il resto si può sempre trovare in posizione di svantaggio. Non per togliere demeriti tecnici a MS intendiamoci, ma il fatto di poter collaborare direttamente con i produttori hardware video e decidere l'evoluzione delle funzionalità della GPU è un provilegio non da poco. Anche per questo MS uscì fuori da OpenGL (di cui se non erro era un membro di primo piano) per iniziare il progetto DirectX da zero (e non è stato facile imporlo sul mercato, visto che appunto sono partiti da zero, ma avevano tanti "assi" nella manica che sono facilmente immaginabili )
Per quanto riguarda DX 10.1, ripeto, aspettiamo di vedere giochi DX 10.0, poi giustamente MS parla del futuro della piattaforma (del resto il GDC mi sembra un luogo appropriato).

EDIT: poi ora grazie ad XBox, anche Carmack ha "capitolato" verso DirectX (del resto i soldi sono soldi ): ma nella PS3 invece che librerie grafiche si usano? Mi pareva una versione modificata di OGL.

[coschizza]

Originariamente inviato da -fidel-

EDIT: poi ora grazie ad XBox, anche Carmack ha "capitolato" verso DirectX (del resto i soldi sono soldi ): ma nella PS3 invece che librerie grafiche si usano? Mi pareva una versione modificata di OGL.

per ora le principali tecnologie sono:

OpenGL ES 2.0 compliant except for the use of nVidia's Cg instead of GLSL
OpenMAX
OpenVG

[^TiGeRShArK^]

Originariamente inviato da Pr|ckly

La mia non è una scheda Dx 9.0b ma 9.0
E' una 9800, shader 2.0 ma non credo proprio che non supporti le 9.0c, una volta me le ha pure richieste per far partire un gioco.
Penso che un conto sia non avere un'effetto come gli shader 3.0 perchè la scheda non lo supporta, un conto non supportare del tutto una versione di directx...

Qua nessuno sta dicendo che le schede non partono con i giochi scritti con le dx 10.1.
Si sta dicendo che non sono compatibili con questa versione di dx e quindi NON ne possono sfruttare le nuove caratterisitche.

[^TiGeRShArK^]

Originariamente inviato da Bellaz89

X ^TiGeRShArK^

E vero ieri è vero oggi e sarà vero domani, le dx sono di troppo alto livello per fare certe cose, e inoltre sono pensate per fare giochi e basta (escludendo utilizzi non molto complessi). Inoltre da un certo punto di vista le opengl possono fare cose che in dx non si può neanche immaginare, sennò come me lo spieghi che la gente compra Quadro e Firegl o workstation della sgi ?Senza andare poi nel campo dell' integrato e del critico....

Dimmi, a livello di codice, in cosa sarebbero meglio le opengl rispetto alle directx.
Con le Directx puoi fare tutto quello ke fai con le opengl con minor sforzo.

[Pr|ckly]

Originariamente inviato da ^TiGeRShArK^

Qua nessuno sta dicendo che le schede non partono con i giochi scritti con le dx 10.1.
Si sta dicendo che non sono compatibili con questa versione di dx e quindi NON ne possono sfruttare le nuove caratterisitche.

Si ok ma voglio dire, siamo sicuri che le dx 10.1 intordurranno tecnologie non supportate dalle schede dx10 ora in commercio?
Era questo che volevo dire, forse mi sono spiegato male.

[-fidel-]

Originariamente inviato da coschizza

per ora le principali tecnologie sono:

OpenGL ES 2.0 compliant except for the use of nVidia's Cg instead of GLSL
OpenMAX
OpenVG

Interessante. Penso che questo potra fare da traino per un non-abbandono delle OpenGL su larga scala, forse anche per il mondo PC, visto che sempre più spesso i giochi sono multipiattaforma (sia in ambito console che per PC).

[diabolik1981]

Originariamente inviato da -fidel-

Interessante. Penso che questo potra fare da traino per un non-abbandono delle OpenGL su larga scala, forse anche per il mondo PC, visto che sempre più spesso i giochi sono multipiattaforma (sia in ambito console che per PC).

Il fatto è che in ambito PC, come detto sopra, le schede video vengono progettate su specifiche DX, quindi sarà dura che le OGL tornino ad imporsi, soprattutto se poi si pensa che anche le console ormai usano schede video derivate dal mondo PC, quindi anche li prima o poi le DX faranno il loro ingresso in modo definitivo.

[^TiGeRShArK^]

Originariamente inviato da Pr|ckly

Si ok ma voglio dire, siamo sicuri che le dx 10.1 intordurranno tecnologie non supportate dalle schede dx10 ora in commercio?
Era questo che volevo dire, forse mi sono spiegato male.

si, io sono piuttosto sicuro

[^TiGeRShArK^]

Originariamente inviato da Bellaz89

^TiGeRShArK^ , le Opengl sono di più basso livello, e se da una parte le dx rendono più facili lo sviluppo di cose come giochi o simili, dall altra mettono in difficoltà lo sviluppo dei programmi che richiedono un controllo totale sulla scheda video o genericamente sull' unità di elaborazione.
Questo lo dico non perchè mi piacciono più le ogl che le dx (anche se con queste posso portare i miei programmi su ogni piattaforma mi venga in mente) ma perchè la struttura di queste due essenzialmente è differente: ci sono campi in cui è faticoso programmare con un' api di basso livello, che è solo un insieme di chiamate scritte in C alla vga, e altri in cui non puoi permetterti di sviluppare codice basato su api closed source , che hanno maggiore ruolo interpretativo dei tuoi comandi, in cui non sai nemmeno che genere di algoritmi vengono utilizzati e che non hanno praticamente portabilità.

E questo non lo dico solo io , anche la stessa microsoft lo diceva tempo fa.

E poi, anche senza addentrarsi nel codice, pensa a un elaboratore per scopi scientifici/militari/civili o quello che ti pare che ha migliaia di gpu/cpu magari anche diverse: con le directx semplicemente sei impossibilitato a fare qualsiasi cosa.

Inoltre vai a guardare i membri di Khronos.org, non è che siano propio 2 azienducce in croce a promuovere opengl.

ancora non mi hai spiegato cosa intendi quando dici che le open gl sono + a basso livello delle direct x.
Fammi un esempio di codice Open GL che in directx secondo te sarebbe impossibile da scrivere.
Inoltre mi sfugge il motivo per cui Direct X dovrebbe supportare meno schede video rispetto ad Open GL.
Forse in realtà è vero il contrario.
Le schede supportano meglio direct x di quanto non suportino open gl (basta pensare alle schede ATI tanto per fare un esempio che in open gl rendono di meno)

[jappilas]

Originariamente inviato da Bellaz89

^TiGeRShArK^ , le Opengl sono di più basso livello,

in realtà è il contrario
DX è come dicevo precedentemente , poco più di un wrapper sulle caratteristiche e funzioni dell' HW, OpenGL invece mi risulta essere una libreria molto più complessa, con una macchina a stati propria

e se da una parte le dx rendono più facili lo sviluppo di cose come giochi o simili, dall altra mettono in difficoltà lo sviluppo dei programmi che richiedono un controllo totale sulla scheda video o genericamente sull' unità di elaborazione.

in realtà è il contrario, le versioni di DX dalla 5 (se non ricordo male) in poi sono strutturate proprio in modo da consentire agli sviluppatori di giochi un controllo praticamente pieno sulle funzioni HW

(anche se con queste posso portare i miei programmi su ogni piattaforma mi venga in mente)

questa è l' unica cosa giusta, motivo per cui vedrei bene una reimplementazione open source delle DX sotto sistemi operativi alternativi - e laddove per le versioni fino alla 9 si poteva addurre la scusa della dipendenza del codice dall' OS sottostante, paradossalmente per le DX 10 la distinzione tra il KMD e l' UMD ( kernel - e user- mode driver) dovrebbe essere molto più pulita e di conseguenza replicabile tramite IOCTL...
come anche le novità introdotte con il WDDM 2 nell' hardware fatto per supportarlo, dovrebbero essere parecchio benefiche nei riguardi dei nuovi desktop accelerati per linux...

ma perchè la struttura di queste due essenzialmente è differente: ci sono campi in cui è faticoso programmare con un' api di basso livello, che è solo un insieme di chiamate scritte in C alla vga,

non confondere il linguaggio usato con il modello di programmazione richiesto all' una o all' altra API (non foss' altro perchè esistono svariate librerie con classi di incapsulazione che permettono di accedere a OGL in una maniera consona alla parogrammazione Object Oriented)

e altri in cui non puoi permetterti di sviluppare codice basato su api closed source,

una API non è per definizione closed source o open source - una API, è esattamente una interfaccia ed è aperta finchè le sue specifiche sono documentate e disponibili (e su questo mi pare che le DX lo siano tanto quanto le opengl) - nonconfoderti con la disponibilità o meno del codice sorgente di una implementazione della API in oggetto (perchè se è vero che le DX sono closed source lo stesso vale anche per le implementazioni proprietarie delle opengl, come delle altre API del khronos group - per dire, OpenVG è una specifica pubblica ma la libreria Amanith che la implementa, no)

che hanno maggiore ruolo interpretativo dei tuoi comandi, in cui non sai nemmeno che genere di algoritmi vengono utilizzati e che non hanno praticamente portabilità.

sulla portabilità ti posso dare ragione (ma la portabilità di una soluzione SW ha comunque un costo)
sugli algoritmi, quelli che ricadono nella sfera della geometria analitica e della matematica/fisica ad uso grafico o videoludico sono se non risaputi, quantomeno noti e diffusi tra gli addetti ai lavori del settore
se invece ti riferisci a quelli che ricadono nel dominio del kernel e delle operazioni che questo compie per inviare i comandi grafici alle GPU come I/O, beh, non credo il programmatore di videogiochi se ne debba interessare più di tanto , almeno non prima di aver padroneggiato alla perfezione l' API grafica ...

E poi, anche senza addentrarsi nel codice, pensa a un elaboratore per scopi scientifici/militari/civili o quello che ti pare che ha migliaia di gpu/cpu magari anche diverse: con le directx semplicemente sei impossibilitato a fare qualsiasi cosa.

per scopi scientifici/militari/civili quello che conta non è "fare qualsiasi cosa", ma fare quello che si deve fare in un modo che sia sicuro e affidabile, il che implica maggiori attenzioni e cure per il testing delle funzioni del proprio codice per assicurarsi che segua le specifiche, il che richiede maggiori capacità e competenze ma questo a prescidere dall' uso di una libreria piuttoto che un' altra

Inoltre vai a guardare i membri di Khronos.org, non è che siano propio 2 azienducce in croce a promuovere opengl.

da una parte è proprio quello il punto, quando in un consorzio coesistono più aziende, specialmente quando ognuna ha dimensioni ragguardevoli e quindi pretende la sua parte di voce in capitolo, uno dei problemi da risolvere è proprio portare avanti la soluzione in un modo che accontenti tutti nonostante le diversità di vedute, gli interessi, ambiti applicativi e obiettivi industriali dei singoli membri
laddove ti venga il sospetto che per certi aderenti l' obiettivo possa essere proprio il mantenimento della compatibilità con il passato, o magari assecondare le esigenze dei produttori di strumenti CAD (in cui magari si lavori in wireframe) o laddove ti renda conto che imporre specifiche a livello HW sia sempre stato al di là degli intenti del gruppo (proprio perchè le opengl sono nate api trasversali, non è nell' interesse del consorzio fissare delle specifiche HW ufficiali) , ma e ripensando semplicemente che OpenGL è una API grafica, arrivi a comprendere che questo contesto non sia esattamente uno che spinga l' innovazione tecnologica nell' ambito delle GPU ... l' innovazione viene da altrove, e opengl sembra subirla al più avvantaggiandosene...

sennò come me lo spieghi che la gente compra Quadro e Firegl o workstation della sgi ?

semplice, driver certificati nonchè multithreaded (aspetto da non sottovalutare)
da quel che so, in passato, cioè con schede della passata generazione, per non dire di quelle a pipeline non programmabile (nessun supporto shader), la gestione di contesti grafici multipli a livello di scheda grafica, era notevolmente ardua, prona a errori e in certi casi introducente pesanti overhead (se non ricordo male, hanno fatto storia i rallentamenti delle prime versioni mac os x tenendo aperte finestre opengl 3D insieme ad applicazioni normali...) - e non è un caso che fino a tempi recenti, driver grafici multithreaded siano stati appannaggio delle schede professionali, lo sforzo di SW design per far lavorare in modo concorrente un oggetto complesso come una gpu, non è banale (per non dire di quello di testing)

[jappilas]

Originariamente inviato da Bellaz89

Un' api è a basso livello rispetto a un'altra è quando la prima è a uno strato software più vicino all' hardware della seconda, ovvero meno librerie incluse possibili, meno codice frapposto , linguaggi (ma questo non è del tutto vero) di livello più basso.Le opengl sono scritte in C e sono Os indipendent, mentre le dx usano risorse del sistema e sono scritte in C++.

proprio perchè closed source non puoi affermare con certezza in quale linguaggio siano scritte - il linguaggio in cui è scritta una libreria e quello dell' interfaccia che esporta non è detto che coincidano, a maggior ragione su Windows, dove non bisogna dimenticare la presenza di COM...

Per l'ultima richiesta ti dico che non esistono solo ATI e NVIDIA sul mercato vga(che peraltro sono membri dell' arb di ogl e la supportano) ma anche aziende come matrox e miriadi di aziende che producono solo prodotti dedicati.

se io producessi schede grafiche mi iscriverei all' ARB perchè se la grafica 3d fosse il mio core business, mi convierrebbe ... la presenza di determinati marchi nel consorzio non è indicativa, dal mio pdv è anzi pressochè scontata

Ti fo un miglioramento del mio esempio sopra descritto: come pensi che possano girare qualche migliaio di cell o di arm destinati alla grafica sotto dx? secondo me non girano.

mi spieghi perchè dovrei volere usare un cluster di processori embedded attraverso una libreria grafica piuttosto che attraverso una api dedicata al messaging di dati tra sistemi separati (openMPI), quando poi buona parte dei core ARM non ha eccezionali prestazioni in virgola mobile per la mancanza di unità dedicate?

Infine gli utilizzatori hanno il grosso vantaggio di poter creare estensioni a loro piacimento per le loro macchine cosa che non puoi fare sotto le dx visto che sono closed e propietarie.

grosso vantaggio (opinabile comunque) per i produttori di HW, grosso svantaggio per chi sviluppa applicazioni per la API in pratica se la tua applicazione fa uso di un misto di estensioni ti tocca controllare la presenza di ciascuna a livello di supporto HW e usare potenzialmente un code path per ciascuna
le funzioni opzionali non sono mai una cosa positiva - vedi che anche le DirectX hanno elimiinato i cosiddetti "capability bits" , ma d' altra parte anche opengl in realtà ingloba in ogni major release quelle che per la precedente erano estensioni, solo che avviene molto di rado per va della frequenza degli aggiornamenti alla API

[jappilas]

Originariamente inviato da Bellaz89

il contrario? ma se le dx utilizzano le risorse del sistema, inoltre se non sono di più alto livello, mi spieghi perchè le dx 10 sono così os dependent ?(per ora i sistemi operativi sono solo vista e a detta di microsoft portare le dx su winxp e precedenti non è un problema banale)

qualunque cosa si interfacci con l' HW "usa le risorse di sistema" , sia dell' hardware stesso sia del sistema operativo ... anche un driver di stampante se è per questo
il punto è che mentre sui sistemi della famiglia NT5.x (tra cui XP ) il driver grafico è pressochè interamente integrato nel kernel (dove è locato anche il window manager ), con il driver model di Vista ( WDDM) questo è più nettamente separato in una parte KMD (kernel mode), che si occupa solo delle funzioni di più basso livello tra cui la gestione dei contesti DMA, e una parte UMD che si occupa dei comandi da inviare alla GPU sotto forma di shader language (già è interessante il fatto che si parta dal presupposto che la GPU sia basata su shader invece che su una pipeline non programmabile, e che anche le operazioni raster 2D possano essere emulate via shader)
e l' implementazione lato kernel delle DX 10 è modellata sul WDDM

Hai detto bene su GIOCHI non su altro.

intendevo applicazioni basate sulla libreria, che i giochi siano stati i primi e per molto tempo le principali applicazioni DirectX è un altro discorso...

Ok mi sono espresso male, volevo dire "la libreria che viene interfacciata dall' api X" Ok?

No, io non volevo dire che con le OpenGl puoi fare qualsiasi cosa, volevo dire che con dx non puoi propio fare nulla, le Opengl danno in questo campo la possibilità di essere "scorciate", estese o modificate secondo le propie necessità, mentre con le dx non puoi fare questo lavoro

se modificassi una libreria "scorciando" o modificando dei code path in modo sostanziale rischhierei di ottenere qualcosa di diverso che rompa la compatibilità con le applicazioni o con l' Hw preesistenti
quindi , anche nel caso delle extension OGL, mi risulta essere sempre un aggiungere, mai cambiare...

Hai ragione , non lo posso affermare, ma mi spieghi l'utilità di non rendere pubblica l'interfaccia sottostante (questo lo dico perchè non lo so)

coerenza con la politica di sempre, di lavorare proteggendo il codice...
a maggior ragione quando si tratti di codice integrato con quello di sistema (comunque mi risulta i partner di microsoft coinvolti nell' implementazione delle specifiche abbiano comunque limitato ed esclusivo accesso al codice coinvolto, per lo sviluppo congiunto)

anche solo a vedere Ati e nvidia , non è che sembrano solo membri passivi, anche per le ragioni che ho detto a ^TiGeRShArK^ , inoltre se il tuo core businness è il 3d è senti la necessità assoluta di presiedere nell' arb di opengl allora vuol dire che in molti campi del 3d questa fa da padrona.

è ovvio che non saranno membri passivi... i produttori di HW cercheranno di portare in OpenGL almeno parte delle innovazioni che avranno implementato nei loro chip perchè questi siano directX compliant
quello che volevo dire è che non mi risulta che il consorzio si prefigga di progettare delle specifiche su cui imcentrare lo sviluppo delle nuove GPU ma solo una API grafica che si adatta all' HW disponibile

la libreria che usi dipende da quello che vuoi fare, se ti servono funzioni per la grafica accellerata su gpu usi opengl che ha già tutte le funzioni predisposte per farlo.

a seconda anche dell' obiettivo che il mio progetto si pone... ad esempio compatibilità vs. massimizzazione del target di pubblico
se per il dato obiettivo lo strumento plausibile è solo uno, userò quello - se invece posso scegliere tra più API, opto per quella che mi rende più facile il raggiungimento dell' obiettivo
ogni altro discorso è puramente accessorio, o strumentale a determinare quale sia lo strumento migliore per il lavoro da fare

i processori arm erano un esempio, anche se dipende da quello che vuoi fare.

non capivo perchè avrei dovuto usare un cluster di cpu arm (che anche se embedded hanno un modello di programmazione molto diverso da quello di una GPU - per dire, hanno una MMU e questo è già fondamentale) per simulare una GPU virtuale - magari per inviargli computazioni generiche in comandi shader

Resta il fatto che anche solo una ventina di gpu collegate insieme (c'era un'articolo di hwu che lessi su un cluster di gpu ATI, anche se non ricordo che genere di gpu erano) non sono comodamente gestibili da dx.

gpu di che generazione? può essere determinante visto che , in ambito "GPGPU" andavano per la maggiore soluzioni nvidia fino a poco tempo fa, e visto che le modifiche al WDDM di cui si parlava si prefiggono proprio la fattibilità di uno scheduler per ogni blocco di calcolo interno alla GPU (analogamente al set di code per ogni cpu logica a livello di scheduler dei processi) il che renderebbe l' utilizzo delle unità di calcolo stesse, molto più scalabile

Propio per questo esiste l'arb, per ratificare le estensioni ufficiali e per rilasciare le versioni ufficiali di opengl.Se inoltre una azienda ha bisogno di una determinata funzione deve essere obbligata a non averla?

la sfrutterà ovviamente, ma rischierà di legarsi allo specifico vendor che ha implementato quell' estensione - il che in sostanza vanifica l' utilità di uno standard... si può affermare che le estensioni siano deroghe allo standard , quantomeno laddove emergano per una stessa funzione, estensioni di vendor differenti, divergenti e/o incompatibili quanto a comportamento
e sì , questo per me vale anche a livello di CPU

[Pr|ckly]

Originariamente inviato da ^TiGeRShArK^

si, io sono piuttosto sicuro

Mi sapresti dire anche il perchè?

Interessante la discussione comunque.

[^TiGeRShArK^]

Originariamente inviato da Bellaz89

Le gpu del articolo mi sembra che fossero dei derivati di x800 e infatti molti
erano stupiti di questa soluzione che si basava su ogl, c'è anche da dire che i normali driver distribuiti sono, come posso dire "generici", mentre per questa soluzione saranno stati utilizzati driver più ottimizzati.
Per la questione del kernel mode ti ringrazio perchè non lo sapevo.
Resta il fatto che nonostante le sue pecche, opengl resta IMHO(e ribadisco IMHO) e resterà la regina nel campo PRO.
Questo può essere dato dal fatto che non ci sono concorrenti multipiattaforma al suo pari, o che ormai si è imposta come standard , ma di certo non verrà scardinata dalle dx(almeno non da questo genere di api, se in futuro microsoft farà un'api 3d di questo genere sarà profondamente differente dalle dx attuali).
E' che ancora bene o male le opengl sono molto flessibili e possono essere utilizzate in vari contesti; non c'è ancora un'api che mi copra in un solo colpo cose come i programmi per fare le TAC e insieme gestire i programmi di telerilevamento dei satelliti o i calcoli di traiettoria degli aerei, essere utilizzata nei linguaggi come il java senza badare alla piattaforma e nei telefoni cellulari e negli smartphone.
Semplicemente queste cose le dx non le sanno fare e se in un futuro ci riusciranno non si chiameranno più directx.

Se c'è una cosa che ho imparato è: mai avere certezze...soprattutto nel campo dell'informatica
Forse eri troppo piccolo per ricordare (se l'89 del nick si riferisce al tuo anno di nascita) ma già ai tempi delle 3dfx voodoo e voodoo 2 venivano utilizzati cluster di VSA-100 (il chip base della voodoo 2) per applicazioni di simulazioni militari.
Le API utilizzate qual'erano? Direct X? Open GL? No di certo.
Erano le allora mitiche GLIDE, le librerie proprietarie di 3DFX.
All'epoca tale casa era leader indiscussa delle prestazioni e le loro API erano molto utilizzate.
Ebbene...com'è ke ora non si sente + parlare di 3dfx?
Semplice...è fallita per alcune scelte errate ed è stata acquisita da Nvidia.
Questo tanto per dire due cose:
1)Non è una prerogativa solo di open Gl quella di far girare delle applicazioni con schede video multiple (anzi, a onor del vero è una caratteristica che dipende dai driver. Spesso e volentieri le librerie grafiche non hanno alcuna coscienza del numero di GPU su cui viene renderizzata la scena, come insegna l'SLI....a proposito...ho già menzionato che l'SLI, che oggi va tanto di moda, era già stato inventato da 3dfx TAAANTO ma TAAANTO tempo fa? )
2)La predominanza odierna di open gl nel mercato professionale potrebbe non essere così scontata in futuro come tu credi
X quanto riguarda la flessibilità, nel senso di portabilità su altre piattaforme, anch'io ritengo OpenGL ad oggi ovviamente superiore.
Però che non si possa programmare in Direct x su dispositivi portatili non è poi così vero
http://msdn2.microsoft.com/it-it/lib...04(VS.80).aspx

[^TiGeRShArK^]

Originariamente inviato da Pr|ckly

Mi sapresti dire anche il perchè?

Interessante la discussione comunque.

è solo una mia opinione, ma è basata sulle mie esperienze passate osservando i vari step tra una versione e l'altra di direct x e inoltre c'è anche quanto fatto notare da yossarian per rafforzare ulteriormente la mia ipotesi, ovvero la necessità di un maggior numero di registri inter-stage per questa nuova versione di Direct X. (Non chiedermi xkè hanno deciso di aggiungere questi registri supplementari che non ne ho idea....magari yoss ci può illuminare )