Mantle: la scommessa di AMD sulle API grafiche di basso livello

[Mitch]

Continua qui

[Fottemberg]

Questo mi riporta alla mente l'intervista a Tamas, nella quale affermava che si sarebbe dovuti tornare ad una programmazione a basso livello, anche e soprattutto nei videogiochi. Probabilmente era già a conoscenza di Mantle.

Tornando più sul concreto, è vero che nVidia può farne una propria versione, ma a questo punto rimane tagliata fuori Intel. Ne fa una versione propria anche lei? E i developer di VG che fanno? Tre motori grafici di differenti?

Imho si rimane ad un bivio:
Mantle -> GPU AMD
DirectX -> nVidia e Intel

[Mitch]

AMD è da due anni che lavora su Mantle ma le serviva un quid per avere un minimo di chance.
Ed ecco che arriva Johan Andersson, giovane e brillante programmatore che guarda caso lavora sull'engine che sarà il più utilizzato della prossima stagione (Frostbite 3 is everywhere: BF4, NFS, Mirror Edge 2, Dreagon Age Inquisition, Star Wars ecc.)

Frosbite 3: check ... adesso AMD deve solo mettere mano sul Cryengine 3 (per metà giù l'ha fatto basta guardare la nuova demo ri Ruby) e sull'UE4 (qui la vedo più dura) ed il gioco è fatto.

[Fottemberg]

Ed è qui che entra in gioco Koduri, il creatore nel 2002 dei driver Catalyst.

[Alessio89]

Questo mi riporta alla mente l'intervista a Tamas, nella quale affermava che si sarebbe dovuti tornare ad una programmazione a basso livello, anche e soprattutto nei videogiochi. Probabilmente era già a conoscenza di Mantle.

Tornando più sul concreto, è vero che nVidia può farne una propria versione, ma a questo punto rimane tagliata fuori Intel. Ne fa una versione propria anche lei? E i developer di VG che fanno? Tre motori grafici di differenti?

Imho si rimane ad un bivio:
Mantle -> GPU AMD
DirectX -> nVidia e Intel

Tamas però diceva allo stesso tempo che le API non possono assolutamente essere così driver dipendenti.... Secondo me sarà un fallimento totale.
Tuttavia dipende come sto mantle lavora: l'hanno chiamata "command line API", probabilmente è da usare come funzione esterna nel codice passandogli i parametri come stringhe... se fosse così sarebbe come usare le estensioni proprietarie (purtroppo esistono anche per D3D), di buono c'è che è compatibile con HLSL (anche se non hanno detto se a livello di codice sorgente o di compilato, l'ideale sarebbe la seconda). Inoltre mi chiedo della stabilità, visto che dipenderà interamente dai loro driver.... Infine mi chiedo da che pulpito esce la predica sulle poche draw calls per seconds di OGL e D3D, quando OGL supporta teoricamente il multithreaing rendering da SEMPRE (visto che nasce come API per rendering software o semi-software), mentre in D3D sono stati i primi a iniziare a supportarlo e i primi a decidere anche di toglierne il supporto (seguiti poco dopo da NVIDIA)....

[Fottemberg]

Ok, potrebbe essere un fallimento totale, però osservando le persone che si sono raccolte attorno a questo progetto, le aziende che vi collaborano e l'architettura unificata, non si sta mettendo male.

[Alessio89]

Non si sta mettendo male, ma un driver audio che dipende dai driver della AMD e che funziona solo su CGN... NVIDIA ha ancora i 2/3 ca del mercato delle dedicate, e poi l'audio da dove esce, da un maledetto canale HDMI? Se lo possono tenere.

[Fottemberg]

A me dove è veicolato importa poco.

[Mitch]

Non si sta mettendo male, ma un driver audio che dipende dai driver della AMD e che funziona solo su CGN... NVIDIA ha ancora i 2/3 ca del mercato delle dedicate, e poi l'audio da dove esce, da un maledetto canale HDMI? Se lo possono tenere.

Da quello che ho capito è solo processato dalla GPU, l'output può essere tranquillamente mandato alle uscite audio integrate nella mobo.

[Alessio89]

capito...