Creative ALchemy Project: EAX anche su Windows Vista

[coschizza]

In aggiunta a quello che ha scritto mauriziofa posso aggiungere che gia da tempo la microsoft ha messo in stato di "deprecated" alcune API delle directx, le principali sono le DirectInput e DirectSound e DirectPlay , solo parzialmente le DirectShow.

Questo perche la MS ha trovato nuove tecnologie che ritiene migliori per sostituirle, nel caso del DirectInput sta migrando a XInput (nato dall'esperienza con l'xbox). Il DirectPlay verra sostituito dall'Xbox Live, il DirectShow verra passato ai "Media Foundation".

nel caso che ci interessa cioè il DirectSound è in migrazione al sistema utilizzato dall'xbox cioè il XACT.

quindi è probabile che essendo queste tecnologie in fase di dismissione vengano tolte da componenti fondamentali come HAL e kernel per poter cambiarle con altre senza dover stravolgere il sistama durante il suo periodo di vita.

AGGIUNTA

mi sono scordato un particolare non banale, in vista la microsoft vuole poter controllare in maniera centrale i flussi audio per poter essere sicura che contenuti protetti DRM o canali HDMI siano bloccati in caso non siano di origine lecita, per fare cio deve far im modo che il controllo del tutto passi per un componente unico e centrale come il kernel, quindi togliere le vecchie tecnologie "legacy" è anche una questione strategica per il futuro.

[dsajbASSAEdsjfnsdlffd]

Sul sito della tanto odiata(da alcuni) Microsoft tempo fa c'era proprio una paginetta che spiegava come HAL e strati SW vari aggiunti in anni di gestione diminuissero la frequenza massima teorica di chiamata a funzioni (con scopi spiccatamente multimediali) che invece avrebbero potuto essere più veloci (ossia chiamate più di frequente).

avere millemila strati SW che rendono il tutto astratto è bello dal punto di vista della modularità del sistema, ma si spiegava appunto che, paragonando con una metafora l'esecuzione di un programma ad un flusso di dati su un canale, gli "header" (operazioni inutili o ridondanti, tipo push multipli dello stesso valore nello stack) introdotti dalle chiamate a funzioni di strati sottostanti aggiungessero overhead al "protocollo" (inteso come sequenza di chiamate dall'applicazione fino all'hw) riducendo la "banda" (capacità elaborativa della macchina) disponibile al "payload" (ossia i dati che effettivamente si vogliono processare)

stimavano che solo snellendo il sistema di chiamate si potesse avere un guadagno prestazionale immediato sensibile (mi pare di ricordare più del 10%) il che non è affatto male se si considera che ciò vuol dire che sullo stesso identico HW le cose vanno il 10% più veloci semplicemente rivedendo la struttura dell'OS.

ovviamente ci sono i soliti lamentoni ai quali tutto ciò sembrerà assurdo e privo di senso, ma infatti sono quelli che si ostinano a dire che Vista è solo Aero... allora perche non l'hanno chiamato Aero direttamente? boh non lo so... spero me lo spieghino questi che san sempre tutto...

[HW-MLCR]

Originariamente inviato da mauriziofa

@MenageZero
L'HAL c'era già con NT ma solo per determinate periferiche. I driver video e quelli audio erano dentro al kernel come Linux oggi perchè al tempo si pensava che fare un kernel enorme con tutti i driver dentro portasse benefici alle prestazioni, ed in effetti è vero perchè il codice viene eseguito più velocemente.

L'HAL è il layer di astrazione hardware di NT, esiste da quando esiste NT, non si può aggiungere/togliere a piacere, e gestisce l'accesso a tutte le risorse hardware del sistema, ma in generale non è il driver layer; i driver dei dispositivi si appoggiano ad HAL. Poi semmai NT è nato come micronucleo con i subsystem ed i servizi fuori dal nucleo, ed è stato riunificato in struttura monolitica nell'NT4.0.

Originariamente inviato da mauriziofa

@MenageZero
Poi però si è scoperto che se un driver è scritto male ed è in kernel mode crasha l'intero sistema.

Quaesto lo hanno scoperto all'incirca negli anni 50, mica ieri....

Originariamente inviato da mauriziofa

@MenageZero
Ma non si poteva riscrivere tutto da zero perdendo la compatibilità così il concetto di HAL di NT è stato esteso e si è arrivati al plug & play di Win2000 che aveva ancora i driver in kernel mode ma con uno strato software in mezzo a cercare di ottimizzare le chiamate tra l'hardware da un lato e il kernel dall'altro.

