DOOM: molto più fluido sulle GPU AMD grazie alle API Vulkan

13 Luglio 2016 229

Se seguite il mondo del PC Gaming, saprete di sicuro che l'ultimo e tanto atteso aggiornamento rilasciato da Bethesda per DOOM, permette tra le altre cose di poter sfruttare le API Vulkan. Per chi ancora non ne avesse sentito parlare, le Vulkan sono librerie a basso livello, presentate lo scorso anno da Khronos Group e caratterizzate da un approccio open source e multipiattaforma.

Detto questo, a trarre beneficio da questo aggiornamento su DOOM sembrano essere soprattutto le schede grafiche AMD. Stando infatti ai primi benchmark, il passaggio da Open GL a Vulkan porterebbe una scheda come la Radeon R9 Fury X a un incremento del framerate pari al 52%.

Nel grafico che riportiamo a seguire, troviamo la Radeon R9 Fury X rapportata alla potente GeForce GTX 1070; la cosa che salta all'occhio è che in Open GL la scheda AMD è il 15% più lenta dell'avversaria, mentre quando si passa alle API Vulkan risulta il 25% più veloce.

Questo test, che sottolinea il miglioramento ottenuto con questo update, mostra ancora una volta come spesso le performance delle schede grafiche siano molto condizionate dal supporto software.


Il perfetto compagno nella fascia media? Redmi Note 9 Pro, in offerta oggi da Emarevolution a 208 euro oppure da Amazon a 269 euro.

229

Commenti

Regolamento Commentando dichiaro di aver letto il regolamento e di essere a conoscenza delle informazioni e norme che regolano le discussioni sul sito. Clicca per info.
Caricamento in corso. Per commentare attendere...
smn_lrt

Hai appena detto "i calcoli vettoriali sono pieni di matrici, cioè di calcoli matriciali"...cosa sei in seconda superiore liceo classico?
Hai detto più o meno una cosa del tipo "una ruota ha 4 automobili"...chissa che risate si farà chi legge!!

shoot3r

mi risp da solo..si parla di vulkan okkkkkkk

shoot3r

scusate ma io non capisco .io avevo una 980ti g1 gaming su monitor 2k e settando tutto a manetta sia da gmae che da pannello nvidia giocapo tra i 130 144fps .poi con i nuovi driver giocavo a 140-144fps..perciò questi grafici dove l han presi?

Nigellus Blake

Pls ragazzi informatevi.
Comunque, la ragione del guadagno cosi marcato con le cpu amd sta proprio nel modo in cui funzionano vulkan/dx12. Sono api di basso livello, fatti in modo di poter lavorare il più vicino possibile a livello hw. Questo si sapeva, un'altro punto importante però, è il fatto che queste api riducono tanto l'overhead delle cpu. Riducendo quest'ultimo le gpu possono esprimere tutto il loro potenziale. Un esempio di questo si è visto con battlefield 3 e l'implementazione di mantle. Si è visto come una fx 6300 raggiungeva un i5/i7 e altre cpu con basso ipc.
Opencl alla fine opera come dx 11. Il fatto che sia open non centra niente.
E smettetela di dire che se è vulkan è "amd optimized", non esiste, proprio perché vulkan non è di amd, è open. Qui il discorso è semplicemente di librerie supportate e architetture hw concepiti in modo diverso. Un semplice paragone è quando siamo passati dai processori single core spinti a 4ghz ai dual core a 1.5/2ghz.

Juanito82

Vulkan É l'evoluzione di opengl

Simone Dalmonte

A meno che tu nn abbia, programmi aziendali, periferiche che nn aggiornano i driver per la compatibilità o altre cose particolari, con 10 avrai solo vantaggi, ad esempio boost boot dell OS e gestione della RAM netamente migliorata, e questi erano miglioramenti tangibili che ti dava già W8/8.1

Biggy866

mi sembra la stessa cosa quando tutti quelli che avevano xp volevano le dx10 e 11

