AMD: libertà sviluppatori come su console senza DirectX

io non so cosa si sono fumati quelli di AMD per spararne tante di fila, perché presumo che anche loro, come me e tanti altri, c'erano ai tempi dei giochi con dos4gw, delle mille schede audio diverse, dei pasticci con gli interrupts e altri troiai che neanche voglio a parlarne.

ora non è che dico che non hanno ragione: grazie al ciufolo che le api introducano overhead e livellino verso il basso le prestazioni dell'hw; ma meglio avere prestazioni basse e poterle sfruttare, o avere prestazioni alte e tornare ai tempi in cui per giocare con tutto il proprio hardware funzionante bisognava prima mettere il computer al centro di un pentacolo tracciato con il sangue di un gallo nero durante una notte di luna piena?

se poi il discorso diventa: facciamo in modo che gli sviluppatori più volenterosi, e in sostanza, più fighi, POSSANO entrare nel dettaglio dell'hardware, facendo giochi che vadano oltre le dx, allora sono d'accordo, ma non nascondo lo scetticismo, perché dubito fortemente che gli sviluppatori possano concentrare tante di quelle energie e risorse economiche per interfacciarsi senza api direttamente con molti tipi di hw differenti; se già è un impegno spropositato realizzare un motore grafico o fisico, tant'è che il mercato dei middleware è nato proprio in questa direzione, opposta a quanto dice AMD!

se invece si vuole andare verso l'abbandono delle dx, questa è proprio una grande strepitosa gigantesca CAZZATA.

credo che questa notizia sia collegata con questa e chi capisce capisce
http://www.youtube.com/watch?v=Bsyw...player_embedded
http://www.youtube.com/watch?v=D3vf...player_embedded
e le gpu stanno cambiando con cuba core stream processor unita di calcolo generico se non mi sono spiegato scusate e perche vado di fetta

Appunto perchè è una figura di rilievo, non ti sembra che il suo discorso (e quello degli sviluppatori) sia più il punto di un'osservazione sulla situazione attuale piuttosto che l'imposizione del "togliamo via le API, senza se e senza ma"?

Insomma, quello che sembra venire fuori è che le DirectX, così per come sono concepite, e così per come è concepito lo stack grafico attuale, sono fortemente limitanti nei risultati che si possono ottenere.

Un approccio close-to-metal attualmente è duro da ottenere, specialmente se devi lavorare in un ambiente multiprocesso ed hai a che fare con architetture eterogenee. Insomma, molti dei commenti qui dentro dicono "è impensabile!", però nessuno si è posto il dubbio che è impensabile perchè forse si sta fraintendendo il punto del discorso? O che forse la news riportata non è sufficientemente precisa?

guarda io non ne faccio una questione tecnica, ma di mercato ed economia: se il mondo delle swhouse si è mosso sempre più verso l'uso e la produzione di middleware, un motivo c'è: ed è che il business dei videogiochi non ce la fa a ripagare di uno sforzo epico come potrebbe essere quello di dedicarsi direttamente al funzionamento a basso livello dell'hardware - non con hardware così tanto differenziato: le combinazioni sono praticamente infinite!
Questo ragionamento ad esempio, lo si può estendere al so, perché anch'esso offre un livello di astrazione che tuttavia provoca una bottleneck. Ecco perché non distribuiamo i videogiochi su dvd autoavviante? bypassando il so ogni gioco potrebbe sfruttare l'hw direttamente senza passare da api castiganti...

il punto cruciale della questione invece è che le dx probabilmente soffrono del loro quasi-monopolio. Un tempo la concorrenza con le ogl spingeva entrambe al miglioramento, adesso la stagnazione del mercato, unito anche ad un abuso della superpotenza grafica disponibile (specialmente se confrontiamo col mondo console) ha fatto "rilassare" i developers implicati nello sviluppo delle dx, creando il problema.

Magari la soluzione, anche dal pdv commerciale, può essere dare la possibilità agli sviluppatori di sviluppare un proprio approccio close2metal, e lasciar loro scegliere eventualmente di concederlo in licenza come middleware ad altre swhouse: esattamente come adesso accade coi motori grafici, fisici e quant'altro.

No.
Oltre il 50% sono DD, il retail occupa un posizione di minoranza. Parlo di vendite, non di guadagni. Il DD rappresenta il 43% dei guadagni su pc, ma va ben oltre il 50% delle vendite.



No, Steam prende circa l'80% della torta, non i 2 terzi. Il fatto che il mac prenda un 5% dell'utenza è irrilevante, il 99% degli oltre 2000 giochi su Steam non gira su Mac.