L'HAL è stato esteso per il Plug&Play (così come per tutte le nuove feature hardware) quando è cambiato il modello di programmazione/progettazione dell'hardware. Certo che non lo aveva nell'1989, ma non significa che è un errore di progettazione.

Originariamente inviato da mauriziofa

@MenageZero
Oggi con Vista si è scoperto che questo approccio rallenta notevolmente lo sviluppo della grafica 3D perchè non permette di accedere con celerità alle risorse hardware della gpu processando meno poligoni al secondo e non solo, infatti le texture processate non possono superare una certa qualità visiva pena il rallentamento del motore 3d.

Non confondere la riprogettazione dell'API DX10 con lo spostamento fuori dal nucleo del codice: sono due cose differenti. L'incemento di trasfer-rate che MS dichiara è legato all'architettura dell'API DX10, non ad altro.
Lo spostamento di parti significative dei driver audio/video (ma non tutto, nota bene) è collegato a questioni di semplicità di sviluppo e di stabilità di sistema.

Originariamente inviato da mauriziofa

@MenageZero
Per questo motivo è stato deciso di rimuovere l'HAL software che era stato esteso con Win2000 riscirvendo la maggior parte dei driver in user mode con il .net framework e usando al minimo il kernel mode.

Ma hai bevuto qualcosa? Il .Net framework nei driver delle schede video???
Guarda che una parte del driver gira sempre in kernel level, perchè deve gestire IRQ, memoria, accesso al bus, etc...
Non è stato eliminato il driver dal nucleo, ma sono stati ripartiti i compiti tra cosa è fatto in spazio nucleo, cosa nel servizio D3D e cosa nello spazio dell'applicazione.

[Nockmaar]

Complimenti a mauriziofa, finalmente una disamina argomentata come si deve.

[Vifani]

Originariamente inviato da uvz

Non mi intendo di audio ma non penso che l'Auidy 2 lo supporti, essendo uscita "tanto" tempo fa.


A chi segue l'informatica con più precisione di me, ma Microsoft sta "abbandonando" i suoi vecchi standard, criticati da tutti per la loro pessima qualità? Si parla da tempo se il Direct 3D verrà abbandonato completamente a favole dell'Open GL. Adesso questo OpenAL.
Un'altra cosa, le cpu cisc che una volta andavano bene con un certo tipo di computer si stanno "trasformando" sempre più in risc perchè come sono fatti i computer oggi, i risc vanno meglio (prendete la mia frase per quella che è, non voglio essere corretto al 100%; chi la sa bene può spiegarlo meglio di me).
Mi sembra propio che i personal computer siano nati storti, con la tecnologia "peggiore" (forse la più economia) da supprotare su quelle che c'erano sul mercato. Oggi piano piano cercando di radrizzarsi.

Le schede audio Audigy 2 sono supportate da Creative per Windows Vista e lo stesso progetto ALchemy inizialmente verrà testato solo con X-Fi, ma ne è previsto il supporto anche per le Audigy 2 e 4.

La storia degli standard da tutti criticati è una cosa che dici tu e basta perché se è vero che inizialmente (parliamo del 1996/97) le DirectX erano abbastanza disastrose rispetto alle controparti OpenXX, ora la situazione è opposta. Microsoft fornisce strumenti di sviluppo, documentazione e risorse di elevatissima qualità al punto che programmare per Direct3D è oggi molto più immediato e veloce che non programmare per OpenGL. Chiedi ai programmatori di videogames se è più facile programmare per XBox 360 (DirectX) o per PS3 (OpenGL) e ne riparliamo.

[mauriziofa]

@coschizza

Preciso solo una cosa prima che si scateni un flame anti Microsoft. Tutti i sistemi operativi che vorranno supportare il play dei contenuti HD, HD-Dvd e Blu Ray, dovranno supportare il controllo del flusso audio e video hdcp sia sulle porte hdmi, sia sulle vecchie analogiche come component o dvi. In questi ultime 2 porte il segnale verrà degradato se non originale.

Questo vuol dire che anche il MacOs X nuovo e Linux di quest'anno avranno strumenti che supporteranno queste protezioni. Lo so è un arogmento trito e ritrito che fa infuriare gli utenti ma se tutti i so lo supporteranno potrebbe essere digerito meglio.

