Microsoft spiega il futuro della tecnologia DirectX

per ora le principali tecnologie sono:

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

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.

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.

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.

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.

si, io sono piuttosto sicuro

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)

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

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