Link all'Articolo: http://www.hwupgrade.it/articoli/skvideo/4330/amd-asynchronous-shaders-piu-efficienza-alle-gpu_index.html

Le GPU AMD basate su architettura Graphics Core Next implementano il supporto agli asynchronous shaders, grazie ai quali ottenere una superiore efficienza nella gestione dei vari comandi ai quali la GPU è chiamata per disegnare le scene 3D. Una importante componente per guadagnare efficienza, soprattutto nell'ottica dei visori per la realtà virtuale

Click sul link per visualizzare l'articolo.

Sempre più palese... Mantle è la base delle DX12...

Sempre più palese... Mantle è la base delle DX12...

più probabile che mantle abbia cercato di anticipare dx12 scimmiottando le feature delle dx12
è cosi innovativo mantle che l'amd ha deciso di bloccarlo come progetto ....


PS : ma tutto il reparto R&D di amd è impiegato a fare slide sempre migliori :cool: :cool:

Praticamente hanno velocizzato il context switch.

Sempre più palese... Mantle è la base delle DX12...

Che lavorino basandosi sugli stessi principi e obiettivi siamo d'accordo.. ma che DX12 sia venuto fuori da mantle proprio lo escluderei.

Una libreria del genere non salta mica fuori in una settimana, probabilmente ci stanno smanettando su da ANNI. Non è che hanno visto mantle e sono corsi a fare le DX12.

Io come utente Os X e AMD invece spero per Vulkan, potrebbe probabilmente farmi smettere di desiderare Nvidia :D

Chissà però quanto tempo ci metteranno...

altri soldi spesi in una tecnologia che poi verrà abbandonata perchè adottata da 4 gatti... :rolleyes:

ma il nuovo ceo che fa? prosegue sulla strada di rory read? si vede che se ne andrà anche lei tra 2 anni per prendersi qualche milioncino di liquidazione...

Che lavorino basandosi sugli stessi principi e obiettivi siamo d'accordo.. ma che DX12 sia venuto fuori da mantle proprio lo escluderei.

Una libreria del genere non salta mica fuori in una settimana, probabilmente ci stanno smanettando su da ANNI. Non è che hanno visto mantle e sono corsi a fare le DX12.

No, infatti. Le dx12 non sono altro che mantle con un nome diverso,figlio di un accordo di 4 mesi fa tra amd e Microsoft.

Difficilmente sapremo come sono andate veramente le cose, però microsoft ha lavorato strattamente con AMD per l'APU di xbox one quindi che ci sia qualcosa in comune tra dx12 e mantle è probabile.

Magari capiremo qualcosa di più quando sarà possibile svolgere più test.

No, infatti. Le dx12 non sono altro che mantle con un nome diverso,figlio di un accordo di 4 mesi fa tra amd e Microsoft.

Ok, va benissimo.
Allora diciamo che le MANTLE e le DX12 sono "gemelli diversi" perchè semplicmente MS ed AMD hanno lavorato congiuntamente alla loro creazione.
Quindi il fatto che AMD abbi presentato prima il suo sistema "proprietario" e poi MS il suo equivalente "universale" è stato un puro gioco di tempistiche.

Ma non è che uno ha copiato l'altro o simili..

Io ho parlato solo di "probabile" :)

Non capisco perchè definisci mantle "proprietario" e DX12 "universale"
Sono entrambe proprietarie, anzi volendo ben vedere mantle è proprietario ma freeware e chiunque può usarlo, inoltre è stato annunciato anche per linux.
DX12 è solo windows e chiuso.

Hai ragione, mi sono espresso male.
Intendevo dire che mantle funziona esclusivamente con schede AMD.. in questo senso "proprietario".
Mentre invece DX12 è per tutte le schede.. come è giusto che sia.