[MenageZero]

Originariamente inviato da mauriziofa

@MenageZero

L'HAL c'era già con NT ma solo per determinate periferiche. I driver video e quelli audio erano dentro al kernel come Linux oggi perchè al tempo si pensava che fare un kernel enorme con tutti i driver dentro portasse benefici alle prestazioni, ed in effetti è vero perchè il codice viene eseguito più velocemente.
Poi però si è scoperto che se un driver è scritto male ed è in kernel mode crasha l'intero sistema. Ma non si poteva riscrivere tutto da zero perdendo la compatibilità così il concetto di HAL di NT è stato esteso e si è arrivati al plug & play di Win2000 che aveva ancora i driver in kernel mode ma con uno strato software in mezzo a cercare di ottimizzare le chiamate tra l'hardware da un lato e il kernel dall'altro.

Oggi con Vista si è scoperto che questo approccio rallenta notevolmente lo sviluppo della grafica 3D perchè non permette di accedere con celerità alle risorse hardware della gpu processando meno poligoni al secondo e non solo, infatti le texture processate non possono superare una certa qualità visiva pena il rallentamento del motore 3d.Per questo motivo è stato deciso di rimuovere l'HAL software che era stato esteso con Win2000 riscirvendo la maggior parte dei driver in user mode con il .net framework e usando al minimo il kernel mode.
Purtroppo questa descisione elimina il supporto eax, che però è garantito da una serie di librerie, OpenAL, che sfruttando lo user mode riabilitano l'audio accelerato in hardware. Ma per poter rendere compatibile una scheda audio con queste librerie bisogna che i driver le supportino e la Creative per non stare a riscrivere tutti i driver ha creato l'Alchemy Project che traduce ogni istruzione vecchia nelle nuove compatibili OpenAl ma al costo enorme di risorse di cpu e memoria, funziona come un emulatore.
Secondo me le nuove schede audio Creative, che saranno PCI express, avranno i driver OpenAl nativi.

non mi tornano molto i concetti sugli albori di nt, ms lo ha sempre descritto come un modello "ibrido"(non ricordo la definizione ufficiale) ma a microkernel di base, con sopra l'hal e soprab ancora i drv e tutti i vari moduli, il tutto a comporre l' "executive", sopra il quale girano i processi user-space. certo tutto l'executive dovrebbe girare cmq in kernel mode se le mie remioniscenze del momento sono corrette e questo sostanzialmente concide con la tua spiegazione, ma non con il modello a "mega" kernel-monolitico.

ma apparte queste quisquigle marginali nell'argomento specifico, grazie per la delucidazione

non è che hai "lumi" anche su ciò che collega l'eliminazione dell'hal al voler passare per openal per avere acc. hw anziché ancora per ds3d, previo ovviamente adattamento dei drv al nuovo drv-model e kernel da parte di creative ?

a margine, se ora i drv, pr es video, sono in user space (e in origine erano tutti in kernel proprio per avere maggiori prestazioni, hal apparte, rispetto allo user-mode) e inoltre scritti e compilati per .net, il che aggiunge un ulteriore layer, e nonostante tutto si attendono migliori prestazioni... mi sono perso qualcosa... o il capo progetto per il drv model di vista si chiama... merlino ?
(o il suddetto hal dal pdv delle prestazioni faceva tanti e tali "danni" da annullare completamente i vantaggi del kernel mode vs user + un altro eventuale layer, .net ? )

i drv creative dovrebbero cmq già supportare openal, alchemy se ho capito bene dovrebbe wrappare le chimate dei giochi a ds3d su openal... o no ?

[mauriziofa]

@HW-MLCR

Scusa mi sono spiegato male. Chiarisco alcuni punti.

Non ho mai detto che i driver sono tutti in .net e tutti in user mode. Buona parte del driver video, buona parte non tutta, è stata spostata in user mode. Certo che le parti vitali rimangono in kernel mode come IRQ, memoria, accesso al bus, ecc...
La parte in .net è quella della configurazione, già la ATI la adotta nei driver di WinXp.

Sul fatto che i driver in kernel mode crashassero il sistema se ne saranno anche accorti negli anni 50 ma in WinXp del 2001 bastano 50k di codice per far crashare il driver video e tutto il sistema dietro. Quindi è vero che sono anni che ne sono al corrente ma lo hanno messo in pratica solo ora con Vista.