" Questo piccolo thread è dedicato a tutti coloro che si pongono la domanda:

"Le librerire DirectX 10 possono essere sfruttate sull'OS Windows XP?"

La risposta è semplice: dal punto di vista tecnico, è possibile; dal punto di vista di marketing, tempistiche e risorse finanziarie, assolutamente no. "

ric

Facile insultare da dietro una tastiera ...sei un pagliaccio vorrei vedere di persona cosa fai buffone

smn_lrt

Perché hai screditato tizio quando di fondo il suo ragionamento era giusto al di là dei termini..
Per i vettori cerca su Wiki gcn in inglese e ottieni questo come descrizione dei CU..."Each Compute Unit consists of a CU Scheduler, a Branch & Message Unit, 4 SIMD Vector Units (each 16-lane wide)"
I calcoli che fa sono vettoriali perché sono unitá vettoriali...che poi li lanci roba matriciale a livello di sorgente comunque lui arrangia in vettori in esecuzione...
Il context switching (gli switch contexts??) non l'ho nominato ma è implicito in quello che ho detto...coi numeri che hanno dato per la preemption in Pascal(100uSec)...non è più un problema che c'era con Maxwell (come ho scritto) è porta Pascal allo stesso livello di gcn...
Per cambiare contesto per la CU o gli SM senza interrompere quello in esecuzione quindi aspettando che finisca per allocare ad altro compito è uguale...anche gcn deve aspettare di finire quindi svuotare il buffer nelle CU prima di cambiare contesto...

NatNev

amd ha ritenuto conveniente renderlo open. ha aperto la sua creazione.

hassunnuttixe

non vedo quale parte della pappardella (che tra l'altro tralascia cose tipo gli switch contexts, uno degli elementi chiave dell'Async Compute) che hai scritto mi contraddica:
1- dire "thread" su una GPU ha senso solo se in modalità GPGPU, no in modalità grafica
2- in pratica non esistono carichi mono-thread su una GPU

Tralascio di risponderti la parte sul calcolo matriciale perchè non hai neanche capito quello che ho detto e perchè quello che hai scritto non ha un senso.

Ser Davos

Si ma è open

NatNev

visto l'andazzo prestazionale con vulkan e dx12 meglio un fx8320-8350 da occare un po'.

NatNev

nvidia in prospettiva è sempre una incool-8

NatNev

sei un poveraccio

NatNev

vulkan esiste solo grazie a MANTLE quindi grazie ad AMD. il resto è venuto dopo e si è accodato.

smn_lrt

?il termine thread esiste anche per la gpu (shader su amd, thread su Nvidia)?
Quello che mi è nuovo è che l'async compute serve a fare i calcoli matriciali (che poi sono vettoriali perché non ci sono unitá matriciali ma vettoriali a con 16 unitá...per un calcolo matriciale usi n calcoli vettoriali ma sono vettoriali, in matenatica sono matriciali)...
tra un po cammina sulle acque come il Messia questo async compute...
Serve a saturare meglio la gpu punto e fine...Non esegue più calcoli in parallelo su una risorsa che ne accetta uno per volta...sono tutti stack che fanno come da buffer interoperazionali in produzione...quando ci sono risorse libere lancio shader (o gruppi di questi)...mi spiego meglio...dalle slide AMD nel loro sito ti fanno vedere l'autostrada con segnali di colore diverso in parallelo, quello è lo stato in coda non l'esecuzione...ne vedi di più in parallelo perché hanno usato più di una coda per tenere i dati in coda (dati nella stessa coda = serie)...
comunque se due operazioni sono legate dalla casualità: il risultato di una è l'input della seconda allora non possono per logica essere fatte in parallelo quindi sono nella stessa coda in serie....le code si possono parallele tra di loro ma comunque i programmi poi utilizzeranno le risorse che ci sono non ne inventano di nuove...e anche nelle code ci sono dei limiti sul numero di code e di elementi per ciascuna coda...