è un errore considerare Steam una minoranza, dato che si tratta della fetta più grossa del mercato più grosso ed in espansione crescente. Anche tra chi non ha un pc all'ultimo grido. Il fatto che dici che Steam "è roba moderna per chi aggiorna sempre il pc" dimosta quanto sei fuori strada nelle tue considerazioni, dato che vga più diffusa tra gli utenti Steam è la Geforce 9800GTX.

E Sfruttiamoli come si deve questi Pc Moderni!

Mi sembra che questo tipo dal titolo altisonante:

abbia scoperto l'acqua calda.
E' chiaro che l'accesso diretto all'hardware consentirebbe prestazioni nettamente migliori ma avrebbe pure diverse enormi controindicazioni:
legare un titolo ad uno specifico hardware (beh questo potrebbe fare piacere, almeno ai produttori, ma non certo all'utente finale);
aumento della complessità in fase di programmazione (perfino tra schede video della stessa linea figuriamoci tra generazioni diverse);
possibilità di bloccaggi dello stesso S.O. a causa di titoli mal scritti (avere uno strato software intermedio, aiuta a ridurre questa problematica).
Considerando la velocità con cui vengono rinnovate le schede video a cui, chiaramente, non può corrispondere qualità nello sviluppo dei driver, non farebbe che esacerbare il problema all'estremo.
Mettere insieme driver scadenti con software con accesso diretto all'hardware sarebbe una miscela esplosiva.

Poi uno si domanda, se uno hai piani alti dice certe cose, senza la minima cognizione di causa, mah ... (beh ci sarebbe da dire molto ... però nella mia infinità bontà e misericordia vi risparmio ... per adesso ...).

ci sono.
Giochi che si autocompilano in base all'hardware.
Ora voglio un applauso.

fatemi capire per piacere
1)l' articolo menziona l' approcio di nvidia a cuba questa sfrutta hardware direttamente?
2)questa dichiarazione ad amd che con microsoft ci lavora a stretto contatto anche solo per la prossima console che benefici avrebbe?

Beh però middleware non significa automaticamente non ottimizzato. Per esempio, quella che fu Ageia forniva un middleware per la fisica, che utilizzava una scheda acceleratrice apposita. Anche un motore grafico è un middleware, e giustamente al giorno d'oggi è diventato così così costoso produrre un motore grafico che un'azienda lo produce e un'altra lo usa nei suoi prodotti.



Si, però pensa ad un attimo a quanti livelli di astrazione abbiamo per accedere alle risorse di una periferica. A spanne, quelli che mi vengono in mente:

- Driver
- API del SO
- API del sottosistema (grafico, audio, etc...)
- API del runtime (vc++ solitamente)
- Eventualmente interprete JIT (.NET oppure JAVA).

Insomma, tutti livelli che devono essere risaliti e che mangiano cicli di clock a iosa.



Non saprei... il punto è che con l'hardware del tipo video c'è un problema di fondo che non c'è con le CPU: non esiste un'ISA condivisa. Non c'è un insieme di istruzioni condiviso, e quindi hai il problema della compatibilità. Siccome i problemi dell'hardware si pagano nel software, c'è bisogno di un layer di astrazione per fare quello che si vuole fare.

Huddy, nell'intervista originale, cita anche il progetto Larrabee:

"'I certainly hear this in my conversations with games developers,' he says, 'and I guess it was actually the primary appeal of Larrabee to developers – not the hardware, which was hot and slow and unimpressive, but the software – being able to have total control over the machine, which is what the very best games developers want. By giving you access to the hardware at the very low level, you give games developers a chance to innovate, and that's going to put pressure on Microsoft – no doubt at all."

e pone l'accento sul lato software che, con una ISA standard, permette di fare tutto quel che si vuole con quell'hardware perchè così il programmatore quell'hardware può programmarlo.

Attualmente possiamo spremere le CPU fino all'osso (OS permettendo) perchè esse eseguono il codice scritto da noi espressamente compilato in codice macchina per loro. Non possiamo spremere le GPU fino all'osso perchè esse eseguono comandi fissi determinati dal driver che le comanda, e in sequenza dalle API che comandano il driver. Huddy parla anche del fatto che gli shader avrebbero dovuto cambiare questo andazzo (e qui si lega il paragone fatto con CUDA) perchè permettono di programmare la GPU per i compiti più disparati, ma anche qui cita l'appiattimento delle possibilità obbligato dalle API DirectX.

La bellezza delle soluzioni Fusion di seconda generazione e di non so quale altra invenzione intel tirerà fuori, è che finalmente potremo avere fra le mani un'ISA SIMD come dio comanda per far fare alla CPU quello che oggi fa una GPU. Lo dico sempre che, in questo momento, il processore Cell è un pioniere: dove bisogna macinare conti in parallelo è molto apprezzato e guarda caso le GPU sono molto apprezzate negli stessi ambiti.

Spero di non aver detto troppe cazzate, chi più ne sa corregga.