Certo, se DX12 fosse open e freeware sarebbe bello davvero.. :(

il problema è che se anche fosse che mantle si eventualmente usabile su GPU nVidia opportunatamente programmate, non credo che nVidia si metta ad adattare i propri prodotti su un SW avversario, lo faranno in DX12, ed anche un SH in caso di titolo multipiatta credo programmi in DX12 piùtosto che mantle, quindi sempre in teoria mantle rimarrebbe appetibile solo in ambiti specifici o se programmato ad hoc

Tempo fa dicevano che volendo mantle può funzionare su qualsiasi gpu compatibile o meglio che chiunque può fare una gpu compatibile con mantle proprio come si fanno compatibili con DX12 o openGL.
Il problema è che Nvidia di certo non è interessata a farlo.

OK, ma partiamo dal presupposto che la cosa migliore per tutti è avere una libreria standard gestita da ente indipendente a cui i produttori adeguano le proprie GPU.
Perchè se poi ognuno fa la sua si torna ai tempi delle 3dfx in cui ogni gioco doveva essere rivisto per ogni scheda grafica, e se invece la libreria la gestisce uno solo poi finisce che va ad intralciare l'altro.

Il top del top sarebbe che a comandare fosse opengl.
E ogni gioco dovrebbe pagare una minima percentuale a copia come royalty ad openGL per garantire fondi per sviluppo e supporto.

ma siete sicuri che mantle e dx12 siano imparentati? a quanto leggo su wiki i due progetti sono separati, fatti in tempi diversi e da team diversi, hanno in comune solo gli obiettivi, ma allora anche opengl si è mossa per diminuire l'overhead della cpu ma non per questo ha copiato a dx12 o mantle...

Sempre più palese... Mantle è la base delle DX12...

E le glide sono la base di mantle?

:stordita:

Ragazzi, Non scordiamoci che le console sono due, e una di essa non userà certamente le dx12. Quindi userà mantle.

Ragazzi, Non scordiamoci che le console sono due, e una di essa non userà certamente le dx12. Quindi userà mantle.

anche questo è vero! non ci pensavo. :)

OK, ma partiamo dal presupposto che la cosa migliore per tutti è avere una libreria standard gestita da ente indipendente a cui i produttori adeguano le proprie GPU.
Vulkan arriva in aiuto: non è limitato a una certa piattaforma (D3D su Windows/XBox), non è limitato dall'architettura (Mantle su AMD), e scala dai desktop ai dispositivi embedded (sostituendo in un sol colpo sia OpenGL che OpenGL ES).

E ogni gioco dovrebbe pagare una minima percentuale a copia come royalty ad openGL per garantire fondi per sviluppo e supporto.