Non crea risorse dal nulla, satura meglio la GPU...quando tizio sopra diceva è più veloce con 1200 thread...intendeva che forse 1200 thread, che possono in buona parte essere parallelizzati, se li lasciamo schedulare alla GPU il gcn satura meglio...che poi dipende perché han visto che da maxwell in poi non cambia niente...l'unico tipo di carico che da fastidio a maxwell è se li diamo lavoro di geometria misto a lavoro di texture in percentuali variabili nel tempo (perché è costretto a cambiare gli SM assegnati a geometria con texture o viceversa e lì svuota da quello che c'è per caricare altro fermando l'esecuzione così l'esecuzione : da qui le perdite di efficienza e i frame rate che calano su AOS)...cosa che con Pascal non si verifica perché interrompe il lavoro lo lascia in cache e/o lo alloca ad altre risorse (ci hanno anche provato non rallenta)....perché hanno implementato il dynamic load balancing in hardware (perché in Cuda esisteva già da Fermi queste opzione: un thread ne poteva lanciare altri..ma va ben) che fa lo switch per bilanciare le risorse in automatico...
Pecca di Nvidia: non ci sono tante code come su amd qquidni ci si aspetta che sia saturato peggio...
Pecca di Amd: una volta passato dagli ACE alle CU il programma può essere riscedulato solo all'interno delle CU...quindi c'è una stima di quanto una serie di istruzioni starà in esecuzione fatta dall'ACE...stima che non è il tempo effettivo...una volta assegnato alla CU questa può riallocarlo solo all'interno della CU stessa...e ancora non si sceglie l'elemento in coda con regole di ottimizzazione, quando c'è qualcosa di libero vai, l'ottimizzazione avviene perché i carichi son piccoli e c'è un altro buffer dentro alle CU....mentre su Nvidia con la preemption + load balancing si può riallocare tra diversi SM...

franky29

Ecco cosa significa ottimizzare il software viva vulkan!

NaXter24R

Il problema è che fare due cose assieme non gli riesce particolarmente bene. AMD invece ha delle unità ferme che puo usare quando vuole. Comunque 8 ace non vuol dire x8, vuol dire che alcune cose le puoi scaricare li, ma non tutto

Roman Pierce

Girava, ma solo perché il gioco non era compatibile con async compute, qualche giorno fa invece è uscita la patch che porta AC, quindi immagino tu sappia cosa vuol dire.

Sì mi è chiaro. Però pur avendo 8 ACE non è 8 volte più veloce. Se disattivi l'Async infatti sei più lento "solo" del 30%.
Non ti so dire perché NVidia non usa questo sistema... Alcuni dicono che c'è ma è disattivato. Altri dicono che porta altri problemi con sé... Boh!
Ma anche se NVidia ne ha uno solo per il computing, questo può prendere la prossima istruzione mentre è all'opera con quello attuale per come ho capito, quindi bene o male non dovrebbe essere tanto penalizzato.

Ma non avevi detto che Tomb Raider gira meglio su NVidia?

NaXter24R

Appunto. Quel che volevo dire era che il problema non era tanto nell'x86, prendi la licenza (Intel e AMD non son le uniche) e fai quel che devi fare, ma non ne hanno mai fatta una e partire così, di botto, con una console non è il massimo

NaXter24R

No, Nvidia non andrà mai meglio su questa funzione, a meno che non cambino qualcosa a livello hw.
Te la faccio semplice, hai presente la tassellazione? Ecco, Kepler, Maxwell e Pascal hanno più unità di AMD dedicate alla tassellazione.
In questo caso invece, AMD ha le ACE, che Nvidia non ha, questo permette ad AMD di fare contemporaneamente sia la grafica che il computing, infatti queste unità rimangono ferme se non utilizzate e sono sganciate dal resto, possono lavorare parallelamente senza problemi, un po come il decoder video (Nvenc per Nvidia e VCE per AMD).
Nvidia deve quindi contare sulla CPU per alcune cose e poi deve fare in modo di avere uno scheduler che sappia il fatto suo.
Tradotto, AMD fa come le pare, ogni unità nella GPU si fa i fatti suoi e puo operare indipendentemente dall'altra.
Nvidia invece deve poter organizzare il tutto perchè non ha unità dedicate. Puoi farcela, ma non avrai mai lo stesso aumento prestazionale

