Microsoft spiega il futuro della tecnologia DirectX

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
intendevo applicazioni basate sulla libreria, che i giochi siano stati i primi e per molto tempo le principali applicazioni DirectX è un altro discorso...

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

Mi sapresti dire anche il perchè?

Interessante la discussione comunque.

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/li...504(VS.80).aspx

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