Il dover pagare delle royalties sarebbe controproducente, in quanto verrebbe a mancare il fatto di essere lo standard "free" per eccellenza (senza contare che quasi sicuramente ucciderebbe implementazioni open-source/free-software come Mesa).
E comunque non è necessario: Khronos Group (l'ente che standardizza OpenGL/OpenCL/Vulkan e altra roba) è formato da grosse aziende del settore, quindi i soldi non mancano:
https://www.khronos.org/about

Vulkan arriva in aiuto: non è limitato a una certa piattaforma (D3D su Windows/XBox), non è limitato dall'architettura (Mantle su AMD), e scala dai desktop ai dispositivi embedded (sostituendo in un sol colpo sia OpenGL che OpenGL ES).



Il dover pagare delle royalties sarebbe controproducente, in quanto verrebbe a mancare il fatto di essere lo standard "free" per eccellenza (senza contare che quasi sicuramente ucciderebbe implementazioni open-source/free-software come Mesa).
E comunque non è necessario: Khronos Group (l'ente che standardizza OpenGL/OpenCL/Vulkan e altra roba) è formato da grosse aziende del settore, quindi i soldi non mancano:
https://www.khronos.org/about

Se i soldi non mancano ottimo, avevo pensato alla cosa delle royalties perchè un progetto che va avanti a donazioni non riuscirebbe ad essere competitivo..

Vulkan sembra essere una ottima evoluzione, resta però il problema principale: farlo preferire ale DX12.. purtroppo questo è un problema di non facile soluzione..

Vulkan sembra essere una ottima evoluzione, resta però il problema principale: farlo preferire ale DX12.. purtroppo questo è un problema di non facile soluzione..

L'idea di avere una sola API scalabile da sistemi desktop a sistemi embedded (oggiogiorno le gpu di smartphone e tablet hanno architetture simili alle gpu desktop) è sicuramente una gran furbata, in quanto uno sviluppatore che impara Vulkan è capace di realizzare programmi per una vasta gamma di dispositivi, ed è anche più facile riutilizzare librerie e/o motori grafici.

Comunque, alla fine, l'API è in gran parte irrilevante: tutti i moderni motori grafici supportano tranquillamente una vasta gamma di API, e considerando che le nuove API (D3D12, Vulkan, Metal e Mantle) sono praticamente tutte uguali tra di loro (cambia un po' la terminologia di ognuna, ma sono tutte basate sul concetto di Execution Queue e Command Buffers, più gestione manuale della memoria), i wrapper specifici per ogni API sono sempre più ridotti.

Valve probabilmente sarà la compagnia che spingerà più possibile all'uso di Vulkan, sopratutto considerando la loro spinta verso le Steam Machines e SteamOS: stanno già provvedendo a realizzare un debugger per il codice grafico, e hanno incaricato una compagnia di scrivere un driver Linux dimostrativo per le GPU Intel, in modo da aiutare gli sviluppatori il più possibile quando uscirà la specifica definitiva. Hanno pure confermato che Source 2 supporterà Vulkan di default.

Ragazzi, Non scordiamoci che le console sono due, e una di essa non userà certamente le dx12. Quindi userà mantle.
Le consolle usano già API di questo tipo. All'uscita di Mantle AMD ha dichiarato di essersi ispirata alle consolle per portare questo tipo di ottimizzazione su PC.
Le DX12, su XboX, non avranno certo la stessa incidenza che avranno su PC.

Le consolle usano già API di questo tipo. All'uscita di Mantle AMD ha dichiarato di essersi ispirata alle consolle per portare questo tipo di ottimizzazione su PC.
Le DX12, su XboX, non avranno certo la stessa incidenza che avranno su PC.

certo ,lo standard e più facile su di esse ,visto che sono tutte uguali .(hardware).

L'idea di avere una sola API scalabile da sistemi desktop a sistemi embedded (oggiogiorno le gpu di smartphone e tablet hanno architetture simili alle gpu desktop) è sicuramente una gran furbata, in quanto uno sviluppatore che impara Vulkan è capace di realizzare programmi per una vasta gamma di dispositivi, ed è anche più facile riutilizzare librerie e/o motori grafici.

Comunque, alla fine, l'API è in gran parte irrilevante: tutti i moderni motori grafici supportano tranquillamente una vasta gamma di API, e considerando che le nuove API (D3D12, Vulkan, Metal e Mantle) sono praticamente tutte uguali tra di loro (cambia un po' la terminologia di ognuna, ma sono tutte basate sul concetto di Execution Queue e Command Buffers, più gestione manuale della memoria), i wrapper specifici per ogni API sono sempre più ridotti.

Valve probabilmente sarà la compagnia che spingerà più possibile all'uso di Vulkan, sopratutto considerando la loro spinta verso le Steam Machines e SteamOS: stanno già provvedendo a realizzare un debugger per il codice grafico, e hanno incaricato una compagnia di scrivere un driver Linux dimostrativo per le GPU Intel, in modo da aiutare gli sviluppatori il più possibile quando uscirà la specifica definitiva. Hanno pure confermato che Source 2 supporterà Vulkan di default.

considerando quindi PS4, smartphone e tablet Android, Linux - Steam OS direi che Vulkan ha uno spazio di espansione non indifferente..

Nell'articolo si parla solo di AMD e GCN, quindi questa feature sarà abilità dalla serie 7xxx amd? Mentre nVidia?

Nell'articolo si parla solo di AMD e GCN, quindi questa feature sarà abilità dalla serie 7xxx amd? Mentre nVidia?

Si , però essendo API teoricamente con i giusti driver e volontà ,potrebbero teoricamente funzionare anche con la serie hd 5000,.:)

Ragazzi, Non scordiamoci che le console sono due, e una di essa non userà certamente le dx12. Quindi userà mantle.

Ma basta con sta scemenza.