Sul fatto dell'HAL ho sbagliato a scrivere che è stato un errore di progettazione ma il succo non cambia, lo hanno esteso mentre ora lo hanno rimosso.

Infine forse ho scritto male ma non intendo dire che l'HAL ha i driver ma che era lo strato che si frapponeva tra il device e il driver.

[GabrySP]

Ho letto molti commenti interessanti ma si è perso di vista il punto focale della news, i giochi che non supportano OpenAL (il 99% ), avranno con Vista un audio smorto, peggio di quello generato dai peggio chip integrati (almeno quelli supportano il 5.1, da schifo ma lo supportano )

Sarà rigorosamente stereo e senza effetti 3D in tempo reale, uno schifo .

Si spera che tutti i nuovi giochi abbiano il supporto nativo per le OpenAL.

Questa volta Microsoft ha sbagliato a pensare di elaborare l'audio solo via software, quando neanche 100 Core2 in parallelo possono fare quello che fa una X-fi. (questo errore ricorda lo sfondone preso dalla Sony con PS3, quando pensava di fare calcolare l'intera scena video 3d dal solo Cell , poi hanno aggiunto un G70 )

Non si può dale un calcio nel a una tecnologia così valida come EAX.

[mauriziofa]

@MenageZero

Scusa non volevo entrare troppo nel tecnico, l'archiettura video nuova si chiama WDDM magari cercati il documento tecnico di molte e molte pagine che ti chiarisce bene i concetti.

Il succo però è questo:

In Kernel mode è stato lasciato il necessario: gestione bus, irq, memoria ecc...
In User mode sono state spostate le altre chiamate, tanto è vero che si era parlato del fatto che poteva essere aggiornato il driver video senza dover riavviare il pc, cosa oggi invece necessaria.

In .net sono stati spostati tutte le chiamate di configurazione del device, infatti se noti Ati ha postato gli ultimi driver per WinXp con il pannello in .net.

Spero di averti chiarito.

[mauriziofa]

@GabrySP

Dici un'inesattezza. Se la Creative termina lo sviluppo dell'Alchemy Project tutti i vecchi giochi avranno l'audio in hardware non in software, solo che saranno tradotte tutte le vecchie chiamate in quelle nuove.

In pratica non sono così sicuro che i vecchi giochi gireranno con l'audio "sincronizzato" con quanto accade sullo schermo perchè la risosrsa di cpu richiesta per tradurre le istruzioni è molto alta.

I giochi nuovi invece avranno i driver Creative nativi già scritti in OpenAL quindi senza problemi sonoro in hardware tranquillamente

[coschizza]

Originariamente inviato da GabrySP

Questa volta Microsoft ha sbagliato a pensare di elaborare l'audio solo via software, quando neanche 100 Core2 in parallelo possono fare quello che fa una X-fi.

non sono daccordo su questo punto del tuo post per una motivazione puramente tecnica
tanto per farti un esempio banale sia la xbox 360 che la ps3 non hanno un schip audio integrato che possa fare gli effetti ma viene utilizzato un mixer software fatto girare sull cpu.

le informazioni ufficiali della microsoft dicono che per gestire 256 canali separati con effetti audio applicati il consumo di risorse causato dal mixer software è nel caso peggiore il 25% di 1 thread hardware di 1 core della sua console, che significa (essendo disponibili 6 thread hardware in totale) che nel caso paggiore si parla del 12% di prestazioni dell'intera cpu, se hanno risparmiato 1-2 euro per un chip dedicato vuole dire che bastano meno do "100 Core2" per emulare il tutto in software.

lo so che le console sono differenti ma a livello pratico con i pc oggi disponibili credo sia difficile notare un reale degreado delle performance se non in ambiente di benchmark e nel futuro con la presenza di sempre piu X core il supporto hardware diventerà (se non lo è gia diventato) persino sconveniente rispetto a un approccio software.

[Cloud76]

Originariamente inviato da KinKlod

Qualcuno sa se anche le Audigy 2 supportano le OpenAL?

Originariamente inviato da uvz

Non mi intendo di audio ma non penso che l'Auidy 2 lo supporti, essendo uscita "tanto" tempo fa.