Roman Pierce

Non dico che NVidia sia migliore o peggiore, dico che usa un approccio diverso e che in alcuni casi può risultare migliore mentre in altri peggiore.

In Vulkan/DX12 fin'ora non ho visto nemmeno un gioco in cui Nvidia risulta migliore di AMD. Questo è l'argomento o mi sbaglio? Se poi intendevi in dx11 allora sei OT.

Quando AMD o NVidia rilasciano un driver appositamente per un gioco, RICORDATI!!!, non è mai per ottimizzare la scheda ma SEMPRE per correggere gli errori dei programmatori di giochi! Ci sono vari articoli a riguardo... Quando Ubisoft non segue le linee guida delle API o si dimentica di chiudere il collegamento per il caricamento di immagini ad una scheda, questo provoca rallentamenti dovuti all'errore del programmatore. Poi magari AMD riesce a gestirlo e NVidia no, quindi NVidia rilascia un driver che "cracka" il gioco affinché l'errore di Ubisoft venga corretto.

Che centra questo ora? Anche qui sei OT.

Monto una NVidia HD 5700 ;)
Gli sviluppatori di Doom usano le schede ATI al momento per sviluppare e si vede, non dire il contrario che sai bene che non è così.
Non dico che NVidia sia migliore o peggiore, dico che usa un approccio diverso e che in alcuni casi può risultare migliore mentre in altri peggiore.
Quando AMD o NVidia rilasciano un driver appositamente per un gioco, RICORDATI!!!, non è mai per ottimizzare la scheda ma SEMPRE per correggere gli errori dei programmatori di giochi! Ci sono vari articoli a riguardo... Quando Ubisoft non segue le linee guida delle API o si dimentica di chiudere il collegamento per il caricamento di immagini ad una scheda, questo provoca rallentamenti dovuti all'errore del programmatore. Poi magari AMD riesce a gestirlo e NVidia no, quindi NVidia rilascia un driver che "cracka" il gioco affinché l'errore di Ubisoft venga corretto.

smn_lrt

??AC serve ai calcoli matriciali??

stiga holmen

"DX12 é da una parte API (quelle definite da Microsoft) e da una parte HW (implementate da NVidia, AMD, Intel). Microsoft indica cosa una scheda grafica deve poter fare e i produttori per poter applicare l'etichetta DX12 devono supportare le funzionalità descritte da MS"

Stiamo parlando della stessa cosa...i produttori supportano meglio le API DX di MS che le altre.....per supportare le DX devono scrivere buoni driver che dicano al pezzo HW cosa fare una volta ricevuta la chiamata API...
L'HW di per se esegue solo istruzioni a basso livello, non sa se sta disegnando una linea o una superficie... è compito delle API/driver gestire le informazioni giuste e chiedere all'HW di eseguire il lavoro sporco...

Roman Pierce

Ma che stai a dire? DOOM fatto per AMD? Caro, vedi che DOOM fino a poco tempo fa andava con AMD su OpenGL 4.3 mentre con Nvidia su OpenGL 4.5. Poi anche le prestazioni sempre in DOOM erano a favore di Nvidia. Ora che esce Vulkan e Amd giustamente pisci@ in testa ad Nvidia te ne esci con Warframe, LOL. Non so se sei serio o stai trollando. Cioè, ricapitolando tu metti sullo stesso piano DOOM (un gioco molto atteso da tutti i videogiocatori che sta avendo buonissime vendite su PC ed è acclamato dalla critica) con Warframe(Un f2p vecchio di qualche anno)?