Nè Xbox One nè PS4 usano api basate su Mantle o Directx.

Le api per console vengono espressamente scritte per quell'hardware nella maniera più efficiente possibile. Sono api di basso livello, DX11 è un api di alto livello.

L'hardware e il software delle console viene sviluppato parallelamente in maniera che l'uno sprema al meglio l'altro. Fine.

Mentre Directx è un api generica (di alto livello, ergo più righe di codice, ergo richiede indicizzazione, ecc) scritta per far fare al computer le cose in maniera generica (e compatibile con più hardware possibile del tipo A manda a B che calcola C che rimanda ad A che manda a D che calcola le ombre che manda al processore che lascia nella cache ma poi rimanda a G che poi fa calcolare la fisica..) ecc, ecc, le api console tagliano tutti quei processi superflui (e legati anche al come funziona il kernel di windows).

Quello che AMD ha fatto con Mantle è stato molto semplice. Abbiamo una serie di schede video (GCN based) che hanno tutte la stessa architettura, funzionano tutte nello stesso modo, perchè non facciamo un api che tagli tutti quei processi superflui e poco performanti?
In particolare DX11 rimanda spesso nella generazione di un singolo frame informazioni da e alla cpu prima di ricalcolarle, tagliamo questi passaggi. E difatti Mantle ha mostrato perfomance superiori a DX11 soprattutto in situazioni cpu limited.

C'è un motivo se le console, si anche quelle di questa generazione, hanno sempre prestazioni superiori a pc di configurazione simile (e se mi tirate fuori il fatto che una 7850/70 vanno come o più di una ps4, neanche vero, accoppiatemi pure queste schede non con un i5/i7 come nei benchmark ma con un processore con architettura da tablet che consuma praticamente nulla) e questo è dato dalle api e il kernel delle console che sono per forza di cose più performanti (senza contare che queste console hanno un processore a parte basato su architettura ARM per l'os).

Tra l'altro dalle slide di 3DMark DX12 e Mantle sembrano avere pressochè le stesse prestazioni.

E a chi dice che DX12 non scimmiotta Mantle (il che non è un idea sbagliata, ma è ovvio che è Mantle che ha scosso il tutto) ricorderei che la stessa Microsoft annunciava giusto un anno fa che non si sarebbero viste altre Directx per eoni.

E' chiaro come il kernel di windows e le directx abbiano tenuto dietro prestazionalmente l'hardware che compravamo.

Perchè Mantle è stato abbandonato? Perchè è ridondante nel momento in cui DX12 avrà pressochè le stesse prestazioni (o probabilmente, di molto poco inferiori) con tutte le schede e non sarà più esclusiva di GCN. Permette sia ad AMD di cambiare architettura che di smettere di investirci danaro. Anche perchè a dicembre 2014 schede video GCN rappresentavano l'11 % della base installata su pc e i giochi Mantle una frazione ancor più limitata.

Ultima cosa. Ora Microsoft millanta di "upgradare" Xbox One a DX12 il che è una pura idiozia. Ingegneri Microsoft dicono che l'api di Xbox One non sfrutta appieno le memorie ESRAM il che significa che non l'hanno scritta bene, e cambiarla con la generica api (per quanto possa essere di livello più basso di quella DX 11) DX 12. Marketing, nient'altro. Gli stessi ingegneri poi che hanno concepito una console con tre sistemi operativi.

Ma basta con sta scemenza.

Nè Xbox One nè PS4 usano api basate su Mantle o Directx.

Le api per console vengono espressamente scritte per quell'hardware nella maniera più efficiente possibile. Sono api di basso livello, DX11 è un api di alto livello.

L'hardware e il software delle console viene sviluppato parallelamente in maniera che l'uno sprema al meglio l'altro. Fine.

Mentre Directx è un api generica (di alto livello, ergo più righe di codice, ergo richiede indicizzazione, ecc) scritta per far fare al computer le cose in maniera generica (e compatibile con più hardware possibile del tipo A manda a B che calcola C che rimanda ad A che manda a D che calcola le ombre che manda al processore che lascia nella cache ma poi rimanda a G che poi fa calcolare la fisica..) ecc, ecc, le api console tagliano tutti quei processi superflui (e legati anche al come funziona il kernel di windows).