La Audigy 2 suppoorta OpenAL senza problemi.
Prima avevo una Audigy 2 ZS, per usare OpenAL bisogna andare sul sito Creative e scaricare i driver (mi sembra beta) per i quali dicono che non danno supporto e con i quali alcuni programmi presenti nel CD di installazione non funzionano.
Li avevo installati (su XP ovviamente) e funzionava tutto senza problemi quindi penso che anche con Vista non ci siano problemi. Ora però sul sito della Creative non li vedo più...
EDIT:
cercando con google ho trovato questi:
http://www.fileplanet.com/152019/150...ver-for-OpenAL

[GabrySP]

Originariamente inviato da coschizza

non sono daccordo su questo punto del tuo post per una motivazione puramente tecnica
tanto per farti un esempio banale sia la xbox 360 che la ps3 non hanno un schip audio integrato che possa fare gli effetti ma viene utilizzato un mixer software fatto girare sull cpu.

le informazioni ufficiali della microsoft dicono che per gestire 256 canali separati con effetti audio applicati il consumo di risorse causato dal mixer software è nel caso peggiore il 25% di 1 thread hardware di 1 core della sua console, che significa (essendo disponibili 6 thread hardware in totale) che nel caso paggiore si parla del 12% di prestazioni dell'intera cpu, se hanno risparmiato 1-2 euro per un chip dedicato vuole dire che bastano meno do "100 Core2" per emulare il tutto in software.

lo so che le console sono differenti ma a livello pratico con i pc oggi disponibili credo sia difficile notare un reale degreado delle performance se non in ambiente di benchmark e nel futuro con la presenza di sempre piu X core il supporto hardware diventerà (se non lo è gia diventato) persino sconveniente rispetto a un approccio software.

Scusami non voglio criticare ma non puoi paragonare l'audio del 360 con quello che può fare una x-fi, sono due cose enormemente differenti, una CPU general-purpose non può calcolare le "vagonate" di FFT che può fare un DSP, anche l'audio integrato di un pc fa fare quasi tutto alla CPU, il risultato non è lo stesso che sentire le EAX 5 di una x-fi.

E' come credere che una CPU possa fare quello che fa una GPU o una PPU, è solo fantasia, ci sono ordini di grandezza di differenza.

Saluti a tutti.

[MenageZero]

Originariamente inviato da mauriziofa

@MenageZero

Scusa non volevo entrare troppo nel tecnico, l'archiettura video nuova si chiama WDDM magari cercati il documento tecnico di molte e molte pagine che ti chiarisce bene i concetti.

Il succo però è questo:

In Kernel mode è stato lasciato il necessario: gestione bus, irq, memoria ecc...
In User mode sono state spostate le altre chiamate, tanto è vero che si era parlato del fatto che poteva essere aggiornato il driver video senza dover riavviare il pc, cosa oggi invece necessaria.

In .net sono stati spostati tutte le chiamate di configurazione del device, infatti se noti Ati ha postato gli ultimi driver per WinXp con il pannello in .net.

Spero di averti chiarito.