Che poi a dirla tutta proprio in Warframe AMD è sopra ad Nvidia, Lo era gia ai tempi di kepler vs CGN 1.0, figurati ora.

Comunque aspettati gli stessi risultati in Rises of Tomb Rider, che in ultima patch ha aggiunto il supporto all'Async compute.

Sì ho capito! Ma parliamo sempre ancora di Doom fatto per AMD! Se prendi i benchmark di Warframe (fatto per NVidia) allora vince NVidia.

Roman Pierce

Il fatto è che Amd guadagna e pure tanto, sia in Vulkan che in DX12. Nvidia invece in molti giochi perde addirittura le prestazioni, quando guadagna è pochissimo. Se Nvidia avesse questa feature implementata via HW come fa Amd non avrebbe queste prestazioni.

Efficienza non posso dire niente, non so cosa entra in gioco per quella...

Lascia stare cosa entra in gioco, se guardiamo prestazioni/watt Amd è sopra in Vulkan e DX12, qualcosa vorrà pur dire.

Guarda il grafico, una r7 370 (7870) da la paga ad una 780TI, una 7950 che eguaglia una gtx 960, non so se mi spiego.

RX 480: OpenGL 65 min, 83 AVG. Vulkan 91 min, 110 avg.
GTX 970: OpenGL 74min, 92 AVG. Vulkan 76 min, 88 avg.

Roman Pierce

La licenza la prendi
La licenza non la prendi, è diverso. Poi mettiamo anche che Nvidia riesca a prendere la licenza per progettare una cpu x86, non ha il know how. I tegra sono dei semplici arm (cortex a9) con gpu nvidia, niente di che.

Che io sappia, NVidia non emula... Usa un metodo completamente diverso! AMD divide l'esecuzione di un shader su 2/8 processori contemporaneamente, mentre NVidia ne utilizza solo 1 alla volta (non emula e non usa un secondo processore via software).
Questo non vuol dire che dei migliaia cores, una volta eseguito un comando, il core non faccia più niente. E' questo che differenzia AMD da NVidia. AMD perde tempo per dividere l'istruzione su 8 per completare il comando. NVidia avendo ne ha 2 e a dipendenza del comando ne usa uno o l'altro. Ma non emula niente, per fare cosa? uno shader non puoi emularlo a livello software senza perdere il 99% del framerate.
Non ti so dire se ci sono giochi in cui una NVidia possa funzionare meglio rispetto al sistema di AMD, ma adottano sistemi diversi per svolgere lo stesso compito.
Efficienza non posso dire niente, non so cosa entra in gioco per quella...

Roman Pierce

Amd ha async compute nell'architettura a partire da GCN 1.0 (2011), Nvidia No, Nvidia emula calcoli asinchroni e lo fa grazie ai driver. Cosa c'è di non chiaro? Sto forse sbagliando? Illuminami.

Per quanto riguarda l'efficienza, sei d'accordo che amd è in vantaggio in Vulkan/dx12? Visto che non hai risposto.

NaXter24R

La licenza la prendi, è che Nvidia lato GPU, non gli si puo dire nulla, lato CPU gli si puo dire tanto, vedi i Tegra, sulla carta bellissimi, meno all'atto pratico.
Inoltre sia Sony che MS hanno offerto pochissimo, tanto che AMD ci è andata in perdita per un anno, ma ha guadagnato gli sviluppatori e le nuove console

NaXter24R

Sport. Perchè vai a sballare anche altre cose oltre alla CPU

NaXter24R

Correggo xD

no, non software... sarebbe impossibile e avresti prestazioni da 1% rispetto alla versione HW! Parli di librerie o async? Async è il termine usato per dire che i core della scheda grafica sono in grado di lavorare contemporaneamente per elaborare i dati dei shaders.

Roman Pierce

Già, una via HW e l'altra Via SW. Cogli le differenze?
E' un dato oggettivo che in dx12 e vulkan prestazioni/watt amd è sopra.