Quello che AMD ha fatto con Mantle è stato molto semplice. Abbiamo una serie di schede video (GCN based) che hanno tutte la stessa architettura, funzionano tutte nello stesso modo, perchè non facciamo un api che tagli tutti quei processi superflui e poco performanti?
In particolare DX11 rimanda spesso nella generazione di un singolo frame informazioni da e alla cpu prima di ricalcolarle, tagliamo questi passaggi. E difatti Mantle ha mostrato perfomance superiori a DX11 soprattutto in situazioni cpu limited.

C'è un motivo se le console, si anche quelle di questa generazione, hanno sempre prestazioni superiori a pc di configurazione simile (e se mi tirate fuori il fatto che una 7850/70 vanno come o più di una ps4, neanche vero, accoppiatemi pure queste schede non con un i5/i7 come nei benchmark ma con un processore con architettura da tablet che consuma praticamente nulla) e questo è dato dalle api e il kernel delle console che sono per forza di cose più performanti (senza contare che queste console hanno un processore a parte basato su architettura ARM per l'os).

Tra l'altro dalle slide di 3DMark DX12 e Mantle sembrano avere pressochè le stesse prestazioni.

E a chi dice che DX12 non scimmiotta Mantle (il che non è un idea sbagliata, ma è ovvio che è Mantle che ha scosso il tutto) ricorderei che la stessa Microsoft annunciava giusto un anno fa che non si sarebbero viste altre Directx per eoni.

E' chiaro come il kernel di windows e le directx abbiano tenuto dietro prestazionalmente l'hardware che compravamo.

Perchè Mantle è stato abbandonato? Perchè è ridondante nel momento in cui DX12 avrà pressochè le stesse prestazioni (o probabilmente, di molto poco inferiori) con tutte le schede e non sarà più esclusiva di GCN. Permette sia ad AMD di cambiare architettura che di smettere di investirci danaro. Anche perchè a dicembre 2014 schede video GCN rappresentavano l'11 % della base installata su pc e i giochi Mantle una frazione ancor più limitata.

Ultima cosa. Ora Microsoft millanta di "upgradare" Xbox One a DX12 il che è una pura idiozia. Ingegneri Microsoft dicono che l'api di Xbox One non sfrutta appieno le memorie ESRAM il che significa che non l'hanno scritta bene, e cambiarla con la generica api (per quanto possa essere di livello più basso di quella DX 11) DX 12. Marketing, nient'altro. Gli stessi ingegneri poi che hanno concepito una console con tre sistemi operativi.

Ma quindi vuol dire che neanche xbox fa uso delle directX ed usa una libreria a parte specifica solo per lei? E idem quindi ps4?
E che quindi le DX12 sono legate a doppio filo solo ed esclusivamente con windows non per ragione di proprietà e marketing ma proprio per come sono programmate?

Da quello che si legge PS4 usa un OS denominato Orbis OS, una versione modificata del FreeBSD 9.0.

Ma quindi vuol dire che neanche xbox fa uso delle directX ed usa una libreria a parte specifica solo per lei? E idem quindi ps4?
E che quindi le DX12 sono legate a doppio filo solo ed esclusivamente con windows non per ragione di proprietà e marketing ma proprio per come sono programmate?

Le api altro non sono che set di istruzioni, strumenti specifici che indicano al programma come interagire con la macchina.

Api di alto livello sono per avere set di istruzioni generici, sono più lente e meno efficienti quindi di api di basso livello che invece sono più vicine al linguaggio della macchina.

Detto in altri termini, ad esempio, il computer non comprende il C++ sono le api che convertono ciò che il programmatore scrive in linguaggio macchina, una serie di 1 e 0.

Le api delle console vengono sviluppate in fase di progettazione da gente che di computer ci capisce a livelli molto più elevati del nostro (se concepire una di quelle scatolette costa miliardi, un motivo ci sarà :asd: ), e vengono scritte in un livello più basso (e corretto) possibile.