sì grazie (ok il resto, ma xché per es l'applet di config dei drv nv ora gira in kernel-mode ? )

quste cose cmq le avevo +/- già lette, + che altro il "cruccio" era come mai (una volta che avranno da creative i drv ad oc per il model di vista) hanno progettato di passare per openal per ri-avere gli effetti in hw e non per la loro api audio proprietaria, ds3d o cmq l' "erede" che citava coschizza,... magari xchè creative si era già buttata per conto suo nel dare supporto a livello drv a openal e non ne vuol sapere di supportare la nuova api di ms ?

Originariamente inviato da mauriziofa

...
I giochi nuovi invece avranno i driver Creative nativi già scritti in OpenAL quindi senza problemi sonoro in hardware tranquillamente

come dicevo anche in un altro post, se si vanno a veder le note delle + recenti release di drv creative, sembra che le openal siano già supportate, e dalla news sembra più che alchemy riguardi il wrappare su openal le chiamate fatte dall'applicazione alle vecchie api, questo ovviamente per i giochi che non usano openal di loro,

[GabrySP]

Originariamente inviato da mauriziofa

@GabrySP

Dici un'inesattezza. Se la Creative termina lo sviluppo dell'Alchemy Project tutti i vecchi giochi avranno l'audio in hardware non in software, solo che saranno tradotte tutte le vecchie chiamate in quelle nuove.

In pratica non sono così sicuro che i vecchi giochi gireranno con l'audio "sincronizzato" con quanto accade sullo schermo perchè la risosrsa di cpu richiesta per tradurre le istruzioni è molto alta.

I giochi nuovi invece avranno i driver Creative nativi già scritti in OpenAL quindi senza problemi sonoro in hardware tranquillamente

Ho criticato Microsoft non Creative.

Comunque conoscendo Creative non riuscirà a fare un buon lavoro, a livello software fa proprio pena. Pensa che tanti anni fa non riuscendo a fare un driver decente per win98 per la mia soundblaster mi ha spedito a casa una nuova SB128 PCI non riuscendo a far funzionare la vecchia scheda isa.

Speriamo bene che questo Alchemy Project sia l'eccezione alla regola (ne dubito ma non si sa mai )

[KinKlod]

Comunque tirando le somme mi sa che per il momento per giocare conviene tenere XP e Vista in dual boot installando i giochi DX9\OGL su XP e DX10 su Vista.

[MenageZero]

Originariamente inviato da coschizza

In aggiunta a quello che ha scritto mauriziofa posso aggiungere che gia da tempo la microsoft ha messo in stato di "deprecated" alcune API delle directx, le principali sono le DirectInput e DirectSound e DirectPlay , solo parzialmente le DirectShow.

Questo perche la MS ha trovato nuove tecnologie che ritiene migliori per sostituirle, nel caso del DirectInput sta migrando a XInput (nato dall'esperienza con l'xbox). Il DirectPlay verra sostituito dall'Xbox Live, il DirectShow verra passato ai "Media Foundation".

nel caso che ci interessa cioè il DirectSound è in migrazione al sistema utilizzato dall'xbox cioè il XACT.

quindi è probabile che essendo queste tecnologie in fase di dismissione vengano tolte da componenti fondamentali come HAL e kernel per poter cambiarle con altre senza dover stravolgere il sistama durante il suo periodo di vita.

AGGIUNTA

mi sono scordato un particolare non banale, in vista la microsoft vuole poter controllare in maniera centrale i flussi audio per poter essere sicura che contenuti protetti DRM o canali HDMI siano bloccati in caso non siano di origine lecita, per fare cio deve far im modo che il controllo del tutto passi per un componente unico e centrale come il kernel, quindi togliere le vecchie tecnologie "legacy" è anche una questione strategica per il futuro.

tutte queste nuove api che citi saranno parte di dx10 o queste diventeranno da una sorta di "api multimediali unificate" api esclusivamente dedicate alla grafica 3d ?

uno che programma ora ed i futuro per xp, come fa a non scrivere codice deprecated se avesse bisogno di quelle api destinate al pensionamento e già deprecate ? per fare un lavoro "pulito", dovrebbe scriversi o procurarsi api equivalenti per conto proprio ? (non mi sembrerebbe da ms... )

visto che sembri informatissimo, com'è che hanno scelto su vista di re-introdurre l'acc. hw audio tramite openal e non ad es le XACT ?

ps: ma hanno buttato giù la parte "multimediale" di vista e relative api dopo aver approntato x360, o magari in origine x360 doveva avere sù una versione customizzata di vista ?

[MenageZero]

Originariamente inviato da GabrySP

Ho criticato Microsoft non Creative.

Comunque conoscendo Creative non riuscirà a fare un buon lavoro, a livello software fa proprio pena. Pensa che tanti anni fa non riuscendo a fare un driver decente per win98 per la mia soundblaster mi ha spedito a casa una nuova SB128 PCI non riuscendo a far funzionare la vecchia scheda isa.

Speriamo bene che questo Alchemy Project sia l'eccezione alla regola (ne dubito ma non si sa mai )

... lamentati pure...

qundi se la mia audigy 1 non sarà sfruttabile al 100% in vista, mi devo aspettare una xfi ?

[mauriziofa]

@MenageZero

Credo, e quindi potrei essere smentito, che Ati e NVidia abbiano 2 approcci diversi per avvicinarsi a Vista.

Ati ha già creato il pannello di configurazione in .net che è previsto nei WDDM di Vista, anche per WinXp in modo da accumulare esperienza.

NVidia invece ha 2 rami separati di sviluppo: per WinXp continuano lo sviluppo classico, mentre per Vista il team rilascia driver Beta completamente diversi.

Ma sono solo mie supposizioni non ho dati certi a rigurado analizzi i 2 prodotti e valuto. Non so se qualcuno della redazione, che ha contatti diretti con le 2 società, può illuminarci di più o no e non so neanche se si può.