NVidia esegue però in parallelo, quindi la teoria del consumo regge fino ad un certo punto... Tutti e 2 usano il termine "asyncrono" nei loro dati tecnici.

Roman Pierce

Non c'è niente di strano nel vantaggio di Amd in Vulkan e dx12. Semplicemente Amd ha l'async compute implementato via HW nell'architettura da GCN in poi, Nvidia no. Ecco che torna anche perché Amd consuma di più, ha un architettura più completa, nelle nuove api infatti l'efficienza prestazioni/watt è a favore di Amd.

Roman Pierce

Più che altro non si tratta di soldi. Amd sviluppa anche le cpu ed è riuscita a fare delle apu molto bilanciate per le console. Nvidia dal canto suo non ha la licenza per produrre cpu x86 quindi la scelta è andata su amd per ovvie ragioni.

Continui a fare una confusione bestiale! Confondi, API da drivers e persino API da schede video!
Come posso spiegartelo in modo semplice?
1. Scrivi un gioco
2. Il gioco usa delle API (NON drivers e non la scheda grafica)
3. Le API inoltrano le funzionalità richieste al driver
4. Il driver le inoltra alla scheda grafica
5. La scheda grafica esegue il comando
DX12 é da una parte API (quelle definite da Microsoft) e da una parte HW (implementate da NVidia, AMD, Intel). Microsoft indica cosa una scheda grafica deve poter fare e i produttori per poter applicare l'etichetta DX12 devono supportare le funzionalità descritte da MS.
Vulkan, che al momento é più caotico di DX7 fa la stessa cosa! Con il vantaggio che i produttori di schede grafiche possono usare le funzionalità di DX nella parte hardware e Vulkan per le API.
Ma tu ancora sei convinto che un driver possa essere ottimizzato... Quando in realtà é solo una interfaccia!

Alexv

Ci mancherebbe.

stiga holmen

...appunto...se i produttori di schede video non scrivono bene i loro driver, le API che chiami verranno eseguite male....
Non capisco dove vuoi arrivare.

Morale della favola: le DX 12 battono gli altri perché i produttori di schede video hanno finora supportato maggiormente quelle...con le Vulkan forse ci sarà più battaglia vista la maggior propensione a supportarle...

Il nabbo di turno

Windows 10 è meglio di windows 10, questo è sicuro xD.

Giovanni Morelli

Scusa il disturbo, cosa ne pensi dell' overclock su processori skylake non k?

Diego Paolini

infatti sino alla beta girava su opengl 4.5 poi non so xche al rilascio siano andati per il 4.3

Hai letto male il documento di Wikipedia... rileggi ;)
Il driver non é nient'altro che l'interfaccia tra hardware e software. Le API "virtualizzano" l'interfaccia affinché tu possa usare le stesse funzioni su qualsiasi scheda grafica. DX9, 10, 11 e 12 hanno delle funzioni ben definite che tu come programmatore puoi usare (così come anche con Vulcan). Il driver non fa nient'altro che inoltrare le tue richieste (fatte tramite API) alla scheda grafica. Il driver NON esegue niente, é solo una interfaccia.

stiga holmen

"All'interno di questa applicazione ci sono delle direttive definite dalle API. Tipo "carica immagine", "disegna immagine", "ruota immagine"..Queste direttive vengono inviate alla scheda grafica la quale poi esegue queste funzioni a livello hardware."

Ecco, questi sono i driver per DX scritti dai produttori di schede video...se vengono scritti alla razzo di cane avranno prestazioni penose allo stesso modo..

Apple annuncia i processori proprietari per Mac basati su architettura ARM

PlayStation 5 ufficiale: due versioni, design grintoso e futuristico | Caratteristiche

Recensione Honor MagicBook, al pari di MateBook D14 ma costa meno!

La (mia) postazione da Rog Fan: dallo Smartphone al PC fino allo Zaino | Video