AMD, avendo sviluppato l'hardware di entrambe le console e avendo ovviamente collaborato anche nella realizzazione delle api si è detta "alcune di queste soluzioni che utilizzano le console potrebbero essere usate anche nel mondo pc?".

In particolare, uno dei problemi maggiori era quello delle draw call, tradotto in italiano "chiamate di disegno" o "chiamate di attinzione".

Le gpu moderne lavorano a velocità estremamente superiori a quelle delle cpu e hanno relativamente meno compiti (difatti in genere spendiamo molto più per le gpu che per i nostri processori).

Questo significa che ogni qualvolta che la cpu deve richiedere alla gpu di disegnare dei triangoli e processarli può farlo in due maniere differenti:

-o richiede un numero basso di triangolo, ma la cpu e la gpu comunicano in fretta, ma in quel caso sei limitato dalla velocità di comunicazione

-o richiedere un numero elevato di triangoli, ma in quel caso la gpu è limitata dal tempo che ci mette la cpu a riempire il buffer

Poichè le gpu, come detto precedentemente, sono estremamente più veloci nel disegnare i triangoli di quanto le cpu siano nel richiedergli di farlo fondamentalmente non c'è grande differenza fra il richiedere alla gpu di disegnare 2 o 200 triangoli, quindi la cosidetta "ottimizzazione" passa attraverso il sapere quante devono essere queste draw calls, (anche perchè ognuna di queste combinazioni di triangoli forma una mesh e il risultato finale è dato da migliaia o milioni di mesh differenti).

DirectX, un api ad alto livello e generica non gestiva le draw calls nella maniera più efficiente possibile, ma la più generica possibile.

Nel momento in cui restringi il campo di hardware ed architetture possibili, tutti questi elementi generici possono essere soppressi e si possono avere librerie che saltano passaggi.

Ora, questi sono argomenti troppo complessi per me per essere capiti appieno e figuriamoci per essere spiegati, ma fondamentalmente dire che Xbox One verrà upgradata a DX 12 significa dire che l'api della xbox one è stata scritta male. Microsoft millanta un utilizzo delle esram inferiore a quello possibile con api migliori, possibile, ma significa in ogni caso che queste api son state scritte male.

DX 12 verrà probabilmente scritta "meglio" delle versioni precedenti in maniera di sfruttare meglio l'hardware disponibile (compatibile con questa libreria), ridurre il numero di processi, di draw call, ed ottimizzare l'utilizzo delle cpu per eliminare problemi di buffer e comunicazione fra cpu e gpu.

Ma il collegamento con xbox one, mi sfugge. Non credo che con le centinaia di programmatori e hardware designer che hanno concepito xbox one siano andati ad utilizzare soluzioni che poi non avevano idea di come sfruttare.

Ma da povero umano, questi sono concetti che vanno oltre le mie limitate conocenze.

Le api altro non sono che set di istruzioni, strumenti specifici che indicano al programma come interagire con la macchina.

Api di alto livello sono per avere set di istruzioni generici, sono più lente e meno efficienti quindi di api di basso livello che invece sono più vicine al linguaggio della macchina.

Detto in altri termini, ad esempio, il computer non comprende il C++ sono le api che convertono ciò che il programmatore scrive in linguaggio macchina, una serie di 1 e 0.

Le api delle console vengono sviluppate in fase di progettazione da gente che di computer ci capisce a livelli molto più elevati del nostro (se concepire una di quelle scatolette costa miliardi, un motivo ci sarà :asd: ), e vengono scritte in un livello più basso (e corretto) possibile.

AMD, avendo sviluppato l'hardware di entrambe le console e avendo ovviamente collaborato anche nella realizzazione delle api si è detta "alcune di queste soluzioni che utilizzano le console potrebbero essere usate anche nel mondo pc?".

In particolare, uno dei problemi maggiori era quello delle draw call, tradotto in italiano "chiamate di disegno" o "chiamate di attinzione".

Le gpu moderne lavorano a velocità estremamente superiori a quelle delle cpu e hanno relativamente meno compiti (difatti in genere spendiamo molto più per le gpu che per i nostri processori).

Questo significa che ogni qualvolta che la cpu deve richiedere alla gpu di disegnare dei triangoli e processarli può farlo in due maniere differenti:

-o richiede un numero basso di triangolo, ma la cpu e la gpu comunicano in fretta, ma in quel caso sei limitato dalla velocità di comunicazione

-o richiedere un numero elevato di triangoli, ma in quel caso la gpu è limitata dal tempo che ci mette la cpu a riempire il buffer

Poichè le gpu, come detto precedentemente, sono estremamente più veloci nel disegnare i triangoli di quanto le cpu siano nel richiedergli di farlo fondamentalmente non c'è grande differenza fra il richiedere alla gpu di disegnare 2 o 200 triangoli, quindi la cosidetta "ottimizzazione" passa attraverso il sapere quante devono essere queste draw calls, (anche perchè ognuna di queste combinazioni di triangoli forma una mesh e il risultato finale è dato da migliaia o milioni di mesh differenti).

DirectX, un api ad alto livello e generica non gestiva le draw calls nella maniera più efficiente possibile, ma la più generica possibile.

Nel momento in cui restringi il campo di hardware ed architetture possibili, tutti questi elementi generici possono essere soppressi e si possono avere librerie che saltano passaggi.

Ora, questi sono argomenti troppo complessi per me per essere capiti appieno e figuriamoci per essere spiegati, ma fondamentalmente dire che Xbox One verrà upgradata a DX 12 significa dire che l'api della xbox one è stata scritta male. Microsoft millanta un utilizzo delle esram inferiore a quello possibile con api migliori, possibile, ma significa in ogni caso che queste api son state scritte male.

DX 12 verrà probabilmente scritta "meglio" delle versioni precedenti in maniera di sfruttare meglio l'hardware disponibile (compatibile con questa libreria), ridurre il numero di processi, di draw call, ed ottimizzare l'utilizzo delle cpu per eliminare problemi di buffer e comunicazione fra cpu e gpu.

Ma il collegamento con xbox one, mi sfugge. Non credo che con le centinaia di programmatori e hardware designer che hanno concepito xbox one siano andati ad utilizzare soluzioni che poi non avevano idea di come sfruttare.

Ma da povero umano, questi sono concetti che vanno oltre le mie limitate conocenze.

Se sono oltre le tue limitate conoscenze , perché parli ,anzi scrivi?. addirittura un poema di cose di congettura :doh: .

Se sono oltre le tue limitate conoscenze , perché parli ,anzi scrivi?. addirittura un poema di cose di congettura :doh: .

non c'è alcuna congettura. ciò che t'ho scritto è una versione semplificata ma corretta del nocciolo della questione.

tempo fa su questo sito scrivevano persone con un minimo di conoscenza e buon senso, oggi sono rimasti solo i bimbiminkia.

Che lavorino basandosi sugli stessi principi e obiettivi siamo d'accordo.. ma che DX12 sia venuto fuori da mantle proprio lo escluderei.

Una libreria del genere non salta mica fuori in una settimana, probabilmente ci stanno smanettando su da ANNI. Non è che hanno visto mantle e sono corsi a fare le DX12.
infatti le dx12 non sono ancora disponibili.
Mentre le caratteristiche che richiederanno nuovo hardware erano previste già per le future dx11.3.
Smanettare da anni. Non scherziamo. Pensate davvero che AMD abbia più risorse di MS? :rolleyes:


Nè Xbox One nè PS4 usano api basate su Mantle o Directx.
La forza di Mantle era proprio la forte somiglianza con le librerie di basso di livello delle console. Suppongo che Mantle non sia altro che un adattamento delle openGL di ps4.


più probabile che mantle abbia cercato di anticipare dx12 scimmiottando le feature delle dx12
è cosi innovativo mantle che l'amd ha deciso di bloccarlo come progetto ....
UFFICIALMENTE Vulkan eredita il codice sorgente di Mantle.
Sempre UFFICIALMENTE, Mantle resterà una beta in perenne evoluzione.

A me pare chiaro che MS DOVEVA NECESSARIAMENTE far uscire le DX12 per contrastare VULKAN-MANTLE.